Zusammenfassung

  • HelloRetryRequest startet TLS 1.3 nicht neu. Das zweite ClientHello muss das erste wiederholen; abweichen dürfen nur ausdrücklich erlaubte Punkte wie der verlangte Schlüsselanteil, das Entfernen von Early Data, die Rückgabe eines Cookies und neu berechnete Binder.
  • Das Protokoll ersetzt die Bytes von ClientHello1 durch eine synthetische message_hash-Nachricht mit dessen Hash und authentifiziert diese Bindung zusammen mit der Anforderung und den folgenden Nachrichten. Zustandslosigkeit verdichtet die Geschichte, löscht sie aber nicht.
  • Betriebliche Beweise müssen beide ClientHello, Anlass, zulässige Differenz, Cookie-Regel, Endgruppe, Alerts und Zusatzlatenz erfassen. Ein erfolgreicher Handshake beweist weder die Zulässigkeit der Anforderung noch eine ursprüngliche Präferenz des Clients.

Ein Mitschnitt, der zu spät einsetzte

Die Diagnose wirkte eindeutig. ClientHello2 führte einen Schlüsselanteil, ServerHello wählte dieselbe Gruppe, CertificateVerify und Finished liefen ohne Alert durch. Das Dashboard formulierte daraus: Der Client bot die Gruppe an, der Server akzeptierte sie.

Die fehlende erste Nachricht zeigte einen anderen Ablauf. Der Client hatte mehrere Gruppen in supported_groups genannt, aber nur für eine andere Gruppe sofort einen key_share berechnet. Der Server wollte diese Prognose nicht verwenden und verlangte per HelloRetryRequest eine Gruppe, die der Client bereits als unterstützt bezeichnet, für die er aber noch keinen Anteil gesendet hatte. Der einzelne Anteil im zweiten Hello war Antwort auf die Serverentscheidung, nicht Beleg der ersten Clientwahl.

Konfigurierbare Fähigkeit, angekündigte Unterstützung, vorausgesendeter Anteil, angeforderte Gruppe und endgültige Auswahl sind getrennte Tatsachen. Beobachtung ab dem zweiten Flug schreibt die Serverpräferenz dem Client zu, verbirgt eine Netzwerkrunde und verfälscht die Ursachenanalyse bei Algorithmuswechseln.

Korrektur nach geschlossener Erlaubnisliste

Die aktuelle TLS-1.3-Spezifikation verlangt, dass ClientHello2 grundsätzlich ClientHello1 entspricht. Enthält die Anforderung key_share, ersetzt der Client seine Liste durch genau einen neu erzeugten Anteil für die angegebene Gruppe. early_data wird entfernt, ein Cookie unverändert übernommen und ein PSK-Binder über den Retry-Verlauf neu berechnet. Eine künftige Erweiterung darf nur dann eine weitere Änderung zulassen, wenn sie in der Anforderung vorkommt und die Änderung definiert.

Das ist keine bloße Ähnlichkeitsregel, sondern eine Erlaubnisliste. Geschützt wird nicht nur der spätere Algorithmus, sondern auch die Grenze dessen, was zwischen den beiden Angeboten veränderbar ist.

Die verlangte Gruppe muss im ursprünglichen supported_groups stehen und darf im ersten key_share noch keinen Anteil gehabt haben. Eine wirkungslose Anforderung, ein zweites HRR, eine nie angebotene Cipher Suite oder ein ServerHello mit abweichender Gruppe müssen scheitern.

Damit wird Retry zu einem deterministischen Zustandswechsel. Der Server darf einmal eine zulässige Korrektur erbitten. Er darf weder sämtliche Felder neu öffnen noch so lange wiederholen, bis der Client eine andere Politik hinnimmt.

message_hash hält das erste Angebot fest

Viele TLS-Berechnungen beruhen auf dem geordneten Hash der Handshake-Nachrichten. Ein Server, der ein Cookie ausgeben und danach clientbezogenen Zustand verwerfen will, möchte weder jedes vollständige ClientHello noch einen bibliotheksspezifischen Zwischenzustand speichern.

TLS ersetzt ClientHello1 im Verlauf durch die synthetische Nachricht message_hash vom Typ 254, deren Inhalt Hash(ClientHello1) ist. Danach folgen HelloRetryRequest, ClientHello2, ServerHello und die Authentisierungsnachrichten. CertificateVerify, Finished und der erneuerte PSK-Binder bleiben damit an das erste Angebot gebunden.

Der Hash ist eine Verpflichtung, kein rücklesbares Archiv. Die Endpunkte können einen Bruch der authentisierten Geschichte erkennen; ein Betriebsteam kann daraus aber nicht alle ursprünglichen Erweiterungen und Anteile rekonstruieren. Das Protokoll beweist Kontinuität, der Mitschnitt erklärt die Differenz.

Unterstützung, Prognose und Auswahl auseinanderhalten

Ein TLS-1.3-Client spart eine Netzwerkrunde, indem er im ersten Hello Schlüsselanteile vorhersagt. Für jede unterstützte Gruppe einen Anteil zu erzeugen erhöht Rechenaufwand und Nachrichtengröße. Nur einen zu senden spart Bytes, kann aber HRR auslösen, wenn der Server eine andere ebenfalls unterstützte Gruppe fordert.

Hybride Post-Quanten-Gruppen machen den Zielkonflikt sichtbar. OpenSSL bietet Gruppensätze, markierte Prognoseanteile und Serverpräferenz. Die Dokumentation weist zugleich darauf hin, dass ein großes ClientHello eine TCP-Segmentgrenze überschreiten und fehlerhafte Firewalls treffen kann. Wird ein großer Anteil zurückgestellt, zahlen nur Server mit ausdrücklicher Anforderung die zusätzliche Runde. GnuTLS trennt ebenfalls Gruppenregeln von der Option, nur einen TLS-1.3-Anteil zu senden.

Ein Inventareintrag „unterstützt X“ genügt daher nicht. Die Implementierung kann X kennen, die Konfiguration X aktivieren, das erste Hello X ohne Anteil ankündigen, der Server X verlangen und die Verbindung X schließlich auswählen. Jeder Zustand braucht sein eigenes Beweisfeld.

Early Data überlebt den Umweg nicht

Enthielt ClientHello1 early_data, muss ClientHello2 die Erweiterung entfernen. HelloRetryRequest belegt somit, dass der 0-RTT-Pfad dieses Handshakes nicht angenommen wurde.

Der Client kann vor Eintreffen der Anforderung dennoch Anwendungsbytes gesendet haben. Ob die Operation wiederholt werden darf, ob bereits eine Antwort vorlag und wie Nebenwirkungen abgeglichen werden, bleibt Sache der Anwendung. Späterer 1-RTT-Erfolg macht eine nicht idempotente Aktion nicht sicher.

Telemetrie muss Versuch, Ablehnung durch HRR, Wiederholungsentscheidung und Geschäftsergebnis trennen. Das Etikett „Wiederaufnahme erfolgreich“ verschluckt den entscheidenden Übergang.

Ein Cookie beweist nur seinen Konstruktionszweck

Der Server kann ein undurchsichtiges Cookie senden und dessen unveränderte Rückgabe verlangen. Es kann den Hash des ersten Hello, ausgewählte Parameter, Zeit oder Routingkontext binden. Integritätsschutz belegt Herkunft und Unverändertheit innerhalb der Grenzen von Schlüsselverwahrung, Laufzeit und Prüfung.

DTLS 1.3 zeigt eine weitere Verwendung: Bindung an die scheinbare Clientadresse, um vor einer vergrößerten Antwort den Rückweg zu prüfen. Schlüsselrotation, überlappende Gültigkeitsfenster und Zeitstempel verdeutlichen, dass auch ein zustandsloses Token einen Lebenszyklus hat.

Erreichbarkeit ist keine Identität. Die Cookie-Rückgabe kann Empfang an einer Adresse in einem Zeitraum zeigen, aber weder Person noch Geräterolle oder Anwendungsrecht. Ein gültiges Cookie hebt auch den Vergleich der beiden ClientHello nicht auf.

Erweiterungen treten in dieselbe Geschichte ein

Encrypted Client Hello liefert ein begrenztes Beispiel. Der Random-Wert von HelloRetryRequest ist fest, daher kann ECH seine Bestätigung dort nicht wie im gewöhnlichen ServerHello unterbringen. Stattdessen definiert es eine encrypted_client_hello-Erweiterung, deren Bestätigung aus innerem ClientHello und verändertem HRR-Verlauf entsteht.

Die Aussage ist nicht, diesen Beitrag zu einem ECH-Leitfaden zu machen. Jede Erweiterung muss festlegen, was sich ändern darf, wo ihr Signal steht und wie es Teil der authentisierten Geschichte wird. Sie erhält keinen privaten, unbegrenzten Verhandlungsraum.

Beweise, die einen Vorfall überstehen

Eine belastbare Aufzeichnung beginnt vor dem Zeitpunkt, den viele Dashboards Verbindung nennen. Sie speichert Hash und zulässige Analysefelder von ClientHello1, das genaue HelloRetryRequest, einen Cookie-Hash statt Geheimnis, die Felder von ClientHello2 und das endgültige ServerHello. Jede Entscheidung wird mit Implementierungs- und Konfigurationsstand verbunden.

Für Gruppen gehören aktivierte Menge, Reihenfolge, Prognoseanteile, Serverpräferenz, angeforderte, zurückgesandte und ausgehandelte Gruppe in getrennte Felder. Für HRR: Grund, Zulässigkeit der Differenz, Ablehnungsalert und ein möglicher zweiter Versuch. Für Folgen: Zusatz-RTT, Größe beider Hello, Segmentierung, Early-Data-Ergebnis, Abschluss und Clientpopulation.

Auch Negativbeweise zählen. Zu testen sind die Ablehnung einer nicht angekündigten oder bereits geteilten Gruppe, einer wirkungslosen Anforderung, einer veränderten Suite, eines zweiten HRR und eines widersprüchlichen ServerHello. Der BoringSSL-Testläufer modelliert solche Varianten, weil korrektes Ablehnen zur Interoperabilität gehört.

Der erfolgreiche Handshake ist das Ende der Erzählung, nicht der Beweis jeder vorherigen Entscheidung. Dieser Beweis liegt in der nachprüfbaren Kette begrenzter Änderungen.

Quellen