Kryptographie - Identitätsprüfung, Teil 4 - Zertifikate in SSL/TLS
In dieser Folge wird der Einsatz von X.509-Zertifikaten im Rahmen von SSL/TLS beschrieben. Etwas allgemeiner habe ich das ja schon im Rahmen der Beschreibung von MitM-Angriffen auf HTTS-Verbindungen erklärt.
Die ausgetauschten Nachrichten im Überblick
Folgende Nachrichten werden während des SSL/TLS-Handshakes ausgetauscht:
Client | Server | |
---|---|---|
------- 'ClientHello' ------> |
||
| ||
<------- 'ServerHello' ------ |
||
<----- X.509-Zertifikat ----- |
||
<---- 'ServerHelloDone' ----- |
||
|
||
-- RSA(Pre-Master-Secret) --> |
||
|
|
|
<-- Sichere Kommunikation --> |
Der Handshake
Mit der 'ClientHello'-Nachricht sendet der Client folgende Informationen an den Server:
- Version:
Die höchste SSL/TLS-Version, die der Client versteht. - Random:
Ein vom Client gewählter Zufallswert, gebildet aus einem Zeitstempel und einer Zufallszahl. Er verhindert Replay-Angriffe während des Schlüsselaustauschs. - SessionID:
Eine Sitzungskennung, um verschiedene Verbindungen/Sitzungen zu unterscheiden. - CipherSuite:
Eine Liste der vom Client unterstützten Verschlüsselungsalgorithmen, sortiert nach abnehmender Bedeutung. Jeder Eintrag enthält eine Methode zum Schlüsselaustausch und die so genannte CipherSpec mit Angaben über Verschlüsselungs- und MAC-Algorithmen, über Strom- oder Blockchiffre und Informationen für die Verschlüsselung und MAC-Berechnung. - Compression Method:
Eine Liste der vom Client unterstützten Komprimierungsalgorithmen.
Die vom Server als Antwort gesendete 'ServerHello'-Nachricht enthält folgende Informationen:
- Version:
Die höchste SSL/TLS-Version, die sowohl Client als auch Server verstehen. - Random:
Ein von Server gewählter Zufallswert, gebildet aus einem Zeitstempel und einer Zufallszahl. Der Wert ist unabhängig von dem vom Client gesendeten Random-Wert. - SessionID:
Beim Start einer neuen Sitzung die vom Server vergebene ID, sonst die vom Client gelieferte ID der bestehenden Sitzung. - CipherSuite:
Enthält den vom Server aus der Liste des Clients gewählten Verschlüsselungsalgorithmus. Dies kann je nach Präferenz zum Beispiel der stärkste oder schnellste der möglichen Algorithmen sein. - Compression Method:
Enthält den vom Server aus der Liste des Clients gewählten Komprimierungsalgorithmus.
Der Server sendet nach der 'ServerHello'-Nachricht sein Zertifikat (oder ggf. auch mehrere) in einer Zertifizierungsnachricht an den Client und signalisiert danach durch eine 'ServerHelloDone'-Nachricht, dass er fertig ist. Danach beginnen die Server-Authentifizierung und der Schüsselaustausch.
Server-Authentifizierung (Prüfung des Zertifikats)
Der Client muss nun das X.509-Zertifikat prüfen. X.509-Zertifikate sind immer an einen "Distinguished Name" oder "Alternative Name", zum Beispiel eine E-Mail-Adresse oder einen DNS-Eintrag, gebunden. Im Fall von HTTPS ist zum Beispiel immer der Domainname des Servers relevant, bei der Authentifizierung einer E-Mail die E-Mail-Adresse.
Die Systeme und/oder Webbrowser enthalten eine vorkonfigurierte Liste vertrauenswürdiger CAs, Den davon ausgestellten Zertifikaten vertrauen die Browser dadurch automatisch. Kann der Browser das Zertifikat nicht selbst verifizieren, fragt er beim Benutzer nach.
Dieser kann dem Zertifikat dann (zweckmäßigerweise nach einer gründlichen Prüfung) einmalig oder auf Dauer sein Vertrauen aussprechen oder die Verbindung abbrechen. Bei Bedarf kann ein vom Browser akzeptiertes Zertifikat auch zusätzlich vom Benutzer geprüft und dessen Fingerprint mit einem auf sicheren Weg erhaltenen Vergleichswert verglichen werden.
Seit SSL-Version 3.0 kann der Server zusätzlich seinerseits vom Client ein Zertifikat anfordern. Da diese Möglichkeit sehr selten eingesetzt wird, soll hier nicht weiter darauf eingegangen werden.
Schüsselaustausch
Nachdem das Zertifikat erfolgreich geprüft wurde, beginnt der Austausch der Schlüssel für die symmetrische Verschlüsselung. Dies soll hier beispielsweise mit RSA geschehen.
Der Client erzeugt eine neue sichere, d.h. nicht vorhersagbare, Zufallszahl, das so genannte Pre-Master-Secret. Dieses wird mit dem öffentlichen Schlüssel des Servers aus dem Zertifikat verschlüsselt und an den Server gesendet. Dieser kann es als einziger mit seinem privaten Schlüssel entschlüsseln und beweist dadurch seine Authentizität.
Sowohl Client als auch Server können dann aus dem Pre-Master-Secret und den beiden Random-Werten aus den 'ClientHello'- und 'ServerHello'-Nachrichten das so genannte Master-Secret berechnen.
Master-Secret = f(Pre-Master-Secret, Client.Hello-Random, Server.Hello-Random)
In diesem Punkt unterscheiden sich SSLv3 und TLS 1.0: Während SSL
für die Berechnung des Master-Secrets auf die vorhandenen, inzwischen
als unsicher geltenden Hash-Funktionen MD5 und SHA zurückgreift,
verwendet TLS dafür eine eigene Zufallszahlenfunktion PRF
(Pseudorandom Function). Aus dem Master-Secret werden dann die
Schlüssel für die symmetrische Verschlüsselung der
Verbindung berechnet.
In der nächsten Folge wird der Diffie-Hellman-Schlüsselaustausch beschrieben.
Trackbacks
Dipl.-Inform. Carsten Eilers am : Verfahren der Kryptographie, Teil 13: Perfect Forward Secrecy
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Kryptographie - Ein Überblick
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : WLAN-Sicherheit 13 - Authentifizierung in WPA2, Teil 2
Vorschau anzeigen