Cloudflareは、Cloudflare OHTTP Gatewayのクローズドテストを開始した。これは顧客のドメインで有効化できる有料の追加機能で、管理型インフラストラクチャを通じてOblivious HTTP（OHTTP）トラフィックを受信する。このサービスは、特にCloudflareネットワークの背後やWorkers上にホストされている場合に、アプリケーションサーバーからIPアドレスやクライアント識別情報を隠したい開発者を対象としている。
これと同時に、同社は以前の製品であるPrivacy GatewayをCloudflare OHTTP Relayへ改称した。この変更は、OHTTPモデルにおける2つの異なる製品の存在を反映している。relayは暗号化されたリクエストを転送してクライアントの身元を隠す一方、gatewayはリクエストの暗号化されたカプセル化を解除し、アプリケーションサーバーへ渡す前にレスポンスを再度カプセル化する。
OHTTPモデルの仕組み
従来の通信では、アプリケーションサーバーはクライアントのIPアドレス、TLSの特性、位置情報を見ることができ、それによって複数のリクエストを同じユーザーに関連付けられる可能性がある。OHTTPでは、リクエストは独立したrelayを経由し、クライアントの識別情報が取り除かれてから転送される。リクエストの内容はHybrid Public Key Encryption（HPKE）を使用して暗号化されたままであり、relayが平文を見ることはない。
その後、gatewayが暗号化部分を処理し、通常のHTTP形式でアプリケーションサーバーへリクエストを送る。これにより、信頼の分離が生じる。relayは接続の身元を見られるがリクエスト内容は見られず、gatewayとアプリケーションサーバーはクライアントの直接的な身元を知らずにリクエスト内容を見ることができる。このモデルでは、relayとgatewayの役割を担う2者が共謀して管理しないことが条件となる。
新しいgatewayが加えるもの
OHTTP GatewayはCloudflareのドメイン内の機能として動作し、/.well-known/ohttp-gatewayなどの特定のアクセスポイントを通じて有効化できる。このサービスは標準OHTTPとChunked OHTTPをサポートしており、リクエストを段階的に処理するため、分割型の利用が推奨されている。また、CloudflareはHPKE公開鍵の管理と顧客への提供を担い、鍵のライフサイクル管理を顧客の責任としない。
このサービスはCloudflareのグローバルネットワークを利用するため、ネットワークエッジでgatewayを稼働させ、relayとgateway間の遅延を短縮できる。アプリケーションサーバーが同社のCDNを利用している場合、リクエストの処理とサーバーへの到達を同じ基盤上で行える。gatewayが処理するのはOHTTPリクエストのみであり、通常のリクエストはOHTTP処理を経由せず、引き続きサーバーに到達する。
信頼性と利用に関する制御
Cloudflare Accessにより、リクエストを復号する前に認証ポリシーを適用できる。これにはmutual TLS、固定されたサービス認証情報、カスタムの外部ロジックが含まれる。またgatewayは、Cloudflare Workersから送信されたリクエストや、Cloudflareを経由するホストからのリクエストの復号を拒否する。これは、同じ組織がrelayとgatewayを運用してOHTTPが依存する信頼の分離を弱めることを避けるためである。
Cloudflareは、アプリケーションサーバーがCloudflareの背後にある場合、またはApple LiveCallerIDの一部のユースケースのように、サードパーティに属するrelayとクライアントからリクエストが来る場合に、OHTTP Gatewayを利用することを推奨している。一方、新しい名称のCloudflare OHTTP Relayは、Cloudflareのrelayを利用しつつ、Cloudflare外部で自らgatewayを運用したいユーザーに適している。
実際に何が変わるのか
新サービスはOHTTP Gateway構築に伴う運用負担を軽減するが、基本的なアーキテクチャ要件をなくすものではない。クライアントはOHTTPを実装する必要があり、ユーザーには独立したrelayも必要となる。Cloudflareは、relayはログを検査せず、クライアントの身元と復号されたリクエストを関連付けない点について信頼できる主体であるべきだと強調している。また、OHTTPはリクエスト本文自体に含まれるメタデータを保護しないため、メールアドレス、ユーザー名、その他の識別子をリクエスト内容に含めて送信しない責任は開発者にある。
このサービスは現在、クローズドテストとウェイトリストの段階にあり、発表では一般提供の時期や価格の詳細は示されていない。そのため、この取り組みはネットワークプライバシーツールの重要な拡張を示す一方で、開発チームはrelay、リクエスト内容、当事者間の信頼モデルについて、なお独自の判断を行う必要がある。