Zusammenfassung

  • draft-ietf-httpbis-connect-tcp-14 identifiziert einen TCP-Proxy über ein URI-Template mit target_host und target_port; die Expansion erzeugt die Ressource für connect-tcp.
  • Das Template wählt Origin, Pfad, Schutzraum und Ort der Zielrichtlinie. Seine Herkunft ist deshalb Teil der Autorisierung.
  • Der IETF Last Call läuft bis 1. Oktober 2026. Der Text ist weiterhin ein Internet-Draft und kein Beleg für RFC-Freigabe, Implementierung oder produktiven Einsatz.

Die Konfiguration bestimmt das Tor

Beim klassischen CONNECT steht das Ziel aus Host und Port im Mittelpunkt. Revision 14 gibt dem Client zuvor ein URI-Template. Er setzt target_host und target_port ein und richtet die Anfrage an die daraus entstandene Ressource des Proxy-Origins.

Damit entscheidet die Konfiguration, wohin Zugangsdaten gelangen, welchen Pfad ein HTTP-Gateway routet und welchem Origin Zustände wie HSTS, Alt-Svc oder Cookies zugeordnet werden. Das Template ist nicht bloß eine Schreibweise. Es bestimmt den Kontrollpunkt.

Die Anforderungen stammen aus RFC 9298: absolute Form, nichtleere Scheme-, Authority- und Path-Komponenten, Variablen nur in Path oder Query, beide Zielvariablen und Ausschluss mehrerer Expansionsoperatoren. Erkennt der Client eine Verletzung, muss er die Konfiguration vor dem Senden verwerfen.

Diese Prüfung belegt Syntax und Ableitung. Sie belegt nicht, wer das Template verteilt hat, ob dieser Akteur den Ausgang ändern durfte oder ob der Origin zum erwarteten Verwaltungsdienst gehört. Auch eine kompromittierte Vorlage kann formal korrekt sein.

HTTP-Status ist ein Stufenbeleg

Unter HTTP/1.1 sendet der Client GET an die expandierte URI und fordert Upgrade: connect-tcp. Ist die Anfrage zulässig, versucht der Proxy die TCP-Verbindung vor einer endgültigen Antwort. Bei Erfolg folgt 101 Switching Protocols; ohne etablierte Verbindung darf kein Protokollwechsel stattfinden.

Unter HTTP/2 und HTTP/3 kündigt der Proxy extended CONNECT an. Die Anfrage verwendet :protocol = connect-tcp, die Proxy-Autorität und den aus dem Template abgeleiteten Pfad. Eine erfolgreiche CONNECT-Antwort öffnet den Stream für das Capsule Protocol.

Expect: 100-continue trennt eine frühere Stufe ab. 100 bedeutet: Anfrage empfangen und nicht sofort abgelehnt. Der Ziel-Handshake muss noch nicht abgeschlossen sein. Ein späteres 101 oder erfolgreiches extended CONNECT besagt stärker, dass der Proxy TCP als hergestellt meldet. Es bestätigt weder die Anwendungsidentität noch das Zielzertifikat, die Bytezustellung oder den beabsichtigten Geschäftseffekt.

Ein einziges Erfolgsfeld verwischt Ablehnung am Eingang, fehlgeschlagenen TCP-Aufbau und Anwendungsfehler im bestehenden Tunnel. Diese Zustände brauchen getrennte Messwerte und Verantwortliche.

Authentifiziert wird der Schutzraum des Proxys

Der Template-Proxy besitzt einen eindeutigen Origin und nutzt normalerweise 401, WWW-Authenticate und Authorization. Die klassischen 407-Felder werden nicht verwendet, weil sie normale HTTP-Gateways nicht durchqueren. Ressourcen aus einem Template teilen üblicherweise einen Protection Space; TLS-Clientzertifikate sind ebenfalls möglich.

So lassen sich Pfadrouting, DDoS-Abwehr, Request-Sanitizing und Nutzerautorisierung wiederverwenden. Ein hochentropischer Pfad oder Concealed Authentication kann den Dienst für unberechtigte Sonden verbergen.

Der Geltungsbereich eines Nachweises bleibt trotzdem eng. Akzeptierte Zugangsdaten beantworten nur die Authentifizierungsfrage für diesen Protection Space. Eine andere Regel entscheidet über Zielhost und Port. DNS liefert Adressen. Ziel-TLS prüft eine weitere Identität. Die Anwendung entscheidet über die erlaubte Aktion.

RFC 9110 warnt vor CONNECT zu beliebigen Ports, weil ein Proxy dadurch fremde Protokolle weiterleiten kann. Das URI-Template beseitigt diese Gefahr nicht. Es schafft einen klareren Ort für die Zielregel.

DATA schützt Reihenfolge, FINAL_DATA eine Richtung

TCP-Nutzdaten liegen in DATA-Kapseln. FINAL_DATA kann die letzten Bytes tragen und markiert zusätzlich den FIN dieser Richtung. Danach sind weder DATA noch ein zweites FINAL_DATA erlaubt. Ein empfangener TCP-FIN muss zu FINAL_DATA werden; gültiges FINAL_DATA muss einen TCP-FIN auslösen.

Kapselgrenzen entsprechen nicht zwingend TCP-Segmenten, TLS-Records, HTTP-Frames oder Anwendungsnachrichten. Ein Vermittler darf aufeinanderfolgende Kapseln teilen oder zusammenführen, wenn die Bytefolge und der letzte Kapseltyp erhalten bleiben.

Das gemeinsame Protokoll garantiert also Reihenfolge und Half-Close-Semantik, nicht Geschäftsbedeutung. Der Client kann in den HTTP-Stream geschrieben haben, während der Proxy optimistische Daten puffert. Der Proxy kann in den TCP-Socket geschrieben haben, ohne Verarbeitung durch die Gegenstelle. FINAL_DATA kann den FIN erhalten, obwohl die Rückrichtung später abrupt endet.

Bei HTTP/2 und HTTP/3 muss optimistische Nutzlast bis zur beschreibbaren ausgewählten TCP-Verbindung gepuffert und bei Fehlschlag verworfen werden. Bei mehreren konkurrierenden Adressen darf keine Nutzlast an Verlierer gehen. Die Beweiskette trennt daher Template-Herkunft, Proxy-Zertifikat, Authentifizierung, Zielregel, DNS, TCP-Versuch, HTTP-Status, DATA/FINAL_DATA, Ziel-TLS, Bytes, Abschluss und Anwendungsergebnis.

Last Call ist kein Betriebsnachweis

Die IESG-Mitteilung erbittet Kommentare bis 1. Oktober. Datatracker führt Revision 14 als aktiv, beim IESG eingereicht und für Proposed Standard vorgesehen.

Das Dokument kann noch geändert, ersetzt oder ablaufen. Auch ein späterer RFC würde einen Interoperabilitätsvertrag belegen, nicht vorhandenen Code, Gateway-Kompatibilität, korrekte Half-Closes oder sichere Betreiberregeln.

Running-Code-Primacy verlangt Belege aus dem System, das die Wirkung trägt. Die minimale Anfangsspezifikation hält den gemeinsamen Kern bei Syntax, Reihenfolge, Abschluss und Fehlern. Vertrauen in Provisionierung, Ziele und Ergebnisannahme bleibt lokal.

Der Proxy darf den Tunnel öffnen. Er kann nicht stellvertretend beweisen, was dahinter geschieht.

Quellen