RFC 3093：HTTP通過は内部パケットの承認ではない

要約

FEPは完全なIPデータグラムをHTTP本文で運び、内側の協力ホストが復号して自身のプロトコルスタックへ注入する。
HTTP接続の通過が示すのは外側の運搬路だけであり、内側のアドレス、ポート、アプリケーション、利用者、注入や結果の承認ではない。

規則が見たのは外見だった

文書の出発点は、エンドツーエンドの革新と経路上の統制の衝突である。ホスト同士で新しいアプリケーションを動かせても、企業のファイアウォールが通信種別を認めなければ実験できない。RFC 3093はその不便への回答を極端にした。HTTPが通るなら、あらゆるパケットをHTTPの姿にすればよいというのである。

外部ホストはデータグラムをFEPへ渡す。FEPはHTTPメッセージにして通常の通路で内部へ送る。内側のソフトウェアはそれを取り出し、IPデータグラムを再構成し、保護されたホストのスタックへ戻す。文書は、ファイアウォールが存在しなかったかのように配送すると説明した。

それでもファイアウォールが観測したのは外側のセッションである。内側には別の送信元、宛先、トランスポート、用途がある。運搬手段の許可は、積荷へ自動的には移らない。

内部の協力者が新しい統制点になった

RFC 3093は、内側のホストが協力しなければ動かないため、ファイアウォールの安全モデルを破らないと述べる。そこではファイアウォールが外部脅威を防ぎ、内部脅威を無視するという前提が置かれた。これは文書の主張であって、安全保証ではない。任意のデータグラムを解包し注入できるプロセスは、それ自体が強い権限を持つ。

ファイアウォール運用者は外側の接続を決める。内部ホストの運用者はFEPと注入権限を管理する。利用者は運びたいアプリケーションを選ぶ。実装はバイト列の解釈を決める。どれか一つの事実から、組織が全体を承認したとは言えない。

したがって「HTTPを許可した」というログは内部フローのログではない。トンネルでの受信は注入を証明せず、注入はソケット受理を証明せず、ソケット受理はアプリケーション処理や外部成果を証明しない。

読みやすいヘッダーは複製だった

完全なIPデータグラムはHTTP本文にある。そのうえでTCPフィールドと任意のIPフィールドが新しいHTTPヘッダーへコピーされた。ポートは十進文字列になり、緊急性は大文字・小文字で表され、寿命は文章になり、見かけの送信元はドメイン名にもなる。

RFC自身が、完全なデータグラムが本文にあるため、これらは人間が読むためだけだと述べた。見える TCP_Dport は本体の宛先を認証しない。二つの表現が食い違う可能性もある。再構成をどちらが支配するのか、範囲をどう検査するのか、注入前にどの方針を適用するのかが別途必要だった。

GET要求とGET応答のどちらにもパケットを載せる構想も、許可されそうな形を利用した。普通のWeb資源取得になったわけではない。中間装置が認識する表面がHTTPだった。構文の認識と意図の認識が別問題であることを、設計自身が示した。

笑い話にも運用上の診断が残った

公開日、戯画的なフィールド、「本当のセキュリティ考慮事項はない」という節は、この文書を安全な導入手順ではなくInformationalな挑発として位置づける。作者の意図を推測しなくても、仕組みだけで十分である。端点が包む意思を持てば、粗い許可規則は一般的な運搬路になり得る。

RFC 2775は透明性の低下、RFC 2979はファイアウォールの振る舞い、RFC 2663、3027、3234はNATやミドルボックスの影響を記録した。SOCKS5は明示的なゲートウェイ交渉と認証方式を持つ別の設計である。いずれもFEPの実装や普及を証明しない。

残る教訓は限定的だ。HTTPを正しく許可した規則でも、内側の意味を審査したとは限らない。制御を主張するには、トンネル端点、認証、許容される内部パケット、注入権限、アプリケーション受信、観測された結果を分離して記録する必要がある。

ファイアウォールはHTTPを通した。中のパケットを承認したわけではない――RFC 3093

なぜ重要か

要約

規則が見たのは外見だった

内部の協力者が新しい統制点になった

読みやすいヘッダーは複製だった

笑い話にも運用上の診断が残った

出典

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説