TLS und sichere Kanäle

Transport Layer Security (TLS) ist das Protokoll, das die meisten Internetkommunikationen sichert. Es kombiniert authentifizierten Schlüsselaustausch und authentifizierte Verschlüsselung, um einen vertraulichen, integritätsgeschützten Kanal zwischen zwei Endpunkten zu schaffen.

Definition

Ein sicheres Kanalprotokoll wie TLS etabliert zwischen zwei Parteien eine Sitzung, die Vertraulichkeit, Integrität und Authentifizierung aller ausgetauschten Daten gewährleistet, indem es einen authentifizierten Schlüsselaustausch durchführt, gefolgt von einer authentifizierten Verschlüsselung des Datenverkehrs.

Scope

Dieses Thema behandelt Protokolle für sichere Kanäle, wobei TLS als zentrales Beispiel dient: den Handshake, der den Server (und optional den Client) authentifiziert und Sitzungsschlüssel etabliert; die Record-Schicht, die authentifizierte Verschlüsselung, Forward Secrecy und Downgrade-Schutz bietet; und die Lehren aus historischen Angriffen. Es wird erläutert, wie die kryptografischen Bausteine zu einem implementierten Protokoll zusammengefügt werden. Ausgenommen sind die Zertifikatsinfrastruktur (PKI) und die einzelnen Primitive, die in verwandten Themen behandelt werden.

Core questions

• Wie authentifiziert der TLS-Handshake den Server und vereinbart Sitzungsschlüssel?
• Wie schützt die Record-Schicht jede Nachricht mit authentifizierter Verschlüsselung?
• Wie wird Forward Secrecy erreicht und warum ist sie für aufgezeichneten Datenverkehr wichtig?
• Wie werden Downgrade- und Neuverhandlungsangriffe verhindert?
• Was haben historische Angriffe (BEAST, POODLE, Heartbleed) über das Protokoll- und Implementierungsdesign gelehrt?

Key concepts

• TLS-Handshake
• Record-Schicht
• authentifizierte Verschlüsselung (AEAD)
• ephemerer Schlüsselaustausch (ECDHE)
• Forward Secrecy
• Server- und Client-Authentifizierung
• Downgrade- und Neuverhandlungsangriffe
• Sitzungswiederaufnahme
• Aushandlung der Cipher Suite

Key theories

Handshake plus Record-Protokoll

TLS trennt einen authentifizierten Schlüsselaustausch-Handshake – der die Identität über Zertifikate überprüft und Sitzungsschlüssel ableitet – von einer Record-Schicht, die Anwendungsdaten mit diesen Schlüsseln verschlüsselt und authentifiziert, wodurch Authentifizierung, Schlüsselvereinbarung und Massenschutz sauber kombiniert werden.

Forward Secrecy und Downgrade-Schutz

TLS 1.3 schreibt ephemeres (elliptische Kurven) Diffie-Hellman für Forward Secrecy vor und bindet das Handshake-Transkript in den Schlüsselplan ein, sodass ein aktiver Angreifer ein Downgrade auf schwächere Parameter nicht unbemerkt erzwingen kann.

Mechanisms

Bei TLS 1.3 sendet der Client seine Schlüsselaustauschanteile und unterstützten Parameter; der Server antwortet mit seinem eigenen ephemeren Diffie-Hellman-Anteil, Zertifikat und einer Signatur über das Handshake-Transkript. Beide leiten dann Sitzungsschlüssel über eine Schlüsselableitungsfunktion (HKDF) ab. Die Record-Schicht schützt anschließend alle Daten mit einer AEAD-Chiffre (wie AES-GCM oder ChaCha20-Poly1305). Das Transkript wird authentifiziert, um Manipulationen oder Downgrades zu verhindern, und der Handshake wird in einem einzigen Roundtrip abgeschlossen, mit optionaler Zero-Round-Trip-Wiederaufnahme.

Clinical relevance

TLS sichert die überwiegende Mehrheit des Internetverkehrs: HTTPS für das Web, sicherer E-Mail-Transport, APIs, VPNs und Messaging laufen alle darüber. Seine Korrektheit bestimmt direkt, ob Passwörter, Zahlungen und persönliche Daten vor Netzwerkangreifern geschützt sind. Die Migration von fehlerhaftem SSL/frühem TLS zu TLS 1.3 – und die damit verbundene Analyse – ist ein Modell für die Protokollentwicklung unter realem Druck.

Evidence & guidelines

TLS 1.3 ist in RFC 8446 standardisiert und wird empfohlen; SSL 3.0, TLS 1.0 und TLS 1.1 sind veraltet (RFC 8996). NIST SP 800-52 gibt Konfigurationshinweise. TLS 1.3 wurde mit umfassender formaler Analyse entwickelt, wodurch veraltete Schwachstellen (statischer RSA-Schlüsselaustausch, CBC-Modus, Neuverhandlung) beseitigt wurden, die frühere Angriffe wie BEAST, POODLE und den Implementierungsfehler Heartbleed ermöglichten.

History

Netscape entwickelte SSL in den Jahren 1994-1995; SSL 3.0 wurde von der IETF als TLS 1.0 (1999) neu gestaltet und bis TLS 1.2 (2008) verfeinert. Ein Jahrzehnt von Angriffen – BEAST, CRIME, POODLE, der Heartbleed-Implementierungsfehler, Logjam und FREAK – deckte Schwachstellen in älteren Modi und der Downgrade-Behandlung auf. TLS 1.3 (RFC 8446, 2018) war eine umfassende Neugestaltung mit obligatorischer Forward Secrecy, einem schnelleren Handshake und formaler Sicherheitsanalyse.

Key figures

• Eric Rescorla
• Hugo Krawczyk
• Kenny Paterson
• Taher ElGamal

Seminal works

• rfc8446
• stallings2017
• katz2020

Frequently asked questions

Was ist der Unterschied zwischen SSL und TLS?

TLS ist der Nachfolger von SSL. SSL (Versionen 2.0 und 3.0) ist veraltet und unsicher; 'SSL' bleibt ein umgangssprachlicher Begriff, aber alle aktuellen sicheren Webverbindungen verwenden TLS, wobei TLS 1.3 die moderne Version ist.

Schützt mich TLS vor einer bösartigen Website?

TLS garantiert lediglich, dass Sie einen vertraulichen, authentifizierten Kanal zu dem im Zertifikat genannten Server haben – es bestätigt, dass Sie mit dieser Domain kommunizieren, nicht dass die Domain vertrauenswürdig ist. Eine Phishing-Website kann ein gültiges Zertifikat für ihre eigene (ähnlich aussehende) Domain bereitstellen, sodass TLS nicht für die Ehrlichkeit der Website bürgt.