Seminararbeit zu SSL/TLS

Transkript

1 Lehrstuhl für Softwaretechnik Universität Augsburg Seminararbeit zu SSL/TLS im Seminar Internetsicherheit Michael Hübschmann Betreuung: Dipl. Inf Kuzman Katkalov Studiengang: Bachelor Informatik Datum:

2 Abstract. Egal was man im Internet tut, Verschlüsselung ist omnipräsent. Das Protokoll dafür ist SSL/TLS. Wie das Protokoll aufgebaut ist und funktioniert wird in dieser Arbeit genauso betrachtet, wie bisherige Angriffe auf das Protokoll und welche Änderungen sich daraus für SSL/TLS ergaben. 2

3 Abbildungsverzeichnis Fig. 1. Einordnung von TLS in das Schichtenmodell des Internets, angelehnt an Figure 4.1 aus [4]... 7 Fig. 2. Die Operationen und Datenstrukturen des TLS Record Protokoll... 9 Fig. 3. Der Ablauf des TLS Handshake Protokoll

4 Inhaltsverzeichnis 1 Einleitung und Motivation Von SSL zu TLS, die Geschichte der sicheren Datenübertragung im Internet 5 3 Funktionsweise von SSL/TLS TLS Record Protokoll TLS Handshake Protokoll TLS Public Key Infrastructure TLS Change Cipher Spec Protokoll TLS Alert Protokoll TLS Application Data Protokoll Kryptographie und Hash Verfahren Implementierungen des Protokolls Angriffsmöglichkeiten und Sicherheitslücken Verwundbarkeiten im Protokoll TLS-Kompression: CRIME, TIME und BREACH Renegotiation und Triple-Handshake Probleme Verschlüsselungsverfahren RC4: RC4 biases attack Sichere Zertifikate? Angriffe auf die Public Key Infrastruktur Fehler in Implementierungen Heartbleed Bug in OpenSSL Zusammenfassung und Ausblick Literaturverzeichnis

5 1 Einleitung und Motivation Die jüngsten Entwicklungen haben der Kryptographie zu einem Boom verholfen. Staaten, die die eigenen Bürger abhören und ausländischen Firmen Geheimnisse entlocken, haben das Sicherheitsbewusstsein der Öffentlichkeit gestärkt. Dabei fällt auf, dass ein Begriff immer wieder Thema ist: SSL/TLS. s sollen verschlüsselt werden, der inländische Datenverkehr sowieso, und jede Website, die mit keinem Schloss-Symbol in der Browser-Leiste aufwarten kann, wird kritisch beäugt [1]. Doch was bedeutet eigentlich SSL/TLS und wie funktioniert es? Die Presse wird zudem oft von Angriffen auf SSL/TLS beherrscht, ist SSL/TLS überhaupt noch sicher? SSL/TLS ist ein sehr umfangreiches Themengebiet und betrachtet man SSL/TLS, müssen viele Themengebiete der Kryptographie angerissen werden. In dieser Arbeit wird das wichtigste Wissen zu SSL/TLS soweit wie möglich zusammengefasst und erläutert. Nach einem kurzen Abriss über die Geschichte von SSL/TLS wird in Kapitel 3 das Protokoll im Detail inspiziert und Grundlagen für die im nächsten Kapitel folgenden Angriffe geschaffen. Kritische und bekannte Angriffe auf SSL/TLS werden nachvollzogen und entsprechende Lösungen erläutert. 2 Von SSL zu TLS, die Geschichte der sicheren Datenübertragung im Internet Die Anfangsjahre des Internets dominierte ein Browser, Mosaic oder später Netscape Navigator genannt. Vor allem aufgrund seiner Fähigkeit, als erster Browser überhaupt auf Internetseiten Bilder anzuzeigen, erfuhr er eine massive Verbreitung [2]. Die Entwickler dieses Browsers der Firma Netscape erkannten ebenso früh die Bedeutung des Internets für Unternehmen und die Möglichkeiten für E-Commerce. Um diesen Geschäftszweig in einem Internet, in dem theoretisch jede Kommunikation zwischen den Teilnehmern irgendwo mitgehört werden konnte, überhaupt erst möglich zu machen, begannen sie daher mit der Entwicklung eines Protokolls für die sichere und verschlüsselte Übertragung im Internet SSL (Secure Sockets Layer). Da das Protokoll von Haus aus mit dem Netscape Browser nutzbar war, der lange Jahre einen Marktanteil von weit über 50% hatte, wurde es schon gleich nach Einführung von SSL zum einzigen und damit de facto Standard (SSL 1.0 wurde aufgrund von Sicherheitslücken nie veröffentlicht). Zusätzlich sollte durch das Format die Webserver-Software der Firma, der zu Beginn als Einziger sichere SSL Verbindungen beherrschte, verkauft werden [3]. Den endgültigen Siegeszug jedoch trat SSL an, als Netscape Sicherheitsexperten von anderen Firmen und von Universitäten einlud, das Protokoll zu verbessern und Fehler zu finden. Dadurch wurde der Weg geebnet, SSL als Industriestandard für sichere Kommunikation im Internet zu nutzen. Netscape zementierte diesen Anspruch durch 5

6 öffentlich nutzbare Patente und wandte sich letztendlich an die IETF 1. Diese übernahm große Teile der aktuellsten SSL Version (SSL 3.0), erweiterte das Protokoll um zusätzliche Fehlermeldungen und tauschte einige kryptografische Verfahren gegen Sicherere aus. Da Sockets von Secure Sockets Layer kein eigentlicher Teil der standardisierten Internetprotokolle waren und außerdem SSL stark mit der Firma Netscape verbunden war, benannte die IETF SSL zu TLS (Transport Layer Security) um und der erste internationale Standard für sichere Datenübertragung im Internet war geschaffen [3]. Aufgrund dieser Standardisierung stellte der Hauptkonkurrent Microsoft für seinen Browser Internet Explorer bisherige eigene Bemühungen ein, und implementierte TLS als Sicherheitsprotokoll, was ob der baldigen marktbeherrschenden Stellung des Internet Explorers entscheidend war. Die IETF entwickelt TLS seither stetig weiter, sodass 2006 TLS 1.1 und 2008 die bis heute aktuelle Version 1.2 mit dem RFC 5246 spezifiziert wurde. Trotz der Umbenennung wird vielfach noch der Begriff SSL verwendet, auch im TLS-Protokoll gibt sich beispielsweise TLS 1.0 als SSL 3.1 aus [4]. SSL wurde ursprünglich entwickelt, um Daten des Hyper Text Transfer Protocols (HTTP) gesichert zu übertragen. Da SSL damals aber grundsätzlich unabhängig von darüber liegenden Protokollen wie eben HTTP konzipiert wurde, kann es von beliebigen Anwendungsschicht-Protokollen verwendet werden. Fast alle Protokolle haben inzwischen entsprechende sichere Pendanten, die mit TLS gesichert sind, und teilweise an einem angehängten S für Secure erkennbar sind. Sehr bekannt ist HTTPS, aber auch das Dateiübertragungsprotokoll FTPS und für Kommunikation SMTPS sind weit verbreitet. 3 Funktionsweise von SSL/TLS Über TLS werden mehrere Aspekte der Kommunikation im Internet zwischen zwei Partnern, meistens Server und Client, gesichert. Die drei klassischen Ziele der Informationssicherheit - Authentizität, Vertraulichkeit und Integrität werden vom TLS Protokoll umgesetzt. TLS stellt sicher, dass sowohl Server als auch Client sich eindeutig gegenüber dem jeweils Anderen authentifizieren, dass die anschließende Kommunikation gesichert und für Dritte unlesbar ist 2 und zuletzt auch, dass die übertragenen Daten auf dem Weg zwischen den Kommunikationspartnern nicht verändert wurden. Dabei verwendet TLS für die Authentifikation asymmetrische Verschlüsselungsverfahren, für die Sicherung der eigentlichen Kommunikation wird jedoch ein symmetrischer Schlüssel erzeugt. Alle im Protokoll verwendeten Methoden sind nicht festgelegt, sondern können ausgetauscht werden (siehe Kapitel 3.7). 1 Internet Engineering Taskforce: forciert als lose internationale Vereinigung von Internetnutzern und -betreibern die Standardisierung von Protokollen im Internet 2 Da Integrität bei der ersten Version SSL 1.0 nicht gewährleistet werden konnte, wurde erst SSL 2.0, bei dem diese Sicherheitslücke geschlossen war, veröffentlicht. 6

7 Die Einordnung von SSL/TLS in das Schichtenmodell des Internets, das TCP/IP- Referenzmodell(siehe Abbildung 1) ist schwierig. Es bekommt Daten von Anwendungsschicht Protokollen wie HTTP und versendet sie gesichert per Transport- Protokoll wie TCP. Hierbei übernimmt es Aufgaben und Eigenschaften aus beiden Schichten, daher ist SSL/TLS irgendwo zwischen der Anwendungsschicht (Application layer) und der Transportschicht (Transport layer) einzuordnen. Im ISO/OSI Modell mit sieben Schichten kann man TLS eindeutiger den Schichten vier und fünf, also Sitzungs- und Transportschicht zuordnen. Fig. 1. Einordnung von TLS in das Schichtenmodell des Internets, angelehnt an Figure 4.1 aus [4] Betrachtet man den Aufbau des SSL/TLS Protokolls, lässt sich die Einordnung nachvollziehen: TLS besteht wiederum aus zwei Schichten, das Record Protokoll als untere Schicht sorgt für Verschlüsselung, Integrität und Authentizität bei allen darauf aufbauenden Protokollen und ist sitzungsbasiert. Unterstützt vom ChangeCipherSpec Protokoll wird mit dem Handshake Protokoll eine sichere Verbindung ausgehandelt, das Alert Protokoll sorgt für verständliche Fehlermeldungen und über das Application Data Protokoll werden letztendlich die Daten der Anwendungsschicht gesichert übertragen. In den folgenden Kapiteln werden die Protokolle eingehender betrachtet. 3.1 TLS Record Protokoll Die Basis für die anderen TLS Protokolle stellt das TLS Record Protokoll bereit. Eingehende Daten durchlaufen mehrere Schritte, für die jeweils eine Operation und eine resultierende Datenstruktur vorgegeben sind. Diese Algorithmen sind austauschbar, und die Operationen des TLS Record Protokolls verwenden die in der aktiven CipherSuite spezifizierten Algorithmen. Für jede Verbindung wird mithilfe des TLS Handshake Protokolls eine solche CipherSuite festgelegt. Sie besteht aus mehreren Algorithmen. Es wird aufgeführt, 7

8 welcher Key Exchange Algorithmus für den Schlüsselaustausch 3 und welcher generelle Verschlüsselungsalgorithmus zur Verschlüsselung der Daten eingesetzt werden soll, sowie mit welchem Hash-Algorithmus ein Message Authentication Code erzeugt werden soll. Ist kein Key Exchange Algorithmus angegeben, spricht man von einer CipherSpec. Am Ende gibt das TLS Record Protokoll die Daten als SSL/TLS Record an ein verbindungsorientiertes Transportprotokoll aus. Aber auch verbindungslose oder unsichere Transportprotokolle können mit entsprechenden Anpassungen verwendet werden, beispielsweise wurde für UDP eine TLS Version namens Datagram Transport Layer Security (DTLS) entwickelt, das mit Paketverlust und unsicherer Paketreihenfolge umgehen kann. Der Ablauf des TLS Record Protokolls wird im Folgenden detailliert beschrieben, eine Übersicht ist in Abbildung 2 zu finden. Erhält eine Implementierung des TLS Record Protokolls Anwendungs-Daten von einer darüberliegenden Schicht des TLS Protokolls, wie dem Application Data Protokoll, so werden diese zuerst fragmentiert, also in Blocks (mit einer Maximalgröße von 2 14 Bytes) unterteilt. Jeder resultierende Block wird in eine Datenstruktur gepackt, die im Protokoll TLSPlaintext genannt wird, und zusätzlich Nachrichten-Typ, SSL/TLS- Version und Nachrichten-Länge enthält. Einzelne Nachrichtenblöcke der höherliegenden Protokolle werden hier zusammengefasst, sodass zum Beispiel auch mehrere Application Data Nachrichten in einem TLS Record landen können. Dieser TLSPlaintext wird als nächstes mit einem Kompressionsverfahren komprimiert, welches bestimmte Konditionen erfüllen muss 4. Häufig wird allerdings keine Kompression verwendet - in SSL 3.0 wurden beispielsweise gar keine Kompressionsalgorithmen spezifiziert. An die resultierende Datenstruktur TLSCompressed (die die 3 Attribute von TLSPlaintext übernimmt) wird nun ein Message Authentication Code (MAC) angehängt. 3 4 wird für das TLS Record Protokoll nicht benötigt Das Kompressionsverfahren für das TLS Record Protokoll darf den Datenblock nicht um mehr als 1024 Bytes vergrößern. Vor allem bei sehr kleinen Datenblöcken ist das relevant. 8

9 Fig. 2. Die Operationen und Datenstrukturen des TLS Record Protokoll Durch den MAC wird die Integrität der übertragenen Daten, also der Anwendungsdaten mitsamt der Attribute, garantiert. Falls auf dem Übertragungsweg Daten verändert würden oder verloren gingen, würde der MAC nicht mehr zur Nachricht passen. Bei SSL wurde der MAC mithilfe eines zweistufigen Hash-Algorithmus aus dem Mastersecret 5, der Sequenznummer der Nachricht und den Anwendungsdaten generiert. Während die zu verwendenden Hash-Algorithmen hier fest vorgegeben waren (die mittlerweile unsicheren MD5 oder SHA-1), wurde für TLS das Verfahren komplett überarbeitet und auf Keyed-Hash Message Authentication Code (H-MAC) umgestellt. Dieses erlaubt es jetzt theoretisch, einen beliebigen Hash-Algorithmus zu verwenden 6. Wie auch bei SSL wird ein H-MAC Geheimnis aus dem Mastersecret erstellt und zusammen mit den TLSCompressed Daten in die H-MAC Funktion eingespeist, weitere Daten sind nicht nötig. Der Block aus TLSCompressed-Daten und angehängtem (H)MAC wird nun zu TLSCiphertext verschlüsselt. Welche Verschlüsselung verwendet werden soll, ist in der CipherSpec festgesetzt. Grundsätzlich können Stromchiffren oder Blockchiffren verwendet werden, wobei für Blockchiffren entsprechend ein Padding angehängt werden muss, um die Datenlänge auf ein Vielfaches der Block-Länge zu bringen. Außerdem kann für manche Blockchiffren ein Initialisierungsvektor nötig sein, um 5 6 Das Mastersecret wird zwischen den Kommunikationspartnern mithilfe des Handshake Protokolls ausgemacht. Praktisch wird die Auswahl an Hash Algorithmen durch die Verfügbarkeit in CipherSpecs eingeschränkt. Diese werden allerdings durch das IETF kontinuierlich erweitert. 9

10 den ersten Datensatz zu verschlüsseln. Dieser wird mithilfe des Sitzungsidentifikators des TLS Handshake Protokolls gewonnen. Wurden die Daten erfolgreich verschlüsselt, wird zuletzt vorne an den TLSCiphertext ein Record Header angefügt. Dieser besteht wie bei den Datenstrukturen TLSCompressed und TLSPlaintext aus Nachrichten-Typ, SSL/TLS Version sowie der ursprünglichen Länge der Daten. Zusammen ergeben Header und Ciphertext einen TLS Record, der jetzt versendet wird. Jede dieser Operationen ist optional, wodurch das TLS Record Protokoll sehr flexibel von allen höheren TLS-Protokollen angesprochen werden kann. Für die initiale Kommunikation kommt beispielsweise kaum eine der Operationen zum Einsatz - bis ein gemeinsames Mastersecret und die CipherSpec festgelegt wurden, ist Verschlüsselung oder das Erstellen eines MAC schließlich nicht möglich [4] [5]. 3.2 TLS Handshake Protokoll Als zweites wichtiges Protokoll sorgt das TLS Handshake Protokoll dafür, dass sich die Kommunikationspartner authentifizieren, sich auf eine CipherSuite einigen und schließlich ein gemeinsames Mastersecret vereinbaren. Diese Daten spezifizieren den Sitzungszustand, daher ist das Protokoll zustandsbehaftet. Der prinzipielle Ablauf ist auch in Abbildung 3 nachzuverfolgen. Im ersten Schritt sendet der Client eine ClientHello Nachricht an den Server. Diese ist natürlicherweise noch unverschlüsselt und besteht im Wesentlichen aus Zeitstempel, Zufallszahl, Sitzungsidentifikator, CipherSuites sowie Komprimierungsmethoden. Als CipherSuites sowie Komprimierungsmethoden gibt der Client alle von ihm unterstützten Methoden mit. Erhält der Server die ClientHello Nachricht, überprüft er zuerst den Record Header. Als SSL/TLS Version für die Verbindung nimmt er die Version aus dem Header, falls er allerdings nur eine niedrigere Version unterstützt, wählt er diese (aber immer höchstmöglich). Da der Client immer die höchste von ihm unterstützte SSL/TLS Version im ClientHello versendet, wird für die Kommunikation somit die höchstmögliche Version etabliert. In diesem zweiten Schritt nun verifiziert der Server die Parameter der ClientHello Nachricht, wählt aus den CipherSuites sowie den Komprimierungsmethoden jeweils eine aus, die von ihm unterstützt wird. Diese Daten versendet der Server nun an den Client, durch das TLS Record Protokoll wird außerdem die SSL/TLS Version mit zurückgegeben. Client und Server haben dadurch für die Verbindung die bestmöglichen Protokollversionen und Algorithmen festgelegt, die auch für künftige Sitzungen verwendet werden. Um sich nun gegenüber dem Client zu authentifizieren, kann der Server zusätzlich noch in Schritt zwei des Protokolls ein Zertifikat mitsenden. Dieses Zertifikat besteht aus mehreren öffentlichen Schlüsseln - dem öffentlichen Schlüssel des Servers sowie der übergeordneten Authorities (dazu mehr in Kapitel 3.3) - und wird in einer Certificate Nachricht gesendet.. Alternativ kann der Server einen temporären öffentlichen Schlüssel per Server- KeyExchange Nachricht übermitteln. 10

11 Möchte der Server auch den Client authentifizieren (was im Internet sehr selten praktiziert wird) sendet er noch eine CertificateRequest Nachricht zum Client, der dann seinerseits im nächsten Schritt mit einem Zertifikat aufwarten muss. Hat der Server diese Nachrichten alle abgeschlossen, folgt ein ServerHelloDone, um zu signalisieren, dass alle Nachrichten des Schrittes gesendet wurden. Diese Nachrichten können meist alle gesammelt in einen TLS Record gepackt werden, da die Länge aller Nachrichten die Fragmentgröße nicht übersteigt. Fig. 3. Der Ablauf des TLS Handshake Protokoll Der Client überprüft in Schritt 3 zunächst die Nachrichten. Falls alle Werte von ihm akzeptiert werden, und das Server Zertifikat gültig ist, sendet er falls gefordert sein Zertifikat, und daran anschließend eine ClientKeyExchange Nachricht. Diese enthält die entscheidenden Daten um serverseitig Daten zu verschlüsseln. Je nach ausgehandeltem Key Exchange Algorithmus kann das ein Pre-Master-Secret sein, das mithilfe des öffentlichen Schlüssels des Servers verschlüsselt wird, oder ein Datenblock für den Diffie-Hellmann Algorithmus. Muss sich auch der Client authentifizieren, sendet er eine mit seinem geheimen Schlüssel signierte Nachricht namens CertificateVerify an den Server, sodass dieser überprüfen kann, dass der Client das Zertifikat auch wirklich besitzt. Bevor der Client mit einer Finished Nachricht an den Server meldet, dass alle Nachrichten des Schrittes drei gesendet wurden, sendet er noch eine ChangeCipherSpec 11

12 Nachricht. Sie signalisiert dem Empfänger, dass ab jetzt die ausgehandelte CipherSuite verwendet wird. Da diese allerdings nicht mehr zum TLS Handshake Protokoll gehört, sondern ihr eigenes Protokoll hat, wird sie in Kapitel 3.4 genauer betrachtet. Wie durch die ChangeCipherSpec angekündigt, wird die Finished Nachricht als Erste Nachricht mit den ausgehandelten Verschlüsselungsalgorithmen und Schlüsseln geschützt. Dies wird im darunterliegenden TLS Record Protokoll umgesetzt [6]. Der Server sendet, nach optionaler Überprüfung des Client Zertifikats, ebenfalls eine ChangeCipherSpec gefolgt von einer Finished Nachricht. Client und Server haben dank des Key Exchange Algorithmus jetzt beide das gleiche pre-master-secret und berechnen aus Diesem und den Zufallszahlen der HelloMessages unabhängig voneinander das MasterSecret. Mithilfe des MasterSecret werden die Schlüssel für HMAC, Verschlüsselung und den eventuell für Blockchiffren benötigten Initialisierungsvektor generiert. Alle Parameter des TLS Record Protokolls sind jetzt vorhanden und der Status für das TLS Record Protokoll wechselt daher von pending auf current. Die Kommunikation in beide Richtungen ist damit gesichert und die Übertragung von Anwendungsdaten mithilfe des Application Data Protokolls kann beginnen [3] [4]. 3.3 TLS Public Key Infrastructure TLS nutzt für die eindeutige Identifizierung eines Kommunikationspartners Zertifikate. Diese Zertifikate beinhalten im Wesentlichen den öffentlichen Schlüssel des Inhabers, dessen Name und einen Gültigkeitszeitraum. Außerdem muss das Zertifikat von einer Certificate Authority (CA), also einer Zertifizierungsstelle mit deren geheimen Schlüssel signiert sein. Diese Zertifizierungsstellen befinden sich in einer Hierarchie, in der übergeordnete Zertifizierungsstellen die Zertifikate der untergeordneten Zertifizierungsstellen signieren, und garantieren, dass die untergeordnete Zertifizierungsstelle geeignet und vertrauenswürdig ist. Somit muss jeder Benutzer nur wenigen übergeordneten Zertifizierungsstellen vertrauen und kann für jedes Zertifikat die Hierarchie nach oben durchgehen und überprüfen, ob eine Zertifizierungsstelle auf dem Weg liegt, der vertraut wird. Im Detail nimmt man jeweils den öffentlichen Schlüssel der angegebenen Zertifizierungsstelle und prüft, ob das zu prüfende Zertifikat korrekt, also mit dem zum öffentlichen Schlüssel passenden geheimen Schlüssel, signiert wurde [7]. Man nenn diese Konstellation die Public Key Infrastructure (PKI) von TLS. Ob ein Kommunikationspartner bei TLS wirklich der ist, für den er sich ausgibt, und ob dem Kommunikationspartner vertraut werden kann, hängt also allein davon ab, welchen Zertifizierungsstellen man vertraut. In der Praxis findet sich in Browsern eine Liste von vertrauenswürdigen Root CAs, also CAs die sich selbst ein Zertifikat ausgestellt haben, und damit an der Spitze der Hierarchie stehen. Damit wirdallen Zertifikaten die valide von diesen oder untergeordneten CAs vergeben wurden, automatisch vertraut. Das Überprüfen der Kette von CAs übernimmt meist der Browser. 12

13 3.4 TLS Change Cipher Spec Protokoll Das Change Cipher Spec Protokoll beschreibt eine einzige, ein Byte lange Nachricht die ChangeCipherSpec Nachricht. Durch diese Nachricht wird beim Handshake Protokoll signalisiert, dass ab jetzt die verhandelte CipherSuite angewendet wird. Die Nachricht ist als eigenes Protokoll spezifiziert, da im TLS Record Protokoll eingehende Nachrichten des gleichen Typs, also Protokolle zusammengefasst werden können. Wäre die ChangeCipherSpec Nachricht also Teil des Handshake Protokolls, könnte innerhalb eines Fragmentes für das TLS Record Protocol die Notwendigkeit bestehen, die vorige Nachricht (z.b. CertificateVerify, siehe Abbildung 4) nicht zu verschlüsseln, die Nachfolgende (z.b. Finished) wegen des Wechsels zur CipherSuite aber zu verschlüsseln. Da aber das TLS RecordProtokoll ein Fragment entweder verschlüsseln kann, oder eben nicht, wurde ein eigenes Protokoll eingeführt. Somit wird die Nachricht im TLS Record Protokoll einzeln verarbeitet [3]. 3.5 TLS Alert Protokoll Für jegliche Fehler oder Warnmeldungen ist bei TLS das Alert Protokoll zuständig. Mit dem Protokoll kann dem Kommunikationspartner mitgeteilt werden, was für ein Problem aufgetreten ist. Dazu enthält es 2 Bytes: Eines zur Einordnung der Schwere des Fehlers (in TLS 1.2 entweder Warnung oder fataler Zustand welcher zum Abbruch der Verbindung führt), und ein Byte für die Alarmsituation. Mit den SSL/TLS Versionen wurde die Anzahl der Fehlermeldungen kontinuierlich erhöht. Ein Beispiel ist der handshake_failure, der dem Kommunikationspartner mitteilt, dass mit den gegebenen Optionen keine passenden Sitzungsparameter gefunden werden konnten. Er ist ein fataler Zustand und führt also zum Verbindungsabbruch. Allerdings kann die Schwere des Fehlers auch vom Kommunikationspartner interpretiert werden, wenn es kein fataler Zustand ist. Warnungen können also beispielsweise trotzdem zum Abbruch führen. 3.6 TLS Application Data Protokoll Wurde eine Verbindung zwischen Server und Client mithilfe des Handshake Protokolls erfolgreich hergestellt, werden alle weiteren eingehenden Daten des darüberliegenden Protokolls (z.b. HTTP) vom Application Data Protokoll behandelt. Nach dem Protokoll werden die eingehenden Daten ohne Veränderung dem TLS Record Protokoll übergeben, welches für die Sicherung sorgt. 3.7 Kryptographie und Hash Verfahren Für jede SSL und TLS Version sind mehrere CipherSuites definiert, die sich mit jeder Version geändert haben, da bestimmte Kombinationen oder Algorithmen sich zwischenzeitlich als unsicher oder anderweitig unbrauchbar herausstellten. Da es als Basis für Kapitel 4 hilfreich ist, wird ein Verschlüsselungsalgorithmus (RC4) im Detail betrachtet. 13

14 RC4 ist eine Stromchiffre, sie verschlüsselt also einen Strom von Daten, die bereits 1980 entwickelt wurde. Obwohl seitdem viele Schwachstellen entdeckt wurden und der Einsatz nicht empfohlen wird, ist sie für SSL/TLS gesicherte Verbindungen immer noch oft im Einsatz. Zuerst wird ein initialer Array mit Werten von 0 bis 255 vorbelegt. Mithilfe des Schlüssels wird dann jeder Wert des Arrays verschoben. Die zu verschlüsselnden Daten werden danach mithilfe des Arrays Byte für Byte verschlüsselt (Hierfür verwendet RC4 die XOR Operation). Nach jedem Schritt werden im Array zwei Werte vertauscht. Entschlüsselt wird mit dem selben Algorithmus. RC4 ist mittlerweile als unsicher eingestuft und sollte nicht mehr verwendet werden [8]. TLS 1.2 verwendet mittlerweile weder RC4 noch das unsichere Hashverfahren MD5, sondern setzt allein auf AES Verschlüsselung im CBC (Cipher Block Chaining Mode) oder GCM (Galois / Counter Mode), da für beide Modi noch keine Sicherheitslücken gefunden wurden und auch AES mit längerer Schlüssellänge noch als sicher gilt. Als Hashverfahren wird ausschließlich SHA mit hohen Bit-Größen eingesetzt. Nur die ursprüngliche Vielfalt an Key Exchange Algorithmen ist weiterhin gegeben, sodass RSA und viele Varianten des Diffie-Hellmann Algorithmus weiterhin bestandteil von TLS 1.2 sind und verwendet werden können. 3.8 Implementierungen des Protokolls Auch wenn ein Protokoll wie TLS/SSL vollständig sicher sein sollte, entstehen trotzdem die meisten Fehler noch bei der Implementierung des spezifizierten Protokolls. Da derartige Aufgaben nur Sicherheitsexperten und Kyptographiespezialisten durchführen sollten, setzen auch nahezu alle, die TLS verwenden wollen, auf bereits fertige Bibliotheken. Die am häufigsten verwendete Bibliothek ist die OpenSource Implementierung von SSL/TLS namens OpenSSL. Für alle verbreiteten Betriebssysteme ist OpenSSL verfügbar, und alle SSL/TLS Versionen samt DTLS Versionen werden unterstützt. Als weitere weitverbreitete Bibliothek bietet die Java Secure Socket Extension (JSSE) für die Programmiersprache JAVA die Möglichkeit, per TLS verschlüsselte Verbindungen aufzubauen. Während der Umgang mit der Bibliothek zu Beginn noch kompliziert war, und kleine Fehler in der Verwendung der API zu großen Sicherheitslücken führen konnten, wurden diese Fehler mittlerweile behoben und auch TLS 1.1 und TLS 1.2 eingebunden. 4 Angriffsmöglichkeiten und Sicherheitslücken SSL/TLS ist durch die Verwendung im Internet wohl das am meisten genutzte und auch das bekannteste Verschlüsselungsprotokoll der Welt. Durch diese weite Verbreitung steht das Protokoll allerdings ebenfalls von Beginn an im Fokus von Forschern aber auch Kriminellen, die das Protokoll auf Schwachstellen und Fehler abklopfen. Doch nicht nur das Konzept, auch die verschiedenen Implementierungen des Proto- 14

15 kolls können Fehler enthalten, die an sich nichts mit SSL/TLS zu tun haben, aber zum Zusammenbruch der Verschlüsselung führen können. 4.1 Verwundbarkeiten im Protokoll Die Mehrzahl der Schwachstellen von SSL/TLS sind auf die verwendeten Verschlüsselungs- und Hash-Algorithmen zurückzuführen. Daher sind seit TLS 1.0 keine Algorithmen mehr im Protokoll selbst fest vorgegeben. Es wird vielmehr eine Auswahl an Algorithmen, die CipherSuites, zur Verfügung gestellt welche beständig um sicherere Algorithmen ergänzt und um gebrochene Algorithmen gekürzt werden. Im Folgenden werden erfolgreiche Angriffe auf SSL/TLS betrachtet, deren Ansatzpunkt die verwendeten Algorithmen oder die Architektur des Protokolls sind [9]. TLS-Kompression: CRIME, TIME und BREACH. Einige Angriffe zielen auf die Komprimierungsfunkion des TLS Record Protocols ab. Die Komprimierungsfunktion wird im Handshake festgesetzt, in der Praxis wird oft null, also gar keine Komprimierungsfunktion verwendet. Sonst werden meist DEFLATE Protokolle wie zlib oder gzip verwendet. DEFLATE vereint zwei Algorithmen um Daten zu komprimieren: Der Lempel-Ziv-Storer- Szymanski-Algorithmus (LZ77) sucht nach Wiederholungen in den Daten und ersetzt diese mit einem Verweis auf das erste Vorkommen. Anschließend werden mit der Huffman Codierung häufige Zeichen durch kürzere Zeichen ersetzt um insgesamt eine möglichst geringe Dateigröße zu erreichen [10] Zwei Forscher stellten 2012 den Compression Ratio Info-Leak Made Easy Angriff oder kurz CRIME vor. Die Attacke nutzt aus, dass die Länge der komprimierten Daten bekannt ist und in den Klardaten häufig ein geheimes Session Cookie enthalten ist, welches mit komprimiert wird. Ist es dem Angreifer möglich, Klardaten einzuschleusen, die anschließend komprimiert und verschlüsselt werden 7, kann er über die Länge des komprimierten und verschlüsselten Ergebnisses Rückschlüsse auf das geheime Session Cookie ziehen. Falls es nämlich Übereinstimmungen zwischen dem Geheimnis und den gewählten Klardaten gibt, werden diese durch den LZ77 eliminiert und das komprimierte Ergebnis ist kürzer als ohne Übereinstimmung. Um das geheime Cookie zu bekommen, testen die Angreifer mithilfe der Fenstergröße des Verschlüsselungsalgorithmus. Der LZ77 Algorithmus der Komprimierungsfunktion sucht nach übereinstimmenden Daten nur innerhalb eines definierten Fenster. Um herauszubekommen ob bestimmte Zeichen im geheimen Cookie vorkommen, werden zwei Anfragen geschickt. Einmal liegt das zu prüfende Zeichen innerhalb des Fensters, einmal außerhalb. War die Länge der Antwort zur Anfrage kürzer, bei der das geprüfte Zeichen im Fenster lag, gibt es eine Übereinstimmung mit dem geheimen Cookie, und es wird mit dem nächsten Zeichen fortgefahren. Mit nicht zu vielen Anfragen lässt sich somit das geheime Cookie erfragen. Für TLS wurde außerdem noch eine andere Möglichkeit gefunden, falls die Fenstergröße nicht bekannt ist. Da bei 7 Diese Art von Angriff ist besser bekannt als Chosen-Plaintext Attack 15

16 einer bestimmten Größe ein TLS Request gesplittet wird, schickt man Anfragen die minimal größer sind, werden sie in der Antwort nicht gesplittet, muss sie kleiner sein. [11]. CRIME war bereits eine Weiterentwicklung von BEAST (Browser Exploit Against SSL/TLS), welches Blockchiffren mithilfe des Initialisierungsvektors aushebeln konnte ( In TLS 1.1 wurde das Problem durch individuelle Initialisierungsvektoren behoben). Ebenso wurde CRIME zu TIME (Timing Info-leak Made Easy) weiterentwickelt, welches einige Schwächen des Angriffs behoben hat. Bei TIME wird nicht mehr die Länge der Antwort abgefragt, sondern die Zeit gemessen, die eine Antwort braucht. Da Anfragen immer am Limit zum Splitting gesendet werden, braucht eine kürzere Antwort weniger Zeit als eine Antwort, die auf zwei Antworten gesplittet werden muss. Durch dieses Vorgehen ist es nicht (wie noch bei CRIME) nötig, die gesamte Kommunikation mitzuschneiden. Man muss also nicht Man in the Middle spielen, sondern nur noch z.b. Javascript auf dem angegriffenen Rechner ausführen. Diese Lücke wurde durch das Deaktivieren der TLS-Komprimierung bei allen gängigen Browsern geschlossen, und auch serverseitig wurde TLS-Komprimierung deaktiviert. Zusätzlich wird häufig empfohlen zusätzliche zufällige zeitliche Verzögerungen in den Verschlüsselungsalgorithmus einzubauen und CAPTCHAs gegen die Vielzahl von automatisierten Abfragen, die für diese Attacken notwendig sind, einzusetzen [12]. Als neueste Fortführung der ursprünglichen CRIME Attacke gilt BREACH ( Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext). Es nutzt nicht mehr die TLS Komprimierung aus, sondern die immer noch eingesetzte HTTP response compression. Wie CRIME und TIME nutzt es die Länge der Antwort und induziert Klartext in die Server-Anfrage. Da es allerdings auf HTTP Kompression setzt, kann die TLS Verschlüsselung umgangen werden 8 [13]. Da das Abschalten der HTTP aufgrund immenser Leistungsverluste nicht praktikabel wäre, werden andere Lösungen empfohlen. Eine Strategie ist es, die Länge einer Anfrage durch überflüssige Daten künstlich und zufällig zu verändern. Außerdem ist eine Voraussetzung für den Angriff, dass das herauszufindende Geheimnis in allen Antworten gleich ist, und daher kann eine Maskierung mit einer zufälligen Zahl ein Herausfinden desselben verhindern. Renegotiation und Triple-Handshake Probleme Wie beim TLS Record Protocol und dessen Komprimierungsfähigkeit gibt es auch einige Angriffe, die auf den Ablauf nach dem Handshake Protokoll zielen. Mithilfe der Renegotiation attack (etwa: Neuverhandlungs-Angriff) können in eine verschlüsselte Kommunikation zwischen zwei Kommunikationspartnern Nachrichten eingebracht werden, die von einem Partner als valide eingestuft und behandelt werden. Dafür verwendet die Attacke die Möglichkeit bei TLS, eine TLS-Sitzung neu zu verhandeln. Der Angriff ist ein Man-in-the-middle Angriff: der Angreifer muss in der Lage sein, den Datenverkehr des Clients zum Server abzufangen. 8 Diese Angriffsart nennt man auch side-channel attack 16

17 Zuerst baut der Angreifer eine Verbindung zum Server auf und kann beliebige Anfragen senden und empfangen. Sendet der Client nun eine Anfrage an den Server, fängt der Angreifer diese ab, und leitet sie über seine gesicherte bestehende Verbindung weiter. Dadurch erfährt der Client einen normalen Verbindungsaufbau, während der Server die Anfrage des Clients als Neuverhandlung der bestehenden Verbindung versteht. Letztendlich interpretiert der Server daher die ursprünglichen Anfragen des Angreifers an den Server als vom Client kommend. Der Angreifer kann also beliebigen Code vor den vom Client gesendeten Code einfügen, und damit großen Schaden anrichten, auch wenn er den weiteren Datenverkehr nicht mehr abhören kann. Einfache Kontrollmethodiken für die Neuverhandlung können diesen Angriff allerdings unterbinden [14]. Ein etwas anderer Angriff namens 3Shake allerdings ermöglicht es einem Angreifer die Kommunikation komplett zu übernehmen, sich gegenüber dem Client also als Server auszugeben, ohne dass dieser erkennen kann, nicht mehr mit dem Server zu kommunizieren. Für diesen Angriff ist es notwendig, dass RSA oder DHE als Key Exchange Algorithmus verwendet wird. Ist dies der fall, kann sich der Angreifer beim Verbindungsaufbau zwischen Client und Server schalten, und nach dem ServerHello das Zertifikat des Servers durch ein eigenes ersetzen. Das ursprüngliche Zertifikat des Servers verwendet der Angreifer anschließend um die vom Client zurückkommende ClientKeyExchange Nachricht dementsprechend zu verändern, damit der Server sie annimmt. Dadurch gelangt der Angreifer in den Besitz des Master-secrets (bzw. premaster-secrets). Da aber die abschließenden Finished Nachrichten Hashes der vorherigen Nachrichten enthalten, welche von Client und Server ja unterschiedliche empfangen bzw. gesendet wurden, stimmen diese nicht überein. Weil beide Teilnehmer das bereits festgesetzte Master-secret speichern, kann mithilfe eines Session Resumption Handshakes, bei dem lediglich die Nachrichten-Schlüssel neu verhandelt werden, zwischen beiden Teilnehmern wieder eine valide Kommunikation hergestellt werden. Bei diesem Session Resumption Handshake werden die bei beiden Parteien unterschiedlichen Zertifikate nicht mehr abgefragt und daher kommt es zu einer gleichen Finished Nachricht bei Beiden, die also vom Kommunikationspartner akzeptiert wird. Somit kann der Angreifer beliebige Nachrichten an den Server senden, von denen der Server glaubt sie kämen vom Client, und danach die Verbindung zwischen beiden erfolgreich herstellen. Eine Lösung für dieses Problem ist das Verwenden eines Hashes über vorherige Nachrichten mit dem Mastersecret zusammen, sodass die vom Angreifer manipulierten Nachrichten auffallen und die Attacke nicht mehr möglich ist [15] [16] [17]. Verschlüsselungsverfahren RC4: RC4 biases attack Während lange Zeit SSL/TLS mit RC4 Verschlüsselung zwar nicht empfohlen wurde, aber dank der Schnelligkeit, und aufgrund der Tatsache, dass es noch keine Attacke gab, die die Entschlüsselung in SSL/TLS knacken konnte, von allen großen Anbietern für die Verschlüsselung verwendet wurde, wurde 2013 mit der RC4 biases attack ein Angriff veröffentlicht, mit dem geheime Daten - wie bei CRIME und seinen Nachfolgern - aus den Anfragen extrahiert werden können. 17

18 Der Angriff basiert darauf, dass über die ersten 257 Bytes einer mit RC4 verschlüsselten Nachricht statistische Aussagen getroffen werden können. Manche Werte kommen häufiger vor als andere. Da im verschlüsselten Text von RC4 jedes verschlüsselte Byte immer noch an der ursprünglichen Stelle des unverschlüsselten Bytes zu finden ist, kann mithilfe von im verschlüsselten Text bekannten Elementen wie z.b. HTTP Header oder URLs in einigen Versuchen der Klartext herausgefunden werden [9]. Als Lösung wurde RC4 modifiziert, damit die ersten paar Durchläufe des Algorightmus verworfen werden. Auch kann anstatt von RC4 ein anderer Verschlüsselungsalgorithmus verwendet werden [18]. Sichere Zertifikate? Angriffe auf die Public Key Infrastruktur Die Public Key Infrastruktur von TLS/SSL wurde ebenfalls bereits mehrfach umgangen. Verschiedene Ansatzpunkte wurden von Angreifern hier bisher ausgenutzt, um an Zertifikate zu gelangen, die nicht für sie authorisiert waren. Ein Weg führte über das Hacken einer Zertifizierungsstelle, sodass sich die Angreifer für große Anbieter wie Google oder Facebook valide Zertifikate beschaffen konnten. Damit konnten sie diese Anbieter mitsamt verschlüsselter Verbindung fälschen, wodurch ein Client mit gesicherter Verbindung auf einen solchen gefälschten Server zugreifen konnte und sicher war, auf den authentifizierten Servern unterwegs zu sein. Erst Monate später wurde entdeckt, dass diese Zertifikate erstellt wurden, und sie wurden deaktiviert. Eine andere Herangehensweise führte über CAs, die keine ausreichenden Prüfungen veranlassten. Aufgrund des Konkurrenz- und Preiskampfes zwischen den CAs werden die vorgesehenen Prüfungen bei der Zertifikat-Emission teilweise nur unzureichend durchgeführt, wodurch auch Unberechtigte oder anonyme Personen an derartige Zertifikat kommen können. Diesem Problem versuchten die größten Anbieter durch eine Erweiterung des Zertifikatsystems entgegenzuwirken. Die neu eingeführten Extended Validation Certificates werden nur nach besonders strengen Prüfungen von speziellen CAs herausgegeben, kosten dementsprechend mehr, aber werden bei allen aktuellen Browsern zusätzlich zum üblichen Schlosssymbol durch eine grün hinterlegte Browser-Bar sowie dem Namen des Zertifikatinhabers und der Zertifizierungsstelle eindeutig gekennzeichnet. Besonders Banken setzen auf die zusätzliche Sicherheit dieses Zertifikats, da jeder Benutzer leichter erkennen kann, ob er sich auch wirklich auf der richtigen Seite befindet. 4.2 Fehler in Implementierungen Heartbleed Bug in OpenSSL Im April 2014 wurde in OpenSSL - der quasi Standard-Bibliothek auf Webservern, die TLS/SSL verschlüsselte Verbindungen anbieten - der Heartbleed-Bug entdeckt. Dieser schwerwiegende Fehler in einer Erweiterung der TLS Implementierung namens Heartbeat erlaubt es einem Angreifer, geheime Daten aus dem sicheren Speicher des Servers zu extrahieren. Dazu gehören Benutzername und Passwort, aber auch die geheimen privaten Zertifikatschlüssel der Server. Die Heartbeat-Erweiterung bringt die normalerweise auf Netzwerkebene übliche Funktion, abzufragen ob die Verbindung zum Kommunikationspartner noch steht, in 18

19 die Transportschicht. Mithilfe von Heartbeat kann ein bis zu 16 kbyte großer Datenblock beliebiger Daten an den Kommunikationspartner gesendet werden, welche dieser unverändert zurücksendet. Durch einen Fehler in der Implementierung wurde allerdings nicht überprüft, ob die für den Datenblock angegebene Länge auch wirklich an Nutzdaten gesendet wurde. Dadurch kann ein Angreifer einen Datenblock von beispielsweise einem kbyte senden, aber im entsprechenden Feld eine Größe von bis zu 64 kbyte angeben 9. Der Server empfängt die Daten, speichert das kbyte an Daten in seinen speziellen, sicheren Speicher und möchte den Heartbeat zurücksenden. Hierzu holt er sich die gespeicherten Daten wieder aus dem sicheren Speicher - als Länge verwendet er die vom Client gesendeten 64 kbyte - und sendet diese zurück. Da aber nur ein kbyte an Daten überhaupt gespeichert wurde, sind die restlichen 63 kbyte an Daten aus dem Arbeitsspeicher, die mitgesendet werden, beliebige Daten von anderen Verbindungen oder Aufgaben, die der Server parallel gerade ausführt. Dieser Angriff kann sehr oft ausgeführt werden und hinterlässt beim Server keinerlei Spuren, da kein Fehler oder Absturz provoziert wird. Mithilfe der gewonnenen Geheim-Daten können dann beispielsweise TLS gesicherte Verbindungen entschlüsselt werden. Mit der Ankündigung des Fehlers von den Entwicklern wurde gleichzeitig ein entsprechender Patch herausgegeben. Die Länge des Datenpakets wird nach dem Patch korrekt überprüft [19] [20] [21]. 5 Zusammenfassung und Ausblick Der Heartbleed-Bug sorgte für Aufregung im Internet, da jegliche vermeintlich sichere Kommunikation auch aus der Vergangenheit eventuell mitgelesen worden sein könnte und auch Zugangsdaten bei quasi allen großen Diensten in andere Hände gelangt sein könnten. Trotzdem sind gut zwei Monate nach der Entdeckung bei einer Untersuchung immer noch die Hälfte der Server nicht aktualisiert worden, wodurch der Heartbleed-Bug ausgenutzt werden kann [22]. Da OpenSSL OpenSource ist, und damit der Quellcode für jedermann einsehbar und überprüfbar ist, ging man lange Zeit davon aus, dass Fehler schneller gefunden und behoben würden. Da der schwerwiegende Heartbleed-Bug jedoch vor der Entdeckung bereits 2 Jahre in der Bibliothek vorhanden war, wurde diese Erwartung enttäuscht. In der Folge bekamen die wenigen Entwickler der Bibliothek, die von Brachenriesen wie Facebook, Google oder Yahoo verwendet wird, finanzielle Unterstützung. Dadurch konnten viele weitere Fehler gefunden und behoben werden. Der immer zugrundeliegende Wettlauf zwischen Sicherheitsexperten und Hackern, die sowohl kriminellen als auch staatlichen Hintergrund haben können, setzt sich daher fort. SSL/TLS hat den großen Vorteil, dass die verwendeten Algorithmen keinesfalls fest implementiert sind, sondern immer wieder ausgetauscht werden können und müssen. Doch es hat sich gezeigt, dass auch die über 20 Jahre entwickelte Architektur des 9 Da die spezifizierte Maximalgröße von 16 kbyte nicht überprüft wird. 19

20 Protokolls noch immer Lücken aufweist, die sodass die drei Grundprinzipien Authentizität, Vertraulichkeit und Integrität auch mit SSL/TLS nicht immer gewährleistet sind. Doch die Fehler haben auch ihr Gutes: der Fokus der Öffentlichkeit und damit auch Fördergelder und Ressourcen richteten sich wieder auf SSL/TLS und werden wohl auch in Zukunft eine Erweiterung und Fortentwicklung dieses quasi einzigen internationalen Verschlüsselungsalgorithmus sicherstellen. 20