Zusammenfassung

  • TLS 1.3 erlaubt einem wiederkehrenden Client, Anwendungsdaten mit dem ClientHello zu senden. Das spart ein oder zwei Netzrunden, gibt Early Data aber keine verbindungsübergreifende Nicht-Wiederholungs-Garantie.
  • RFC 8470 ordnet Wissen und Verantwortung: Vermittler bewahren Early-Data: 1, die Origin kennt die Folgen der Ressource, und 425 verweigert genau der riskanten Anfrage die vorzeitige Ausführung.
  • Der Client soll automatisch erneut senden, jedoch niemals wieder als Early Data. Methode, Ziel und Inhalt dürfen gleich bleiben; der kryptografische Zeitpunkt ändert sich. HTTP/3 behielt diese Grenze über QUIC bei.

Der Server hatte noch nichts Neues beigetragen

Im üblichen TLS-Ablauf wartet HTTP auf den Handshake. Beide Seiten liefern frische Werte, daraus entstehen Schlüssel für diese Verbindung, erst dann beginnt die Anwendung. Entfernung macht diese Reihenfolge als Latenz sichtbar.

TLS 1.3 ließ einen Client mit PSK und Sitzungsticket schon neben dem ClientHello Anwendungsdaten senden. Er musste den neuen ServerHello nicht abwarten und konnte ein oder zwei Round Trips einsparen.

RFC 8446 benennt den Preis. 0-RTT ist verschlüsselt, besitzt aber keine Forward Secrecy und keine Garantie gegen Replay zwischen Verbindungen. Die Daten verlassen den Client, bevor der neue Serverzufall sie an genau diese Verbindung binden kann.

Das ist keine Behauptung fehlender Kryptografie. Ein Angreifer kann die authentisierten Bytes nicht beliebig ändern, nicht innerhalb derselben Verbindung verdoppeln und nicht in 1-RTT-Daten umformen. Er kann das frühe Paket auf einer weiteren Verbindung vorlegen, die denselben Wiederaufnahmekontext noch akzeptiert.

Replay und Retry können denselben Effekt treffen

Ein Retry wird vom Client erkannt: Antwort verloren, Verbindung abgebrochen, Nutzer versucht erneut. Ein Replay geschieht ohne sein Wissen. Dennoch können zwei Zonen sie verkoppeln.

Zone A akzeptiert eine Kopie und handelt. Zone B besitzt nicht denselben Replay-Stand, verweigert 0-RTT, schließt aber den Handshake ab. Bleibt A's Antwort verborgen, sendet der Client auf B legitim erneut. Die Operation geschieht einmal durch Replay und einmal durch Wiederherstellung.

Einmal-Tickets, ClientHello-Aufzeichnung, kurze Zeitfenster und eine autoritative Ticketzone begrenzen direkte Replays. Sie verlangen konsistenten Zustand über Instanzen, Regionen und Neustarts. TLS kann dennoch nicht erkennen, ob Bytes eine Grafik lesen oder einen Anspruch verbrauchen.

Die Methode war Hinweis, nicht Freibrief

Sichere und idempotente HTTP-Methoden helfen dem Client bei einer vorsichtigen Vorauswahl. Sie beweisen nicht das Verhalten der Ressource. Ein GET kann einen signierten Einmal-Link verbrauchen, eine kostenpflichtige Berechnung starten oder dauerhafte Messung auslösen. Eine Schreiboperation mit Transaktionsschlüssel kann Wiederholungen dagegen erkennen.

RFC 8470 macht Replay-Verträglichkeit deshalb ressourcenspezifisch. Der Client kennt seine Spekulation, TLS die Phase, das Gateway den Weg und die Origin die Wirkung. TLS-Bibliotheken dürfen 0-RTT weder selbstständig aktivieren noch abgelehnte Daten ohne Anwendungsvorgabe neu senden.

Drei gültige Grenzen

Der Server kann Early Data vollständig auf TLS-Ebene ablehnen. Das ist einfach, nimmt aber jeder Anfrage im Flug den Vorteil, weil TLS keine einzelne HTTP-Nachricht auswählt.

Er kann die Daten annehmen und HTTP-Verarbeitung verzögern. Header dürfen zur Klassifikation gelesen werden, solange noch keine Wirkung beginnt. Multiplexierte Anfragen können unterschiedliche Freigabezeitpunkte haben.

Oder die Origin antwortet einer Anfrage mit 425 Too Early. Nur diese Operation kehrt zum Client zurück; ausdrücklich tolerante Ressourcen behalten 0-RTT. Die Abkürzung wird pro Ressource widerrufbar.

Ein Bit musste durch jede Vermittlungsschicht

Hinter CDN, Reverse Proxy und Gateway sieht die Origin womöglich nur eine fertige Verbindung. Dass der erste Hop Early Data empfing, wäre ohne zusätzliche Herkunft verloren.

Early-Data hat ausschließlich den gültigen Wert 1. Ein Vermittler, der vor Abschluss seines clientseitigen Handshakes weiterleitet, muss ihn setzen; ein vorhandenes Feld darf er nicht entfernen. Mögliche frühere Weiterleitung durch andere Instanzen hält die Markierung ebenfalls aufrecht.

Das Bit ist Geschichte, keine Geschwindigkeitspräferenz. Ein späterer Handshake löscht die mögliche Kopie am früheren Hop nicht. Kann die Origin eine markierte Anfrage nicht sicher verarbeiten, muss sie 425 liefern.

Mehrere oder ungültige Vorkommen zählen als dasselbe konservative Risiko. Das Feld gehört nicht in Antwort, Trailer oder Connection. Seine geringe Ausdruckskraft verhindert, dass ein Proxy es zur Vertrauensbehauptung ausbaut.

Der erneute Versuch ändert die Zeit

Nach 425 auf eine frühe Anfrage soll der User Agent automatisch wiederholen. Der neue Versuch darf kein Early Data sein. Der Client wartet, bis der Handshake abgeschlossen ist, und sendet gewöhnliche Anwendungsdaten.

URI, Methode, Body und Absicht können gleich bleiben. 425 ist keine Umleitung. Es ist nicht 421, weil Verbindung und Origin richtig sein können; nicht 429, weil keine Quote gemeint ist; nicht 503, weil der Dienst gesund sein kann; und nicht 100 Continue, weil es nicht über das Senden des Bodys entscheidet.

Ohne Early-Data-Beleg oder Feld sollte ein Server 425 nicht einsetzen, denn ein normaler Client kennt womöglich die besondere Wiederholung nicht. Die Antwort ist standardmäßig nicht cachebar und keine Repräsentation. Das IANA-Register führt 425 eng als Too Early.

Ein Vermittler kann nur seinen eigenen Anfang verschieben

Kam die Anfrage bereits markiert an, muss der Vermittler 425 weitergeben. Die Unsicherheit liegt oberhalb seiner aktuellen Verbindung und lässt sich nicht lokal beseitigen.

War er selbst der erste Empfänger unmarkierter Early Data, darf er den Handshake mit dem Client abwarten und zur Origin erneut senden. Er kennt dann den Beginn der Geschichte und kann die Anfrage tatsächlich hinter ihn verschieben.

Ein Gateway darf frühe Anfragen nicht an eine Origin geben, deren RFC-8470-Verhalten unbekannt ist. Es wartet oder antwortet selbst. Die Edge darf keine Folgen für eine Anwendung akzeptieren, die diese Herkunft nicht sieht.

Wirkung beginnt nicht mit dem letzten Paket

Header können früh, Bodyteile später eintreffen. QUIC kann einen als früh klassifizierten Stream erst nach Handshakeabschluss zustellen. Ankunft löscht keine Herkunft.

Entscheidend ist, wann die Instanz zu wirken beginnt. Parsen und Routing können neutral sein; Schreiben, Tokenverbrauch, externer Aufruf oder Queue-Eintrag nicht. Alle Instanzen, die dasselbe Ticket akzeptieren, müssen das Invariant „keine Wirkung vor Abschluss“ teilen, auch wenn sie verschieden ablehnen, warten oder 425 senden.

Nach Neustart fehlt einem Knoten die vorherige Replay-Historie. Solange sein Aufzeichnungsfenster die blinde Zeit überlappt, sollte er 0-RTT verweigern. Lokales Vergessen darf die Befugnis einer Anfrage nicht erweitern.

HTTP/3 erhielt einen zweiten Gedächtnistest

RFC 9114 wendet RFC 8470 auf QUIC 0-RTT an. Frühe Anfragen beruhen zusätzlich auf SETTINGS, die der Client aus der letzten Sitzung erinnert.

Kann der Server ihre Vereinbarkeit mit heutigen Werten nicht belegen, muss er 0-RTT ablehnen. Nach Annahme darf er keine kleineren Grenzen verkünden, gegen die bereits gesendete Daten verstoßen hätten.

SETTINGS-Kompatibilität und Ressourcen-Replay sind getrennte Entscheidungen. Die eine schützt Protokollzustand, die andere Wirkungen.

Quellen und Evidenzgrenzen

Die geschlossene Grundlage bilden TLS 1.3, RFC 8446, Using Early Data in HTTP, RFC 8470, HTTP/3, RFC 9114 und das aktuelle IANA-Statuscode-Register. Sie belegen Spezifikation und Grenzen, nicht heutige Verbreitung, universelle Unterstützung, einen bestimmten Vorfall, gemessene Einsparung oder Exactly-once-Ausführung.