3.3 SSL Sub-Protokolle

SSL selbst ist wiederum in zwei Schichten unterteilt. Die untere Schicht besteht aus dem SSL-Record-Protokoll, welches für die Sicherung der Datenverbindung zuständig ist. Seine Aufgaben bestehen in der Komprimierung und Verschlüsselung der Daten, dem Berechnen und Prüfen der Hash-Werte, sowie der Erzeugung der Sequenznummern. Die folgenden vier Protokolle verwenden das Record-Protokoll für ihre Datenübertragung:

SSL-Handshake-Protokoll

Mit Hilfe dieses Protokolls einigen sich die Kommunikationspartner über die gewünschten Sicherungsparameter. Dies beinhaltet die Authentifizierung, die Wahl des Verschlüsselungsalgorithmus, sowie den Austausch eines geheimen Schlüssels für das symmetrische Verschlüsselungsverfahren. Im folgenden wird auf das Handshake-Protokoll noch genauer eingegangen.

SSL-ChangeCipherSpec-Protokoll

Die durch das Handshake-Protokoll ausgehandelten Parameter treten nicht automatisch in Kraft. Stattdessen verwendet jeder Partner das ChangeCipherSpec-Protokoll, um dem anderen mitzuteilen, daß alle folgenden Nachrichten gemäß der neuen Parameter verschlüsselt werden.

SSL-Alert-Protokoll

Seine Aufgabe besteht unter anderem darin, Fehlernachrichten zwischen den Kommunikationspartnern auszutauschen. Zu diesen Fehlern gehören z. B. die Erkennung eines falschen Hash-Wertes oder die Ablehnung eines Zertifikates. Viele dieser Fehler führen zu einem direkten Abbruch der Verbindung.
Die zweite Aufgabe des Alert-Protokolls besteht darin, die Verbindung regulär zu beenden. SSL verlangt, daß beide Partner die Verbindung ordnungsgemäß beenden, um einen Truncation Angriff¹ zu verhindern.

SSL-ApplicationData-Protokoll

Dieses Protokoll dient dazu, die eigentlichen Daten der Anwendung wie z. B. HTTP, FTP oder POP3 über SSL zu übertragen. Der Datenstrom wird hierbei für SSL vollkommen transparent übertragen.

Nachdem eine Verbindung zwischen einem Client und einem Server auf der Ebene der Transportschicht hergestellt worden ist, erfolgt der Datenaustausch zunächst einmal unverschlüsselt. Zwar läuft die Übertragung bereits über das Record-Protokoll, welches für die Verschlüsselung zuständig ist, doch anfangs ist der Algorithmus auf ,,Keine-Verschlüsselung`` eingestellt.

Bevor jetzt Daten der Anwendung übertragen werden können, müssen sich die Kommunikationspartner mit Hilfe des Handshake-Protokolls über die gewünschten Verschlüsselungsparameter einigen. Hierzu sendet der Client eine ClientHello Nachricht, in der er mitteilt, welche Kryptoverfahren und Kompressionsalgorithmen von ihm unterstützt werden. Außerdem enthält diese Nachricht eine 28-Byte lange Zufallszahl. Der Server antwortet mit einer ServerHello Nachricht, die das von ihm gewählte Kryptoverfahren, den Kompressionsalgorithmus, eine Session-ID und ebenfalls eine 28-Byte lange Zufallszahl enthält. Sofern sich der Server authentifizieren will, sendet er daraufhin eine Certificate Nachricht, welche ein Zertifikat nach X.509v3[8] enthält. Falls der Server sich nicht authentifiziert oder sein Zertifikat nur zum digitalen Signieren und nicht zum Schlüsselaustausch geeignet ist, erzeugt er ein temporäres Public/Private-Key-Paar und übermittelt den Public-Key durch eine ServerKeyExchange Nachricht. Wenn eine Authentifizierung des Clients erwünscht ist, kann der Server diese mittels einer CertificateRequest Nachricht anfordern. Anschließend sendet er eine ServerHelloDone Nachricht, um anzuzeigen, daß er jetzt eine Antwort des Clients erwartet.

Der Client antwortet zunächst mit einer Certificate Nachricht, sofern diese angefordert worden war. Daraufhin erzeugt er den sogenannten PreMaster-Key aus dem später die geheimen Schlüssel für die Datenübertragung berechnet werden und übermittelt ihn in einer ClientKeyExchange Nachricht. Der Inhalt dieser Nachricht wird entweder mit dem Public-Key des Server-Zertifikats oder mit dem temporären Public-Key der ServerKeyExchange Nachricht verschlüsselt. Sofern sich der Client authentifizieren sollte, leistet er daraufhin mittels der CertificateVerify Nachricht eine digitale Signatur, mit der er beweist, daß er im Besitz des zugehörigen Private-Key zu seiner Certificate Nachricht ist.

Zu diesem Zeitpunkt sind sowohl Client als auch Server im Besitz des PreMaster-Key, der geschützt durch den Public-Key des Servers übertragen wurde. Aus dem PreMaster-Key und den beiden Zufallszahlen aus den Hello Nachrichten berechnen jetzt Client und Server nach einem vorgegebenem Algorithmus den Master-Key und aus diesem wiederum eine Reihe von geheimen Schlüsseln. Diese Schlüssel dienen zur Verschlüsselung der Nachrichten und zur Generierung der Hash-Werte. Client und Server senden daraufhin ChangeCipherSpec Nachrichten und verwenden von diesem Zeitpunkt an die soeben ausgehandelten Verschlüsselungsparameter. Abschließend senden beide noch eine Finished Nachricht, um sich zu vergewissern, daß sie im Besitz der gleichen geheimen Schlüssel sind.