要約

  • RFC 9110では、Max-Forwardsの十進数値はTRACEまたはOPTIONSをあと何回プロキシ転送できるかを示す。ゼロなら、その中継者が当該要求の最終受信者として応答する。
  • 数えているのはプロトコル上の転送である。一つの会社が複数ホップを運用することも、複数組織が一つの外形に隠れることもある。
  • ViaやProxy-Statusは追加証拠になり得るが、仮名化や非開示が認められる。経路観測、運用主体の同定、診断の承認は別々に管理すべきである。

地図を作らずに途中で止める

障害中のHTTP経路には、出口プロキシ、エッジ、ロードバランサ、サービスメッシュ、逆プロキシなどが並ぶことがある。全構成を中央台帳に登録してからでなければ調査できない仕組みは遅く、すぐ古くなり、機密性の面でも望ましくない。Max-Forwardsは、もっと小さい問題だけを解く。

値は残り転送回数を示す十進整数である。TRACEまたはOPTIONSとともに受信した中継者は、転送前に必ず確認する。ゼロなら転送せず、自ら最終受信者として答える。正なら一を引くが、自身が対応する上限の方が低い場合はそちらを採る。他のメソッドに付いた値は無視してよい。

この処理で選ばれるのは要求の停止深度である。組織境界ではない。同じ事業者の内部で複数コンポーネントを通れば、その数だけ減る。複数会社のサービスが一つの公開エッジの後ろに置かれていても、数字から契約関係は見えない。「三番目のホップ」を「三番目の会社」と登録すれば、観測より強い事実を捏造することになる。

ゼロの「最終」も要求限定である。その中継者は今回の診断要求を終えるのであって、オリジンサーバになったわけではない。対象資源の所有権も、背後のシステムを代表する権限も取得しない。次の要求が別経路を選べば、同じ初期値でも違う受信者が応答できる。

OPTIONSの能力情報とTRACEの反射

OPTIONSは、資源に作用を及ぼすことなく、対象資源またはサーバで利用できる通信上の選択肢を尋ねる。アスタリスク形式はサーバ全体、通常の対象はその資源との通信を扱う。クライアントはMax-Forwardsで列中の特定受信者を狙えるが、フィールドなしで受け取ったOPTIONSを転送するプロキシが勝手に追加してはならない。

応答には全世界共通の完全な台帳形式がない。成功応答は適用可能なオプション機能を示すフィールドを送るべきだが、拡張や開示方針はローカルで異なる。ある深度で機能が見えないからといって、組織全体が未対応とは限らない。機能が見えても、要求者に利用権限が与えられたことにはならない。

TRACEは、最終受信者が受け取った要求メッセージをアプリケーション層で折り返す。途中の変換やViaを調べるには有用だが、反射は秘密を漏らし得る。クライアントは資格情報やCookieなど応答に現れ得る機微なフィールドを送ってはならず、受信者も機微と思われる項目を除くべきである。TRACEには内容を送れず、その応答はキャッシュできない。

したがって、深度を指定できることは調査権の取得ではない。運用者はTRACEを無効にしたり、認証済み担当者だけに限定したり、反射内容を削ったりできる。Max-Forwardsは転送停止を定めるが、誰に何を見せるかは定めない。

Viaの名前は登記簿の名前ではない

Viaは中間のプロトコルと受信者を記録し、ループ検出や互換性判断を助ける。一方、実ホストが機微ならreceived-byを仮名に置き換えられる。コメントは任意で、転送前に削除できる。複数メンバーの結合にも、同じ組織的支配と受信プロトコルの一致などの条件がある。

これは情報不足というより、相互運用と公開範囲を分ける設計である。一つの値が一つの法人を意味するとは限らず、一つの法人が一つの値で表れるとも限らない。診断に必要な一貫性は保ちながら、内部ホストの全公開を共通仕様にしない。

RFC 9209のProxy-Statusは、応答処理に関わった中継者から、エラー、次ホップ、受信した状態、実装固有の詳細を伝えられる。メンバー順はオリジン側から利用者側へ進む。しかし、いつ追加するかは中継者が決め、内部情報の漏えいを防ぐため先行メンバーを削ることもできる。オリジンサーバはこのフィールドを生成してはならない。

背景には安全上の理由がある。バックエンドの配置や設定が分かれば、攻撃者は外部の大量通信や不正入力を想定していないサービスを直接狙える。情報によっては認可された相手にしか適さない。Proxy-Statusがないことは中継者不存在の証明ではなく、存在する識別子も法人確認済みの名前とは限らない。

経路証拠に有効時刻を付ける

ロードバランシング、フェイルオーバー、エッジ選択、サービス構成変更は経路を変える。同じ対象と初期値でも停止点が変わり得る。監視製品が「ホップ4」という一つの欄だけを更新し続ければ、履歴と不確実性が消える。

保存単位は観測一件である。メソッド、対象URI、初期値、時刻、転送文脈、状態コード、応答ダイジェストを組にする。ViaとProxy-Statusは受信値のまま、当時の開示条件とともに保持する。後の結果が違えば上書きせず、別の観測として比較する。

OPTIONSとTRACEの応答がキャッシュ不可であることも重要だ。監査記録として保管することはできるが、古い応答を現在のプロトコル回答として再利用できない。証拠保全とキャッシュによる要求充足は別目的である。

HTTPメッセージ署名は、アプリケーションが選んだコンポーネントの改変検出に役立つ。Max-ForwardsやViaを署名対象にすれば、認識された署名者以後の完全性を評価できる。しかし署名は省略された中継者を復元せず、運営法人を証明せず、次の診断を許可しない。完全性は断言の信頼を高めても、意味を拡大しない。

三つの台帳を混ぜない

経路台帳は要求の転送と停止を記録する。主体台帳は、契約、資産管理、運用確認など独立証拠で技術識別子と運営者を結び、期限を付ける。認可台帳は、誰がどの対象と項目をどの期間調べてよいかを記録する。Max-Forwardsが直接支配するのは最初だけである。

この分離があれば、ゼロ応答を見て管理権限を自動付与したり、Viaの変化だけで未申告の委託を断定したりせずに済む。Proxy-Statusの追加はバックアップ経路かもしれず、削除は秘匿方針かもしれない。OPTIONSの差は資源単位の方針かもしれない。原因判断には追加証拠が要る。

診断要求も最小化する。具体的な故障仮説を置き、必要な範囲で深度を一段ずつ増やし、説明できたところで止める。TRACEから秘密と内容を排除する。OPTIONSはContent-Type付き内容を構文上送れても、その用途はRFC 9110で定義されていない。調査が新しい情報漏えいを作ってはならない。

出典