Erkläre mir den TLS-1.3-Handshake.

Der TLS-1.3-Handshake existiert, um ein Problem zu lösen: Zwei Parteien, die sich nie begegnet sind, müssen sich über ein Netzwerk, das ein Angreifer mitlesen kann, auf ein gemeinsames Geheimnis einigen, und sie müssen sicher sein, mit der richtigen Partei zu sprechen. Er erreicht das in einem einzigen Roundtrip, was die zentrale Verbesserung gegenüber TLS 1.2 ist.

Der Ablauf, Schritt für Schritt

1. ClientHello. Der Client eröffnet mit der gewünschten TLS-Version, einer zufälligen Nonce, den unterstützten Cipher Suites, den benannten Gruppen (elliptische Kurven), auf denen er ECDHE durchführen kann, und – entscheidend – einem Key Share: einem ephemeren öffentlichen Schlüssel für eine oder mehrere dieser Gruppen. TLS 1.3 ist meinungsstark, also rät der Client, dass der Server einen seiner Shares akzeptiert.
2. ServerHello. Der Server wählt eine Cipher Suite und eine Gruppe, sendet seinen eigenen ephemeren Key Share zurück, und nun haben beide Seiten alles, was sie brauchen, um über Diffie-Hellman dasselbe gemeinsame Geheimnis zu berechnen.
3. Schlüsselableitung. Beide Seiten führen die ECDHE-Berechnung durch und speisen das Ergebnis durch die Schlüsselableitungsfunktion HKDF, um die Traffic-Schlüssel zu erzeugen. Ab diesem Punkt ist der Rest des Handshakes verschlüsselt.
4. Server-Authentifizierung. Unter dieser Verschlüsselung sendet der Server sein Zertifikat und ein CertificateVerify – eine Signatur über das Handshake-Transcript, die beweist, dass er den privaten Schlüssel zum Zertifikat besitzt. Der Client validiert die Zertifikatskette bis zu einer vertrauenswürdigen CA.
5. Finished. Beide Seiten tauschen einen MAC über das gesamte Transcript aus, um zu bestätigen, dass nichts manipuliert wurde, und Anwendungsdaten fließen.

Warum es besser als TLS 1.2 ist

• Ein Roundtrip, nicht zwei. Weil der Client spekulativ einen Key Share in der ersten Nachricht sendet, kann der Server mit allem Nötigen antworten. TLS 1.2 benötigte einen zusätzlichen Roundtrip.
• Forward Secrecy ist verpflichtend. TLS 1.3 hat den statischen RSA-Schlüsselaustausch entfernt. Jede Sitzung verwendet ephemere Schlüssel, sodass die spätere Kompromittierung des langlebigen Serverschlüssels einem Angreifer nicht erlaubt, zuvor aufgezeichneten Verkehr zu entschlüsseln.
• Ein kleineres, sichereres Cipher-Menü. Schwache und selten korrekte Optionen (RC4, CBC-Modus-MACs, Renegotiation, Kompression) wurden entfernt, was die Angriffsfläche verkleinert.

Die Falle, auf die man achten muss

TLS 1.3 fügt 0-RTT (»Early Data«) hinzu, bei dem ein wiederkehrender Client bereits in seiner allerersten Nachricht mithilfe eines Pre-Shared Keys Anwendungsdaten senden kann. Das ist schnell, aber 0-RTT-Daten sind durch einen Angreifer wiederholbar (replaybar), daher dürfen sie nur idempotente Anfragen tragen – niemals etwas, das einen Zustand verändert. Eine starke Antwort erwähnt diesen Kompromiss unaufgefordert.