Der TLS-1.3-Handshake im Überblick

Worum es geht

RFC 8446 definiert den Handshake. Der Client sendet ein ClientHello mit den Erweiterungen supported_versions, signature_algorithms und key_share; der Key Share ist ein ephemerer öffentlicher (EC)DHE-Wert für eine oder mehrere Gruppen. Der Server wählt eine Gruppe und antwortet mit einem ServerHello, das seinen eigenen key_share trägt. Beide Seiten leiten nun Handshake-Schlüssel ab, und jede folgende Nachricht ist verschlüsselt: EncryptedExtensions, das Certificate und CertificateVerify des Servers (eine Signatur über den Transkript-Verlauf) sowie Finished (ein HMAC über den Transkript-Verlauf). Der Client antwortet mit seinem eigenen Finished und kann danach Anwendungsdaten senden. Ein Roundtrip, daher «1-RTT». Hat der Client eine Gruppe geraten, die der Server nicht unterstützt, sendet der Server HelloRetryRequest, und der Client versucht es mit einem anderen Key Share erneut, was einen zusätzlichen Roundtrip kostet.

Nach dem Handshake kann der Server NewSessionTicket-Nachrichten senden; eine spätere Verbindung legt das Ticket als pre_shared_key vor und kann den Zertifikataustausch überspringen. Mit einem solchen PSK kann der Client in seinem ersten Flight auch «Early Data» (0-RTT) senden. Das RFC hält unmissverständlich fest, dass 0-RTT-Daten nicht Forward Secret sind und dass es keine Garantien gegen Replay zwischen Verbindungen gibt.

Warum es wichtig ist

RFC 8446 listet auf, was gegenüber TLS 1.2 entfernt wurde: statische RSA- und Diffie-Hellman-Cipher-Suites (RSA-Schlüsseltransport), Kompression, DSA, benutzerdefinierte DHE-Gruppen und die alten symmetrischen Chiffren; Renegotiation ist ausdrücklich verboten. Jeder verbleibende Public-Key-Schlüsselaustausch bietet nun Forward Secrecy, und jede verbleibende Suite ist AEAD (TLS_AES_128_GCM_SHA256 ist verpflichtend zu implementieren). Das Zertifikat ist auf der Leitung nicht mehr sichtbar, was ändert, was passive Middleboxes und Logging sehen können.

So wird es angewendet

• TLS 1.3 bevorzugen, wo beide Enden es unterstützen; die Version wird über supported_versions ausgehandelt, nicht über das alte Versionsfeld, sodass alte Middleboxes, die dieses Feld inspizieren, weiterhin «TLS 1.2» sehen.
• Die von den erwarteten Gegenstellen bevorzugte Key-Share-Gruppe zuerst anbieten, um HelloRetryRequest-Roundtrips zu vermeiden; das RFC verlangt secp256r1 und empfiehlt X25519 für Clients.
• 0-RTT deaktiviert lassen, ausser die Anwendungsschicht sendet früh nur idempotente Anfragen; der Anti-Replay-Abschnitt des RFC beschreibt Einmal-Tickets und Aktualitätsprüfungen, die ein Server dafür bräuchte.
• Resumption mit frischem Key Share bevorzugen (psk_dhe_ke): Das RFC hält fest, dass ein allein verwendeter PSK Forward Secrecy für die Anwendungsdaten verliert, sodass ein geleakter Ticket-Schlüssel diese Sitzungen offenlegen würde. Ticket-Schlüssel unabhängig davon rotieren.

Stolpersteine

Der «Middlebox-Kompatibilitätsmodus» lässt TLS 1.3 auf der Leitung wie eine 1.2-Session-Resumption aussehen; Paketmitschnitte brauchen deshalb die Sitzungsschlüssel, nicht nur das Zertifikat, um entschlüsselt zu werden. Client-Zertifikate funktionieren weiterhin, werden aber innerhalb des verschlüsselten Teils des Handshakes angefragt, sodass Proxys, die TLS terminieren, sie selbst handhaben müssen.