|
|
| Zeile 20: |
Zeile 20: |
|
| |
|
| == Sicherheit == | | == Sicherheit == |
| | | [[TLS/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-Angriff|Man-in-the-Middle-Angreifer]] aus dem [[Padding (Informatik)|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|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 [[Kryptoanalyse#Chosen Plaintext|Chosen-Plaintext-Angriff]] unbekannte Teile des Klartexts ermitteln
| |
| * Ein Angriffsszenario ist das Stehlen von [[HTTP-Cookie]]s, 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 [[Datenkompression|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|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 [[Hypertext Transfer Protocol#HTTP-Kompression|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änkung]]en von [[Kryptographie]] aus den [[Vereinigte Staaten|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|FREAK-Angriff]] (''Factoring RSA Export Keys'') findet ein Downgrade auf [[RSA-Kryptosystem|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-Hellman]]s 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 [[Europäisches Institut für Telekommunikationsnormen|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 [[Electronic Frontier Foundation|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 [[Common Vulnerabilities and Exposures|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'':
| |
| {{Zitat
| |
| |Text=für seine Bemühung, das ‚Enterprise Transport Security‘ Protokoll (ETS) als Teil des neuen technischen Standards für die Verschlüsselung im Internet festzulegen und damit abgesicherte Verbindungen mit einer Sollbruchstelle auszustatten
| |
| |Autor=Frank Rosengart
| |
| |Quelle=Laudatio bei den [[BigBrotherAwards]]
| |
| |ref=}}
| |
|
| |
|
| == Vor- und Nachteile == | | == Vor- und Nachteile == |
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
TLS in der Praxis
TLS/Praxis
Geschichte
TLS/Praxis
Funktionsweise
TLS/Funktionsweise
Sicherheit
TLS/Sicherheit
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:
Siehe auch
Weblinks