10月2日、Cloudflareが「Announcing Cloudflare OHTTP Gateway – expanding access to Cloudflare's privacy-preserving infrastructure」と題した記事を公開した。アプリサーバー側がユーザーのIPアドレスを一切知ることなくHTTPリクエストを受信できる「OHTTP Gateway」の提供開始を発表する内容だ。
プライバシー保護への要求はここ数年で急速に高まっており、生体データを扱うアプリや、端末上のAI推論をサーバーにオフロードするサービスでは、ユーザーのIPアドレスすら残したくないという需要が生まれている。IETFが標準化したOblivious HTTP（OHTTP）プロトコルは、AppleのAI推論基盤「Private Cloud Compute」をはじめ大手プラットフォームへの実装が相次いでいる。今回Cloudflareが発表したのは、そのOHTTPエコシステムへの参入障壁を大きく下げる新製品だ。
「ダブルブラインド」でIPアドレスを隠す仕組み
OHTTPは、クライアントとアプリサーバーの間に「リレー」と「ゲートウェイ」という2つの独立したホップを挟むプロトコルだ。通常のHTTPS通信ではサーバー側に以下のような情報が筒抜けになる。
- ipAddress: 192.0.2.33 # クライアントのIPアドレス
- ASN: 7922
- tlsCipher: AEAD-CHACHA20-POLY1305-SHA256
- tlsVersion: TLSv1.3
- Country: US
- Region: California
- City: Campbell
OHTTPリレーを経由すると、サーバーが受け取るのはリレー自身の情報に置き換わる。
- ipAddress: 128.62.37.13 # リレーのIPアドレス
- ASN: 18
- tlsCipher: AEAD-AES-128-GCM-SHA256
- tlsVersion: TLSv1.3
- Country: US
- Region: Texas
- City: Austin
さらに、クライアントとアプリサーバー間の通信はHPKE（Hybrid Public Key Encryption）で暗号化されており、リレーには暗号文しか見えない。結果として「リレーはクライアント識別子を知るが内容は見えない、ゲートウェイ＆サーバーは内容を知るがクライアントは見えない」というダブルブラインド構造が成立する。どちらか一方が単独では完全な情報を持てないため、両者が共謀しない限りプライバシーが保たれる設計だ。
実際の採用例としては、生理周期トラッカー「Flo Health」の匿名モードや、Appleの「Private Cloud Compute」でのユーザー識別子と推論リクエストの分離がある。
従来製品との違い：なぜ「ゲートウェイ」が必要なのか
Cloudflareは2022年にOHTTPリレー製品「Privacy Gateway」（現：Cloudflare OHTTP Relay）を提供してきた。しかしこれには構造上の制約があった。
OHTTPのプライバシーモデルは「リレーとアプリサーバーが別々の、互いに共謀しない事業者によって運営されること」を前提とする。そのため、すでにCloudflareのCDNやWorkersでアプリサーバーを動かしているユーザーは、Cloudflare製のリレーを使えなかった。Cloudflareがクライアントのメタデータと復号されたリクエスト内容の両方を見ることになり、プライバシーモデルが崩れるからだ。
今回のCloudflare OHTTP Gatewayは、この空白を埋める対となる製品だ。第三者が運営するリレーと組み合わせることで、Cloudflare上にアプリサーバーを置きながらOHTTPのプライバシー分離を維持できる。ユースケース別の選択肢を整理すると以下の通りだ。
| ユースケース | 適切な選択 |
|---|---|
| アプリサーバーがCloudflare外にある | OHTTP Relay ＋ 自前ゲートウェイ |
| アプリサーバーがCDN/Workers上にある | OHTTP Gateway ＋ サードパーティリレー |
| Apple Live Caller ID Lookupなど既存サービスのリレーを使う | OHTTP Gateway |
設計のポイント
anycastによる低レイテンシー
自前でOHTTPゲートウェイを運用するとレイテンシーコストが問題になる。Cloudflareはanycastアーキテクチャにより、OHTTPゲートウェイをグローバルエッジネットワーク上の全サーバーで稼働させる。CDNを利用していれば、ゲートウェイによるリクエスト復号とアプリサーバーによる処理が同一の物理サーバー上で完結するため、ゲートウェイ→オリジン間のレイテンシーをゼロにできる。
鍵管理の自動化
OHTTPゲートウェイはHPKEの公開鍵設定を管理・公開する必要があるが、Cloudflareのゲートウェイは鍵管理を完全にマネージドで提供する。クライアントはGET /.well-known/ohttp-gatewayで公開鍵を取得できる。なお、公開鍵の取得とゲートウェイへのリクエスト送信を異なるIPから行うことも可能だ。これにより、もし鍵配布エンドポイントがIPを記録していた場合でも、その情報が実際のリクエストと結びつかないようにできる。
リレー認証とアクセス制御
Cloudflare Accessをリクエスト復号の前段に配置することで、mTLS・静的サービスクレデンシャル・外部カスタムロジックなどの標準的なアクセスポリシーで、信頼できるリレーのみに通信を絞れる。
誤設定への安全策
リレーとゲートウェイの両方をCloudflare上で動かしてしまう誤設定を防ぐため、CloudflareのWorkers配下またはCloudflareのプロキシ配下のホストから送信されたリクエストの復号はゲートウェイが拒否する仕組みになっている。プライバシーモデルの崩壊を設計レベルで防いでいる。
現在の提供状況
現在はクローズドベータ中で、専用フォームからウェイトリストへの登録が可能だ。有効化するとゾーン上のhttps://your-zone.com/.well-known/ohttp-gatewayエンドポイントでOHTTPトラフィックの受信が始まる。スケールは自動で、容量管理は不要だ。OHTTPクライアントの実装については、OHTTPの仕様・実装をまとめたコミュニティリソースohttp.infoやCloudflareのサンプルクライアントライブラリが参考になる。
詳細はAnnouncing Cloudflare OHTTP Gateway – expanding access to Cloudflare's privacy-preserving infrastructureを参照していただきたい。
