Wikipedia · einfach zusammengefasst · Stand
Transport Layer Security
Während des TLS Handshake finden ein sicherer Schlüsselaustausch und eine zertifikatsbasierte Authentifizierung statt. Für die verschlüsselte und geschützte …
Inhalt6 Abschnitte
Grundidee und Einsatz
Transport Layer Security (TLS), früher Secure Sockets Layer (SSL), ist ein offizielles Internetprotokoll zur sicheren Datenübertragung. Es schützt beispielsweise HTTPS, IMAPS, POP3S, SMTPS, FTPS, OpenVPN sowie DNS over TLS, DNS over HTTPS und DNS over QUIC. Auch Datenbankverbindungen lassen sich damit verschlüsseln und die beteiligten Systeme authentifizieren.
TLS liegt im TCP/IP-Modell zwischen Transportprotokollen wie TCP und Anwendungsprotokollen wie HTTP oder SMTP; im OSI-Modell wird es der Sitzungsschicht zugeordnet. Es arbeitet für Anwendungen weitgehend transparent und kann daher Protokolle absichern, die keine eigenen Sicherheitsmechanismen besitzen.
Die zwei zentralen Aufgaben sind:
- Der TLS Handshake baut die sichere Verbindung auf. Die Beteiligten handeln Algorithmen und Schlüssel aus und authentifizieren mindestens den Server anhand eines Zertifikats.
- Das TLS Record Protocol überträgt anschließend die geschützten Daten mit symmetrischer Verschlüsselung und Integritätsschutz.
TLS 1.3 verwendet für den Schlüsselaustausch DHE oder ECDHE, also Varianten des Diffie-Hellman-Verfahrens. Für jede Verbindung entsteht ein neuer Sitzungsschlüssel ohne Verwendung eines Langzeitschlüssels. Dadurch wird Perfect Forward Secrecy erreicht: Auch wenn ein langfristiger Schlüssel später bekannt wird, können frühere Sitzungen nicht nachträglich damit entschlüsselt werden.
Verbindungsaufbau und Schlüssel
Zu Beginn sendet der Client ein ClientHello, auf das der Server mit einem ServerHello antwortet. Dabei werden unter anderem die unterstützte TLS-Version, eine Session-ID, die Cipher Suite und Zufallsinformationen ausgetauscht. Eine Cipher Suite legt die Verfahren für Schlüsselaustausch, Verschlüsselung und Authentifizierung fest. In älteren Abläufen umfasst die Zufallsinformation 32 Byte: 4 Byte Zeitstempel und 28 Byte Zufallszahl. Optional übermittelt der Client über Server Name Indication (SNI) den gewünschten vollständigen Domainnamen. Bei TLS 1.3 werden bereits Key-Shares für den Diffie-Hellman-Schlüsselaustausch gesendet.
Der Server schickt ein X.509v3-Zertifikat. Der Client prüft dessen Vertrauenswürdigkeit, Gültigkeit und Übereinstimmung mit dem Servernamen. Mit CertificateVerify kann der Server durch eine digitale Unterschrift beweisen, dass er den zum öffentlichen Zertifikatsschlüssel gehörenden geheimen Schlüssel besitzt. Schlägt die Prüfung fehl, beendet der Client die Verbindung.
Danach entsteht ein gemeinsames pre-master-secret. Bei einem älteren RSA-Schlüsselaustausch erzeugt der Client es und verschlüsselt es mit dem öffentlichen Schlüssel des Servers. Beim Diffie-Hellman-Verfahren berechnen beide Seiten das gemeinsame Geheimnis. Werden die Diffie-Hellman-Geheimnisse für jeden Handshake neu und zufällig gewählt, erfüllt die Verbindung die Voraussetzung für Perfect Forward Secrecy.
Optional fordert der Server mit CertificateRequest ein Client-Zertifikat an. Authentifizieren sich beide Seiten mit Zertifikaten, spricht man von mutual TLS oder mTLS. Der Client beweist dabei mit CertificateVerify ebenfalls den Besitz seines geheimen Schlüssels. mTLS wird unter anderem zwischen Unternehmen, zwischen Servern und bei der Anmeldung mit Chipkarten eingesetzt.
Aus dem pre-master-secret wird das Master Secret und daraus werden die Schlüssel für Ver- und Entschlüsselung sowie Integritätsprüfung abgeleitet. In älteren Versionen dienen dazu SHA-1 und MD5; TLS 1.2 nutzt eine durch die Cipher Suite bestimmte Pseudozufallsfunktion. Zusätzlich gehen die beim Handshake ausgetauschten Zufallszahlen in die Berechnung ein. Danach werden die Nachrichten verschlüsselt übertragen.
Aufbau der TLS-Protokolle
Das Record Protocol bildet die untere TLS-Schicht. Es fragmentiert Daten in Blöcke von höchstens 16.384 Byte (2^14 Byte), verschlüsselt sie symmetrisch und schützt Integrität und Authentizität gewöhnlich durch einen HMAC, also einen schlüsselabhängigen Message Authentication Code. Ein komprimierter Block darf 1024 Byte, ein verschlüsselter Block 2048 Byte größer sein. Ältere TLS-Ausgaben unterstützen unter anderem DES, Triple DES und AES; die Schlüssel und ein mögliches Kompressionsverfahren werden im Handshake ausgehandelt.
Ein Record enthält einen Content Type von 1 Byte, je 1 Byte für Major- und Minor-Version sowie eine 2 Byte lange Längenangabe. Die Content Types sind Change Cipher Spec = 20, Alert = 21, Handshake = 22 und Application Data = 23.
Das Change Cipher Spec Protocol besteht aus genau einer Nachricht von einem Byte mit dem Wert 1. Sie kündigt an, dass der Sender zur ausgehandelten Cipher Suite wechselt. Das eigene Protokoll verhindert, dass diese Nachricht mit anderen Handshake-Nachrichten in einem Record zusammengefasst wird.
Das Alert Protocol meldet Warnungen und schwere Fehler. Schwere Fehler beenden die Verbindung sofort. Eine Meldung besteht aus AlertLevel (Warning = 1 oder Fatal = 2) und AlertDescription, jeweils 1 Byte. Beispiele sind unexpected_message, bad_record_mac, handshake_failure, unknown_ca, certificate_expired und protocol_version. close_notify zeigt an, dass keine weiteren Nachrichten gesendet werden, und muss von jedem Partner als letzte Nachricht übermittelt werden.
Das Application Data Protocol transportiert die eigentlichen Anwendungsdaten über das Record Protocol. TLS zerlegt, gegebenenfalls komprimiert und abhängig vom Sitzungszustand verschlüsselt sie, interpretiert ihren Inhalt aber nicht.
Versionen und praktische Nutzung
Die Versionsfolge lautet: SSL 1.0 (1994), SSL 2.0 (1995), SSL 3.0 (1996), TLS 1.0 (1999), TLS 1.1 (2006), TLS 1.2 (2008) und TLS 1.3 (2018). SSL 2.0 gilt seit März 2011, SSL 3.0 seit Juni 2015 sowie TLS 1.0 und 1.1 seit März 2021 als überholt. TLS 1.3 ist in RFC 8446 festgelegt. Das Bundesamt für Sicherheit in der Informationstechnik empfiehlt TLS 1.2 und 1.3 sowie bevorzugt Cipher Suites mit Perfect Forward Secrecy.
SSL 3.0 und ältere Ausgaben sind wegen bekannter Schwächen normalerweise deaktiviert. TLS 1.3 wird von Browsern auf Desktops und Smartphones unterstützt; TLS 1.2 erreichte im Februar 2022 98,7 % aller Browserinstallationen. Im August 2024 wurde für TLS 1.3 erstmals ein post-quantumsicheres Handshakeverfahren auf Grundlage des Kyber-Algorithmus eingeführt (ML-KEM beziehungsweise FIPS 203).
TLS ist ohne verlässliche zertifikatsbasierte Authentifizierung anfällig für Man-in-the-Middle-Angriffe: Ein Angreifer zwischen Client und Server könnte beiden Seiten eigene Schlüssel vorspiegeln, den Datenverkehr lesen und verändern. Im Tor-Netzwerk ist die Prüfung des Serverzertifikats deshalb besonders wichtig, weil ein Exit Node unverschlüsselte Verbindungen leicht abhören könnte.
SNI löste 2003 das Problem, dass bei virtuellen Servern zunächst nur ein Zertifikat pro Kombination aus IP-Adresse und Port ausgewählt werden konnte: Der gewünschte Servername wird schon beim Verbindungsaufbau übertragen. Weil dieser Name dabei zunächst im Klartext sichtbar blieb, wurden 2018 Encrypted SNI und 2020 Encrypted Client Hello eingeführt. ECH benötigt Unterstützung durch Browser und DNS. Das BSI bewertet es als bedeutenden Fortschritt für Privatsphäre und Sicherheit.
Extended-Validation-Zertifikate wurden von 2007 bis 2019 in Browsern besonders hervorgehoben. Sie prüfen den Inhaber aufwendiger, bieten aber weder stärkere Verschlüsselung noch einen erweiterten technischen Schutz. Die auffällige Kennzeichnung wurde eingestellt, weil der erwartete Sicherheitsgewinn für Endnutzer ausblieb.
Angriffe und Schutzmaßnahmen
Bekannte Angriffe betreffen sowohl Schwächen älterer Protokollvarianten als auch fehlerhafte Implementierungen:
- Padding-Oracle-Angriffe: Serge Vaudenay zeigte 2002, dass manipulierte CBC-verschlüsselte Nachrichten Informationen über korrektes Padding und damit über den Klartext verraten können. Selbst einheitliche Fehlermeldungen reichen nicht immer, weil Antwortzeiten Hinweise liefern können. Betroffen sind SSL, TLS bis 1.2 und DTLS bei CBC-Cipher-Suites; Authenticated Encryption ist nicht betroffen. POODLE erzwang 2014 ein Downgrade auf SSL 3.0 und nutzte dort diese Schwäche.
- BEAST: SSL 3.0 und TLS 1.0 verwenden im CBC-Modus einen vorhersagbaren Initialisierungsvektor. Ein Angreifer kann bei einem Chosen-Plaintext-Angriff etwa ein HTTP-Cookie zeichenweise erraten. Der Angriff wurde 2004 beschrieben und 2011 praktisch demonstriert. TLS 1.1 und höher sind nicht betroffen. Für TLS 1.0 wurde der abwärtskompatible Workaround 1/(n-1) TLS record splitting eingesetzt.
- Kompressionsangriffe: CRIME wurde 2012 veröffentlicht. Beim Erraten eines geheimen Textteils verringert gute Kompression die Nachrichtenlänge und verrät dadurch, ob die Vermutung stimmt. TLS 1.3 unterstützt keine Kompression mehr. TIME und BREACH können auch bei abgeschalteter TLS-Kompression angreifen, wenn HTTP-Kompression genutzt wird; daher sind anwendungsspezifische Maßnahmen bis hin zum Verzicht auf Kompression nötig.
- Exportverschlüsselung: FREAK erzwang 2015 aufgrund eines Implementierungsfehlers RSA-Exportschlüssel mit 512 Bit. Logjam stuft den Diffie-Hellman-Austausch auf 512-Bit-Gruppen herab und ist eine Protokollschwäche. Server sollen Export-Cipher-Suites deaktivieren und mindestens 2048 Bit lange Gruppen verwenden; Clients sollen Gruppen unter 1024 Bit ablehnen.
Auch Programmfehler gefährden TLS. Ein besonders schwerwiegendes Beispiel ist der 2014 entdeckte Heartbleed-Bug in OpenSSL. Bekannte Implementierungen sind OpenSSL, GnuTLS, LibreSSL, Network Security Services, mbed TLS, BoringSSL, Cryptlib, Microsoft SChannel und WolfSSL.
Unter der Bezeichnung eTLS beziehungsweise später ETS wurde außerdem ein absichtlich nachschlüsselfähiges Verfahren vorgeschlagen, das Dritten unbemerkten Einblick ermöglichen sollte. Fachleute und Organisationen wie die EFF warnten vor den möglichen Schäden. Das Verfahren gilt als vorsätzlich fehlerhafte TLS-Implementierung; das zuständige ETSI-Gremium erhielt dafür 2019 einen BigBrotherAward.
Stärken und Grenzen
Der wichtigste Vorteil von TLS ist seine Unabhängigkeit von einzelnen Anwendungen und Betriebssystemen: Grundsätzlich kann jedes höherliegende Protokoll darauf aufbauen. Die eigentliche Verschlüsselung benötigt je nach Algorithmus nur wenig Rechenzeit.
Nachteilig ist der vergleichsweise rechenintensive und dadurch langsamere Verbindungsaufbau auf dem Server. Bereits verschlüsselte Daten lassen sich auf tieferen Protokollschichten kaum noch komprimieren.
TLS schützt nur die Verbindung zwischen jeweils zwei Stationen. Läuft eine Nachricht durch mehrere Zwischenstationen, muss jede Station die gesamte TLS-geschützte Nachricht entschlüsseln können. Soll jede Station nur ausgewählte Teile lesen dürfen, reicht TLS allein daher nicht aus; an jeder entschlüsselnden Zwischenstation können zusätzliche Sicherheitslücken entstehen.
