Summary

  • RFC 9931 stellt klar: Eine Upgrade- oder CONNECT-Anfrage vollständig zu senden ist notwendig, reicht aber nicht aus, um den Zustand einer HTTP/1.1-Verbindung zu ändern. Frühere Erfolge stützen eine Prognose; nur die aktuelle 101 Switching Protocols- oder 2xx-Antwort bestätigt den aktuellen Wechsel.
  • Gibt ein vertrauenswürdiger HTTP-Client vor dieser Bestätigung Bytes einer nicht vertrauenswürdigen dritten Partei frei, kann der ablehnende Server sie als weitere authentisierte HTTP-Anfrage lesen. Ein belastbarer Betriebsnachweis verbindet deshalb Wartezustand, Antwort, Freigaberegel und aktiven Parser, ohne den Nutzinhalt zu speichern.

Der schnelle Pfad verbraucht Gewissheit im Voraus

Optimistisches Senden hat einen nachvollziehbaren Zweck. Wenn ein Server den Wechsel fast immer akzeptiert, wirkt das Warten auf seine Antwort wie vermeidbare Latenz. Der Client beendet die Anfrage und beginnt sofort mit Daten, die der erwartete neue Protokollzustand verarbeiten soll. Trifft die Annahme zu, startet die nutzbare Kommunikation früher.

RFC 9931 untersucht den anderen Ausgang auf HTTP/1.1. Das Dokument wurde im März 2026 im IETF-Stream als Standards-Track-RFC veröffentlicht und aktualisiert RFC 9112 sowie RFC 9298. Es erklärt nicht jede Optimierung zum Fehler. Es trennt zwei benachbarte Ereignisse, die Betriebsprotokolle gern zusammenziehen: Der Client hat den Wechsel beantragt; der Server hat den Wechsel angenommen.

Bei Upgrade schlägt der Client ein anderes Anwendungsprotokoll für die bestehende Verbindung vor. Mit 101 Switching Protocols erklärt der Server sein Einverständnis und nennt das nach der Antwort geltende Protokoll. CONNECT bittet einen Proxy um einen Tunnel. Eine erfolgreiche 2xx-Antwort schaltet nach dem Ende der Antwort-Header in den Tunnelmodus. Jede andere Antwort bedeutet, dass noch kein Tunnel besteht.

HTTP verlangte bereits, die Anfrage vollständig zu senden, bevor der Client das neue Protokoll beginnt. RFC 9931 ergänzt die entscheidende Einschränkung: Das ist nur eine notwendige Bedingung. Der Server kann das Token nicht unterstützen, Authentisierung verlangen, Ziel oder Port ablehnen, an der Namensauflösung scheitern oder bei HTTP/1.1 bleiben. Vor seiner Antwort gibt es Erwartung, aber keinen bestätigten Verbindungszustand.

Erfolgsquoten gehören in die Prognose

Vergangene Beobachtungen sind nicht wertlos. Kompatibilitätsdokumentation, Tests, Softwareversionen, Ablehnungsquoten und jüngste Erfolge helfen bei Rollout, Kapazität und der Bewertung eines Latenzgewinns. Ein verantwortlicher Betrieb sollte daraus lernen.

Er darf nur die Fragestellung nicht austauschen. Seit der letzten Verbindung können Route, Backend, Berechtigung, Zielrichtlinie oder Vermittlerkette gewechselt haben. Auch ohne sichtbare Änderung kann ein Ziel gerade jetzt ausfallen. Vor allem weist das Protokoll dem gegenwärtigen Server die Entscheidung über die gegenwärtige Anfrage zu. Eine Statistik erzeugt keine noch fehlende Antwort.

Verkürzte Sätze fördern die Verwechslung. „Der Proxy unterstützt CONNECT“ wird zu „Dieses CONNECT ist angenommen“. „Das Token ist registriert“ wird zu „Die Verbindung hat gewechselt“. „Es funktioniert immer“ wird zur stillen Dauererlaubnis, Daten früh freizugeben. Mit jeder Verkürzung verschwinden Verbindung, Anfrage, Antwort oder Zeitpunkt.

Ein sauberer Nachweis hält daher zwei Flächen auseinander. Prognosebelege umfassen Version, Test, Dokumentation und Historie. Zustandsbelege umfassen HTTP-Version, Verbindungsepoche, aktuelle Antwort und gewähltes Protokoll. Beide können fast immer übereinstimmen und dennoch nicht austauschbar sein.

Derselbe Datenstrom kann einen anderen Urheber bekommen

RFC 9931 behauptet nicht, jede Zweiparteienverbindung erzeuge dieses Sicherheitsproblem. Wenn beide Enden ohnehin mit beliebigen Daten des anderen rechnen, kann eine Fehlprognose ein begrenzter Protokollfehler bleiben. Kritisch wird die Anordnung, wenn der Server dem HTTP-Client vertraut, die weitergeleiteten Daten aber von einer nicht vertrauenswürdigen dritten Anwendung gewählt werden.

Eine lokale Anwendung bittet etwa einen authentisierten Proxy-Client um einen TCP-Tunnel. Sie liefert sofort die ersten Bytes für den entfernten Dienst. Der Client leitet sie vor dem 2xx weiter. Kann der Proxy das Ziel nicht erreichen, lehnt er CONNECT ab und erwartet auf derselben Verbindung die nächste HTTP/1.1-Anfrage.

Eine bösartige Anwendung kann ihre Daten so formen, dass sie zugleich eine gültige HTTP-Anfrage an den Proxy bilden. Der Server sieht sie auf der Verbindung des vertrauenswürdigen Clients, vielleicht mit einem Client-Zertifikat auf Verbindungsebene. Damit sprechen Drittbytes unter einer fremden Identität. RFC 9112 beschreibt Request Smuggling als Ausnutzen unterschiedlicher Parserauslegung, um Anfragen zu verbergen, die Richtlinien sonst blockieren würden.

Es liegen drei getrennte Fehler vor. Die Wechselprognose war falsch. Sender und Empfänger wählten verschiedene Grammatiken. Und die Aktion wurde einem Akteur zugeschrieben, der ihre Bytes nicht bestimmt hatte. Ein Zähler abgelehnter Wechsel erfasst nur den ersten Fehler.

Auch unvollständige Anfragen können gefährlich sein, wenn sie einen Parser erreichen, dessen Vertrauensannahme dadurch verletzt wird. Die Quellen belegen keine konkrete Produktlücke und keinen Vorfall. Sie belegen die bedingte Struktur: Eine Freigabe vor Bestätigung verändert, wer den alten Parser mit Eingaben versorgen kann.

WebSocket, UDP und IP wählen verschiedene Abkürzungen

WebSocket schreibt Warten vor. Nach dem Eröffnungs-Handshake darf der Client erst weitere Daten senden, wenn er die Serverantwort erhalten und geprüft hat. Zusätzlich werden Client-zu-Server-Frames mit hoher Entropie maskiert. Das sind getrennte Regeln für Zeitpunkt und Byteform.

RFC 9298 erlaubte, UDP-Pakete schon vor der Proxyantwort optimistisch zu senden. RFC 9931 beschränkt diese Möglichkeit auf HTTP/2 oder neuer und verbietet sie auf HTTP/1.x. RFC 9484 zieht für IP-Pakete dieselbe Grenze. Übersetzt ein Vermittler HTTP/2 oder HTTP/3 nach HTTP/1.1, muss er Kapseln zurückhalten, bis eine erfolgreiche Proxyantwort geparst ist.

Der Unterschied liegt in der Struktur. HTTP/1.1-Anfragen sind seriell, ihre nächste Grenze ergibt sich implizit aus dem Ende der vorherigen. HTTP/2 und HTTP/3 trennen Anfragen über explizite Streams. Dadurch fallen Daten eines abgelehnten Wechsels nicht einfach in die Syntaxposition der nächsten HTTP/1.1-Anfrage. Das ist kein allgemeines Sicherheitszertifikat für neuere Versionen, Ziele oder Tunnelinhalte.

Für künftige Upgrade-Tokens nennt RFC 9931 weitere Entwürfe: Optimismus verbieten, das neue Protokoll mit einer festen Präambel beginnen, die HTTP/1.1 eindeutig beendet, oder Daten hochentropisch maskieren. Hat die HTTP-Methode nach dem Wechsel keine Bedeutung, reduziert GET ohne Inhalt zusätzlich das Material mit doppelter Lesart.

Die IANA-Registrierung hat eine andere Aufgabe. Sie verbindet Tokenname und Spezifikationsreferenz. Sie beobachtet keine laufende Verbindung und bestätigt nicht, dass ein bestimmter Server dieses Token jetzt akzeptiert.

Der CONNECT-Ablehnungsweg braucht beide Seiten

Ein HTTP/1.1-Proxy-Client, der für einen nicht vertrauenswürdigen TCP-Client arbeitet, muss laut RFC 9931 mindestens eine von zwei Maßnahmen einsetzen. Er wartet vor der Payload-Weiterleitung auf 2xx. Oder er sendet Connection: close, damit eine Ablehnung die Verbindung beendet und vorzeitige Daten nicht als Folgeanfrage gelesen werden. Beides ist möglich.

Auch der ablehnende Proxy-Server erhält eine Pflicht: Er muss die zugrunde liegende Verbindung schließen, ohne weitere Anfragen darauf zu verarbeiten. Diese Maßnahme fängt fehlerhafte Clients ab, kostet aber Leistung. Besonders nach einer 407-Authentisierungsaufforderung ist eine neue Verbindung langsamer als Wiederverwendung.

Darum darf der Server die Maßnahme für einen Client abschalten, von dem bekannt ist, dass er auf 2xx wartet. RFC 9931 nennt User-Agent und Herstellerdokumentation als Identifikationshilfe. RFC 9110 definiert User-Agent jedoch als Produktinformation des sendenden Programms und rät von Maskerade ab; es macht daraus keine kryptografisch bestätigte Identität.

Eine Ausnahme sollte daher ein Ablaufdatum haben. Produkt und Version, geprüfte Herstellererklärung, lokaler Test, betroffene Vermittler, Eigentümer, Prüftermin und Rücknahmebedingung gehören zusammen. Ein Update kann die Sendereihenfolge ändern. „Bekannter Client“ ist eine datierte Schlussfolgerung, keine Eigenschaft für immer.

Ein Wechselbestätigungsbeleg ohne Verkehrskopie

Die entscheidende Antwort liegt bereits auf der Leitung. Häufig trennen Betriebsdaten trotzdem Wechselversuch, Freigabe fremder Bytes und endgültigen Parserzustand. Daniel Kade schlägt für relevante Pfade einen kompakten Wechselbestätigungsbeleg vor.

Der erste Block nennt Verbindungsepoche und HTTP-Version. Er verzeichnet Upgrade oder CONNECT, Token oder Tunneltyp und bei Bedarf eine geschützte Zielreferenz. Er klassifiziert die Datenquelle als eigene Kontrolle, begrenztes Teilsystem oder nicht vertrauenswürdige dritte Partei, ohne die Daten zu kopieren.

Der zweite Block beschreibt das Tor. Welche Clientversion und Richtlinie bestimmten die Freigabe? Wartete der Pfad auf 101 oder 2xx, verlangte er Schließen, nutzte er Präambel, Maskierung oder expliziten Stream? Wurden vor der Antwort Bytes gesendet, und falls ja, auf Grundlage welcher sicheren Konstruktion statt welcher historischen Quote?

Der letzte Block verbindet Antwortklasse, ausgewähltes Protokoll, tatsächlich aktiven Parser oder Tunnel, Behandlung nach Ablehnung und Eindämmungsaktion. Ausnahmen tragen Beleg, Umfang, Verantwortlichen, Frist und Ungültigkeitsauslöser. Änderungen an Client, Server, Vermittler, Authentisierung oder Richtlinie eröffnen eine neue Entscheidung.

Der Beleg enthält weder Payload noch Berechtigungsheader, Zertifikatsgeheimnisse oder Anmeldedaten. Auch überschätzt er 2xx nicht: Die Antwort bestätigt den Tunnel, nicht jede geschäftliche Handlung darin. Anwendung und Zieldienst behalten ihre eigenen Autorisierungsentscheidungen.

Dies ist Daniel Kades redaktioneller Vorschlag, kein Feld aus RFC 9931 und keine IETF-Anforderung an Unternehmensprozesse. Er bewahrt eine kleine Tatsache: Welche aktuelle Antwort ließ welche Datenklasse unter welcher Regel die Parsergrenze überschreiten?

Grenzen der Aussage

Die Quellen nennen kein verwundbares Produkt, keinen Einsatzanteil, keine Ausnutzungsrate und keinen Vorfall. Sie entscheiden auch nicht universell zwischen Warten, Schließen, Puffern, Präambel, Maskierung und Versionswechsel. Jede Architektur trägt andere Kosten.

Latenz und Ressourcen sind echte Einschränkungen. Eine regierbare Optimierung muss nicht langsam sein. Sie muss bei einer Fehlprognose Parser, Urheber und Zustand auseinanderhalten und einen prüfbaren Korrekturweg bieten.

Die belastbare Aussage bleibt eng: Früherer Erfolg kann die Prognose verbessern. Den aktuellen Wechsel bestätigt allein die aktuelle Antwort.

Sources

  1. RFC 9931: Sicherheitsbetrachtungen für optimistische Protokollwechsel in HTTP/1.1
  2. RFC-Editor-Informationsseite zu RFC 9931
  3. RFC 9110: HTTP Semantics
  4. RFC 9112: HTTP/1.1
  5. RFC 9298: UDP-Proxying in HTTP
  6. RFC 6455: WebSocket Protocol
  7. RFC 9484: IP-Proxying in HTTP
  8. RFC 9113: HTTP/2
  9. RFC 9114: HTTP/3
  10. IANA-Register der HTTP-Upgrade-Tokens
  11. Heng Lu, „The Policy Mirror“
  12. Heng Lu, „Minimum Initial Specification, Localized Future Decision, Voluntary Adoption“
  13. Heng Lu, „On Why BTW Media Exists, and Why Reality, Not Advocacy, Is the Product“