要約

  • RFC 9458では、リレーはクライアントのネットワーク上の接続元を知る一方で要求本文を読めず、ゲートウェイは要求本文を読める一方で元の接続元を知らない。文書が掲げるプライバシー目標のためには、両者を同一主体にしてはならない。
  • この分離は暗号だけでは維持できない。Cookie、アカウント情報、端末固有の鍵設定、HPKEコンテキストの再利用、共通ログ、少ない利用者数、時刻やサイズの相関が、隠したはずの対応関係を復元する。
  • Martin ThomsonとRFCを共著したChristopher A. Woodの仕事は、万能な匿名化ではなく、知識を分ける検証可能な仕組みとして読むべきである。実運用には独立した管理、状態の削減、再送制御、鍵の廃棄、十分な匿名集合の証拠が要る。

分析：二人の管理者が同じ答えを持たない設計

あるサービスへの要求について、「どの端末の接続だったか」と「何を要求したか」が一つの記録に並べば、運用者は便利になる。障害調査も不正対策も早い。しかし、その便利さは、利用者と機微な内容を直結できる権限でもある。

OHTTPはこの権限を二つに割る。クライアントはHTTP要求をバイナリ形式にし、ゲートウェイの鍵設定を使ってHPKEでカプセル化する。HTTPSで受け取るリレーにはクライアントとの接続が見えるが、封じられた要求は開けない。リレーは別のHTTPS接続でゲートウェイへ転送する。ゲートウェイは要求を開いて対象リソースへ届けるが、見える上流はリレーであって元のクライアントではない。応答も同じ役割分担を通って戻る。

リレーが持つのはネットワーク上の「誰から」、ゲートウェイが持つのはアプリケーション上の「何を」である。RFC 9458は、掲げるプライバシー目標を達成するには両者が同一の主体であってはならないと明記する。

ここでいう主体を、サーバー名の違いだけで済ませることはできない。二つのシステムが同じ特権アカウントで管理され、同じ監視基盤へログを送り、同じ委託先が障害時に両方を取得できるなら、実際の知識は分かれていない。法律上の支配、管理権限、ログと分析の経路まで分離を確かめるべきだというのは、本稿の運用上の推論でありRFCの逐語的な要件ではない。とはいえ、その確認なしに「別主体」を実証することは難しい。

暗号が接続中に消した結合キーを、観測基盤が時刻で付け直すこともある。したがって、OHTTPの監査対象は暗号ライブラリだけではない。組織図、権限表、ログ配送、事故対応手順もプロトコルのプライバシー境界を左右する。

Woodの功績を、前提条件と共同著作の中で読む

RFC 9458は2024年1月にIETFのStandards Track文書として公開され、著者はMartin ThomsonとChristopher A. Woodである。2026年9月1日に保存したIETF Datatrackerの記載では、WoodはAppleで暗号技術に取り組むエンジニアとされ、RFC 9458を含む24件のRFCが公開プロフィールに並ぶ。所属や件数は取得時点の情報であり、将来変わり得る。これをOHTTPの単独発明や、各社の実装に対する保証へ広げてはならない。

WoodはJonathan Hoylandとともに、2022年にCloudflareで計算機支援による解析も説明している。Tamarinモデルの攻撃者はネットワークを観測し、リレーかゲートウェイのどちらかを侵害できる。ただし、両者が結託しないこと、クライアントを識別する情報がゲートウェイへ渡らないことを前提にする。

公開リポジトリには、要求と応答の秘匿性、結び付き、整合性、ノンス再利用などに関する検証結果が残る。クライアントを結び付けられないという性質も限定的である。モデルの中で、攻撃者が問い合わせ内容とリレーに届いた暗号化接続の双方を知るなら、リレーとゲートウェイの双方を侵害している必要がある。記事は、これが一般的な識別不能性の証明ではないとも明記する。統計的な推測や通信量解析は残る。

この限定は弱点ではなく、評価の出発点である。形式手法は定義された脅威モデルでメッセージがどう振る舞うかを調べられる。一方、共通管理者、ログ保存、契約上のデータ共有、少人数の地域展開まで自動で検査するものではない。Woodの人物像を語るなら、暗号で「匿名化した人」と誇張するより、保証と前提を切り分けた標準化の仕事に焦点を置く方が正確である。

ゲートウェイを対象リソースと取り違えない

OHTTPのメッセージ保護は、クライアントとゲートウェイの間に成立する。クライアントとTarget Resourceの間に直接成立するのではない。ゲートウェイは要求を復号し、対象へ送り、クライアントへ返す応答を決められる。

そのためクライアントは、対象ごとにどのゲートウェイを許可するのかを知り、その鍵設定を認証しなければならない。鍵設定の配布は単なる準備作業ではない。偽の設定に置き換えられれば、平文を得る地点も置き換わる。

対象サーバーの証明書を直接固定するような方針も、この仲介経路へそのまま持ち込めない。アプリケーションは、ゲートウェイが接続できる対象、対象が受け入れるゲートウェイ、別オリジン間のHTTPS、応答に対する責任を明示する必要がある。OHTTPで隠れるのは元のネットワークアドレスであり、対象への直接認証が新たに生まれるわけではない。

さらに、鍵設定そのものが識別子になり得る。一台の端末だけに異なる設定を配れば、暗号化された要求を読まなくても、その設定を手掛かりに追跡できる。設定の数が増えるほどよいのではない。各設定を同じ時間帯に何人の実利用者が共有するかが重要である。

更新時には新旧設定の重複期間も必要になる。地域、アプリ版、契約区分ごとに細分化すれば、総利用者が多くても各匿名集合は小さくなる。署名検証の成功だけでは、この問題を捉えられない。

アプリケーションが平文の中に名札を入れる場合

リレーとゲートウェイが完全に独立していても、要求にアカウントCookieが入っていればゲートウェイは利用者を知る。認可ヘッダー、端末ID、固定された疑似ID、珍しい言語と機種の組み合わせも同じ役割を果たし得る。

RFC 9458は、アプリケーション内容が要求間を結び付ける状態を持たない場合にのみ、通信経路の分離が有用だと説明する。「ステートレス」という設計書上の表示だけでは足りない。HPKEへ渡す直前のバイナリメッセージを調べ、SDKが自動追加する値、失敗時の診断情報、再送で引き継ぐトークンまで確認する必要がある。

正常経路で消した識別子が、例外経路で戻ることもある。最初の要求は匿名でも、エラー応答が端末固有の値を返し、次の要求がそれを送れば結び付きができる。不正対策が少数の利用者だけに異なるチャレンジを与える場合も、匿名集合は縮む。

リレー側も、元のクライアントを示すViaやForwardedを付けてはならない。識別情報をいったん受け取り「後で除く」設計より、最初から受け取らない方が検証しやすい。

必要なのは、フィールドごとの台帳である。値は要求間で安定するか、別のデータと照合できるか、誰が必要性を承認したか、削除すると何が失われるか。プライバシーはAPIの名称ではなく、実際に運ばれる平文の性質で決まる。

暗号の新鮮さと処理の一回性

RFC 9180のHPKEは、鍵カプセル化、鍵導出、認証付き暗号を組み合わせて保護コンテキストを作る。RFC 9458はOHTTP要求ごとに新しいコンテキストを要求する。再利用は要求同士の相関を可能にし、条件によってはリレーへの内容漏えいにつながる。

再送も新しいHPKE状態で行う。しかし、暗号状態を新しくしても業務処理が一回になるとは限らない。クライアントがタイムアウトした時点で、ゲートウェイが最初の要求を処理済みかもしれない。購入、設定変更、申請のような処理をもう一度送れば、効果が重複する。

サーバーはリプレイを拒否するか、繰り返しても効果が増えないようにする。自動再送は、最初の要求が処理されなかったと応答が明示した場合に限るべきである。カプセル化された鍵の値はリプレイ検出のノンスとして利用できる。時刻を使えば窓を狭められるが、時計差、許容幅、保存期間という別の設計が必要になる。RFC 8470はHTTPの早期データに関するリプレイを扱うが、個々のOHTTPアプリケーションの業務効果を決めるものではない。

ゲートウェイの秘密鍵には、さらに長い時間軸がある。一つの鍵設定が有効な期間全体について、OHTTPだけで将来の侵害から過去を守る前方秘匿性は得られない。秘密鍵が漏れ、必要な通信記録やリレーの協力があれば、その設定で保護された過去の交換が読まれ得る。

鍵更新は対象期間を狭め、古い秘密鍵の削除が期間を閉じる。稼働ノードから消えても、バックアップ、障害解析資料、メモリ取得物に残れば削除は完了していない。発行から配布、切り替え、失効、全コピーの廃棄までを一つの証跡として扱う必要がある。

HTTPSでも隠れない通信の輪郭

二つの区間はどちらもHTTPSを必須とする。これにより内容の盗み見や改変は難しくなるが、送信時刻、サイズ、順番、メッセージ境界、全体量までは同じにならない。

利用者が少ない時間帯に、一件だけ大きな要求がクライアント側で観測され、直後に同じ特徴の転送がゲートウェイ側で観測されれば、暗号を解かずに対応を推測できる。応答サイズや周期が加われば確度は上がる。

パディングはサイズ差を小さくし、遅延、まとめ送り、揺らぎは時刻の一致を弱める。その代わり帯域、待ち時間、実装の複雑さが増える。混雑時にパディングを止める判断は、単なる性能変更ではなくプライバシー変更として記録されるべきである。

リレーの扱いも匿名集合を変える。特定クライアントだけを遅らせる、遮断する、別経路へ送ると、対象を群れから切り離せる。不正対策のシグナルがゲートウェイ側へ渡れば、復号せずとも識別の補助になる可能性がある。

したがって、指標は累計登録数ではなく、同じ設定と経路を同じ時間窓で使った実利用者数でなければならない。HPKE成功率は暗号処理の健康を示す。匿名集合の健康は別に測る必要がある。

分掌を証拠に変える

監査表は、クライアント、リレー、ゲートウェイ、対象の四列から始められる。各列に、法的な管理主体、クラウド口座、管理者、委託先、地域、ログ、保存期間、事故時アクセスを書く。その後、列をまたぐ経路を洗い出す。共通の監視、ID基盤、サポート資料、バックアップ、不正対策、法的開示手続きが該当する。

クライアントについては設定の入手と検証、実平文の項目、新規HPKEコンテキスト、再送規則を残す。リレーについては接続元ログの最小化、識別ヘッダーの不在、差別的転送の統制を示す。ゲートウェイについては鍵、許可対象、平文ログ、更新と削除を示す。対象については許可したゲートウェイとリプレイの効果を示す。

侵害訓練も役割別に行う。リレーだけなら接続元と時刻、ゲートウェイだけなら平文と鍵、共通ログ基盤なら双方の結合が問題になる。「OHTTPが侵害された」という一語では、攻撃者が何を知ったかも、どの遮断が必要かも分からない。

Heng Luの「稼働するコードを優先する」という考え方に従えば、信用は実行可能な機能の範囲に限定される。OHTTPのコードは可視性を分けられるが、組織の独立を証明できない。「最小の初期仕様」という考え方も、共通部分を小さく保つ効用と同時に、採用側がその成立条件を壊してはならないことを示す。

OHTTPが運用者へ求めるのは、知識の最大化ではなく、役割ごとの有用な無知である。リレーは内容を知らず、ゲートウェイは接続元を知らず、分析基盤は両者を結合せず、アプリケーションは別の名札を入れない。

Christopher A. Woodの仕事を特徴づけるなら、「匿名HTTPを完成させた」という大きすぎる表現より、この分掌を検証可能なプロトコルへ落としたことが適切である。優れた導入報告は「OHTTP対応」とだけ書かない。単独の運用者が「誰が、何を」を同時に答えられない理由を、権限、データ、鍵、利用者数の証拠で示す。

出典