SSL

Aus Kryptowiki - Die freie Enzyklopädie der Kryptowährungen
Wechseln zu: Navigation, Suche
TLS im TCP/IP-Protokollstapel
Anwendung HTTPS IMAPS POP3S SMTPS
Transport TLS
TCP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token
Bus
Token
Ring
FDDI

Transport Layer Security (TLS, englisch für Transportschichtsicherheit), weitläufiger bekannt unter der Vorgängerbezeichnung Secure Sockets Layer (SSL), ist ein hybrides Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet. Die letzte Version des SSL-Protokolls war 3.0 und danach wurde es unter dem neuen Namen TLS, beginnend mit Version 1.0, weiterentwickelt und standardisiert. (Zwar werden protokollintern die Werte 3 und 1 verwendet, um TLS 1.0 zu repräsentieren, offiziell gibt es aber kein SSL 3.1.) In diesem Artikel wird die Abkürzung TLS für beide Bezeichnungen verwendet, sofern nicht explizit auf die alten Versionen Bezug genommen wird.

Bekannte Implementierungen des Protokolls sind OpenSSL, LibreSSL und GnuTLS.

TLS in der Praxis[Bearbeiten]

TLS-Verschlüsselung wird gegenwärtig vor allem mit HTTPS eingesetzt. Die meisten Webserver unterstützen TLS 1.0, viele auch SSLv2 und SSLv3 mit einer Vielzahl von Verschlüsselungsmethoden, fast alle Browser und Server setzen jedoch bevorzugt TLS mit RSA- und AES- oder Camellia-Verschlüsselung ein. In aktuellen Browsern ist SSLv2 deaktiviert oder führt zu einer Sicherheitswarnung,[1] da diese Protokollversion eine Reihe von Sicherheitslücken[2][3] aufweist. Seit dem Bekanntwerden des Poodle-Angriffs auf die Verschlüsselung mit SSL gilt dies bei vielen Servern und Browsern auch für SSLv3. Die Weiterentwicklung TLS 1.1 wird von Google Chrome unterstützt, TLS 1.2 wird in der Standardkonfiguration von Internet Explorer, Firefox, Google Chrome, Opera und Apple iOS Safari verwendet (Stand 02/2014).[4]

Seit einiger Zeit nutzen immer mehr Webseitenbetreiber Extended-Validation-TLS-Zertifikate (EV-TLS-Zertifikat). In der Adresszeile des Browsers wird zusätzlich ein Feld angezeigt, in dem Zertifikats- und Domaininhaber im Wechsel mit der Zertifizierungsstelle eingeblendet werden. Zudem wird je nach verwendetem Browser und/oder Add-on die Adresszeile (teilweise) grün eingefärbt. Internetnutzer sollen so noch schneller erkennen, ob die besuchte Webseite echt ist, und besser vor Phishingversuchen geschützt werden. EV-TLS-Zertifikate bieten in technischer Sicht keinen erweiterten Schutz, die Verschlüsselung und deren Stärke ist identisch. Nur der Inhaber wird dabei besser und aufwändiger verifiziert. Deshalb benutzt Google generell keine EV-Zertifikate.[5]

Seit Januar 2017 markiert der Web-Browser Chrome Internetseiten als unsicher, die Informationen sammeln, ohne dabei HTTPS zu nutzen. Dies wird voraussichtlich zu einem signifikanten Anstieg des Einsatzes von HTTPS führen. Im Februar 2017 war HTTPS bei 2,57 % aller registrierten deutschen Internet-Domains[6] sowie bei 3,70 % der österreichischen Domains[7] und 9,71 % der Schweizer Domains[8] aktiviert. Eine Untersuchung von rund 40.000 Webseiten klein- und mittelständischer Unternehmen in Baden-Württemberg durch den Landesbeauftragten für den Datenschutz und die Informationsfreiheit Baden-Württemberg hat ergeben, dass rund 7 % der untersuchten Webseiten über HTTPS angeboten werden. Bei jenen Webseiten, die über HTTPS angeboten werden, ist die serverseitige Unterstützung für TLS 1.0 noch sehr weit verbreitet (99 %).[9]

TLS ist ohne eine zertifikatsbasierte Authentifizierung anfällig für Man-in-the-Middle-Angriffe: Ist der Man-in-the-Middle vor der Übergabe des Schlüssels aktiv, kann er beiden Seiten seine Schlüssel vorgaukeln und so den gesamten Datenverkehr im Klartext aufzeichnen und unbemerkt manipulieren. Wegen der mangelnden Vertrauenswürdigkeit einiger Zertifizierungsstellen wird seit Anfang 2010 die Sicherheit von TLS grundsätzlich angezweifelt.[10][11][12][13] Durch die Deaktivierung fragwürdiger Zertifizierungsstellen im eigenen Browser lässt sich dieses Risiko jedoch weitgehend beseitigen.

In Verbindung mit einem virtuellen Server, zum Beispiel mit HTTP (etwa beim Apache HTTP Server über den VHost-Mechanismus), ist es grundsätzlich als Nachteil zu werten, dass pro Kombination aus IP-Adresse und Port nur ein Zertifikat verwendet werden kann, da die eigentlichen Nutzdaten des darüber liegenden Protokolls (und damit der Name des VHosts) zum Zeitpunkt des TLS-Handshakes noch nicht übertragen wurden. Dieses Problem wurde mit der TLS-Erweiterung Server Name Indication (SNI) im Juni 2003 durch die RFC 3546 behoben. Dabei wird bereits beim Verbindungsaufbau der gewünschte Servername mitgesendet. Die ursprüngliche Erweiterung wurde für TLS 1.0 beschrieben, aufgrund der Kompatibilität der einzelnen TLS-Versionen zueinander wird SNI auch bei TLS 1.1 und TLS 1.2 entsprechend der Empfehlung umgesetzt.

Neben HTTPS als verschlüsselte Variante von HTTP sind weitere bekannte Anwendungsfälle für TLS beispielsweise:

Versionen[Bearbeiten]

Version Erscheinungsjahr Bemerkungen
Old version, no longer supported: SSL 1.0 1994
Old version, no longer supported: SSL 2.0 1995 Seit 2011 "deprecated (prohibited)" durch RFC 6176.
Old version, no longer supported: SSL 3.0 1996 Seit Juni 2015 "deprecated" durch RFC 7568.
Old version, no longer supported: SSL 3.1 bzw. TLS 1.0 1999 Entspricht seit 30. Juni 2018 nicht mehr PCI Data Security Standard (PCI DSS)[14]
Older version, yet still supported: TLS 1.1 2006
Older version, yet still supported: TLS 1.2 2008
Current stable version: TLS 1.3 2018[15] Entwurf seit April 2014[16]
Legend: Old version Older version, still supported Current stable version Latest preview version Future release

Geschichte[Bearbeiten]

  • 1994, neun Monate nach der ersten Ausgabe von Mosaic, dem ersten verbreiteten Webbrowser, stellte Netscape Communications die erste Version von SSL (1.0) fertig.
  • Fünf Monate später wurde zusammen mit einer neuen Ausgabe des Netscape Navigator die nächste Version SSL 2.0 veröffentlicht.
  • Ende 1995 veröffentlichte Microsoft die erste Version seines Webbrowsers Internet Explorer. Kurz darauf wurde auch die erste Version ihres SSL-Pendants bekannt, PCT 1.0 (Private Communication Technology). PCT hatte einige Vorteile gegenüber SSL 2.0, die später in SSL 3.0 aufgenommen wurden.
  • Als SSL von der IETF im RFC 2246 als Standard festgelegt wurde, benannte man es im Januar 1999 um zu Transport Layer Security (TLS). Die Unterschiede zwischen SSL 3.0 und TLS 1.0 sind nur gering. Doch entstanden durch die Umbenennung Versionsverwirrungen. So meldet sich TLS 1.0 im Header als Version SSL 3.1.
  • Später wurde TLS durch weitere RFCs erweitert:
    • RFC 2712 – Addition of Kerberos Cipher Suites to Transport Layer Security (TLS).
    • RFC 2817 – Upgrading to TLS Within HTTP/1.1 erläutert die Benutzung des Upgrade-Mechanismus in HTTP/1.1, um Transport Layer Security (TLS) über eine bestehende TCP-Verbindung zu initialisieren. Dies erlaubt es, für unsicheren und für sicheren HTTP-Verkehr die gleichen „well-known“ TCP Ports (80 bzw. 443) zu benutzen.
    • RFC 2818 – HTTP Over TLS trennt sicheren von unsicherem Verkehr durch Benutzung eines eigenen Server-TCP-Ports.
    • RFC 3268 – Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) nutzt die Erweiterbarkeit von TLS und fügt den bisher unterstützten symmetrischen Verschlüsselungsalgorithmen (RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES) und Triple DES) den Advanced Encryption Standard (AES) hinzu.
    • RFC 3546 – Transport Layer Security (TLS) Extensions führt das Konzept der Erweiterungen ein, durch welches optionale Datenfelder oder Header vor allem bei der anfänglichen Aushandlung übertragen werden können. Eine der wohl bekanntesten Erweiterungen ist Server Name Indication.
  • Im April 2006 wurde in RFC 4346 die Version 1.1 von TLS standardisiert und damit RFC 2246 obsolet. In TLS 1.1 wurden kleinere Sicherheitsverbesserungen vorgenommen und Unklarheiten beseitigt.
  • Im August 2008 erschien mit RFC 5246 die Version 1.2 von TLS, welche somit RFC 4346 obsolet machte. Als wesentliche Änderung wurde die Festlegung auf MD5/SHA-1 in der Pseudozufallsfunktion (PRF) und bei signierten Elementen fallen gelassen. Stattdessen wurden flexiblere Lösungen gewählt, bei denen die Hash-Algorithmen spezifiziert werden können.
  • Für die Version 1.3 liegt seit Januar 2015 ein Entwurf vorVorlage:Zukunft.[17]
  • Im Februar 2015 wurde RFC 7465[18] veröffentlicht, das RC4 für Verschlüsselung verbietet.[19]
  • Im Mai 2015 wurden mit RFC 7525,[20] basierend auf dem aktuellen Stand der Technik, Empfehlungen für den sicheren Einsatz von TLS und DTLS veröffentlicht. Diese spezifizieren, dass unter anderem SSLv2, SSLv3, RC4 und sonstige aufgrund von Exportbeschränkungen auf weniger als 112 Bit Schlüssellänge beschränkte Verschlüsselungsalgorithmen nicht verwendet werden dürfen. Vom Einsatz von 3DES zur Verschlüsselung und RSA zum Schlüsselaustausch mit statischen Parametern wird abgeraten. Konkret zum Einsatz empfohlen werden Cipher Suites, die zum Schlüsselaustausch Ephemeral Diffie-Hellman in Kombination mit RSA verwenden, was Forward Secrecy (gegen späteres nachträgliches Entschlüsseln) bietet, zur Verschlüsselung AES im Galois/Counter Mode mit 128 oder 256 Bit Schlüssellänge sowie die Hashfunktion SHA-256 oder SHA-384 für die Pseudozufallsfunktion von TLS.[21]

Funktionsweise[Bearbeiten]

Der Client baut eine Verbindung zum Server auf. Der Server authentifiziert sich gegenüber dem Client mit einem Zertifikat. Der Client überprüft hierbei die Vertrauenswürdigkeit des X.509-Zertifikats und ob der Servername mit dem Zertifikat übereinstimmt. Optional kann sich der Client mit einem eigenen Zertifikat auch gegenüber dem Server authentifizieren. Dann schickt entweder der Client dem Server eine mit dem öffentlichen Schlüssel des Servers verschlüsselte geheime Zufallszahl, oder die beiden Parteien berechnen mit dem Diffie-Hellman-Schlüsselaustausch ein gemeinsames Geheimnis. Aus dem Geheimnis wird dann ein kryptographischer Schlüssel abgeleitet. Dieser Schlüssel wird in der Folge benutzt, um alle Nachrichten der Verbindung mit einem symmetrischen Verschlüsselungsverfahren zu verschlüsseln und zum Schutz von Nachrichten-Integrität und Authentizität durch einen Message Authentication Code abzusichern.

TLS-Protokolle im Protokollstapel[Bearbeiten]

Im OSI-Modell ist TLS in Schicht 5 (der Sitzungsschicht) angeordnet. Im TCP/IP-Modell ist TLS oberhalb der Transportschicht (zum Beispiel TCP) und unterhalb Anwendungsprotokollen wie HTTP oder SMTP angesiedelt. In den Spezifikationen wird dies dann zum Beispiel als „HTTP over TLS“ bezeichnet. Sollen jedoch beide Protokolle zusammengefasst betrachtet werden, wird üblicherweise ein „S“ für Secure dem Protokoll der Anwendungsschicht angehängt (zum Beispiel HTTPS). TLS arbeitet transparent, so dass es leicht eingesetzt werden kann, um Protokollen ohne eigene Sicherheitsmechanismen abgesicherte Verbindungen zur Verfügung zu stellen. Zudem ist es erweiterbar, um Flexibilität und Zukunftssicherheit bei den verwendeten Verschlüsselungstechniken zu gewährleisten.

Das TLS-Protokoll besteht aus zwei Schichten:

TLS Handshake Protocol TLS Change Cipher Spec. Protocol TLS Alert Protocol TLS Application Data Protocol
TLS Record Protocol

TLS Record Protocol[Bearbeiten]

Das TLS Record Protocol ist die untere der beiden Schichten und dient zur Absicherung der Verbindung. Es setzt direkt auf der Transportschicht auf und bietet zwei verschiedene Dienste, die einzeln oder gemeinsam genutzt werden können:

Außerdem werden zu sichernde Daten in Blöcke von maximal 16.384 (214) Byte fragmentiert und beim Empfänger wieder zusammengesetzt. Dabei schreibt der Standard vor, dass die Blockgröße diesen Wert nicht übersteigt, außer der Block ist komprimiert oder verschlüsselt – dann darf die Blockgröße um 1024 Byte (bei Kompression) bzw. 2048 Byte (bei Verschlüsselung) größer sein. Auch können die Daten vor dem Verschlüsseln und vor dem Berechnen der kryptografischen Prüfsumme komprimiert werden. Das Komprimierungsverfahren wird ebenso wie die kryptografischen Schlüssel mit dem TLS Handshake-Protokoll ausgehandelt.

Der Aufbau einer TLS-Record-Nachricht lautet wie folgt: Content Type (1 Byte: Change Cipher Spec = 20, Alert = 21, Handshake = 22, Application Data = 23) | Protokollversion Major (1 Byte) | Protokollversion Minor (1 Byte) | Länge (1 Short bzw. zwei Byte)

TLS Handshake Protocol[Bearbeiten]

TLS-Handshake mit Zwei-Wege-Authentifizierung mittels Zertifikaten

Das TLS Handshake Protocol baut auf dem TLS Record Protocol auf und erfüllt die folgenden Funktionen, noch bevor die ersten Bits des Anwendungsdatenstromes ausgetauscht wurden:

  • Identifikation und Authentifizierung der Kommunikationspartner auf Basis asymmetrischer Verschlüsselungsverfahren und Public-Key-Kryptografie. Dieser Schritt ist optional eine Zwei-Wege-Authentifizierung (in diesem Fall wird manchmal von mutual TLS gesprochen), für gewöhnlich authentifiziert sich aber nur der Server gegenüber dem Client.
  • Aushandeln zu benutzender kryptografischer Algorithmen und Schlüssel. TLS unterstützt auch eine unverschlüsselte Übertragung.

Der Handshake selbst kann in vier Phasen unterteilt werden:

  1. Der Client schickt zum Server ein client_hello, und der Server antwortet dem Client mit einem server_hello. Die Parameter der Nachrichten sind:
    • die Version (die höchste vom Client unterstützte TLS-Protokoll-Version)
    • eine 32 Byte Zufallsinformation (4 Byte Timestamp + 28 Byte lange Zufallszahl), die später verwendet wird, um das pre-master-secret zu bilden (sie schützt damit vor Replay-Attacken)
    • eine Session-ID
    • die zu verwendende Cipher Suite (Algorithmen für Schlüsselaustausch, Verschlüsselung und Authentifizierung)
    • Optional den gewünschten FQDN für die Unterstützung von Server Name Indication
  2. Der Server identifiziert sich gegenüber dem Client. Hier wird auch das X.509v3-Zertifikat zum Client übermittelt. Außerdem kann der Server einen CertificateRequest an den Client schicken. Diese Phase darf nur bei anonymem Key Agreement weggelassen werden.
  3. Hier identifiziert sich der Client gegenüber dem Server. Besitzt der Client kein Zertifikat, antwortete er früher mit einem NoCertificateAlert. TLS-konforme Systeme verwenden diesen Alert jedoch nicht. Der Client versucht außerdem, das Zertifikat, das er vom Server erhalten hat, zu verifizieren (bei Misserfolg wird die Verbindung abgebrochen). Dieses Zertifikat enthält den öffentlichen Schlüssel des Servers. Wird die Cipher-Suite RSA verwendet, so wird das vom Client generierte pre-master-secret mit diesem öffentlichen Schlüssel verschlüsselt und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden. Alternativ kann hier auch das Diffie-Hellman-Verfahren verwendet werden, um ein gemeinsames pre-master-secret zu generieren. Werden die Diffie-Hellman Geheimnisse von Server und Client während des Handshakes frisch und zufällig gewählt, sind die Voraussetzungen für Perfect Forward Secrecy erfüllt. Diese Phase ist optional.
  4. Diese Phase schließt den Handshake ab. Aus dem vorhandenen pre-master-secret kann das Master Secret abgeleitet werden und aus diesem der einmalige Sitzungsschlüssel (englisch „session key“). Das ist ein einmalig benutzbarer symmetrischer Schlüssel, der während der Verbindung zum Ver- und Entschlüsseln der Daten genutzt wird. Die Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, werden nur noch verschlüsselt übertragen.

TLS Change Cipher Spec Protocol[Bearbeiten]

Das Change Cipher Spec Protocol besteht nur aus einer einzigen Nachricht. Diese Nachricht ist ein Byte groß und besitzt den Inhalt 1. Durch diese Nachricht teilt der Sender dem Empfänger mit, dass er in der aktiven Sitzung auf die im Handshake Protocol ausgehandelte Cipher Suite wechselt. Ein wesentlicher Grund für die Definition eines eigenen Protokolls für diese Nachricht besteht darin, dass TLS-Implementierungen mehrere Nachrichten eines Protokolls in einem Record (also einer TLS-Dateneinheit) zusammenfassen können. Für die Nachricht „Change Cipher Spec“ ist das unerwünscht. Weil Records verschiedener Protokolle nicht zusammengefasst werden dürfen, ist das Problem durch Definition eines eigenen Protokolls gelöst.[22]

TLS Alert Protocol[Bearbeiten]

Das Alert Protocol unterscheidet etwa zwei Dutzend verschiedene Mitteilungen. Eine davon teilt das Ende der Sitzung mit (close_notify). Andere beziehen sich zum Beispiel auf die Protokollsyntax oder die Gültigkeit der verwendeten Zertifikate. Es wird zwischen Warnungen und Fehlern unterschieden, wobei letztere die Verbindung sofort beenden.

Der Aufbau einer Fehlermeldung lautet wie folgt: AlertLevel (1 Byte: Warning = 1, Fatal = 2) | AlertDescription (1 Byte: close_notify = 0, […], no_renegotiation = 100).

In der Spezifikation von TLS werden die folgenden schweren Fehlertypen definiert:

unexpected_message Unpassende Nachricht wurde empfangen.
bad_record_mac Ein falscher MAC wurde empfangen.
decompression_failure Dekomprimierungsalgorithmus empfing unkorrekte Daten.
handshake_failure Absender konnte keine akzeptable Menge von Sicherheitsparametern bearbeiten.
illegal_parameter Ein Feld in der Handshake-Nachricht lag außerhalb des erlaubten Bereichs oder stand im Widerspruch mit anderen Feldern.

In der Spezifikation von TLS werden die folgenden Warnungen definiert:

close_notify Teilt Empfänger mit, dass Absender keine weiteren Nachrichten auf dieser Verbindung senden wird. Muss von jedem Partner einer Verbindung als letzte Nachricht gesendet werden.
no_certificate Kann als Antwort auf eine Zertifikatanforderung gesendet werden, falls passendes Zertifikat nicht verfügbar ist. (Wurde in TLS 1.0 entfernt[23])
bad_certificate Empfangenes Zertifikat war unvollständig oder falsch.
unsupported_certificate Der Typ des empfangenden Zertifikats wird nicht unterstützt.
certificate_revoked Zertifikat wurde vom Unterzeichner zurückgerufen.
certificate_expired Zertifikat ist abgelaufen.
certificate_unknown Andere, nicht genau spezifizierte Gründe sind beim Bearbeiten des Zertifikats aufgetreten, die dazu führen, dass das Zertifikat als ungültig gekennzeichnet wurde.

In der Spezifikation von TLS 1.0 wurden folgende Warnungen ergänzt:[23]

decryption_failed Entschlüsselung fehlgeschlagen.
record_overflow
unknown_ca Unbekannte oder nicht vertrauenswürdige CA.
access_denied Zugriff verweigert.
decode_error Decodierungsfehler.
decrypt_error Entschlüsselungsfehler.
export_restriction Exportbeschränkung.
protocol_version Veraltete Version von TLS/SSL.
insufficient_security Unzureichende Sicherheit.
internal_error Interner Fehler.
user_canceled Abbruch durch Benutzer.
no_renegotiation

TLS Application Data Protocol[Bearbeiten]

Die Anwendungsdaten werden über das Record Protocol transportiert, in Teile zerlegt, komprimiert und in Abhängigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt. Inhaltlich werden sie von TLS nicht näher interpretiert.

Berechnung des Master Secrets[Bearbeiten]

Aus dem pre-master-secret wird in früheren Protokollversionen mit Hilfe der Hashfunktionen SHA-1 und MD5, in TLS 1.2 mit Hilfe einer durch eine Cipher Suite spezifizierten Pseudozufallsfunktion das Master Secret berechnet. In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein. Die Verwendung beider Hash-Funktionen sollte sicherstellen, dass das Master Secret immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt. In TLS 1.2 wird dieser Ansatz durch die flexible Austauschbarkeit der Funktion ersetzt.

Sicherheit[Bearbeiten]

Auf SSL und TLS sind jeweils eine Reihe von Angriffen bekannt, die die Sicherheitsgarantien untergraben.[24] Die folgende Liste stellt einen Teil der bekannten Angriffe dar.

Padding-Oracle-Angriffe[Bearbeiten]

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.[25]

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.[26]

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[27] und ein Verfahren zum Schutz vor Downgrade-Angriffen auf TLS spezifiziert.[28]

BEAST[Bearbeiten]

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[29] und 2011 erstmals in der Praxis unter dem Namen BEAST (Browser Exploit Against SSL/TLS) demonstriert.[30][31] TLS-Version 1.1 und höher sind nicht betroffen, da jede Nachricht mit einem pseudozufälligen Initialisierungsvektor verschlüsselt wird.

Kompressionsangriffe[Bearbeiten]

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.[32] 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.[33]

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.[34] 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[Bearbeiten]

Als Folge der Exportbeschränkungen von Kryptographie aus den Vereinigten Staaten sind in TLS zahlreiche exporttaugliche Cipher Suites spezifiziert, die kurze Schlüssellängen 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.[35] Der Angriff setzt einen Implementierungsfehler voraus, bei dem der Client den 512-Bit-Schlüssel anstatt des längeren Schlüssel aus dem Serverzertifikat verwendet. Der Fehler betraf unter anderem OpenSSL und SecureTransport (Apple).[36][37]

Kurz darauf veröffentlichte ein Forscherteam den Logjam-Angriff, der einen Downgrade des Diffie-Hellman-Schlüsselaustauschs auf 512-Bit-Restklassengruppen ermöglicht. Ursache ist die Unterstützung von exporttauglichen Cipher Suites mit Ephemeral Diffie-Hellman.[38] 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.[39]

Implementierungsfehler[Bearbeiten]

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.

Vor- und Nachteile[Bearbeiten]

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[Bearbeiten]

Zu den bekanntesten Programmbibliotheken, die Transport Layer Security implementieren, gehören:

Siehe auch[Bearbeiten]

Literatur[Bearbeiten]

  • Eric Rescorla: SSL and TLS. Designing and building secure systems. Addison-Wesley, New York NY u. a. 2001, ISBN 0-201-61598-3.
  • Roland Bless u. a.: Sichere Netzwerkkommunikation. Grundlagen, Protokolle und Architekturen. Springer Verlag, Berlin u. a. 2005, ISBN 3-540-21845-9, (X.systems.press).
  • Claudia Eckert: IT-Sicherheit. Konzepte – Verfahren – Protokolle. 6. überarbeitete Auflage. Oldenbourg, München u. a. 2009, ISBN 978-3-486-58999-3.

Externe Links[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Firefox kann keine sichere Verbindung aufbauen weil die Website eine ältere unsichere Version des SSL-Protokolls verwendet. Abgerufen am 19. Januar 2016.
  2. SSLv2 insecure – should be disabled by default. Abgerufen am 19. Januar 2016.
  3. On SSL 2 and older protocols. Abgerufen am 19. Januar 2016.
  4. Firefox 27 verschlüsselt mit TLS 1.2. Abgerufen am 19. Januar 2016.
  5. Does Google use extended validation certificates? In: security.stackexchange.com. Abgerufen am 27. August 2016.
  6. Deutsch Internet Statistiken reflecte.de. Abgerufen am 22. Februar 2017 (deutsch).
  7. Österreichisch Internet Statistiken reflecte.at. Abgerufen am 22. Februar 2017 (deutsch).
  8. Schweizerisch Internet Statistiken avidom.ch. Abgerufen am 22. Februar 2017 (deutsch).
  9. Ronald Petrlic, Klaus Manny: Wie sicher ist der Zugriff auf Websites im Internet? In: Datenschutz und Datensicherheit - DuD. Band 41, Nr. 2, 3. Februar 2017, ISSN 1614-0702, S. 88–92, doi:10.1007/s11623-017-0734-y.
  10. EFF zweifelt an Abhörsicherheit von SSL. Abgerufen am 19. Januar 2016.
  11. New Research Suggests That Governments May Fake SSL Certificates. Abgerufen am 19. Januar 2016.
  12. Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL. Abgerufen am 19. Januar 2016 (PDF, english).
  13. Law Enforcement Appliance Subverts SSL. Abgerufen am 19. Januar 2016.
  14. Are You Ready for 30 June 2018? Saying Goodbye to SSL/early TLS. Abgerufen am 19. Juli 2018 (english).
  15. [TLS Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt).] Abgerufen am 31. März 2018.
  16. Eric Rescorla <ekr@rtfm.com>: The Transport Layer Security (TLS) Protocol Version 1.3. Abgerufen am 2. Juni 2018 (english).
  17. The Transport Layer Security (TLS) Protocol Version 1.3. Abgerufen am 19. Januar 2016.
  18. Prohibiting RC4 Cipher Suites. Abgerufen am 20. Februar 2015.
  19. Jürgen Schmidt: IETF verbietet RC4-Verschlüsselung in TLS. Heise Security, 20. Februar 2015, abgerufen am 20. Februar 2015.
  20. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Abgerufen am 10. Mai 2015.
  21. Jürgen Schmidt: IETF spezifiziert Richtlinien für den Einsatz von Verschlüsselung. Heise Security, 8. Mai 2015, abgerufen am 10. Mai 2015.
  22. Joshua Davies: Implementing SSL / TLS Using Cryptography and PKI. John Wiley and Sons, Indianapolis 2011, S. 344.
  23. 23,0 23,1 Schwenk, Jörg (2010): Sicherheit und Kryptographie im Internet. Von sicherer E-Mail bis zu IP-Verschlüsselung, herausgegeben von Vieweg+Teubner Verlag / GWV Fachverlage GmbH, Wiesbaden. ISBN 978-3-8348-0814-1.
  24. Y. Sheffer, R. Holz, P. Saint-Andre: RFC 7457: Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS). In: Request for Comments. Internet Engineering Task Force, Februar 2015, abgerufen am 10. Januar 2016.
  25. Serge Vaudenay: Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS... In: Advances in Cryptology – EUROCRYPT 2002 (= Lecture Notes in Computer Science). Band 2332. Springer, Berlin / Heidelberg 2002, S. 535–545, doi:10.1145/586110.586125 (iacr.org [PDF]).
  26. Nadhem J. AlFardan, Kenneth G. Paterson: Lucky Thirteen: Breaking the TLS and DTLS Record Protocols. In: IEEE Symposium on Security and Privacy. IEEE, 2013, S. 526–540, doi:10.1109/SP.2013.42 (ieee-security.org [PDF]).
  27. R. Barnes, M. Thomson, A. Pironti, A. Langley: RFC 7568: Deprecating Secure Sockets Layer Version 3.0. In: Request for Comments. Internet Engineering Task Force, Juni 2015, abgerufen am 10. Januar 2016.
  28. B. Moeller, A. Langley: RFC 7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks. In: Request for Comments. Internet Engineering Task Force, April 2015, abgerufen am 10. Januar 2016.
  29. Gregory V. Bard: The Vulnerability of SSL to Chosen Plaintext Attack. In: Cryptology ePrint Archive. 2004, doi:10.1145/586110.586125 (iacr.org [PDF]).
  30. Thai Duong, Juliano Rizzo: Here Come The Ninjas. 13. Mai 2011, abgerufen am 10. Januar 2016 (PDF).
  31. Juliano Rizzo, Thai Duong: Browser Exploit Against SSL/TLS. 3. Oktober 2011, abgerufen am 10. Januar 2016.
  32. Juliano Rizzo, Thai Duong: The CRIME attack. 2012, abgerufen am 11. Januar 2016 (PDF, Präsentation bei der Ekoparty 2012.).
  33. R. Peon, H. Ruellan: RFC 7541: HPACK: Header Compression for HTTP/2. In: Request for Comments. Internet Engineering Task Force, Mai 2015, abgerufen am 11. Januar 2016.
  34. Tal Be'ery, Amichai Shulman: A Perfect CRIME? Only TIME Will Tell. 2013, abgerufen am 11. Januar 2016 (PDF).
  35. Cipher Suites mit „RSA_EXPORT“ im Namen.
  36. Benjamin Beurdouche, Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Markulf Kohlweiss, Alfredo Pironti, Pierre-Yves Strub, Jean Karim Zinzindohoue: A Messy State of the Union: Taming the Composite State Machines of TLS. In: IEEE Symposium on Security and Privacy. IEEE, 2015, S. 535–552, doi:10.1109/SP.2015.39 (research.microsoft.com [PDF]).
  37. Benjamin Beurdouche, Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Markulf Kohlweiss, Alfredo Pironti, Pierre-Yves Strub, Jean Karim Zinzindohoue: A messy state of the union: Taming the Composite State Machines of TLS. 2015, abgerufen am 11. Januar 2016 (PDF, Präsentationsfolien.).
  38. Cipher Suites mit „DHE_EXPORT“ im Namen.
  39. David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Béguelin, Paul Zimmermann: Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice. In: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. ACM, New York 2015, S. 5–17, doi:10.1145/2810103.2813707 (weakdh.org [PDF]).
  40. Google entwickelt eigene SSL-Bibliothek auf heise online

Spenden-Adressen:
Bitcoin Icon BTC: 1EoecgUZnAjamUYaKstqwbremQqbucTaoZ
Ethereum Icon ETH: 0x0D2Ab63dfe70a7fA12f9d66eCfEA9dDc8F5173A8
XEM Icon XEM: NBZPMU-XES6ST-ITEBR3-IHAPTR-APGI3Y-RAAMHV-VZFJ
Verge Icon XVG: DGYmzxoe3ryK6MnsR13GqR9r1NThpxPcKs