Comparison SSL/TLS

Einleitung

Als das Internet entstand war es ein Netz das von wenigen Universitäten betrieben und benutzt wurde. Sicherheit spielte keine Rolle, die Netzteilnehmer kannten sich und vertrauten einander. Doch mit dem rasanten Wachstum des Internets und vor allem durch das Aufkommen einer Vielzahl von kommerziellen Anwendung erwuchs die Nachfrage nach gesicherter Datenübertragung. SSL und sein Nachfolger TLS sind eine weit verbreitete Lösung für dieses Problem. Das grundsätzliche Konzept von SSL und TLS besteht darin zunächst gemeinsame Schlüssel per rechenaufwendiger, asymmetrischer Verschlüsselung auszutauschen und die anschließende Datenübertragung mittels symmetrischer Kryptographie abzusichern. Hierfür werden eine Vielzahl von Algorithmen unterstützt. Es werden folgende Dienste angeboten:

• Authentifizierung
• Verschlüsselung der Kommunikation
• Integrität der Nachrichten

Kryptographische Grundlagen

Um die Funktionsweise von SSL zu verstehen ist etwas Wissen über grundlegende kryptographische Verfahren notwendig. Im folgenden werden wir sehr grundlegende Erklärungen der Begriffe Hashfunktion, Signatur und Zertifikat geben, da diese Techniken zentrale Bedeutung für das SSL Protokoll haben. Vorausgesetzt wird Wissen über die Funktion von symmetrischer und asymmetrischer Verschlüsselung.

Das SSL Handshake Protocol

Das Handshake Protokoll dient dem Aufbau einer gesicherten Verbindung zwischen den Kommunikationspartnern. Während des Handshakes besteht für beide Parteien die Möglichkeiten sich gegenüber der jeweils anderen zu authentifizieren. Des weiteren dient der Handschlag dem Austausch der Schlüssel für die Kommunikation und Integritätsprüfung. Der Verbindungsaufbau beginnt damit, dass der Client ein ClientHello Paket an den Server sendet. Mit dieser Nachricht übermittelt er die höchste von ihm beherrschte SSL/TLS Version, eine Zufallszahl Rc, welche später zur Berechnung der benötigten Schlüssel verwendet wird und eine Liste der von so genannten Cipher Suites. Jede Cipher Suite steht für eine Anzahl an Algorithmen die der Client beherrscht. In den Cipher Suites werden Algorithmen für den Schlüsselaustausch, die symmetrische Verschlüsselung während der Datenübertragung und für die MAC Bildung spezifiziert. Der Server wählt nun zunächst eine der vom Client angebotenen Cipher Suites und die zu verwendende SSL Version aus. Er teilt dem Client seine Wahl im ServerHello Paket mit. Außerdem übermittelt er mit diesem Paket eine Zufallszahl Rs. Anschließend sendet er im Certificat Paket ein Zertifikat, dass seine Identität bestätigt und seinen öffentlichen Schlüssel enthält. Meist handelt es sich hierbei um ein X.509 Zertifikat. Dieses kann der Client nun verwenden um zu überprüfen, dass er auch wirklich mit dem Server und nicht etwa mit einer dritten Partei kommuniziert Anschließend sendet er noch eine Server Hello Done Nachricht an den Client um diese Phase des Handschlags zu beenden. Der Client generiert nun eine weitere Zufallszahl, das so genannte Premaster secret. Dieses bietet zusammen mit den Zahlen Rs und Rc die Basis für die spätere Berechnung der eigentlichen Schlüssel. Im Gegensatz zu diesen wird das Premaster Secret jedoch nicht unverschlüsselt übertragen. Stattdessen verwendet er den in der Cipher Suite bestimmten asymmetrischen Verschlüsselungsalgorithmus und den in der Certificate Nachricht übermittelten öffentlichen Schlüssel des Servers. Das verschlüsselte Premaster Secret schickt er im ClientKeyExchange Paket an den Server. Nun verfügen beide Parteien über genügend Informationen um das Master Secret zu bilden. Dieses wird folgendermaßen berechnet:

Master Secret = MD5( Pre | SHA( 'A' | Pre | Rc | Rs)) | MD5( Pre | SHA( 'BB' | Pre | Rc | Rs)) | MD5( Pre | SHA( 'CCC' | Pre | Rc | Rs)) ...

Diese Berechnungsvorschrift wird so lange iteriert bis genügend Material für die Erzeugung aller Schlüssel vorhanden ist. Insgesamt werden 4 Schlüssel erzeugt: 2 Schlüssel für die symmetrische Verschlüsselung und 2 für die Erzeugung der MACs. Jeweils einer der Schlüssel wird für die Kommunikation vom Server zum Client und der andere für die Kommunikation vom Client zum Server verwendet. Anschließend wird der Handshake durch das ChangeCipherSpec Protokoll abgeschlossen. Dieses Protokoll besteht aus 2 Nachrichten: Der ChangeCipherSpec und der Finished Nachricht. Beide Nachrichten werden zunächst vom Client zum Server und anschließend vom Server zum Client gesendet. Das ChangeCipherSpec Paket besagt hierbei, dass alle folgenden Nachrichten mit dem in der CipherSuite gewählten symmetrischen Algorithmus verschlüsselt werden. Das Finished Paket besteht aus besteht aus MACs über alle bisher ausgetauschten Nachrichten. Hierdurch wird verhindert, dass ein Angreifer die ersten unverschlüsselten Pakete (ClientHello und ServerHello) unbemerkt manipuliert. ChangeCipherSpec ist als eigenes Protokoll und nicht als Teil des Handshake Protokolls, da es auch zu anderen Zeitpunkten während der Übertragung, wie z.B. bei einem Überlauf der Sequenznummern im Record Layer oder bei Alert Meldungen, ausgeführt werden kann. Nach der Beendigung des ChangeCipherSpec Protokolls ist der Handschlag abgeschlossen.

Die vorangegangene Beschreibung bezieht sich auf die üblichste Variante des Protokolls, bei welcher sich nur der Server gegenüber dem Client authentifiziert. Es besteht jedoch auch die Möglichkeit, dass der Client sich gegenüber dem Server ausweist, oder dass keinerlei Authentifikation der beiden Parteien stattfindet. Eine Authentifikation des Clients muss vom Server explizit gewünscht werden. Um diesen Wunsch zu äußern sendet der Server ein ClientCertificateRequest Paket nach der Certficate Nachricht. Der Client sendet nun sein Zertifikat (sofern er eines besitzt) in einem Certifcate Paket vor dem ClientKeyExchange Paket. Dies reicht allerdings noch nicht als Authentifizierung aus, da noch nicht bewiesen ist, dass der Client auch über den zum public key gehörenden private key verfügt. Dieser Beweis erfolgt beim Webserver implizit durch die Entschlüsselung des ClientKeyExchange Paketes. Der Client hingegen muss sich explizit durch ein zusätzliches Paket ausweisen. Hierzu sendet er Nach der ClientKeyExchange Nachricht noch ein Paket namens CertificateVerify. Dieses Paket besteht aus MACs über alle bisher gesendeten Nachrichten, welche vom Client signiert werden. Durch die Überprüfung der Signatur stellt der Server sicher, dass der Client über den nötigen private Schlüssel verfügt. Falls der Server sich nicht gegenüber dem Client authentifizieren kann oder will so verzichtet er auf das Senden einer Certificate Nachricht. Statt dessen sendet er einen temporären öffentlichen Schlüssel in der ServerKeyExchange Nachricht.