Ausarbeitung zum Vortrag. Secure Socket Layer. von Jelle Hellmann im Rahmen der Vorlesung Sicherheit in Datennetzen von Herrn Prof.

Transkript

1 Ausarbeitung zum Vortrag Secure Socket Layer von Jelle Hellmann im Rahmen der Vorlesung Sicherheit in Datennetzen von Herrn Prof. Schäfer an der im WS 2004/2005

2 Inhaltsverzeichnis: INHALTSVERZEICHNIS: EINLEITUNG Motivation Geschichtliche Entwicklung VERWENDETE MECHANISMEN IN SSL SECURE SOCKET LAYER PROTOKOLLE SSL Record Layer protocol SSL ChangeCipher Protokoll SSL Alert Protokoll SSL Handshake Protokoll SSL Application Protokoll VERBINDUNGSARTEN Server und Client ohne Authentifizierung Server mit und Client ohne Authentifizierung Server und Client mit Authentifizierung Man in the Middle Attack (Version rollback) ZUSAMMENFASSUNG QUELLEN... 12

3 1. Einleitung Als erstes möchte ich ein paar Worte darüber verlieren, warum und wozu das Secure Socket Layer Protokoll entwickelt wurde und wie geschichtliche Entwicklung verlief. 1.1 Motivation Mit Einzug des Internets in den Alltag der Menschen mussten Mechanismen und Möglichkeiten geschaffen werden, wie man zum einen seinen gegenüber identifiziert und als vertrauenswürdig einstuft, sowie die zu übertragenden Daten sicher ohne das diese manipuliert werden können und verschlüsselt zu übermitteln. Als Beispiel kann man ein E-Business/Commerce nennen. Hier möchte der Käufer eines Produktes sicher sein, wem er seine Daten übermittelt und dass niemand seine Daten unerlaubterweise manipuliert oder einsieht während der Übertragung. Schließlich werden dabei oftmals sensible Daten, wie z.b. Kreditkartennummern, übermittelt. 1.2 Geschichtliche Entwicklung Die Firma Netscape, welche auch den Internet-Browser Netscape Communicator entwickelt, veröffentlichte im Juli 1994 ihr erstes Protokolldesign zum Secure Socket Layer in der Version 1.0. Bereits im April 1995 gab es dann die erste Referenzimplementation von SSL Version 2.0 im damaligen gerade veröffentlichten Internet-Browser. Wegen einer Nachlässigkeit in der Implementierung des Pseudo- Random Number Generators konnten die mit SSL generierten verschlüsselten Daten im September 1995 erstmals entschlüsselt werden. Dies war ein herber Rückschlag für die bis dahin als sehr sicher geltende Methode SSL. Obwohl dies nicht ein Fehler im Protokoll SSL war, wurde schnell an einer verbesserten Version 3.0 gearbeitet, in die auch teile von Microsoft eigens als Gegenpart entwickelten PCT (Private Communication Technology) einflossen. Im März 1996 wurde dann die Version 3.0 von SSL veröffentlicht. Seit 1996 beschäftigt sich dann schließlich auch die Transport Layer Security Working Group der IETF Internet Engineering Task Force mit dem Ziel das SSL Protokoll zu Standardisieren. Dazu wurde im November das Internet Draft SSL V 3.02 veröffentlicht. Im Januar 1999 entstand dann das Protokoll Transport Security Layer Version 1.0, welches auf dem SSL Protokoll Version 3.0 basiert. Seit Februar 2001 ist das TLS Protokoll Version 1.0 in der RFC 2246 wiederzufinden. 2. Verwendete Mechanismen in SSL Das Secure Socket Layer Protokoll bedient sich verschiedener Mechanismen die im Folgenden kurz angesprochen werden. Die eigentliche Verschlüsselung der Daten geschieht aus Performancegründen mittels symmetrischen Verschlüsselungsverfahren. Der hierzu verwendete Schlüssel wird mittels Asymmetrischer Verfahren übertragen. Eigentlich wird nicht der konkrete symmetrische Schlüssel übertragen, sondern nur ein Hash Wert über diesen und über die dazu notwendigen Daten zu dessen Berechnung, denn der Schlüssel wird aus den ausgetauschten Daten von Client und Server lokal berechnet und der Hash Wert dient nur zur Kontrolle, ob der Schlüssel korrekt berechnet wurde. Des Weiteren müssen sich der Server und der Client authentifizieren können. Dazu werden Zertifikate nach X.509 Standart ( siehe RFC Internet X.509 Public Key Infrastructure (PKI), Certificate and CRL Profile ) ausgetauscht, die von CA (Certificate Authority) ausgestellt werden.

4 Als Beispiel für eine solche CA seien hier VeriSign ( ) und D-Trust ( ) genannt. Diese Zertifikate kann man als ( Internet- ) Ausweis ansehen und diese werden während über die Certificate-Message des Handshake Protocols ausgetauscht. Abbildung 1 Zertifikat der FH-Aachen Wichtige Felder sind: Issuer: identifiziert die Organisation die das Zertifikat ausstellt/innehat Period of validity: gibt an wie lange das Zertifikat gültig ist Subject: Public Key Issuer signature: Hashwert des Ausstellers 3. Secure Socket Layer Protokolle Betrachten wir nun den Aufbau des SSL Protokolls und wo es im Internet Protokoll bzw. im OSI - Referenzmodell (OSI-RM)zu finden ist. Secure Socket Layer besteht primär aus den zwei Schichten SSL Handshake Protocol und dem SSL Record Protocol. Des Weiteren gibt es noch ein 3 Protokolle die direkt auf der schicht neben dem Handshake Protocol zu finden sind. Es sind die Protokolle

5 ChangeCipher, Alert und Application, welche im weiteren Verlauf noch aufgegriffen und erklärt werden Wie aus Abbildung 2 hervorgeht, ist das SSL Protokoll zwischen dem Application - Layer und dem Network - Layer des Internet-Protokolls zu finden. Im OSI - Referenzmodell sind dies der Session-Layer ( Layer 5 ) und Transport-Layer ( Layer 4 ). Hieraus lässt sich nun auch erkennen, warum SSL nun auch als Transport Layer Security ( TLS ) bezeichnet wird. 3.1 SSL Record Layer Protocol http ftp telnet Application Layer Change Cipher Alert Handshake Apllication Secure Socket Record Layer Layer Transport Layer TCP Abbildung 2 Einordnung von SSL in 's OSI-RM Das SSL record protocol nimmt Datenblöcke vom Application-Layer ( im ORM Session- Layer ) in beliebiger Größe entgegen, fragmentiert diese in Blöcke geeigneter Größe, wendet optional einen Komprimierungsalgorithmus an, führt des weiteren den durch den Handshake vereinbarten Verschlüsselungsalgorithmus aus, signiert das erhaltene Datenpaket mit dem Message Authentication Code ( MAC ) und gibt die Daten schließlich an denn darunter liegenden Network-Layer ( im ORM Transport-Layer ) weiter. Beim Empfänger werden die einzelnen Tätigkeiten entsprechend in umgekehrter Reihenfolge ausgeführt. Welche Komprimierungs- und Verschlüsselungsfunktionen zur Anwendung kommen, wird während des SSL-Handshakes vereinbart. Zu Beginn der Sitzung erfolgen keine Komprimierung und auch keine Verschlüsselung. Für die exakte Berechnung des MAC verweise ich auf die SSL Protokollspezifikation. Diesem sicheren Kommunikationsmodus von SSL geht ein erfolgreicher SSL - Handshake voraus, in dem unter anderem die gemeinsamen Schlüssel erzeugt werden.

6 1 byte 2 bytes 2 bytes Protocol Version Length Length Protocol Message(s) Bis zu 2^14 (16384) bytes Inklusive MAC Messages Authentication Code (Optional) Abbildung 3 Record Layer Protocol kapselt alle Protokolle der darüber liegenden Schicht 3.2 SSL ChangeCipher Protokoll 1 byte 2 bytes 2 bytes Prot: 20 Vers: 3 0 Len: 0 1 CCS: 1 Abbildung 4 ChangeCipher Protocol Einfachstes Protokoll, weil es nur eine Nachricht kennt. CCS =1 d.h. ab jetzt sind die ausgehandelten Parameter zu benutzen Warum ein eigenes Protokoll? Muss unabhängig von den anderen Protokollen, bei denen es möglich ist mehrere Nachrichten hintereinander zu reihen und zusammen zu kapseln, sein weil nicht nur ein Teil der Nachricht verschlüsselt werden kann. 3.3 SSL Alert Protokoll 1 byte 2 bytes 2 bytes Prot: 21 Vers: 3 0 Len: 0 2 Level Desc Abbildung 5 Alert protocol

7 0 CloseNotify (w) 40 HandshakeFailure (f) 44 Certificate-Revoked 10 UnexpectedMessage (f) 41 NoCertificate (client, w ) 45 Certificate-Expired 20 BadRecord MAC (f) 42 BadCertificate 46 Certificate-Unknown 30 Decompres-sionFailure (f) 43 Unsupported Certificate 47 IllegalParameter Abbildung 6 Nachrichten Werte + Beschreibung Dieses Protokoll wird benutzt, um einen Fehler oder eine Warnung zu melden. Diese Funktionen sind wichtig genug, dass es ein eigenes Protokoll bekommt Severity Level: Es gibt 2 Level, einmal Warning (Level 1) und noch Fatal (Level 2) Bei fatalen Alert Messages wird die Sitzung von beiden Teilnehmern sofort terminiert. Bei Warnings kann das System entscheiden ob die Sitzung beendet wird oder nicht. 3.4 SSL Handshake Protokoll 1 byte 2 bytes 2 bytes Prot: 22 Vers: 3 0 Length Value 0 1 Handshake Msg. Typ HelloRequest ClientHello Length Length MSG Type MSG Length Handskake Message ServerHello Certificate ServerKeyExchange MSG Type MSG Length CertifikateRequest ServerHelloDone Handskake Message CertifikateVerify ClientKeyExchange. 20 Finished Abbildung 7 Handshake Protocol + Nachrichten + Kennung Während das SSL record protocol die eigentlichen Verfahren zur sicheren und verschlüsselten Datenübertragung ausführt, werden im SSL handshake protocol die dazu nötigen Informationen ausgetauscht. Dazu werden folgende Ziele verfolgt: Optionale, gegenseitige Authentifizierung der Kommunikationspartner Einigen auf die zu verwendenden Verschlüsselungs- und Komprimierungsmethoden Erzeugen des gemeinsamen Geheimnisses, aus dem alle benötigten Schlüssel abgeleitet werden können

8 3.4 SSL Application Protokoll 1 byte 2 bytes 2 bytes Record Layer Prot: 23 Vers: 3 0 Length Length Application Data encrypted MD5/SHA Message Authentication Code (16/20 bytes) MD5 MAC Abbildung 8 Aufbau des Application Protocol In diesem Protokoll werden schließlich die sensiblen Daten(Application Data) gekapselt verschlüsselt und signiert. Im Weiteren betrachten wir nun die drei Verbindungsarten, die das SSL Protokoll vorsieht. 4. Verbindungsarten 4.1 Server und Client ohne Authentifizierung Bei dieser Verbindungsart verlangt weder der Server noch der Client eine Authentifizierung von seinem Gegenüber durch ein Zertifikat. Abbildung 9 zeigt die zwischen Server und Client ausgetauschten Nachrichten 1. ClientHello 2. ServerHello 3. ServerKeyExchange 4. ServerHelloDone 5. ClientKeyExchange 6. ChangeCipherSpec 7. Finished 8. ChangeCipherSpec 9. Finished Abbildung 9 Server & Client nicht authentifiziert

9 Die erste Nachricht, die vom Client an den Server gesendet wird, ist die so genannte ClientHello Nachricht. Im Gegenzug antwortet der Server mit der ServerHello Nachricht. In diesen beiden Nachrichten, erzeugen Client und Server gemeinsam Zufallsdaten. Diese werden zur weiteren Erzeugung des gemeinsamen Master Secrets benötigt. Weiterhin teilt der Client dem Server mit welche Verschlüsselungs- und Komprimierungsverfahren er beherrscht. Daraufhin wählt der Server den stärksten Verschlüsselungsalgorithmus und das geeignete Komprimierungsverfahren aus und teilt dies dem Client in der ServerHello Nachricht mit. Welche Verfahren hier angewendet werden können, kann man im Detail aus der Protokollspezifikation entnehmen. In der OpenSSL Version des Protokolls werden folgende Verschlüsselungsverfahren verwendet: Hash Verfahren (für MAC) MD2, MD4, MD5, MDC2 128 bit hash SHA1 (DSS1), Symmetrische Verschlüsselung Blowfish, Cast5, DES, 3DES, IDEA, RC2, RC4, RC5, ab V0.9.7 AES Most support different modes: CBC, CBF, ECB, OFB Default: CBC Public Key Verfahren Diffie-Hellman key agreement DSA digital signatures RSA key agreement, digital signatures, encryption Als nächstes sendet der Server die ServerKeyExchange Nachricht. In ihr wird der Public- Key des Servers übermittelt und dessen Verschlüsselungsart ( z.b. RSA ). Danach sendet der Server die ServerHelloDone Nachricht und wartet auf die Rückmeldung des Clients. Daraufhin antwortet der Client mit der ClientKeyExchange Nachricht. In dieser Nachricht, die der Client mit dem Public Key des Servers verschlüsselt, steht ein 48 bit langes Premaster Secret. Jetzt haben Client und Server alle Daten um das Master Secret zu erzeugen. Um sicher zu gehen, dass beide Seiten das richtige Master Secret erzeugt haben, werden die beiden Finished Nachrichten ausgetauscht. Diese Nachrichten enthalten zwei Hash Werte. Einen MD5 und einen SHA Hash Wert, jeweils erzeugt aus dem Master Secret und den bisher ausgetauschten Sitzungsnachrichten. Sind die übermittelten Hash Werte identisch, kann mit dem eigentliche Applikationsdatenaustausch begonnen werden. 4.2 Server mit und Client ohne Authentifizierung Bei dieser Verbindungsart Authentifiziert sich der Server dem Client gegenüber, indem er dem Client ein Zertifikat im X.509 Format übermittelt. Dies geschieht in der ServerCertificate Nachricht. Diese Nachricht enthält allerdings nicht nur das Zertifikat, sondern auch alle übergeordneten Zertifizierungsstellen, um das Zertifikat auf Echtheit zu überprüfen. Durch dieses Zertifikat erhält der Client schließlich auch den Public Key des Servers. Konnte der Client den Server authentifizieren, verläuft der Rest des Handshakes, wie in der Verbindungsart ohne Authentifizierung.

10 1. ClientHello 2. ServerHello 3. Certificate 4. ServerHelloDone 5. ClientKeyExchange 6. ChangeCipherSpec 7. Finished 8. ChangeCipherSpec 9. Finished Abbildung 10 Server authentifiziert Client nicht 4.3 Server und Client mit Authentifizierung Bei dieser Verbindungsart authentifizieren sich Server und Client bevor sie mit dem eigentlichen Datenaustausch beginnen. Zunächst verläuft die Verbindungsaufnahme wie bei der Server mit / Client ohne Authentifizierung. Der erste Unterschied ist die CertificateRequest Nachricht. In ihr übermittelt der Server dem Client alle Zertifizierungsstellen, die ihm bekannt sind, anhand derer der Server Zertifikate verifizieren kann. Gleichzeitig signalisiert der Server dem Client, dass er eine Authentifizierung vom Client erwartet. 1. ClientHello 3. Certificate 2. ServerHello 4. CertificateRequest 5. ServerHelloDone 6. Certificate 7. ClientKeyExchange 8. CertificateVerify 9. ChangeCipherSpec 10. Finished 9. ChangeCipherSpec 10. Finished Abbildung 11 Client & Server authentifiziert

11 Nach der ServerHelloDone Nachricht antwortet der Client mit der ClientCertificate Nachricht. Diese ist genauso aufgebaut wie die ServerCertificate Nachricht und beinhaltet neben dem eigentlichen Zertifikat, das den Client authentifiziert, auch die übergeordneten Zertifizierungsstellen, um das Zertifikat zu verifizieren. Besitzt der Client kein Zertifikat, so wird die Verbindung an dieser Stelle abgebrochen. Mit der CertificateVerify Nachricht bestätigt der Client dem Server, das er auch derjenige ist, für den das zuvor übermittelte Zertifikat ausgestellt wurde, indem er die in der Finished Nachricht enthaltenen Daten mit seinem Privat Key verschlüsselt. Nun kann der Server mit dem Public Key aus dem Zertifikat eindeutig feststellen, ob der Client auch wirklich der Zertifikatsinhaber ist. Die Finished Nachrichten dienen nochmals zur gegenseitigen Bestätigung der Richtigkeit des Master Secrets, wenn bei der Verhandlung etwas schief gegangen wäre könnte entweder der Client oder Server diese Nachricht nicht entschlüsseln. Nun können die eigentlichen Daten ausgetauscht werden. 5. Man in the Middle Attack (Version rollback) Dual Version Client Man-in-the-Middle Attacker Dual Version Server v2 ClientHello 1 2 (with v3 hints) v2 ClientHello (hints removed) v2 ServerHello 4 v2 ServerHello 3 V2 handshake continues Abbildung 12 Man-in-the-Middle-Attack Hier wird durch entfernen der Version 3 SSL hints(andeutungen) die benutzte SSL Version auf die 2. zurückgestellt, welche vor allem aufgrund des Pseudo- Number Generators nicht so wirklich sicher ist. 6. Zusammenfassung Das Secure Socket Layer Protokoll ist universell einsetzbar, da es sich als transparentes Protokoll zwischen zwei Schichten im Internet-Protokoll (Application Layer Network Layer) bzw. im OSI-RM ( Session Layer Transport Layer ) verwenden lässt, er erweitert die Schicht 4. Es ermöglicht die gegenseitige Authentifizierung der beiden Kommunikationspartner durch X.509 Zertifikate und kann somit eine Vertrauensbasis im sonst so anonymen Internet schaffen. Durch die integrierten Verschlüsselungsverfahren, werden die zu übermittelnden Daten sicher ( zumindest für die Dauer der Übertragung ) verschlüsselt. Das Secure Socket Layer Protokoll erkennt das wiedereinspielen bereits gesendeter Nachrichten, sowie das manipulieren der Nachrichten zwischen zwei Kommunikationspartnern, indem es einen Message Authentication Code ( MAC ) zur Kontrolle anwendet, der Sitzungsabhängig und nur den beiden Kommunikationspartnern bekannt ist. Abschließend sei angemerkt, dass man zwar immer noch von SSL spricht, aber immer öfter eigentlich das Transport Layer Security Protokoll meint.

12 7. Quellen SSL and TLS Essentials, Securing the Web Stephen Thomas, WILEY Verlag Internet-Draft zu SSL 3.02 von der TLS Working Group RFC 2459 Internet X.509 Public Key Infrastructure, Certificate and CRL Profile Internet Engineering Task Force: