Cloudflare OHTTPゲートウェイを発表

今日、オンラインプライバシーの負担はエンドユーザーが負いすぎている。 サードパーティのトラッカーやターゲティング広告を避けるために、ユーザーはVPNの使用、Cookieの無効化、または広告ブロッカーのインストールを指示される。 一方、一部のアプリ開発者は、ユーザーが気にする以上にユーザーについて知ることになる：典型的なクライアント・サーバー交換は、クライアントのIPアドレスやTLSフィンガープリントのようなユーザーデータの痕跡を作成する。 このレベルの可視性は負担となりうる。 だからこそCloudflareは、開発者がプライバシーをアプリに組み込むのを助けるインフラストラクチャを構築している。 Oblivious HTTP (OHTTP) は、アプリのバックエンドがユーザーのIPアドレスを見ることなくHTTPリクエストを受信できるように設計されたIETF標準である。 この秋、Cloudflare OHTTPゲートウェイをローンチする。 顧客は、新しいOHTTPゲートウェイをゾーンへの有料アドオンとして有効化し、数クリックでOHTTPトラフィックの受信を開始できるようになる。 詳細については、フォームから登録してウェイトリストに参加してください。 OHTTP製品スイートの拡張 OHTTPでは、リクエストは2つの独立して運用されるホップを通過する：リレーとゲートウェイ。 OHTTPリレーは、クライアント識別子をアプリサーバーから隠すために、暗号化されたリクエストを盲目的に転送する。 OHTTPゲートウェイは、暗号化されたリクエストのデカプセル化とレスポンスのカプセル化という暗号処理を実行し、アプリサーバーが通常のHTTPのようにOHTTPリクエストを処理できるようにする。 リレーとゲートウェイ間の信頼の分離は極めて重要である：これにより、単一の当事者がクライアント識別子とリクエスト内容の両方を見ることを確実にしない。 2022年、私たちはOHTTPリレー製品であるPrivacy Gatewayをローンチした。 Privacy Gatewayは、顧客がユーザーによりプライバシーに配慮した体験を提供できるようにする。 例えば、Flo Healthは匿名モードでOHTTPを使用しており、AppleのPrivate Cloud ComputeはAI推論リクエストをユーザーIDから切り離すためにOHTTPを使用している。 しかし、Cloudflareでサーバーを保護している顧客は、Cloudflare運用リレーも使用することはできない――彼らはOHTTPゲートウェイを必要としている。 既存のCloudflare OHTTPリレーでは、顧客は信頼の分離を維持するために独自のゲートウェイを持ち込む必要がある。 OHTTPリレーの運用経験から、大規模で安全かつ高性能なOHTTPゲートウェイの構築と運用がいかに難しいかを見てきた。 本日、セルフサービスのCloudflare OHTTPゲートウェイのクローズドベータ版をローンチする。 また、2つの製品をより明確に区別するために、「Privacy Gateway」を「Cloudflare OHTTPリレー」に改名する。 これで、必要な信頼の分離を備えたOHTTPアーキテクチャを求める顧客には、2つの選択肢がある： CloudflareのOHTTPリレー（旧Cloudflare Privacy Gateway）を使用し、ゲートウェイを自分で実行する。これは、アプリケーションサーバーがCloudflareの外にホストされており、独自のOHTTPゲートウェイを実行できる場合に最適である。 サードパーティリレーとCloudflareの新しいOHTTPゲートウェイを使用する。これは、アプリサーバーがすでにCloudflare（例えば、CDNやWorkers）の後ろにある場合、サードパーティ（AppleのLiveCallerIDなど）からOHTTPリクエストを受け入れている場合、またはレイテンシと運用オーバーヘッドを最小限に抑えるためにマネージドゲートウェイを望む場合に最適である。 私たちはインターネット全体のプライバシーの基準を引き上げるために取り組んでおり、OHTTPのようなプロトコルは、採用を十分に容易にすれば役立つと信じている。 私たちのOHTTP製品スイートを拡張し、信頼性の高いプライバシーインフラストラクチャをより広範なインターネットにアクセス可能にすることが常に私たちの目標であった。 Cloudflare OHTTPゲートウェイを構築した理由 OHTTPリレー製品をローンチして以来、いくつかのことを観察してきた。 第一に、開発者の間で、アクセス可能で使いやすいプライバシーインフラストラクチャへの需要が高まっていることを見てきた。 プライバシー志向のアプリの開発者は、デフォルトでネットワークプライバシーをアプリケーションに組み込みたいと考えているが、それは本来よりも難しいままである。 第二に、OHTTPゲートウェイの構築と運用が顧客にとって困難であることを学んだ。 どのプロキシアーキテクチャも、リクエストがインターネットを余分に1つか2つホップする必要があるため、ある程度のレイテンシを導入する。 リクエストを復号化し、レスポンスを暗号化するコストと組み合わせると、自作のOHTTPセットアップのレイテンシヒットは相当なものになる可能性がある。 私たちはこの問題を解決するのに有利な立場にある：1.1.1.1やiCloud Private Relayのような製品のために、高速で信頼性の高いプライバシーインフラストラクチャを運用することを可能にするビルディングブロックは、OHTTPゲートウェイのホームとして適している。 CloudflareのAnycastアプローチにより、当社のOHTTPゲートウェイはCloudflareのグローバルエッジネットワーク上のすべてのサーバーで実行され、リレーからゲートウェイへのホップのレイテンシを最小限に抑える。 CDNを使用している場合、ユーザーリクエストは当社のゲートウェイによって復号化され、同じCloudflareメタル上でアプリサーバーによって解決されるため、ゲートウェイからオリジンへのレイテンシが節約される。 最後に、OHTTPのプライバシーモデルでは、リレーとアプリサーバーは別々の、協力しない当事者によって運用される必要があることを思い出してほしい。 私たちは顧客にプライバシーインフラストラクチャの最高の選択肢を提供したいと考えている。 以前は、Cloudflareでアプリサーバーを保護していた開発者は、Cloudflareがクライアントメタデータとリクエストの復号化された内容の両方を見るため、当社のOHTTPリレーを使用できなかった。これはOHTTPのプライバシーモデルを壊す。 これで、開発者はCloudflare OHTTPリレーまたはゲートウェイのどちらが自身のアーキテクチャにより適しているかを選択できる。 OHTTPの概要 クライアントとアプリケーションサーバー間の典型的なやり取りは、クライアントに関する情報を示す。 クライアントとアプリサーバーが互いに通信すると、アプリサーバーはクライアントのIPアドレスを知る。これは、データが送信される各パケットに送信元IPラベルが付いているためである――封筒の「差出人」ラベルに似ている。 アプリサーバーは、サポートされているTLSバージョンや暗号スイートのような属性に基づいてクライアントを「フィンガープリント」することもできる。 これらのシグナルにより、アプリサーバーは複数のリクエストを同じユーザーにリンクすることが可能になる。 しかし、ユーザーについてあまり知らないアプリを構築したい場合はどうだろうか？ 例えば：Flo Healthは、ユーザーが個人健康データにアクセスする際に、ユーザー識別子にリンクされないようにするための匿名モードを構築したいと考えていた。 OHTTPは、「リレー」と呼ばれるプロキシを導入し、クライアントとアプリサーバー間のリクエストとレスポンスを転送して、アプリサーバーからクライアントのIDを曖昧にする。 リレーはIPアドレスやTLSフィンガープリントのようなクライアント識別子を見るが、リクエストを転送する前にそれらを削除する。 これにより、アプリサーバーは複数のリクエストを同じユーザーにリンクできなくなり、リクエストの内容がユーザーのIPアドレスに関連付けられないことを意味する。 例えば、通常のクライアント・サーバー交換では、クライアントに関する以下の情報が明らかになる可能性がある： - 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 これは、各リクエストに対して、アプリサーバーがエンドユーザーの場所やTLSフィンガープリントを知らないことを意味する。 さらに、多くの異なるユーザーがリレーを通じてリクエストを送信している場合、アプリサーバーはどのリクエストが誰から来ているかを区別できず、単一のユーザーへのアプリアクティビティの追跡能力を制限する。 これは強力なプライバシー境界を作成する。 しかし、OHTTPを基本的な転送プロキシと区別するものは、クライアントとアプリサーバー間のデータの暗号化である。 リクエストとレスポンスはHybrid Public Key Encryption (HPKE) を使用してカプセル化されるため、プレーンテキストを見ることができるのはクライアントとアプリサーバーのみであり、リレーは暗号化されたテキストの塊しか見ない。 「ゲートウェイ」はリレーとアプリサーバーの間に位置し、これらの暗号化処理（リクエストのデカプセル化、レスポンスのカプセル化）をすべて処理する――そしてアプリサーバーは通常のHTTPのみを処理する。 これにより、「ダブル