要約

  • 従来のHTTP CONNECTが示すのはTCPの接続先であり、プロキシサービス固有のオリジンやパスではない。新方式はURIテンプレートでサービスを識別し、Capsuleメッセージでバイト列を運ぶ。
  • IESGは10月30日、草案をProposed Standardとして公表することを承認した。対応するゲートウェイは、扱うHTTPバージョン間でトンネル要求を変換する必要がある。公開記録には導入数も実環境の結果もない。

プロキシに住所ができた。ゲートウェイには新しい仕事ができた。

HTTP CONNECTを使えば、クライアントはプロキシに対し、宛先のホストとポートへのTCP接続を求められる。接続後、プロキシはクライアントと宛先の間でバイト列を運ぶ。ただし、リクエストが指すのはトンネルの行き先だ。どのプロキシサービスを使うのかを示すパスやオリジンは含まれない。

一つのHTTPサーバーで複数のプロキシサービスを提供すると、この欠落が効いてくる。サービス固有のパスやオリジンがなければ、通常のWebリソースや仮想ホストのようには区別できない。草案はセキュリティ上の影響も挙げる。プロキシの明示的なオリジンがないため、サーバーポートの誤誘導に対する通常の防御を使えず、Alt-SvcやStrict-Transport-Securityのようなオリジン単位の応答ヘッダーも、どこに適用するか曖昧になる。

IESGは10月30日、draft-ietf-httpbis-connect-tcpをProposed Standardとして公表することを承認した。第17版はその前日に出ている。これはHTTPでTCPを運ぶ新しい方式であり、ユーザーがどの宛先に接続できるかを決める規則ではない。プロキシの入口は明確になる。接続許可は引き続きプロキシ運営者が決める。

草案では、target_hostとtarget_portを含むURIテンプレートでプロキシサービスを識別する。クライアントが接続先を代入してURIを作り、プロキシへ送る。HTTP/1.1ではGETの後にconnect-tcpへUpgradeする。HTTP/2とHTTP/3では、:protocolをconnect-tcpとするExtended CONNECTを使う。プロキシは設定情報で対応状況を知らせる。

TCPのデータはCapsule Protocolのメッセージに入る。DATAはバイト列を運び、FINAL_DATAは最後のバイト列とTCP FIN相当の終了通知を運ぶ。カプセル境界をTCPセグメントやTLSレコードに見立てるわけではない。HTTP上でストリームを包む単位だ。

オリジンとパスが定まると、プロキシサービスを通常のHTTPの意味付けに置ける。一つのサーバー上の複数サービスを区別でき、オリジン単位のヘッダーにも適用範囲ができる。ただし、アクセス許可は別問題だ。プロキシには宛先を制限するルールが要る。URIテンプレートはアクセス制御リストではない。

そこで宿題はゲートウェイに移る。対応を名乗るゲートウェイは、HTTP/1.1のUpgradeまたはExtended CONNECTを扱い、connect-tcpを転送し、サポートするHTTPバージョン間で要求を変換しなければならない。Proxy-Statusも通す必要がある。接続先がTLSクライアント証明書で認証する場合、ゲートウェイ自身が認証するか、証明書情報を接続先へ渡す。

IETFは引き継ぎ要件を書いたが、ゲートウェイの更新までは行わない。草案と決議記録に導入済みゲートウェイ数、採用予測、実運用での相互接続試験結果はない。標準が決めるのはメッセージの形だ。運用側は、経路上の全プロキシ、ゲートウェイ、認証境界を洗い出す必要がある。

出典