Zusammenfassung

  • Klassisches HTTP CONNECT nennt das TCP-Ziel, aber keinen eigenen Ursprung und Pfad des Proxy-Dienstes. Der neue Modus weist ihn über ein URI-Template aus und transportiert den Datenstrom in Capsule-Nachrichten.
  • Die IESG genehmigte den Entwurf am 30. Oktober zur Veröffentlichung als Proposed Standard. Kompatible Gateways müssen den Tunnel zwischen den HTTP-Versionen umsetzen, die sie bedienen; die Unterlagen nennen weder Installationszahlen noch Feldergebnisse.

Der Proxy hat jetzt eine Adresse. Das Gateway bekommt die Arbeit.

HTTP CONNECT lässt Clients seit Jahren über einen Proxy eine TCP-Verbindung zu einem Zielhost und Port öffnen. Danach leitet der Proxy Bytes zwischen Client und Ziel weiter. Die Anfrage benennt aber nur den Zielort des Tunnels. Welchen Proxy-Dienst der Client verwendet, bekommt weder einen eigenen Pfad noch einen eigenen Ursprung.

Das wird zum Problem, wenn ein HTTP-Server mehrere Proxy-Dienste anbietet. Ohne eigenen Ursprung oder Pfad kann er sie nicht so unterscheiden wie gewöhnliche Webressourcen oder virtuelle Hosts. Der Entwurf nennt auch eine Sicherheitsfolge: Ohne expliziten Proxy-Ursprung greifen die üblichen Abwehrmaßnahmen gegen Server-Port-Fehlleitung nicht wie vorgesehen. Außerdem bleibt unklar, für welchen Ursprung Antwort-Header wie Alt-Svc oder Strict-Transport-Security gelten.

Am 30. Oktober genehmigte die IESG draft-ietf-httpbis-connect-tcp zur Veröffentlichung als Proposed Standard. Version 17 des Textes erschien einen Tag zuvor. Der Entwurf schlägt eine neue Art vor, TCP über HTTP zu tunneln. Er entscheidet nicht, welche Ziele ein Nutzer erreichen darf. Die Adresse des Proxy-Dienstes wird eindeutiger; über den Zugriff entscheidet weiterhin der Proxy-Betreiber.

Ein URI-Template mit target_host und target_port identifiziert den Proxy-Dienst. Der Client setzt das Ziel ein und schickt die daraus gebildete URI an den Proxy. Bei HTTP/1.1 verwendet er GET und wechselt dann mit Upgrade zu connect-tcp. Bei HTTP/2 und HTTP/3 läuft der Aufruf als Extended CONNECT mit :protocol = connect-tcp. Der Proxy meldet in seinen Einstellungen, ob er Extended CONNECT unterstützt.

Der TCP-Datenstrom steckt in Nachrichten des Capsule Protocol. DATA trägt Bytes. FINAL_DATA trägt die letzten Bytes und signalisiert das Ende wie ein TCP-FIN. Die Kapselgrenzen sollen weder TCP-Segmente noch TLS-Datensätze nachbilden. Sie verpacken den Datenstrom für den Transport über HTTP.

Mit Ursprung und Pfad wird der Proxy-Dienst Teil der üblichen HTTP-Semantik. Ein Server kann mehrere Dienste auseinanderhalten; ursprungsbezogene Header bekommen einen klaren Geltungsbereich. Die Zugriffsentscheidung bleibt davon getrennt: Der Proxy braucht weiterhin eigene Regeln für erlaubte Ziele. Ein URI-Template ist keine Zugriffsliste.

Die Rechnung landet bei den Gateways. Wer Kompatibilität verspricht, muss HTTP/1.1-Upgrade oder Extended CONNECT verarbeiten, connect-tcp weiterleiten und Anfragen zwischen den unterstützten HTTP-Versionen umsetzen. Auch Proxy-Status muss passieren. Authentifiziert das Ziel seine Nutzer mit TLS-Clientzertifikaten, muss das Gateway selbst authentifizieren oder die Zertifikatsinformationen an das Ziel weitergeben.

Die IETF hat diese Übergabe in die Anforderungen geschrieben. Sie hat keine Gateways aktualisiert. Entwurf und Entscheidungsprotokoll enthalten weder Zahlen zu installierten Gateways noch eine Adoptionsprognose oder Interoperabilitätsergebnisse aus dem Betrieb. Ein Standard legt das Nachrichtenformat fest; Betreiber müssen noch jeden Proxy, jedes Gateway und jede Authentifizierungsgrenze auf dem Pfad finden.

Quellen