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

Geschichte

• 11/1993: Webbrowser Mosaic 1.0 vom NCSA (National Center for Supercomputing Applications)
• 1994: SSL 1.0 von Netscape Communications Corp.
• 01/1995: Netscape Navigator, SSL 2.0
• 1996: SSL 3.0 und Übergabe an die IETF (Internet Engineering Task Force)
• 01/1999: SSL 3.1 als Standard durch die IETF festgelegt und umbenannt in TLS 1.0 (Transport Layer Security)
• 04/2006: TLS 1.1 und TLS Extensions veröffentlicht durch die IETF

Aufbau des SSL Protokolls

Bestandteile des SSL/TLS Protokolls

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.

Hashfunktionen

Hashfunktionen werden von beinahe allen kryptographischen Verfahren verwendet. Grundsätzlich handelt es sich um Funktionen $f:\sum \ ^{*}\ \Rightarrow \ \sum \ ^{n}$ also um Funktionen von einem Alphabet beliebiger Länge (z.B. eine Textnachricht) in ein Alphabet fester Länge, den so genannten Hashwert. Hashfunktionen sind Einwegfunktionen, das bedeutet, dass man von einer Nachricht leicht den Hashwert berechnen kann, aber aus dem Hashwert nicht die Nachricht berechnen kann. Schließlich wird an kryptographische Hashfunktionen noch die Forderung der Kollisionsresistenz gestellt. Man unterscheidet hierbei zwischen starker und schwacher Kollisionsresistenz. Schwache Kollisionsresistenz bedeutet, dass es nicht möglich ist zu einem gegebenen Paar aus Nachricht und Hashwert eine zweite Nachricht mit dem selben Hashwert zu finden. Bei starker Kollisionsresistenz ist die Forderung dass es nicht möglich sein soll zwei Nachrichten mit dem selben Hashwert zu finden. Prominente Beispiele für Hashfunktionen sind SHA-1 und MD5.

Signaturen/MAC

Eine Signatur ist eine digitale Unterschrift. Sie dient dazu zu beweisen, dass eine Nachricht wirklich von einer bestimmten Person stammt. Signaturen benötigen Public-Key Kryptographie und Hashfunktionen. Um ein Dokument zu signieren wird zunächst der Hashwert dieses Dokuments erzeugt. Der Sender verschlüsselt den Hashwert anschließen mit seinem privaten Schlüssel und übermittelt das Ergebnis zusammen mit dem Dokument an den Empfänger. Dieser kann nun selber den Hashwert des Dokuments berechnen und mit dem öffentlichen Schlüssel des Senders den mitgeschickten Hashwert entschlüsseln. Stimmen beide Werte überein hat der Empfänger die Signatur erfolgreich überprüft und somit festgestellt, dass das Dokument wirklich vom Sender stammt. Es ist nicht möglich das Dokument zu verändern ohne den privaten Schlüssel des Senders zu besitzen.

SSL verwendet so genannte Message Authentication Codes (MAC) um die versendeten Pakete zu authentifizieren. MACs funktionieren sehr ähnlich wie digitale Signaturen. Der einzige Unterschied besteht darin, dass MACs mit symmetrischer Kryptographie erstellt werden. Es wird also der selbe Schlüssel zur Ver- und Entschlüsselung verwendet. MACs sind effizienter berechenbar als normale Signaturen, dafür entsteht das Problem des sicheren Schlüsselaustauschs. Dieses Problem wird bei SSL durch das SSL Handshake Protocol gelöst.

Zertifikate/PKI

Ein Zertifikat entspricht einem virtuellen Ausweis und dient der Authentifikation von Verbindungspartnern. Sie enthalten Informationen über den Zertifikatinhaber, wie etwas Name, E-Mail Adresse, Domain, etc. Zertifikate werden, im Allgemeinen gegen Gebühr, von vertrauenswürdigen Dritten, den so genannten Certificate Authorities (CAs), ausgestellt. Um ein Zertifikat zu erhalten muss sich eine Person gegenüber der CA ausweisen. Dies geschieht nach Kriterien die in der Certificate Policy der CA festgelegt werden, z.B. durch persönliches Erscheinen und Vorlegen eines Ausweises. Die CA prüft die Angaben und signiert daraufhin das Zertifikat des Antragstellers. Anhand dieser Signatur kann ein Verbindungspartner, erkennen, dass die Angaben des Zertifikatinhabers durch die CA geprüft werden und somit vertrauenswürdig sind.

Entscheidend für die Funktion von Zertifikaten ist die so genannte Public Key Infrastructure. Sie dient der Verteilung und Überprüfung der Zertifikate. Die Infrastruktur ist baumförmig aufgebaut. Die Wurzeln bilden die so genannten Root CAs. Diese verwenden selbst signierte Zertifikate. Viele dieser Root Zertifikate, werden in den gängigen Browsern mitgeliefert. Die Root CAs können wiederum die Zertifikate anderer CAs signieren. Diese Hierarchie kann fortgesetzt werden bis zu den Endbenutzer Zertifikaten. In der Praxis haben sich allerdings gemeinhin recht flache Hierarchien etabliert.

Das SSL Record Protocol

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 $R_{c}$, 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 $R_{s}$. 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 $R_{s}$ und $R_{c}$ 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 | $R_{c}$ | $R_{s}$)) | MD5( Pre | SHA( 'BB' | Pre | $R_{c}$ | $R_{s}$)) | MD5( Pre | SHA( 'CCC' | Pre | $R_{c}$ | $R_{s}$)) ...

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.

TLS Erweiterungen

TLS 1.1 wird im RFC 4366 um verschiedene Funktionen erweitert. Alle diese Optionen können vom Client über ein ExtendedClientHello Paket angefordert werden. Antwortet der Server mit einem ExtendedServerHello Paket, so beherrscht er die Erweiterungen und kann ihre Benutzung mit dem Client aushandeln. Sendet er ein normales ServerHello Paket so beherrscht er die Erweiterungen nicht oder möchte sie nicht verwenden. Die neuen Funktionen lassen sich in 2 Teilgebiete gliedern: Unterstützung namens basierter, virtueller Hosts und Anpassungen des Protokolls an Hosts mit begrenzten Ressourcen.

Namens basierte virtuelle Hosts

Der Webserver Apache führte das Konzept der virtuellen Hosts ein. Diese gibt es in 2 Varianten, nämlich IP basiert und namens basiert. Bei beiden Konzepten geht es darum, dass ein Webserver nach außen hin als mehrere Hosts auftritt. Bei IP basierten virtuellen Hosts haben diese Hosts jeweils eigene IP Adressen (und sind somit auf IP Ebene unterscheidbar). Bei namens basierten verwenden die Hosts die selbe IP Adresse und unterscheiden sich nur durch ihren (DNS-)Namen. Das Problem bei der Benutzung von SSL/TLS ist nun, dass nicht entschieden werden kann welches Zertifikat ausgeliefert werden soll, falls ein Webserver mehrere durch SSL/TLS geschützte Hosts betreibt. Die Namensinformationen sind nur auf Applikationsebene (z.B. Im HTTP Header) vorhanden, auf welche SSL aber nach dem Schichtenmodell nicht zugreifen sollte. Die Lösung besteht nun darin, dass ClientHello Paket zu erweitern, so dass der Name des Kommunikationspartner auch auf der TLS Ebene übermittelt wird.

Anpassungen an Hosts mit begrenzten Ressourcen

• MaximumFragmentSize: Aushandeln der Fragmentgröße bei Bandbreiten- oder Speicherbegrenzung
• ClientCertificateURLs: Übermittlung einer URL zum Zertifikat, statt Zertifikat selbst
• CA Root Keys: Übermittlung welche Root CA Keys der Client besitzt
• Truncated MAC: HMAC wird auf 80 Bit gekürzt um Bandbreite zu sparen
• Client Certificate Status Information: Certficate Revocation List muss nicht gesendet werden

Quellen

• T. Dierks, E. Rescorla: RFC 4346 . The Transport Layer Security (TLS) Protocol Version 1.1 . http://www.ietf.org/rfc/rfc4346.txt [06.05.2007]
• Blake-Wilson, u.a. : RFC 4366. Transport Layer Security (TLS) Extensions. http://ietfreport.isoc.org/rfc/rfc4366.txt [04.05.2007].
• Eckert, Claudia: IT-Sicherheit. 4. Auflage. München: Oldenbourg Verlag, 2006
• Schwenk, Jörg: Sicherheit und Kryptographie im Internet. 2. Auflage. Wiesbaden: Vieweg Verlag, 2005