Zusammenfassung

  • TLS 1.3 kann mit 0-RTT die Latenz einer Wiederaufnahme senken, verhindert aber nicht grundsätzlich das erneute Senden angenommener Early Data.
  • Eine belastbare Kontrolle verbindet das Transportereignis mit Anforderungssemantik, Anwendungsidempotenz, aktueller Autorisierung und dem tatsächlich bestätigten Effekt.

Man stelle sich einen Zahlungsdienst vor, der einem bekannten Client erlaubt, eine TLS-Sitzung wiederaufzunehmen und einen Überweisungsauftrag als Early Data zu senden. Ein Edge-Standort entschlüsselt und leitet ihn weiter, bevor der neue Handshake abgeschlossen ist. Innerhalb des Ticketfensters erreicht eine wiederholte Kopie einen zweiten Standort. Beide melden gültige Early Data; das Hauptbuch erhält zwei Aufträge. Der Transport erfüllte sein Versprechen. Die Anwendung unterstellte ein weiteres.

Der eingesparte Umlauf hat eine klare Grenze

RFC 8446 erlaubt einem Client bei Wiederaufnahme mit einem vorab geteilten Schlüssel, 0-RTT-Anwendungsdaten vor Abschluss des neuen Handshakes zu senden. Das ist bei zeitkritischen Lesezugriffen und bei semantisch wiederholbaren Operationen nützlich.

Die Sicherheitsgrenze ist ausdrücklich beschrieben. TLS stellt für 0-RTT keinen inhärenten Replay-Schutz bereit. Wer die erste Nachrichtenfolge aufzeichnet, kann ClientHello und zugehörige Daten erneut senden. Der Server kann den Wiederaufnahmekontext trotzdem korrekt authentifizieren und die Bytes entschlüsseln. Kryptografische Annahme beweist daher nur die Zugehörigkeit zu einem akzeptierten Early-Data-Kontext, nicht eindeutige Zustellung oder einmalige Ausführung.

In der Telemetrie geht der Unterschied leicht verloren. Ein Dashboard kann gültiges Ticket, angenommenes 0-RTT und erfolgreiche Antwort anzeigen. Keines dieser Felder sagt, ob derselbe Auftrag einen anderen Prozess, eine andere Region oder einen Replay-Pfad erreicht hat. Ein grünes TLS-Ereignis ist enger als ein Geschäftsergebnis, das genau einmal eingetreten ist.

Replay-Schutz ist ein Betriebssystem, kein Häkchen

RFC 8446 beschreibt Einmaltickets, das Erfassen von ClientHellos und Frischeprüfungen anhand von Ticketalter und beobachteter Ankunftszeit. Jede Variante schafft Betriebsabhängigkeiten. Einmaltickets benötigen konsistenten Annahmezustand. Die Erfassung verlangt eine verfügbare, begrenzte Replay-Datenbank. Zeitprüfungen hängen von Uhren, Toleranzen und einer bewusst gewählten Restrisikofrist ab.

An einer verteilten Edge wird die Entscheidung gemeinschaftlich. Können zwei Standorte dasselbe Wiederaufnahmematerial ohne gemeinsame Einmalentscheidung annehmen, ist ein lokales „noch nicht gesehen“ kein globaler Beleg. Erlaubt der Ausfallmodus die Annahme ohne Replay-Zustand, erweitert die Verfügbarkeitsrichtlinie die Ausführungsfläche. Das kann vertretbar sein, darf aber nicht hinter „0-RTT angenommen“ verschwinden.

Auch Ablehnung entbindet die Anwendung nicht. Der Client kann nach dem Handshake erneut senden. Hat der erste Versuch die Anwendungsgrenze überschritten, bevor die Ablehnung sichtbar wurde, kann der zweite den Effekt duplizieren. Der Nachweis muss Annahme, Ablehnung, Weiterleitung, erneute Übermittlung und Bestätigung umfassen.

HTTP zeigt die fehlende Anwendungsentscheidung

RFC 8470 ordnet den Umgang mit Early Data in HTTP und trennt die Verantwortung von Client, Vermittler und Ursprung. Unsichere Operationen gehören nicht beiläufig in Early Data. Vermittler müssen die frühe Herkunft kenntlich machen. Ein Server kann mit 425 Too Early ablehnen, damit der Client erst nach dem Handshake erneut versucht.

Der Statuscode übergibt Kontrolle; er erklärt nicht jede angenommene Anfrage für ungefährlich. Auch der Methodenname reicht nicht. Ein scheinbar sicherer Lesezugriff kann Abrechnung, knappe Zuteilung oder Auditfolgen auslösen. Ein nominell idempotenter Schreibzugriff verliert diese Eigenschaft, wenn sein Schlüssel fehlt oder regional anders abgegrenzt wird. Replay-Sicherheit gehört zur tatsächlich implementierten Operation im aktuellen Zustand.

QUIC macht dieselbe Grenze zum Ausführungspfad. RFC 9001 bindet TLS-Early-Data in QUIC ein; der Server kann 0-RTT ablehnen, und der Client muss damit umgehen. Der erneute Versand gehört zum Anwendungsgraphen. Allein angenommene QUIC-Pakete zu zählen beweist keine einmalige Geschäftsausführung.

Ein Early-Data-Entscheidungsprotokoll schaffen

Der dauerhafte Nachweis ist ein Entscheidungsprotokoll, das Ticketfingerabdruck und -alter, ClientHello- oder Handshake-Referenz, annehmenden Edge-Standort, Replay-Schutz und Replay-Fenster, Anforderungsfingerabdruck, Methode und Effektklasse, Idempotenzschlüssel, Principal und Autorisierungsstand, Weiterleitungsergebnis, Retry-Verlauf, bestätigten Effekt und Zeitpunkte verknüpft.

Auch Unsicherheit gehört hinein. Lokale Einmaligkeit beweist keine flottenweite Einmaligkeit. Ein gültiges Ticket beweist keine aktuelle geschäftliche Befugnis. Ein Anfragehash beweist keine gleiche Semantik, wenn verborgene Header, Kontostand oder regionale Reichweite wechselten. Eine Transportablehnung beweist nicht, dass keine nachgelagerte Komponente den ersten Versuch sah.

Die Trennung macht die Leistungswahl steuerbar. 0-RTT kann für folgenlos wiederholbare Operationen erlaubt, für begrenzte Schreibvorgänge an global erzwungene Idempotenz gebunden oder bei nicht sicher entscheidbarer Autorisierung und irreversiblen Effekten verweigert werden. Entscheidend ist nicht der Anteil beschleunigter Handshakes, sondern der Anteil erklärbarer Ausführungshistorien.

Quellen