🤝TLS-1.3-Handshake
Wie ein Debugger: vor und zurück durch den offiziellen Beispiel-Handshake aus RFC 8448 „Example Handshake Traces for TLS 1.3“. Jeder Wert wird in deinem Browser nachgerechnet – X25519 mit @noble/curves, SHA-256, HKDF, AES-GCM und RSA-PSS mit WebCrypto – und mit dem RFC verglichen.
🐞Handshake-Debugger
Tasten ← → blättern. Links der Nachrichtenfluss, rechts die Details, unten der Schlüsselplan.
⏳ Rechne den Handshake mit WebCrypto nach …
📚 Quelle: RFC 8448 §3 (Simple 1-RTT Handshake) · RFC 8446 §7.1 Key Schedule (gleich in RFC 9846)
🧱ClientHello-Baukasten
Stelle SNI, ALPN, Suites und Gruppen ein – die Bytes werden sofort neu kodiert (mit echtem X25519-Anteil). Genau dieser Encoder baut in den Tests den ClientHello aus RFC 8448 bitgenau nach.
Cipher Suites
supported_groups
Der key_share enthält hier immer einen echten X25519-Anteil. Ein Browser mit X25519MLKEM768 schickt zusätzlich den 1216-Byte-Hybridanteil.
Gesamt: … Byte. Achte auf das orange SNI-Feld: der Hostname steht im Klartext – nur Encrypted Client Hello (ECH) verbirgt ihn.
⏳
⚡1-RTT, 0-RTT und Session Resumption
Mit einem PSK aus einem früheren NewSessionTicket kann der Client Daten schon im ersten Flug schicken.
Vollständiger Handshake (1-RTT)
Resumption mit 0-RTT (early_data)
⚠️ Replay-Risiko bei 0-RTT
Early Data hängt nur am PSK und am ClientHello – nicht an einem frischen Beitrag des Servers. Ein Angreifer kann den ersten Flug aufzeichnen und erneut abspielen; der Server sieht die Anfrage dann zweimal. Daher 0-RTT nur für idempotente Anfragen (GET ohne Seiteneffekt) zulassen, serverseitig Anti-Replay (Einmal-Tickets, ClientHello-Aufzeichnung, Zeitfenster) nutzen. Außerdem hat 0-RTT-Data keine Forward Secrecy gegenüber dem Ticket-Schlüssel (RFC 8446 §2.3, §8).
💡 Session Resumption (PSK)
Nach dem Handshake schickt der Server
NewSessionTicket. Beim nächsten Mal nennt der Client das Ticket inpre_shared_key und beweist per Binder (HMAC mit dem binder_key), dass er den PSK kennt. Mitpsk_dhe_ke läuft zusätzlich ein frischer X25519-Austausch → Forward Secrecy bleibt erhalten; Zertifikat und CertificateVerify entfallen.🆚Vergleich: TLS 1.2 (2-RTT)
Zum Vergleich die beiden klassischen TLS-1.2-Varianten. Die Anwendungsdaten können erst nach zwei Rundläufen fließen.
TLS 1.2 mit ECDHE
TLS 1.2 mit RSA-Schlüsseltransport
| Merkmal | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Rundläufe bis zu den ersten Daten | 2 (ECDHE und RSA) | 1 · mit PSK + early_data: 0 |
| Schlüsselaustausch | RSA-Transport, DHE, ECDHE | nur (EC)DHE, PSK, PSK + (EC)DHE |
| Forward Secrecy | nur mit (EC)DHE | immer (außer reiner PSK-Modus psk_ke) |
| Cipher Suites | Dutzende, inkl. CBC, RC4, 3DES | 5 AEAD-Suites (0x1301–0x1305) |
| Zertifikat | Klartext | verschlüsselt |
| Schlüsselableitung | PRF (HMAC-SHA256) → master_secret | HKDF-Schlüsselplan mit Transcript-Hashes |
| Renegotiation | ja | entfernt (stattdessen KeyUpdate) |
| Kompression | optional (CRIME!) | verboten |