TLS-1.3-Handshake-Diagramm: Schritt für Schritt, mit Resumption und mTLS

Jede HTTPS-Anfrage beginnt mit einem Gespräch, das sich die meisten Engineers nie ansehen. Bevor dein Browser GET / sendet, einigen er und der Server sich auf eine Protokollversion, tauschen Schlüssel aus, prüfen ein Zertifikat und beweisen, dass niemand an alldem manipuliert hat. Geht das schief, bekommst du kryptische Fehler wie handshake_failure oder bad_certificate, und wenn es langsam ist, zahlt jede Seite dafür.

TLS 1.3 hat den Handshake kürzer und privater gemacht als TLS 1.2. Dieser Beitrag geht ihn mit einem Sequenzdiagramm Nachricht für Nachricht durch und behandelt dann die Varianten, die dir in Produktion begegnen: HelloRetryRequest, Session-Resumption und 0-RTT, Mutual TLS, Encrypted Client Hello und Post-Quanten-Schlüsseltausch.

Was der Handshake leisten muss

Ein TLS-Handshake erledigt vier Aufgaben, bevor Anwendungsdaten fließen:

1. Parameter aushandeln: die Protokollversion, die Cipher Suite und die Gruppe für den Schlüsseltausch.
2. Gemeinsame Schlüssel herstellen: Beide Seiten leiten dieselben Geheimnisse ab, ohne sie je zu senden.
3. Den Server authentifizieren, optional auch den Client, mit Zertifikaten.
4. Integrität bestätigen: Beide Seiten prüfen, dass sie dieselben Handshake-Nachrichten gesehen haben, sodass ein Angreifer die Aushandlung weder herabstufen noch verändern kann.

Die aktuelle Spezifikation ist RFC 9846, veröffentlicht im Juli 2026. Sie ersetzt RFC 8446, behält aber dieselbe Protokollversion bei, sodass ein TLS-1.3-Client, der gegen den alten RFC gebaut wurde, weiterhin mit einem Server spricht, der gegen den neuen gebaut wurde.

Der vollständige Handshake, Nachricht für Nachricht

TLS 1.3 braucht einen Roundtrip. Der Client rät, welchen Schlüsseltausch der Server akzeptieren wird, und schickt seine Hälfte des Schlüsseltauschs schon in der allerersten Nachricht.

Entscheidend ist die Zeile nach ServerHello. Sobald der Client den Key Share des Servers hat, führen beide Seiten den Key Schedule aus (HKDF über das gemeinsame Geheimnis und das Transkript) und leiten Handshake-Traffic-Keys ab. Ab diesem Punkt ist jede Handshake-Nachricht verschlüsselt. Bei TLS 1.2 konnte ein Beobachter im Netz das Zertifikat des Servers lesen; bei TLS 1.3 kann er es nicht.

CertificateVerify beweist, dass der Server den privaten Schlüssel zum gerade gesendeten Zertifikat besitzt. Finished beweist, dass beide Seiten dieselben Nachrichten gesehen haben. Würde ein Angreifer eine Cipher Suite aus dem ClientHello entfernen, unterschieden sich die Transkripte und die Finished-Prüfung schlüge fehl.

Der Server kann direkt nach seinem Finished Anwendungsdaten senden, und der Client schickt seine erste Anfrage unmittelbar nach seinem eigenen Finished. Einen Roundtrip nach dem ClientHello steht die verschlüsselte Verbindung.

Was sich gegenüber TLS 1.2 geändert hat

Die Liste der Cipher Suites schrumpfte auf TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 und zwei CCM-Suites. Eine TLS-1.3-Cipher-Suite benennt jetzt nur noch die Record-Verschlüsselung und den Hash; Schlüsseltausch und Signaturalgorithmus werden separat ausgehandelt. RSA-Zertifikate funktionieren weiterhin. Verschwunden ist der RSA-Key-Transport, bei dem der Client das Geheimnis mit dem öffentlichen Schlüssel des Servers verschlüsselte und ein gestohlener Schlüssel jede aufgezeichnete Session entschlüsselte.

Wenn aus einem Roundtrip zwei werden: HelloRetryRequest

Der Handshake mit einem Roundtrip beruht auf einer Vermutung. Der Client schickt Key Shares für die Gruppen, die der Server vermutlich akzeptiert, meist X25519. Unterstützt der Server keine davon, antwortet er mit einem HelloRetryRequest, der eine akzeptierte Gruppe nennt, und der Client beginnt mit einem neuen ClientHello von vorn. Das kostet einen vollen zusätzlichen Roundtrip.

Das siehst du, wenn Client und Server sich bei den Gruppen uneinig sind, zum Beispiel bei einem Server, der nur für P-256 konfiguriert ist, und einem Client, der nur einen X25519-Share schickt. Die Lösung ist Konfiguration: Sorg dafür, dass die Gruppen, die deine Clients zuerst anbieten, die sind, die deine Server bevorzugen.

Resumption und 0-RTT

Nach dem Handshake kann der Server NewSessionTicket-Nachrichten senden. Ein Ticket erlaubt dem Client, später mit einem Pre-Shared Key (PSK) statt eines vollständigen Zertifikatsaustauschs fortzufahren. Die Resumption führt normalerweise trotzdem einen frischen (EC)DHE-Austausch aus, sodass die fortgesetzte Session Forward Secrecy behält.

Mit einem Ticket kann der Client außerdem frühe Daten senden, genannt 0-RTT: Die erste Anfrage reist im selben Flight wie das ClientHello. Das spart einen Roundtrip, aber RFC 9846 stellt ausdrücklich klar, dass 0-RTT-Daten keine Garantie gegen Replay zwischen Verbindungen haben. Ein Angreifer, der den ersten Flight mitschneidet, kann ihn erneut senden.

Die praktischen Regeln:

• Schick als frühe Daten nur idempotente Requests: GET ohne Seiteneffekte, nie eine Zahlung oder Bestellung.
• Aktiviere 0-RTT auf dem Server nur dort, wo die Anwendung Replays ablehnen oder tolerieren kann. Viele Server markieren Early-Data-Requests (zum Beispiel mit dem in RFC 8470 definierten Header Early-Data: 1), damit die Anwendung mit 425 Too Early antworten kann.
• Nutze 0-RTT nicht für authentifizierte Aktionen, es sei denn, du hast Replay zu Ende gedacht.

Mutual TLS

Bei Mutual TLS (mTLS) verlangt der Server auch vom Client ein Zertifikat. Der Server fügt nach EncryptedExtensions einen CertificateRequest ein, und der Client antwortet vor seinem Finished mit eigenem Certificate und CertificateVerify. Die Zahl der Roundtrips ändert sich nicht.

mTLS ist zwischen Services in einem Mesh der Standard: Jeder Workload bekommt ein kurzlebiges Zertifikat, und Sidecars oder Proxys übernehmen den Handshake. Das Service-Mesh-Architekturdiagramm zeigt, woher diese Zertifikate kommen, und das Zero-Trust-Architekturdiagramm erklärt, warum Identität pro Request wichtiger ist als das Netz, aus dem ein Request kam.

Privatsphäre und Post-Quanten-Schlüssel: was 2026 neu ist

Zwei aktuelle RFCs verändern, wie der Handshake auf der Leitung aussieht.

Encrypted Client Hello. Das ClientHello wird gesendet, bevor es Schlüssel gibt, daher reist die SNI, der Hostname, den der Client möchte, im Klartext. RFC 9849, veröffentlicht im März 2026, definiert Encrypted Client Hello (ECH): Der Client verschlüsselt ein inneres ClientHello, einschließlich des echten Hostnamens, mit einem Schlüssel, den der Server im DNS veröffentlicht. Beobachter sehen nur einen öffentlichen äußeren Namen, typischerweise den eines großen Anbieters.

Hybrider Post-Quanten-Schlüsseltausch. Heute aufgezeichneter Traffic könnte später von einem Quantencomputer entschlüsselt werden, deshalb stellt der Schlüsseltausch zuerst um. RFC 10024, veröffentlicht im August 2026, definiert Hybride wie X25519MLKEM768, das X25519 mit ML-KEM-768 kombiniert. Beide Shares fließen in den Key Schedule, sodass die Verbindung sicher bleibt, solange einer der beiden Algorithmen hält. Chrome und Edge ab 131 sowie Firefox ab 132 bieten ihn standardmäßig an.

Der Preis ist die Größe. Ein X25519MLKEM768-Client-Share ist 1.216 Byte groß und der Server-Share 1.120 Byte, gegenüber je 32 Byte bei reinem X25519. Ein ClientHello kann sich jetzt über zwei Pakete erstrecken, was Middleboxes bloßgestellt hat, die annahmen, dass das nie passiert.

Die Kosten in Roundtrips

Roundtrips, nicht Bandbreite, entscheiden, wie schnell eine Verbindung bereit ist. Bei 100 ms Roundtrip zwischen Client und Server, DNS nicht mitgerechnet:

QUIC transportiert denselben TLS-1.3-Handshake in seinen eigenen Paketen (RFC 9001) und verschmilzt ihn mit dem Transport-Handshake; dort entfällt der zusätzliche Roundtrip. TLS nah an den Nutzern zu terminieren, in einem CDN oder an einem Edge-Load-Balancer, verkürzt den Roundtrip selbst; das Load-Balancer-Diagramm behandelt, wo die Terminierung üblicherweise stattfindet.

Das Handshake-Diagramm

So liest du es:

• Zwei Lebenslinien. Links der Client, rechts der Server. Die Zeit läuft nach unten.
• Einfache Pfeile werden im Klartext gesendet: ClientHello und ServerHello. Alles unterhalb der mit „handshake keys“ markierten Linie ist verschlüsselt.
• Der Flight des Servers trägt EncryptedExtensions, Certificate, CertificateVerify und Finished in einem Rutsch, weshalb der Handshake in einen Roundtrip passt.
• Das optionale Fragment enthält Certificate und CertificateVerify des Clients, die nur bei Mutual TLS gesendet werden. Der gestrichelte CertificateRequest im Flight des Servers fordert sie an.
• Der Markdown-Block listet die Erweiterungen auf, die über den Erfolg des Handshakes entscheiden: Versionen, Gruppen, Signaturalgorithmen, SNI und ALPN.

Protokolldiagramme zeichnen, mit denen man debuggen kann

• Markiere die Verschlüsselungsgrenze. Die häufigste Frage zu TLS lautet, was ein Beobachter sehen kann. Zieh die Linie.
• Nenne die Erweiterungen, die zählen, nicht alle. key_share und supported_versions erklären die meisten Fehler.
• Pack optionale und alternative Pfade in Fragmente. Ein opt-Fragment für Client-Zertifikate und ein alt-Fragment für HelloRetryRequest halten den Hauptfluss lesbar.
• Ein Diagramm pro Frage. Ein vollständiger Handshake, eine Resumption mit 0-RTT und ein mTLS-Austausch sind drei Diagramme, wenn jedes Details braucht.

Das Sequenzdiagramm-Beispiel behandelt Lebenslinien, Fragmente und Namenskonventionen ausführlicher.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge zwei Lebenslinie-Nodes aus dem Sequenz-Pack hinzu, benannt Client und Server.
3. Zeichne die Nachrichten als Kanten zwischen den Lebenslinien, von oben nach unten: ClientHello, ServerHello, dann die vier verschlüsselten Server-Nachrichten und das Finished des Clients. Beschrifte jede Kante mit dem Nachrichtennamen und ihren wichtigsten Feldern.
4. Füge ein Kombiniertes Fragment aus dem Sequenz-Pack mit dem Operator opt um Certificate und CertificateVerify des Clients hinzu und zeichne den CertificateRequest des Servers als gestrichelte Kante.
5. Füge einen Markdown-Block aus dem Basis-Pack mit den Erweiterungen und der Zahl der Roundtrips hinzu sowie eine Notiz, die markiert, wo die Verschlüsselung beginnt.

Das Beispiel nutzt 4 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Wie viele Roundtrips braucht ein TLS-1.3-Handshake? Einen für eine neue Verbindung, gegenüber zwei bei TLS 1.2. Ein HelloRetryRequest fügt einen zweiten hinzu, und mit 0-RTT-Resumption kann der Client seine erste Anfrage ganz ohne Handshake-Roundtrip senden.

Ist das Server-Zertifikat in TLS 1.3 verschlüsselt? Ja. Alles nach ServerHello, einschließlich der Certificate-Nachricht, wird mit Handshake-Keys verschlüsselt. Das ClientHello nicht; das ist die Lücke, die Encrypted Client Hello schließt.

Ist es sicher, 0-RTT zu aktivieren? Nur für Requests, deren Wiederholung unbedenklich ist. Frühe Daten können mitgeschnitten und erneut gesendet werden, also beschränke sie auf idempotente Requests und lass die Anwendung alles andere mit 425 Too Early ablehnen.

Unterstützt TLS 1.3 noch RSA-Zertifikate? Ja. RSA-Signaturen dienen weiterhin zur Authentifizierung von Servern. TLS 1.3 hat den RSA-Key-Transport entfernt, bei dem das Session-Geheimnis mit dem RSA-Schlüssel des Servers verschlüsselt wurde und ein geleakter Schlüssel vergangenen Traffic offenlegte.

Was ist der Unterschied zwischen TLS und mTLS? Bei normalem TLS legt nur der Server ein Zertifikat vor. Bei Mutual TLS fordert der Server auch vom Client ein Zertifikat an, sodass sich beide Seiten im selben Handshake authentifizieren.

Kostenlos starten — ein Seat, keine Kreditkarte.