e-Mail an mich

zurück     weiter

Das Handshake Protokoll

Durch das Handshake Protokoll verhandeln Server und Client den Modus der Verschlüsselung, die Art der Nachrichtenauthentifizierung und die geheimen Schlüssel, die zur Verschlüsselung oder zur Authentifizierung benutzt werden. Des Weiteren bietet das Handshake Protokoll Server und Client die Möglichkeit, sich gegenseitig oder auch einseitig zu authentifizieren. Dies erfolgt dann über den Austausch von Zertifikaten, die dem X.509v3-Standard entsprechen.

Die Handshake Protokoll Nachrichten sind aus drei Feldern aufgebaut.

• Type (1 Byte): Dieses Feld beinhaltet einen der zehn definierten Nachrichtentypen.
• Length (3 Byte): Hier ist die Länge der Nachricht in Byte angegeben.
• Content (≥0 Byte): Dieses Feld enthält die Parameter der Nachricht.

Die im Handshake Protokoll definierten Meldungen sind:

hello_request (0): Diese Nachricht hat keine Parameter. Sie wird vom Server geschickt, um den Client zu einem client_hello zu veranlassen. In einem laufenden Handshake wird diese Nachricht vom Client ignoriert.

client_hello (1): Mit der client_hello Nachricht startet der Client den Aufbau der SSL-Verbindung. In einer bereits aktiven SSL-Verbindung führt diese Nachricht zu einer Neuverhandlung der Sicherheitsparameter. Der Client schickt mit dieser Meldung die Parameter Version, Zufallswert, Sitzungsnummer, Chiffriermodus und Kompressionsmethode. Der Parameter Version gibt die Versionsnummer von SSL an, die der Client benutzen möchte. Im Falle von SSL Version 3.0 stünde hier demnach die 3.0. Der Zufallswert setzt sich aus einem 32-Bit-Wert für Zeit und Datum nach UNIX-Format und einem 28-Byte-Zufallswert, erzeugt durch einen Pseudo-Zufallszahlengenerator, zusammen. Die Sitzungsnummer wird vom Client angegeben, wenn bereits eine sichere Verbindung besteht, auf die sich der Client beziehen will. Der Parameter Chiffriermodus enthält eine Liste der vom Client unterstützten Chiffren, wobei die bevorzugte Chiffre als erste angegeben wird. Hat der Client auf eine bestehende Sitzung per Sitzungsnummer verwiesen, muss er als Chiffriermodus mindestens den bereits eingesetzten Modus angeben. Der Parameter Kompressionsmethode gibt eine Liste von Kompressionsalgorithmen an, wobei der bevorzugte Algorithmus als erster angegeben wird. Hat der Client auf eine bestehende Sitzung hingewiesen, so muss mindestens der bereits verwendete Kompressionsalgorithmus angegeben werden.

server_hello (2): Mit der server_hello Nachricht antwortet der Server auf das client_hello des Clients. Die Nachricht enthält die gleichen Parameter, wie die client_hello Nachricht, teilweise allerdings mit leicht abgewandelter Bedeutung. Der Parameter Version enthält die höchstmögliche Versionsnummer, die von Server und Client unterstützt werden. Der Zufallswert setzt sich bei der server_hello Nachricht genauso zusammen, wie bei der client_hello Nachricht. Er ist unabhängig von dem zuvor gesendeten Zufallswert des Clients. Der Server vergibt eine neue Sitzungsnummer. Hat der Client eine Sitzungsnummer vorgeschlagen, überprüft der Server diese Sitzungsnummer und übernimmt sie, sofern diese Sitzung noch nicht zu lange zurück liegt. Gibt der Server keine Sitzungsnummer an, so bedeutet dies, dass die gegenwärtige Sitzung später nicht erneut aufgenommen werden kann. Der Server wählt einen Chiffriermodus aus der Liste der vom Client gesendeten Chiffren aus. Wurde eine alte Sitzung erneut aufgenommen, so entspricht dieser Parameter dem der letzten Sitzung. Gleiches gilt für die Auswahl der Kompressionsmethode.

certificate (11): Der Server und der Client haben die Möglichkeit sich durch Übermittlung ihres Zertifikats zu authentifizieren. Beim Server handelt es sich hierbei im Normalfall um ein X.509v3-Zertifikat oder um ein modifiziertes X.509-Zertifikat im Falle von KEA. Der Client erhält vom Server eine Auswahl erlaubter Zertifikate. Besitzt er keines der angegebenen, so antwortet er mit der Alert Meldung no_certificate. Dies ist unkritisch, es sei denn, die Authentifizierung des Clients ist zwingend erforderlich. In diesem Fall führt die Meldung zum Abbruch der Verbindung. Der Parameter certificate enthält eine Liste, die mit dem Zertifikat des Servers oder des Clients beginnt. Die weiteren Zertifikate stammen gegebenenfalls von den Beglaubigungsstellen, den sogenannten Certification Authorities CAs. Diese Zertifikate müssen aber nicht vorhanden sein.

sever_key_exchange (12): Diese Meldung wird nicht geschickt, wenn der Server ein Zertifikat mit festen Diffie-Hellman Parametern oder mit RSA-Schlüsselaustausch besitzt. Im Falle von anonymem Diffie-Hellman, ephemeral Diffie-Hellman, KEA oder, wenn RSA nur zur Signierung benutzt wird, wird die Meldung server_key_exchange gesendet. Die Meldung enthält die einzelnen Parameter, die das jeweilige Schlüsselaustauschverfahren benötigt, und wird vom Server signiert. Zur Signierung dienen die Zufallswerte von Client und Server und die Parameter des Schlüsselaustauschs als Input für den DSS oder die Hashfunktion. Im letzteren Fall wird der Hashwert mit dem öffentlichen Schlüssel des Servers verschlüsselt.

certificate_request (13): Ein nichtanonymer Server kann von dem Client verlangen, sich per Zertifikat zu authentifizieren. Hierzu gibt der Server dem Client in den Parametern eine Liste von Zertifikaten, die er verarbeiten kann. Diese sind nach den Präferenzen des Servers sortiert. Außerdem schickt der Server eine Liste von Beglaubigungsstellen (CAs), die er akzeptiert. Schickt ein anonymer Server die Meldung certificate_request, führt dies zu der fatalen Alert Meldung handshake_failure.

server_hello_done (14): Die server_hello_done Meldung wird vom Server geschickt, da die Meldungen certificate, server_key_exchange und certificate_request nicht notwendigerweise geschickt werden. So erkennt der Client das Ende der Begrüßungsmeldungen des Servers.

certificate_verify (15): Mit dieser Meldung signiert der Client sein Zertifikat, sofern er eines geschickt hat. Dies gilt für alle Zertifikate – mit Ausnahme von Zertifikaten, die feste Diffie-Hellman Parameter enthalten. Die Signatur erfolgt abhängig vom privaten Schlüssel des Clients mit Hilfe von DSS oder RSA. Als Input dient hierbei der von SSL erstellte MAC, der als Input alle Handshake Nachrichten, den geheimen Schlüssel und die Paddingwerte hat.

client_key_exchange (16): Die Nachricht client_key_exchange wird in jedem Fall geschickt. Der Inhalt der Nachricht ist vom gewünschten Schlüsselaustausch abhängig. Handelt es sich um Schlüsselaustausch mit festen Diffie-Hellman Schlüsseln, enthält die Nachricht keine Daten, da die erforderlichen Parameter durch das Zertifikat des Clients übermittelt wurden. Im Falle von ephemeral oder anonymem Diffie-Hellman Schlüsselaustausch werden die erforderlichen Diffie-Hellman Parameter übermittelt. Hat der Client ein RSA-Schlüsselpaar, so generiert er ein sogenanntes Pre-Master Secret, das er mit dem öffentlichen RSA-Schlüssel des Servers oder dem temporären RSA-Schlüssel aus der server_key_exchange Meldung verschlüsselt. Aus diesem Pre-Master Secret wird der geheime Schlüssel gewonnen. Soll KEA zum Schlüsselaustausch genutzt werden, schickt der Client seine KEA Parameter und signiert diese mittels DSS.

Finished (20): Die Meldung finished wird vom Client und vom Server nach der Meldung change_cipher_spec gesendet. Sie enthält die MACs der bis dahin gesendeten Handshake Meldungen, des geheimen Schlüssels, der Paddingwerte und der Identifikation, ob die Meldung vom Client oder vom Server stammt, erstellt mit MD5 und SHA-1. Die beiden MACs werden aneinander gehängt. Diese Meldung ist die erste Nachricht, die bereits mit den neuen Sicherheitsparametern für das Record Protokoll behandelt wird.

Der Verbindungsaufbau bei SSL lässt sich in vier Phasen aufteilen. In Phase 1, der Festlegung der Sicherheitsressourcen, schickt der Client ein client_hello, worauf der Server mit einem server_hello antwortet. Die Nachricht client_hello kann dabei auch die Antwort auf ein hello_request des Servers sein. In einer bereits bestehenden SSL-Verbindung sorgt ein client_hello stets für eine Neuverhandlung der Sicherheitsparameter. Nun beginnt Phase 2, in der Serverauthentifizierung und Schlüsselaustausch stattfinden. Hier schickt der Server entweder die Meldung certificate oder die Meldung server_key_exchange. Optional kann er mit certificate_request die Authentifizierung des Clients verlangen. Abschließend schickt der Server die Meldung server_hello_done. In Phase 3 authentifiziert sich gegebenenfalls der Client und der Schlüsselaustausch wird fortgeführt. Der Client schickt zunächst die Meldung certificate, falls ein Zertifikat vom Server angefordert wurde. Nun schickt der Client die Meldung client_key_exchannge und anschließend noch die Meldung certificate_verify, falls er ein Zertifikat geschickt hat. Die Phase 4 beendet den Handshake. Zunächst schickt der Client die Meldung change_cipher_spec, die den Server veranlasst, die gerade ausgehandelten Parameter für die weitere Sitzung zu übernehmen. Die Meldung finished wird dann bereits mit den neuen Parametern verarbeitet. Zur Bestätigung schickt auch der Server die Meldungen change_cipher_spec und finished.

Das Bild zeigt den Austausch der einzelnen Daten beim Handshake Protokoll. Die Meldungen, die nicht in jedem Fall gesendet werden, sind gestrichelt dargestellt.

zurück     weiter

[Home] [IPSec] [SSL] [AES-Kandidaten] [Über mich] [Links] [Gästebuch]