Summary

  • RFC 9931が明確にしたのは、UpgradeやCONNECTの要求を送り終えただけでは、HTTP/1.1接続の状態はまだ変わらないという境界である。以前の成功は予測材料になるが、今回の101 Switching Protocolsまたは成功した2xxだけが今回の切り替えを確定する。
  • 信頼されたHTTPクライアントが、その応答より前に信頼されない第三者のデータを放出すると、拒否後もHTTP/1.1を読むサーバーがそれを次の認証済み要求として扱い得る。記録すべきなのはペイロードではなく、待機の有無、現在の応答、放出規則、最終的なパーサー状態である。

待ち時間を削るとき、何を先に使っているのか

楽観的送信は、根拠のない賭けとは限らない。サーバーがほぼ確実に切り替えを受け入れるなら、応答を待ってから新しいプロトコルのデータを送る一往復は、性能上の無駄に見える。予測が当たれば、利用可能な通信を早く始められる。

2026年3月にIETF標準化過程の文書として公開されたRFC 9931は、HTTP/1.1で予測が外れたときの安全性を扱う。RFC 9112とRFC 9298を更新したこの文書の要点は、最適化そのものを退けることではない。「切り替えを要求し終えた」と「相手が切り替えを受け入れた」を、隣接していても別の出来事として扱うことだ。

Upgradeでは、クライアントが既存接続上のアプリケーションプロトコル変更を提案する。サーバーが理解し応じる意思を示すのが101 Switching Protocolsであり、応答後に有効になるプロトコルも示される。CONNECTでは、成功した2xxの応答ヘッダーが終わったところからトンネルになる。それ以外の応答なら、トンネルは形成されていない。

HTTPの既存仕様は、要求メッセージの途中で新しいプロトコルを話し始めることを許していなかった。RFC 9931は、要求の完了が必要条件にすぎないと明記する。サーバーはトークンを知らないかもしれず、認証を要求したり、宛先やポートを拒否したり、名前解決や接続に失敗したりする。応答が来るまでは、接続状態ではなく予想しかない。

実績は能力の手掛かりであって、今回の回答ではない

運用は過去を学習すべきである。同じトークンが直前に通った、対象群の拒否率が低い、ベンダー文書が対応を表明している、といった情報は、展開範囲や容量、レイテンシー予算を決める助けになる。過去を無視することが慎重さではない。

ただし、その証拠が答える問いを変えてはいけない。前回から経路、バックエンド、資格情報、宛先方針、中継装置が変わる可能性がある。何も変わっていなくても、遠隔接続は今回だけ失敗し得る。そして仕様上、現在の要求を受け入れるかは現在のサーバーが決める。高い成功率は、まだ届いていない応答を生成しない。

誤解は省略された言葉から生まれる。「このプロキシはCONNECT対応」が「このCONNECTは成功済み」になり、「トークンは登録済み」が「接続は切り替わった」に変わる。「いつも通る」は、いつしかデータを先送りする恒久的な許可として扱われる。そこでは接続、要求、時点という識別子が失われている。

管理記録では二つの欄を分ける必要がある。予測の欄には、実装版、過去の結果、文書、検証結果を置く。現在状態の欄には、HTTP版、接続エポック、今回の応答、選択されたプロトコルを置く。両者がほぼ毎回一致しても、互いの代用にはならない。

バイト列の意味だけでなく、発言者まで変わる

RFC 9931は、二者だけの接続すべてに新しい脅威があるとは述べていない。互いに任意のデータを受け取る前提なら、誤予測は単なるプロトコル失敗に収まる場合がある。問題が深くなるのは、サーバーがHTTPクライアントを信頼し、そのクライアントが信頼されていない第三者のデータを転送するときだ。

権限のないローカルアプリケーションが、認証済みのプロキシクライアントにTCPトンネルを求める場面を考える。アプリケーションは遠隔サービス向けの最初のデータをすぐに渡し、クライアントは2xxより先に転送する。宛先が存在しなければ、プロキシはCONNECTを拒否し、同じ接続上で次のHTTP/1.1要求を待つ。

第三者がそのデータをHTTP要求としても読める形に整えていれば、サーバーは信頼されたクライアントの要求として処理し得る。接続レベルのクライアント証明書が使われていれば、第三者のバイトがクライアントの身元を借りる。RFC 9112は、受信者間の解析差を利用して、本来方針で禁止される要求を隠す行為をリクエストスマグリングとして説明する。

したがって障害は三段ある。切り替え予測が外れた。送受信側のフレーミング解釈が食い違った。そして、データを選んだ主体と要求の名義が食い違った。切り替え失敗件数だけでは、最初の段しか見えない。

完全な要求にならないデータでも、信頼されたHTTP入力だけを想定したパーサーへ攻撃者制御の材料を届ける可能性がある。ここから特定製品の脆弱性や実事故を推測してはならない。確認前の放出が、古いパーサーへ入力できる主体を変える、という条件付きの境界が確認できるだけだ。

WebSocket、UDP、IPは同じ近道を選んでいない

WebSocketは、開始ハンドシェイク後にサーバー応答を待ち、検証してから追加データを送る。さらにクライアントからサーバーへのフレームを高エントロピーでマスクする。送信時点とデータ形状をそれぞれ制約する設計である。

RFC 9298は、UDPプロキシ要求への応答前にパケットを送る余地を設けていた。RFC 9931は、その余地をHTTP/2以降に限定し、HTTP/1.xでは明確に禁止した。IPプロキシのRFC 9484も同じ線を引く。HTTP/2またはHTTP/3からHTTP/1.1へ変換する中継者は、成功応答を解析するまで受信カプセルを転送してはならない。

HTTP/1.1では要求が直列で、前の要求の終端から次の要求境界を暗黙に判断する。HTTP/2とHTTP/3は要求ごとに明示的なストリームを持つ。そのため、拒否された切り替え用データが次のHTTP/1.1要求の位置にそのまま落ちる、という特定の曖昧さを避けられる。これは新しい版全体の安全証明でも、トンネル内部の認可でもない。

将来のUpgradeトークンに対して、RFC 9931は複数の設計を挙げる。楽観的送信を禁じる、新プロトコルの先頭にHTTP/1.1解析を確実に終わらせる固定プレアンブルを置く、あるいは高エントロピーのマスキングを使う。切り替え後にHTTPメソッドの意味を引き継がないなら、内容のないGETに限定することも、二重解釈される材料を減らす。

IANAのHTTP Upgrade Token登録簿は、名称と参照仕様を管理する。登録は共通語彙を作るが、稼働中の接続を観測しない。あるトークンが存在することと、あるサーバーが今回受け入れたことは、別の証拠である。

CONNECT拒否はクライアントとサーバーの両方で閉じる

信頼されないTCPクライアントのために動くHTTP/1.1プロキシクライアントは、RFC 9931により二つのうち少なくとも一つを行う。成功した2xxまでTCPペイロードを待つか、Connection: closeを要求に付ける。後者なら拒否と同時に接続を閉じ、先行データを次のHTTP要求として読む余地をなくす。両方を選んでもよい。

拒否するプロキシサーバーも、基礎接続を閉じ、その上で追加要求を処理しない義務を負う。早送りするクライアントをサーバー側で封じ込めるためだ。ただし407認証要求のような場面では、接続再確立による性能損失が起きる。

RFCは、2xxを待つと判明しているクライアントについて、サーバーが拒否時切断を無効にできるとしている。識別方法としてUser-Agentとベンダー文書を示す。RFC 9110上のUser-Agentは送信ソフトウェアの製品情報であり、他製品へのなりすましを避けるべきだとはされるが、暗号学的な本人確認ではない。

例外には寿命が必要になる。対象製品と版、参照したベンダー文書、ローカル試験、中継経路、責任者、期限、取消条件を残す。送信順を変えるアップデート後まで「既知の適合クライアント」という結論だけを持ち越してはならない。

遷移確認レシートは中身を保存しない

切り替えを確定する応答はすでに通信上にある。それでも運用ログでは、要求、第三者データの放出、最終パーサー状態が別々になりやすい。Daniel Kadeは、これらを結ぶ小さな遷移確認レシートを提案する。

最初に接続エポックとHTTP版を記す。UpgradeかCONNECTか、要求したトークンまたはトンネル種別、必要に応じて秘匿・ハッシュ化した宛先参照を持つ。後続データの出所を、自組織管理、限定された下位系、信頼されない第三者のいずれかに分類するが、実データは複製しない。

次に放出ゲートを記録する。どの実装版と方針が、101や2xxを待つこと、切断、固定プレアンブル、マスキング、明示的ストリームのいずれを選んだのか。現在応答前にバイトを送ったか。送ったなら、過去の成功率ではなく、どの安全な構造を根拠にしたのか。

最後に、応答区分、選択プロトコル、実際に有効になったパーサーまたはトンネル、拒否後の接続処理、封じ込め措置を結ぶ。例外には根拠、範囲、承認者、期限、失効条件を付ける。クライアント、サーバー、中継、認証、方針の変更は新しい判断を開く。

レシートにトンネル内容、資格情報、証明書秘密、認可ヘッダーを入れる必要はない。また2xxを過大評価してもいけない。それが確認するのはトンネル形成であり、内部で行われる業務行為の許可ではない。

これはRFC 9931の要求でも新しいHTTPフィールドでもない。RFCが示した薄い境界を、各運用者が説明可能にするためのローカル統制である。

分かっていないことを残す

参照資料は、特定の製品障害、攻撃事例、普及率を示していない。どれほどのクライアントが境界を誤るかも不明である。待機、切断、プレアンブル、マスキング、HTTP版移行のどれが全環境で最適かも決められない。

レイテンシーと再接続コストは正当な制約だ。安全な設計とは、それらを無視する設計ではない。予測が外れても、パーサーと発言者の境界が壊れず、結果を監査し訂正できる設計である。

確実に言える範囲は狭い。前回の成功は次の結果を予測できる。しかし今回の接続を切り替えるのは、今回の応答だけだ。

Sources

  1. RFC 9931：HTTP/1.1における楽観的プロトコル遷移のセキュリティ考慮事項
  2. RFC EditorのRFC 9931情報ページ
  3. RFC 9110：HTTPセマンティクス
  4. RFC 9112：HTTP/1.1
  5. RFC 9298：HTTPによるUDPプロキシ
  6. RFC 6455：WebSocketプロトコル
  7. RFC 9484：HTTPによるIPプロキシ
  8. RFC 9113：HTTP/2
  9. RFC 9114：HTTP/3
  10. IANA HTTP Upgrade Token登録簿
  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」