Transport Layer Security/TMP
Transport Layer Security (TLS, für „Transportschichtsicherheit“), auch bekannt unter der Vorgängerbezeichnung Secure Sockets Layer (SSL), ist ein Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet
TLS besteht aus den beiden Hauptkomponenten TLS Handshake und TLS Record
- Im TLS Handshake findet ein sicherer Schlüsselaustausch und eine Authentifizierung statt
- TLS Record verwendet dann den im TLS Handshake ausgehandelten symmetrischen Schlüssel für eine sichere Datenübertragung – die Daten werden verschlüsselt und mit einem MAC gegen Veränderungen geschützt übertragen
Für den Schlüsselaustausch sind in den älteren TLS-Versionen verschiedene Algorithmen mit unterschiedlichen Sicherheitsgarantien im Einsatz
- Die neueste Version TLS 1.3 verwendet allerdings nur noch das Diffie-Hellmanprotokoll (DHE oder ECDHE)
- Dabei wird für jede Verbindung ein neuer Sitzungsschlüssel (Session Key) ausgehandelt
- Da dies ohne Verwendung eines Langzeitschlüssels geschieht, erreicht TLS 1.3 Perfect Forward Secrecy
TLS in der Praxis
Geschichte
Funktionsweise
Sicherheit
Auf SSL und TLS sind jeweils eine Reihe von Angriffen bekannt, die die Sicherheitsgarantien untergraben
- Die folgende Liste stellt einen Teil der bekannten Angriffe dar
Padding-Oracle-Angriffe
Der Kryptologe Serge Vaudenay entdeckte 2002, dass ein Man-in-the-Middle-Angreifer aus dem Padding einer mit dem Cipher Block Chaining Mode (CBC) verschlüsselten Nachricht Informationen erhalten kann, die zur Entschlüsselung der Nachricht genutzt werden können
- Durch gezielte Manipulation einer verschlüsselten Nachricht lernt der Angreifer, ob der Server ein gültiges Padding meldet und damit ein Teil des Klartexts richtig erraten wurde
Als Schutzmaßnahme sollte der Server ungültige Nachrichten verwerfen, ohne dabei zu offenbaren, ob das Padding oder die Nachrichtenauthentizität ungültig war
- Allerdings kann ein Angreifer diese Information auch durch eine Analyse der Antwortzeiten herleiten (Timing-Angriff)
- Betroffen sind SSL, TLS bis Version 1.2 und DTLS, sofern eine Cipher Suite mit CBC verwendet wird
- Cipher Suites mit Authenticated Encryption sind nicht betroffen
Im Oktober 2014 demonstrierten Sicherheitsforscher den POODLE-Angriff (Padding Oracle On Downgraded Legacy Encryption), mit dem ein Angreifer ein Versions-Downgrade einer TLS-Verbindung erzwingt, um einen Padding-Oracle-Angriff gegen SSL 3.0 durchzuführen
- Zwecks Kompatibilität wurde SSL 3.0 trotz zu dem Zeitpunkt bekannter Sicherheitsschwächen noch von Webbrowsern und anderen Implementierungen unterstützt
- Im Nachgang hat die Internet Engineering Task Force SSL 3.0 als überholt gekennzeichnet
und ein Verfahren zum Schutz vor Downgrade-Angriffen auf TLS spezifiziert
BEAST
SSL 3.0 und TLS 1.0 verwenden im CBC-Modus einen vorhersagbaren Initialisierungsvektor
- Ein Angreifer kann dadurch mit einem Chosen-Plaintext-Angriff unbekannte Teile des Klartexts ermitteln
- Ein Angriffsszenario ist das Stehlen von HTTP-Cookies, die verschlüsselt übertragen werden
- Hierzu muss der Angreifer das Angriffsopfer auf eine bösartige Website locken, die wiederholt HTTP-Anfragen an eine fremde Domain auslöst, wobei der Webbrowser automatisch die für die Domain gesetzten HTTP-Cookies mitsendet
- Durch den teilweise selbst gewählten Inhalt der HTTP-Anfragen und durch Abhören der verschlüsselten TLS-Nachrichten kann der Angreifer das Cookie zeichenweise erraten
Die Grundlagen des Angriffs wurden 2004 beschrieben und 2011 erstmals in der Praxis unter dem Namen BEAST (Browser Exploit Against SSL/TLS) demonstriert
TLS-Version 1.1 und höher sind nicht betroffen, da jede Nachricht mit einem pseudozufälligen Initialisierungsvektor verschlüsselt wird
Der kryptographische Unterschied zwischen TLS 1.0 und TLS 1.1 ist marginal und es gibt einen trivialen und abwärtskompatiblen Workaround mittels 1/(n-1) TLS record splitting, welcher diesen marginalen Unterschied zwischen TLS 1.0 und TLS 1.1 formal beweisbar irrelevant macht
- Dieser triviale Workaround wurde von allen von BEAST betroffenen Anwendungen im Laufe des Jahres 2011 eingebaut
- BEAST betrifft nur Webbrowser, Java im Browser und SSL-VPNs, weil BEAST nur als Inside-Angriff möglich ist
Kompressionsangriffe
Die Verwendung der optionalen Kompression von Nutzdaten eröffnet eine Klasse von Angriffen, die das Erraten von Teilen des Klartexts ermöglichen
- Das Angriffsszenario ist ähnlich wie beim BEAST-Angriff: der Angreifer führt einen Chosen-Plaintext-Angriff durch und beobachtet die verschlüsselten TLS-Nachrichten im Netz
- Das Kompressionsverfahren entfernt Redundanzen aus den Nutzdaten, sodass der zu verschlüsselnde Klartext und damit auch der Geheimtext kürzer wird
- Hat der Angreifer einen Teil des unbekannten Klartexts erraten, zum Beispiel ein Zeichen eines HTTP-Cookies, so erfährt er dies aus dem Längenunterschied einer verschlüsselten TLS-Nachricht
Der Angriff wurde 2012 von den Urhebern des BEAST-Angriffs unter dem Namen CRIME (Compression Ratio Info-leak Made Easy) veröffentlicht
Neben SSL und TLS ist auch das SPDY-Protokoll betroffen
- Als Schutzmaßnahme wird von der Verwendung der Kompression abgeraten
- TLS ab Version 1.3 unterstützt keine Kompression mehr
- Der SPDY-Nachfolger HTTP/2 verwendet ein vereinfachtes Kompressionsformat (HPACK), das weniger effizient komprimiert als Deflate, dafür aber schwerer anzugreifen ist
TIME und BREACH sind verbesserte Varianten des Angriffs
- TIME (Timing Info-leak Made Easy) leitet die Größe einer verschlüsselten TLS-Nachricht aus der Antwortzeit her, ohne dass der Netzwerkverkehr abgehört werden muss
- Beide Angriffe erlauben das Erraten von TLS-verschlüsselten Inhalten, wenn TLS-Kompression abgeschaltet ist und stattdessen HTTP-Kompression verwendet wird
- Da TLS Kompressionsangriffe nicht grundsätzlich verhindern kann, müssen anwendungsspezifische Schutzmaßnahmen verwendet werden, zum Beispiel der vollständige Verzicht auf Kompression
Downgrade auf Exportverschlüsselung
Als Folge der Exportbeschränkungen von Kryptographie aus den Vereinigten Staaten sind in TLS zahlreiche exporttaugliche Cipher Suites spezifiziert, die nur kurze Schlüssel verwenden
- Trotz bekannter Sicherheitsschwächen wurden oder werden diese zum Teil noch von Implementierungen unterstützt
- Der TLS-Handshake soll eigentlich verhindern, dass ein Man-in-the-Middle-Angreifer einen Downgrade auf eine nicht angefragte Cipher Suite erzwingen kann, indem die Handshake-Nachrichten authentifiziert werden
- Die Sicherheit der Authentifizierung hängt allerdings auch von der ausgehandelten Cipher Suite ab, sodass der Angreifer den Schlüssel brechen kann
Beim 2015 veröffentlichten FREAK-Angriff (Factoring RSA Export Keys) findet ein Downgrade auf RSA-basierte Cipher Suites mit 512 Bit langen Exportschlüsseln statt
- Der Angriff setzt einen Implementierungsfehler voraus, bei dem der Client den 512-Bit-Schlüssel anstatt des längeren Schlüssels aus dem Serverzertifikat verwendet
- Der Fehler betraf unter anderem OpenSSL und SecureTransport (Apple)
Kurz darauf veröffentlichte ein Forscherteam den Logjam-Angriff, der einen Downgrade des Diffie-Hellmans auf 512-Bit-Restklassengruppen ermöglicht
- Ursache ist die Unterstützung von exporttauglichen Cipher Suites mit Ephemeral Diffie-Hellman
- Anders als bei FREAK handelt es sich um eine Protokollschwäche in TLS, die auch ohne Implementierungsfehler ausgenutzt werden kann
- Der Logjam-Angriff kann in der Praxis performant durchgeführt werden, da ein Großteil der Rechenarbeit zum Brechen des Schlüssels schon vor dem Verbindungsaufbau durchgeführt werden kann
- Der erforderliche Rechenaufwand während des eigentlichen Schlüsselaustauschs dauert etwa 70 Sekunden
- Als Schutzmaßnahme sollten Server die Unterstützung für exporttaugliche Cipher Suites abschalten und mindestens 2048 Bit lange Gruppen verwenden
- Clients sollten Gruppen verwerfen, die kürzer als 1024 Bit sind
Implementierungsfehler
Neben Sicherheitsschwächen im Protokoll sind TLS-Implementierungen in wiederkehrender Regelmäßigkeit von sicherheitsrelevanten Implementierungsfehlern betroffen
- Einer der schwerwiegendsten Fehler war der 2014 entdeckte Heartbleed-Bug in OpenSSL
Öffentlicher und vorsätzlicher Bruch der Verschlüsselung
Über die ETSI wurde ein sozialer Angriff auf den TLS-Standard gestartet, bei dem eine nachschlüsselfähige und daher als gebrochen anzusehende Version des Standards Eingang in allgemeine Kommunikationsprozesse finden soll
Die Angreifer leiten eine Berechtigung für ihren Angriff auf die Verschlüsselung daraus ab, dass es in der Wirtschaft, insbesondere in der Finanzindustrie, sowie bei Behörden Möglichkeiten geben müsse, übergeordneten Einblick in verschlüsselte Kommunikation zu nehmen, ohne dass die Beteiligten davon erfahren Viele Fachleute und Organisationen, wie z. B
- die EFF, warnen aufgrund der möglichen Kollateralschäden sehr deutlich vor der Nutzung dieses Verfahrens
Der Versuch, diese defekte Verschlüsselung als „eTLS“ („Enterprise TLS“) in die TLS-Familie einzuführen, wurde über die Namensrechte an TLS abgewehrt, weshalb das Verfahren in ETS umbenannt werden wird
Da ETS/eTLS als CVE von TLS anerkannt ist, kann man ETS/eTLS auch als (vorsätzlich) fehlerhafte Implementierung von TLS bezeichnen
Infolgedessen erhielt das Technical Committee CYBER des ETSI 2019 den Negativpreis BigBrotherAward: Vorlage:Zitat
Vor- und Nachteile
Der Vorteil des TLS-Protokolls ist die Möglichkeit, jedes höhere Protokoll auf Basis des TLS-Protokolls zu implementieren
- Damit ist eine Unabhängigkeit von Anwendungen und Systemen gewährleistet
Der Nachteil der TLS-verschlüsselten Übertragung besteht darin, dass der Verbindungsaufbau auf Serverseite rechenintensiv und deshalb langsamer ist
- Die Verschlüsselung selbst beansprucht je nach verwendetem Algorithmus nur wenig Rechenzeit
Verschlüsselte Daten sind auf niedrigeren Schichten (etwa auf PPTP-Ebene) kaum durch Kompression zu verdichten
TLS verschlüsselt nur die Kommunikation zwischen zwei Stationen
- Es sind Szenarien in serviceorientierten Architekturen denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird
- Wenn jede Station nur einen Teil der Nachricht lesen darf, reicht TLS nicht aus, da jede Station alle Daten der Nachricht entschlüsseln kann
- Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann
Implementierungen
Zu den bekanntesten Programmbibliotheken, die Transport Layer Security implementieren, gehören:
- OpenSSL
- GnuTLS
- LibreSSL
- Network Security Services
- mbed TLS, vormals PolarSSL
- BoringSSL
- Cryptlib
- SChannel (Microsoft)
- WolfSSL
Siehe auch
Weblinks
- TLS-Arbeitsgruppe der IETF
- Vorlage:RFC-Internet
- Vorlage:Webarchiv
- Einführung in SSL von Markus Repges Beschreibt Handshake und Protokoll im Detail
- Funktionsweise einer SSL-Verschlüsselung von Websites im Video
- Aktuelle Richtlinie BSI TR-02102-2 „Kryptographische Verfahren: Verwendung von Transport Layer Security (TLS)“ (PDF) mit Auflistung der empfohlenen Cipher Suiten für TLS 1.2 und 1.3; Stand: Februar 2019