Dipl.-Inform. Carsten Eilers

Folgende Nachrichten werden während des SSL/TLS-Handshakes ausgetauscht:

Client		Server
------- 'ClientHello' ------>
		Prüfen/Bilden der SessionID Wahl des geeigneten Schlüsselalgorithmus Wahl des Komprimierungsalgorithmus
	<------- 'ServerHello' ------
	<----- X.509-Zertifikat -----
	<---- 'ServerHelloDone' -----
Prüfen des Zertifikats Erzeugen des Pre-Master-Secrets
-- RSA(Pre-Master-Secret) -->
Berechnung des Master-Secret Schlüsselberechnung		Entschlüsseln von RSA(Pre-Master-Secret) Berechnung des Master-Secret Schlüsselberechnung
<-- 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.

Carsten Eilers