Cloudflare 推出 OHTTP Gateway，擴充隱私保護基礎設施

今天，最終使用者承擔太多網路隱私的負擔。為了避免第三方追蹤器或定向廣告，使用者被建議使用 VPN、停用 Cookie 或安裝廣告攔截器。與此同時，一些應用程式開發者往往比他們願意承擔的還要了解更多關於使用者的資訊：典型的客戶端-伺服器交換會留下使用者資料痕跡，例如客戶端的 IP 位址或 TLS 指紋。這種可見度的程度可能成為負擔。

這就是為什麼 Cloudflare 建置基礎設施，協助開發者將隱私融入他們的應用程式。Oblivious HTTP (OHTTP) 是一個IETF 標準設計用於讓應用程式後端接收 HTTP 請求，而不會看到使用者的 IP 位址。

今年秋季，我們將推出 Cloudflare OHTTP Gateway。客戶將能將我們的新 OHTTP Gateway 作為付費附加元件啟用於其區域，並僅需點選幾下即可開始接收 OHTTP 流量。透過我們的表單註冊加入等候名單。繼續閱讀以瞭解更多。

擴充我們的 OHTTP 產品系列

使用 OHTTP 時，請求會經過兩個獨立運作的跳點：一個中繼和一個閘道。OHTTP 中繼會盲目轉發加密請求，以隱藏客戶端識別資訊不被應用程式伺服器看到。OHTTP 閘道負責解封加密請求並封裝回應，使應用程式伺服器能像處理普通 HTTP 請求一樣處理 OHTTP 請求。中繼與閘道之間的信任分離至關重要：它確保沒有單一方同時看到客戶端識別資訊與請求內容。

2022 年，我們推出了 OHTTP 中繼產品Privacy Gateway。Privacy Gateway 讓我們的客戶能為其使用者提供更具隱私保護的體驗。例如，Flo Health 在其應用程式中使用 OHTTP 來支援Anonymous Mode，而 Apple 的Private Cloud Compute 則使用 OHTTP 來將 AI 推論請求與使用者身份分離。但已在 Cloudflare 之後保護其伺服器的客戶無法再使用 Cloudflare 運營的中繼——他們需要 OHTTP 閘道。

根據我們執行 OHTTP 中繼的經驗，我們發現建立與運營安全、高效的 OHTTP 閘道在大規模環境下相當困難。今天，我們推出了自助式 Cloudflare OHTTP Gateway 的封閉測試版。為了更清楚區分兩款產品，我們還將「Privacy Gateway」重新命名為「Cloudflare OHTTP Relay」。

現在，想要具備必要信任分離的 OHTTP 架構的客戶有兩個選擇：

使用 Cloudflare 的 OHTTP Relay（原名 Cloudflare Privacy Gateway）並自行執行閘道。如果您的應用程式伺服器不託管於 Cloudflare，且您能自行執行 OHTTP 閘道，這是最佳選擇。
使用 Cloudflare 的新 OHTTP Gateway 搭配第三方中繼。如果您的應用程式伺服器已經位於 Cloudflare 之後（例如使用我們的 CDN 或 Workers），或您正在接收第三方的 OHTTP 請求（如 Apple 的 LiveCallerID），或您想要一個受管理的閘道以降低延遲與運營負擔，這是最佳選擇。

我們正努力提升整個網際網路的隱私水準，並相信像 OHTTP 這樣的協定能協助實現——只要我們能讓它們易於採用。擴充 OHTTP 產品系列並將我們可信的隱私基礎設施提供給更廣泛的網際網路使用者，一直是我們的目標。

為何我們打造 Cloudflare OHTTP Gateway

自從我們推出 OHTTP Relay 產品以來，我們觀察到一些情況。

首先，我們發現開發者對可存取、易用的隱私基礎設施需求日益增加。隱私導向應用程式的開發者希望將網路隱私預設嵌入其應用，但實際上仍比應該容易的更困難。

其次，我們瞭解到為客戶建置與運營 OHTTP Gateway 可能相當困難。任何代理架構都會帶來額外延遲，因為請求必須在網際網路上額外往返一兩跳。再加上解密請求與加密回應的成本，自己搭建的 OHTTP 方案所造成的延遲可能相當顯著。我們有能力解決此問題：同樣的構建模組讓我們能為像 1.1.1.1 與 iCloud Private Relay 這類產品提供快速、可靠的隱私基礎設施，亦使我們成為 OHTTP Gateway 的理想平臺。由於 Cloudflare 的 anycast 方法，我們的 OHTTP Gateway 將在 Cloudflare 全球邊緣網路的每一臺伺服器上執行，降低從中繼到 Gateway 的跳遞延遲。若您使用我們的 CDN，使用者請求可由 Gateway 解密，並由同一 Cloudflare 金屬環境中的應用伺服器處理，進而節省 Gateway 到原始伺服器的延遲。

最後，請回想 OHTTP 的 privacy model 需要中繼與應用伺服器由獨立且不共謀的雙方運營。我們希望為客戶提供最完整的隱私基礎設施選項。之前，將應用伺服器放置於 Cloudflare 背後的開發者無法使用我們的 OHTTP Relay，因為 Cloudflare 會同時看到客戶端的元資料與請求的解密內容，違反 OHTTP 的隱私模型。現在，開發者可以自行決定 Cloudflare OHTTP Relay 或 Gateway 是否更適合其架構。

OHTTP 入門指南

客戶端與應用伺服器之間的典型互動會透露客戶端資訊。當客戶端與應用伺服器互相通訊時，伺服器會得知客戶端的 IP 位址，因為每個傳送資料的封包都標示著來源 IP——類似信封上的"from"標籤。伺服器亦可根據支援的 TLS 版本或加密套件等屬性對客戶端進行"fingerprint"辨識。這些訊號使伺服器能將多個請求連結回同一使用者。

但如果我想開發一個真正不瞭解使用者資訊的應用程式會怎樣？例如：Flo Health 想打造一個 Anonymous Mode，讓使用者能夠存取個人健康資料，而不會被連結至潛在的使用者識別碼。

OHTTP 引入一個代理，稱為 'relay'（中繼），它在客戶端與應用伺服器之間轉發請求與回應，以遮蔽客戶端的身份。relay 會看到客戶端的識別資訊，如 IP 位址與 TLS 指紋，但在轉發請求前會將其移除。這樣可防止應用伺服器將多個請求連結回同一使用者，也使請求內容無法與使用者的 IP 位址關聯。

例如，一般的客戶端-伺服器交換可能會透露以下關於客戶端的資訊：

一個先經由 OHTTP relay 傳送的請求，只會向接收請求的應用伺服器透露 relay 的資訊：

這意味著對於每一次請求，應用伺服器不會獲知終端使用者的位置與 TLS 指紋。此外，如果許多不同使用者透過 relay 傳送請求，伺服器將無法辨別哪些請求來自哪位使用者，限制了追蹤應用活動回單一終端使用者的能力。這建立了一個強大的隱私邊界。

真正使 OHTTP 與基本轉發代理區別開來的是客戶端與應用伺服器之間資料的加密。請求與回應使用 Hybrid Public Key Encryption (HPKE) 封裝，確保只有客戶端與應用伺服器能看到明文，而 relay 只能看到一堆密文。gateway 位於 relay 與應用伺服器之間，負責所有加解密工作——解封裝請求、封裝回應——而應用伺服器只處理純 HTTP。

這建立了一個「雙盲」隱私模型：relay 僅能看到客戶端識別資訊；gateway 與應用伺服器僅能看到請求內容；沒有任何一方同時看到兩者。

我們如何構建 OHTTP Gateway

在構建我們的 OHTTP gateway-as-a-service 時，我們的目標是將安全、效能優良的隱私基礎設施帶給更廣泛的網際網路使用者。效能與易於上線至關重要。因此，我們將 Gateway 設計為一個可靈活部署於全球網路的服務。只需點選幾下，即可在您的區域啟用 Gateway，並開始將 OHTTP 傳送至 https://your-zone.com/.well-known/ohttp-gateway。我們會自動調整服務容量，您不必擔心容量問題。

我們考慮了其他使用者需求，這些需求來自於我們觀察到 OHTTP Relay 客戶在自行運營 OHTTP gateway 時遇到的痛點。

首先：我們希望盡可能將 OHTTP 的複雜性抽象化，讓您的應用伺服器不必擔心。開發者可以在繼續接受常規 HTTP 流量的同時，開始接收 OHTTP。於是我們將 Gateway 設計為區域功能，客戶端將 well-formatted OHTTP 請求傳送至您區域的 /.well-known/ohttp-gateway 端點。我們支援標準與 chunked OHTTP，並建議使用 chunked OHTTP 以提升效能，因為它允許我們以「區塊」方式逐步處理請求。

我們的 Gateway 服務將攔截每一次請求，解密後向您的應用伺服器傳送子請求，並將加密後的回應傳回客戶端。所有非 OHTTP 請求將直接傳送至您的伺服器，而不會觸發 Gateway。

將您的 Gateway 繫結到您的區域也能讓我們保護 Gateway 免於濫用。傳送請求到您的區域 example.com 的客戶端可能會傳送到 foo.example.com 或 bar.example.com，但無法傳送到 wikipedia.com。您無需擔心，這能阻止未授權的客戶端將您的區域用作攻擊其他域名的途徑。

第二：無縫的金鑰管理至關重要。Gateway 需要維護公開的 HPKE 金鑰配置，以便客戶端加密請求，但安全管理金鑰是一項挑戰。因此，我們設計了 Gateway 以完全管理客戶的所有金鑰，並在對 /.well-known/ohttp-gateway 傳送 GET 請求時回傳公開金鑰。為了更強的隱私，客戶端可以使用不同於請求 Gateway 的 IP 下載金鑰。

第三：Gateway 需要能夠驗證中繼。由於 Gateway（設計上）對傳送特定請求的客戶端知之甚少，它將信任交給中繼，以驗證客戶端並負責轉發流量。但如何確保只有受信任的中繼能將流量傳送到您的 Gateway？

我們設計 Gateway 使得 Cloudflare Access（Cloudflare 的零信任網路存取產品）在請求解密之前執行，讓您能使用任何標準 Access 策略來驗證進入流量並保護 Gateway 免於濫用。選項包括雙向 TLS、靜態服務憑證，以及自訂外部邏輯。

最後：錯誤難免，我們預見客戶可能會因同時在 Cloudflare 上執行其中繼和 Gateway 而不小心破壞 OHTTP 的隱私模型。因此，為了維持 OHTTP 的信任分離並確保 Cloudflare 永遠不會看到兩者客戶端身份與解密後的內部請求，我們的 Gateway 將拒絕解密來自 Cloudflare Workers 或 Cloudflare 代理主機的請求。

何時 OHTTP Gateway 比 OHTTP Relay 更適合？

如果您想使用 Cloudflare 的 OHTTP 產品組合，但不確定為什麼會選擇 Cloudflare 的 OHTTP Gateway 而非 OHTTP Relay，以下是幾項考量。

首先，您是否想將應用程式伺服器放在 Cloudflare 上，例如位於我們的 CDN 之後或建置於 Workers？如果是，OHTTP Gateway 更適合，以確保遵循 OHTTP 的隱私模型。

第二，您的使用案例是什麼？如果您想從第三方客戶端和中繼接收 OHTTP 請求——例如使用 Apple 的 LiveCallerID SDK——那麼 OHTTP Gateway 很可能是更適合您的解決方案。

快速上手

如果您有功能需求或想註冊我們的候補名單，以便在產品上線時通知您，請在此註冊。

接著，您需要實作一個 OHTTP 客戶端。參考 ohttp.info 或我們的範例客戶端庫，其中有一些範例可協助您開始。構建客戶端時需要注意的一點：OHTTP 在網路層提供隱私，並不會接觸內部請求主體。因此，為了保護使用者隱私，您必須自行避免在請求主體中傳送識別資訊（例如使用者的電子郵件地址或使用者名稱）。

接下來，您需要自行帶來一個中繼器。中繼器可在任何基礎設施供應商上執行，且相當簡單：以下是一些範例程式碼。挑戰與您可能想選擇專用 OHTTP 中繼服務商的原因，是為了能夠向用戶驗證性地承諾您不會檢查帶有客戶端識別碼的日誌。否則，您將能將中繼器上的客戶端與您應用伺服器上解密的請求相互關聯。

最後，當您的 OHTTP 部署上線後，請檢視我們的 pvcli 客戶端以協助測試與除錯。

我們很高興能為全世界的開發者帶來可使用的隱私基礎設施。聯絡我們若您想嘗試新的 OHTTP Gateway 並提升線上隱私標準，請聯絡我們。