Cloudflare OHTTPゲートウェイ

元記事: 2026年10月3日原文(blog.cloudflare.com)

概要

エンドユーザー のオンラインプライバシー負担軽減を目指すCloudflareの新サービス紹介
OHTTP （Oblivious HTTP）によるIPアドレス等の秘匿化技術の解説
Cloudflare OHTTP Gateway の特徴と導入メリット
リレーとゲートウェイ の役割分担、プライバシーモデルの詳細
導入・運用の 容易さとセキュリティ対策 の工夫

オンラインプライバシーの現状とCloudflareの取り組み

現在、 エンドユーザー はVPNや広告ブロッカー等を利用し、プライバシー保護の負担を強いられている状況
一般的なクライアント-サーバー通信では、 IPアドレスやTLSフィンガープリント などのユーザーデータがサーバーに記録される
Cloudflare は、開発者がアプリにプライバシーを組み込めるインフラを構築
OHTTP （Oblivious HTTP）は、IETF標準のプロトコルで、アプリのバックエンドがユーザーIPアドレスを見ずにHTTPリクエストを受信可能にする技術
Cloudflareは OHTTP Gateway を新たに提供開始、簡単な設定でOHTTPトラフィックの受信が可能

OHTTP製品スイートの拡大

OHTTPでは、 リレー と ゲートウェイ の2つの独立した中継点を経由する構成
- リレー ：暗号化されたリクエストを盲目的に転送し、クライアント識別情報をアプリサーバーから隠す役割
- ゲートウェイ ：リクエストの復号・レスポンスの暗号化を担当し、アプリサーバーは平文HTTPとして処理
リレーとゲートウェイの 信頼分離 がプライバシーモデルの鍵
2022年に Privacy Gateway（現OHTTP Relay） を提供開始、Flo HealthやAppleなどが活用
サーバーをCloudflareで保護している場合、リレーとゲートウェイの両方をCloudflareが運用するとプライバシーモデルが崩れるため、 分離運用 が必要
新たに OHTTP Gateway をベータ提供開始、用途や構成に応じてリレーとゲートウェイを選択可能

Cloudflare OHTTP Gateway開発の背景

開発者の間で 使いやすいプライバシー基盤 への需要増加
OHTTPゲートウェイの 自前運用は難易度・コストが高い （遅延増大、暗号処理負荷）
Cloudflareのグローバルエッジネットワークで 低遅延・高可用性 を実現
CDN利用時は ゲートウェイとアプリサーバーが同じサーバー上 で動作し、さらなる遅延削減が可能
OHTTPの 信頼分離モデル を維持しつつ、多様な選択肢を提供

OHTTPの仕組みとプライバシー効果

通常のクライアント-サーバー通信では、 IPアドレス・TLS情報・地理情報 などがサーバーに伝わる
OHTTPでは、 リレー がこれらの情報を遮断し、アプリサーバーにはリレーの情報のみが伝わる
多数のユーザーが同じリレーを経由することで、 個人特定が困難 となる強固なプライバシー境界を形成
OHTTPは Hybrid Public Key Encryption（HPKE） を利用し、リレーは暗号化データのみを扱い、ゲートウェイが復号・再暗号化を担当
ダブルブラインドモデル により、どの事業者もクライアント識別情報とリクエスト内容の両方を知ることができない設計

OHTTP Gatewayの設計と導入の容易さ

グローバルネットワーク上に 柔軟なサービス として展開、数クリックで導入可能
/.well-known/ohttp-gateway エンドポイントにOHTTPリクエストを送信するだけで利用開始
標準OHTTPと チャンク化OHTTP の両方に対応、チャンク化OHTTPは高パフォーマンス
ゲートウェイがリクエストを復号し、アプリサーバーへサブリクエスト、暗号化レスポンスをクライアントへ返送
ゲートウェイは ゾーン単位で紐付け、他ドメインへの悪用を防止

セキュリティ・運用上の工夫

HPKE鍵管理 を完全自動化、公開鍵はGETリクエストで取得可能
ゲートウェイは リレーの認証 が必須、Cloudflare Access等で多様な認証方式をサポート
ミスによるプライバシーモデル破壊 （リレー・ゲートウェイの同一運用）を防ぐため、Cloudflare WorkersやCloudflare上のプロキシからの復号を拒否

OHTTP RelayとGatewayの使い分け

アプリサーバーがCloudflare外 の場合：OHTTP Relay（旧Privacy Gateway）＋自前Gateway運用が最適
アプリサーバーがCloudflare上 の場合や 運用負荷軽減 が目的の場合：OHTTP Gateway＋サードパーティリレー利用が最適
利用ケースやアーキテクチャに応じた 柔軟な選択肢 の提供

提供: ハクソク · 要約更新: 2026年10月5日

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

うーん、面白いね。どうやって「IPでの虐待者の禁止」機能を追加するのか気になるな。まずは虐待を特定して、それを元のIP（または他の識別子）にリンクさせる必要があるよね…。

└

それは無理だよ。悪用するやつは住宅用プロキシを買うだけだから。

CloudflareがCIAの秘密のオペレーションだなんて思う理由は全くないよ。実際、そうじゃないって思う理由はいくらでもあると思う。でも、もしそうだったら、やってることはほとんど予想通りだね。

└

もちろん、CIAのオペレーションじゃないよ。あの機関は外国の情報機関だから。国内の情報機関はNSAって呼ばれてる。

└

もっと多くの人がCFに依存するようになればなるほど、CFを覆すインセンティブが増えるよね。俺がバカなのかな？あと、CFのために働く人を送り込む動機もあるし、準備と希望の問題もあるよね。もしかして、あなたは工作員ですか？ :)

└

アメリカ政府は頼めばいいだけだし、アメリカの企業はそれに応じるよ。手を汚す必要なんてない。

└

情報機関が海賊行為の最大の保護者だって言いたいの？（海賊サイトはCloudflareが大好きだよね）

└

DHSの話ってあまり知られてないの？5年後、プリンス氏はハーバードビジネススクールでMBAをやってたんだけど、そのプロジェクトのことはすっかり忘れてた時に、アメリカ合衆国国土安全保障省から予期しない電話がかかってきたんだ。「君が集めた攻撃に関する情報、どれだけ価値があるか分かってる？そのデータを売ってくれないか？」って言われたって。出典: https://www.bbc.co.uk/news/business-37348016

└

私はちょっと naive かもしれないけど、彼らは途中にホップを追加するプライバシーサービスを提供してるんだよね。彼らは自分たちのサーバーとサードパーティの両方をコントロールしてないし、それがデザインの全てのポイントだよね？それが秘密の政府の操作から期待することなの？デザインが2つのホップを経由していて、そのうちの1つだけがCloudflareによってコントロールされてるってことで合意できる？

クライアントとアプリサーバーだけが平文を見られ、リレーは暗号文のごちゃ混ぜしか見えないようにする。リレーとアプリサーバーの間には「ゲートウェイ」があって、すべての暗号処理を担当する — リクエストをデカプセル化し、レスポンスをカプセル化する — そしてアプリサーバーは平文のHTTPだけを扱う。もし、暗号化と復号化を元のサーバー（RFCでいうターゲットリソース）とクライアントが処理する無知な暗号化方法を設計したら、真ん中の誰かにそのデータを扱わせるよりも良くない？現在の設計は、公共の匿名SOCKS5サーバーに接続して（TLSトラフィックを復号化しない）Cloudflareの背後にあるウェブサイトに接続するのとあまり変わらないように見える。おそらく、誰かが「OHTTPリレー」をホストする必要があるから、匿名SOCKS5サーバーをホストするのと同じように機能するだろうね。

└

OHTTPでダブル暗号化をするのは全然妨げられないよ。ゲートウェイが一度復号化して、オリジン（ターゲットリソース）が二度目に復号化する。内層にはHPKEを使うのがいい選択だね。

└

OHTTPは、比較的狭いユースケースのために設計されてるんだ。ステートレスなリクエストで、ゲートウェイが同じクライアントからの複数のリクエストを関連付けられないようにしたい場合ね（つまり、IPアドレスを隠すだけじゃない）。これが良いアイデアになる明確な例はDNS-over-HTTPSだよ。リゾルバーが同じクライアントからの複数のリクエストを関連付けられないようにしたいからね。SOCKS5でもこれを試みることはできるけど、状態を共有しないようにすごく気をつけなきゃいけない。* 各リクエストごとに新しいTCP接続を使う必要があるし、新しいTLSとHTTP接続も必要。* TLSセッション再開や0-RTTデータを使わないようにしなきゃ。* TLS ClientHelloで送るデータは、フィンガープリンティング情報を露出しないように、できるだけ保守的にする必要がある。SOCKS5は暗号化されてないし、リクエストには宛先が含まれてる：プロキシが解決すればホスト名、クライアントが解決すればIP（ECHはここでは役に立たない、TLSハンドシェイクの後のSNIだけを保護するから）。OHTTPでは、すべてがリレーへのTLS接続内にあるんだ。OHTTPは、クライアントがゲートウェイにサポートしている暗号化方式のメタデータを事前に送る必要がない（ゲートウェイが何をサポートしているかを教えて、クライアントがその中から選ぶだけ）。ゲートウェイはTLSフィンガープリンティング情報を見れないし（それはリレーにしか見えないから）、OHTTPはリクエストごとに新しいTCP接続を作る必要もない（SOCKS5だと、クライアントからプロキシ、プロキシからサーバーへの新しいTCP接続が必要だけど）。リレーへの長期間の接続ができて、リレーはゲートウェイへの長期間の接続を持てる（多くのクライアントで共有される）。これはDNS-over-HTTPSのようなアプリケーションにとって大きなレイテンシの改善になるよ。キーの漏洩リスクも二つで違うんだ。OHTTPでは、ゲートウェイキーの漏洩は、リレーがそのキーを使って記録されたトラフィックを復号できることを意味する（フォワードセキュリティがないから）。一方、クライアントリレーやリレーベースのゲートウェイキーの漏洩はあまり重要じゃない（フォワードセキュリティがあるから）。SOCKS5では、エンドツーエンドのTLS接続を通じてフォワードセキュリティがある。一般的なプロキシのユースケースでは、MASQUEのような作業が、特定のパーティへの露出を制限するためのマルチホップアプローチを提供して、エンドツーエンドのTLS接続を提供するけど、それだとまたフィンガープリンティング情報を露出することになる。一般的なプロキシでは、リクエストを明確に結びつけるセッション固有のデータ（認証トークンなど）を送信しているかもしれないけど。

Hacker Newsで議論の続きを見る