TLS 1.3: 0-RTT, Early Data und Session Resumption

TLS 1.3 (RFC 8446, 2018) wurde mit einem neu gestalteten TLS-Handshake entwickelt, um die Latenz zu reduzieren und überholte Altlasten zu entfernen. Ein vollständiger TLS-1.3-Handshake wird in 1-RTT abgeschlossen: Der Client sendet im ersten Nachrichtenpaket ein ClientHello mit den unterstützten key_shares (ephemeren öffentlichen ECDH-Schlüsseln); der Server antwortet mit ServerHello, seinem key_share, verschlüsselten Erweiterungen, dem Zertifikat und Finished — alles in einer einzigen Antwort. Der Client sendet sein Finished und kann unmittelbar danach Anwendungsdaten übertragen. Im Vergleich zum 2-RTT-Handshake von TLS 1.2 halbiert dies die Verbindungsaufbauzeit für neue Sitzungen.

TLS 1.3 verwendet HKDF (HMAC-based Key Derivation Function) mit einem strukturierten Schlüsselplan. Nach dem ECDHE-Schlüsselaustausch fließt das gemeinsame Geheimnis in eine Hierarchie ein: Extract(early_secret, DHE) -> handshake_secret; anschließend Extract(handshake_secret, 0) -> master_secret. Daraus leitet HKDF-Expand-Label separate Schlüssel für den Handshake-Datenverkehr von Client und Server, den Anwendungsdatenverkehr und die Wiederaufnahme ab. Diese klare Trennung stellt sicher, dass die Kompromittierung einer Schlüsselschicht keine Auswirkungen auf andere Schichten hat — eine deutliche Verbesserung gegenüber der eher ad-hoc auf PRF basierenden Schlüsselableitung von TLS 1.2.

Die Sitzungswiederaufnahme von TLS 1.3 verwendet Pre-Shared Keys (PSKs), die aus vorherigen Sitzungen abgeleitet werden. Nach einem abgeschlossenen Handshake sendet der Server eine NewSessionTicket-Nachricht mit einer PSK-Identität und einem Ticketwert (einem verschlüsselten Blob, der das Geheimnis für die Wiederaufnahme enthält). Beim erneuten Verbindungsaufbau fügt der Client die PSK-Identität in das ClientHello ein. Erkennt der Server sie, leiten beide Seiten aus der PSK und einem frischen ECDHE einen neuen Sitzungsschlüssel ab und erreichen so eine Wiederaufnahme in 1-RTT mit Forward Secrecy. Das Ticket hat eine konfigurierbare Gültigkeitsdauer (typischerweise 24 Stunden) und sollte mit einem regelmäßig wechselnden serverseitigen Schlüssel verschlüsselt werden.

TLS 1.3 ermöglicht frühe Daten in 0-RTT für wiederaufgenommene Sitzungen. Der Client verwendet die PSK aus einer vorherigen Sitzung, um Anwendungsdaten zu verschlüsseln, die bereits im ersten Nachrichtenpaket — noch vor einer Bestätigung durch den Server — gesendet werden. Dadurch entfällt bei Verbindungen zu bereits besuchten Servern ein Round Trip, was für wiederholte Verbindungen eine nahezu latenzfreie Kommunikation ermöglicht. Der Server kündigt die Unterstützung für 0-RTT im NewSessionTicket über die Erweiterung early_data mit einer max_early_data_size an. Der Server muss über einen Mechanismus verfügen, um 0-RTT-Daten anzunehmen oder abzulehnen, und signalisiert die Annahme in EncryptedExtensions.

0-RTT-Daten haben eine grundlegende Sicherheitseinschränkung: Sie sind anfällig für Replay-Angriffe. Ein Angreifer auf dem Übertragungsweg, der das erste Nachrichtenpaket abfängt, kann es erneut an den Server senden und dadurch erreichen, dass der Server die frühen Daten ein weiteres Mal verarbeitet. Das ist systembedingt — der Server hat noch keine Nachricht gesendet, daher gibt es keine vom Server beigesteuerte Aktualität. Mögliche Gegenmaßnahmen: (1) Einmalig verwendbare Tickets (der Server macht ein Ticket nach der ersten Verwendung ungültig und verwendet dafür einen verteilten Cache wie memcached/Redis). (2) Zeitlich begrenzte Tickets (0-RTT nach einem kurzen Zeitraum, z. B. 5 Sekunden, ablehnen). (3) Idempotenz auf Anwendungsebene (0-RTT nur für sichere, GET-ähnliche Vorgänge zulassen).

Der robusteste Mechanismus zum Schutz vor Replay-Angriffen bei 0-RTT sind einmalig verwendbare Sitzungstickets. Der Server verwaltet einen Speicher für „verwendete Tickets“ (bei Bereitstellungen mit mehreren Servern einen verteilten Cache). Wenn 0-RTT-Daten eintreffen, prüft der Server, ob das Ticket bereits zuvor gesehen wurde — falls ja, lehnt er die frühen Daten ab und fällt auf 1-RTT zurück. Falls nein, markiert er das Ticket als verwendet und verarbeitet die frühen Daten. Für die Korrektheit müssen alle Server in einem Cluster den Cache der verwendeten Tickets gemeinsam nutzen. Redis mit kurzen TTLs (entsprechend der Gültigkeitsdauer der Tickets) ist eine gängige Implementierung. Ohne diesen Mechanismus ist 0-RTT für nicht idempotente Vorgänge wie Zahlungen unsicher.

Eine TLS-1.3-PSK-Wiederaufnahme ohne DHE bietet für die wiederaufgenommene Sitzung keine Forward Secrecy — wird die PSK später kompromittiert, kann der gesamte Datenverkehr der wiederaufgenommenen Sitzung entschlüsselt werden. Um Forward Secrecy aufrechtzuerhalten, unterstützt TLS 1.3 PSK-with-DHE: Das ClientHello enthält sowohl eine PSK-Identität als auch einen neuen key_share. Der Server kombiniert die PSK und das ECDHE-Ergebnis, um Sitzungsschlüssel abzuleiten. Selbst wenn die PSK kompromittiert wird, sorgt der ECDHE-Anteil dafür, dass vergangener Datenverkehr geschützt bleibt. RFC 8446 empfiehlt PSK-with-DHE für alle Fälle der Sitzungswiederaufnahme, in denen Forward Secrecy erforderlich ist.

TLS 1.2 verfügte über mehr als 300 Kombinationen von Cipher-Suites, von denen viele unsicher waren. TLS 1.3 reduziert dies auf 5 Cipher-Suites, die alle AEAD verwenden: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 und TLS_AES_128_CCM_8_SHA256. Schlüsselaustausch und Authentifizierung werden separat über die Erweiterungen supported_groups und signature_algorithms ausgehandelt. Diese Trennung beseitigt die kombinatorische Komplexität von TLS 1.2 und stellt sicher, dass jede TLS-1.3-Verbindung authentifizierte Verschlüsselung verwendet.

In der Praxis ist 0-RTT besonders nützlich für HTTP/2-Verbindungen, bei denen der Client eine GET-Anfrage (sicher und idempotent) an einen bereits besuchten Server wiederholt. Browser implementieren 0-RTT vorsichtig: Chrome aktiviert es für sichere HTTP-Methoden; POST-Anfragen werden niemals als 0-RTT-Daten gesendet. HTTP/3 über QUIC integriert TLS 1.3 nativ — 0-RTT von QUIC verwendet den Mechanismus von TLS 1.3 erneut. In QUIC stellt 0-RTT außerdem Transportparameter (Flusssteuerung, Stream-Limits) aus der vorherigen Sitzung wieder her und reduziert dadurch den Einrichtungsaufwand über die TLS-Schicht hinaus.

TLS 1.3 enthält Mechanismen zum Schutz vor Angriffen, bei denen die Protokollversion herabgestuft wird. Das Random-Feld von ServerHello enthält einen speziellen Sentinel-Wert, wenn TLS 1.3 ausgehandelt wird: Die letzten 8 Byte werden auf einen festen Wert gesetzt (0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01 für den TLS-1.2-Fallback). TLS-1.3-fähige Clients prüfen diesen Sentinel, wenn der Server TLS 1.2 aushandelt, und erkennen dadurch aktive Downgrade-Versuche. Zusätzlich umfasst der Finished-Transcript-Hash den gesamten Handshake einschließlich der Versionsaushandlung, sodass jede Manipulation erkannt werden kann. SCSV (Signaling Cipher Suite Values) wie TLS_FALLBACK_SCSV liefern ein separates Downgrade-Signal für ältere TLS-Versionen.

Bei der Bereitstellung von TLS 1.3 müssen mehrere betriebliche Details berücksichtigt werden. Die Verschlüsselungsschlüssel für Sitzungstickets müssen regelmäßig gewechselt (typischerweise alle 24 Stunden) und über Server-Cluster hinweg synchronisiert werden, damit eine Wiederaufnahme auf jedem Server möglich ist. Alte Schlüssel zur Entschlüsselung von Tickets müssen für die Gültigkeitsdauer der Tickets aufbewahrt werden, um unbegründete Handshake-Fehler zu vermeiden. OCSP-Stapling ist bei TLS 1.3 wichtiger, da dadurch ein Round Trip zur Prüfung des Zertifikatsstatus entfällt. Load Balancer müssen das TLS-1.3-ClientHello unverändert weiterleiten — einige ältere Middleboxes beschädigen unbekannte Erweiterungen, sodass Kompatibilitätsmodi erforderlich sein können.

Warum sind frühe 0-RTT-Daten in TLS 1.3 anfällig für Replay-Angriffe?

TLS 1.3 ermöglicht vollständige Handshakes in 1-RTT und Wiederaufnahmen in 0-RTT über PSK-Sitzungstickets. Die Schlüsselableitung verwendet HKDF mit einem strukturierten Schlüsselplan, der separate Schlüssel für jede Datenverkehrsschicht erzeugt. Frühe 0-RTT-Daten sparen einen Round Trip ein, sind aber anfällig für Replay-Angriffe — dagegen helfen einmalig verwendbare Tickets und die Beschränkung von 0-RTT auf idempotente Vorgänge. PSK-with-DHE erhält die Forward Secrecy bei der Wiederaufnahme. TLS 1.3 beschränkt Cipher-Suites auf 5 AEAD-Optionen und beseitigt dadurch unsichere Kombinationen aus älteren Versionen. Der Schutz vor Downgrade-Angriffen verwendet Sentinel-Werte im Random-Feld des Servers.