這就是為什麼 Cloudflare 建置基礎設施，協助開發者將隱私融入其應用程式。Oblivious HTTP (OHTTP) 是一項 IETF 標準，旨在讓應用程式後端在不看見使用者 IP 位址的情況下接收 HTTP 請求。
今年秋季，我們將推出 Cloudflare OHTTP Gateway。客戶將能夠啟用我們新的 OHTTP Gateway 作為其區域的付費附加服務，並透過幾次點擊開始接收 OHTTP 流量。請透過我們的表單註冊以加入候補名單。請繼續閱讀以了解更多資訊。
透過 OHTTP，請求會經過兩個獨立運作的節點：一個中繼 (relay) 和一個閘道 (gateway)。OHTTP 中繼會盲目轉發加密請求，以隱藏客戶端識別資訊免於被應用程式伺服器看見。OHTTP 閘道則執行解密加密請求和封裝回應的密碼學工作，讓應用程式伺服器能夠像處理一般 HTTP 請求一樣處理 OHTTP 請求。中繼和閘道之間信任的分離至關重要：它確保沒有單一一方能同時看見客戶端識別資訊和請求內容。
2022 年，我們推出了 OHTTP 中繼產品 Privacy Gateway。Privacy Gateway 使我們的客戶能夠為其使用者提供更注重隱私的體驗。例如，Flo Health 在其應用程式的匿名模式 (Anonymous Mode) 中使用 OHTTP，而 Apple 的 Private Cloud Compute 則使用 OHTTP 來區分 AI 推論請求與使用者身份。但是，已經將伺服器託管在 Cloudflare 後面的客戶無法同時使用 Cloudflare 營運的中繼——他們需要的是 OHTTP 閘道。
根據我們營運 OHTTP 中繼的經驗，我們了解到在規模化建置和營運安全、高效能的 OHTTP 閘道可能有多麼困難。今天，我們為我們的自助式 Cloudflare OHTTP Gateway 推出封閉測試版。我們也將我們的「Privacy Gateway」更名為「Cloudflare OHTTP Relay」，以更好地區分這兩項產品。
現在，想要擁有必要信任分離的 OHTTP 架構的客戶有兩種選擇：
我們正致力於提高整個網際網路的隱私標準，我們相信像 OHTTP 這樣的協定可以有所幫助——如果我們讓它們足夠容易採用。我們的目標一直是擴展我們的 OHTTP 產品套件，並讓我們的信任隱私基礎設施能夠被更廣泛的網際網路所存取。
自從我們推出 OHTTP Relay 產品以來，我們觀察到了一些現象。
首先，我們看到開發者對於易於存取、可用的隱私基礎設施有日益增長的需求。注重隱私的應用程式開發者希望預設將網路隱私融入其應用程式中，但這麼做仍然比應有的更困難。
其次，我們了解到建置和營運 OHTTP 閘道對客戶來說可能很棘手。任何代理架構都會引入一些延遲，因為請求必須繞過網際網路多繞一兩個節點。再加上解密請求和加密回應的成本，自建 OHTTP 設定的延遲影響可能非常顯著。我們處於解決這個問題的有利位置：使我們能夠為 1.1.1.1 和 iCloud Private Relay 等產品營運快速、可靠的隱私基礎設施的相同建置區塊，也使我們成為 OHTTP 閘道的理想託管者。由於 Cloudflare 的任何點傳遞 (anycast) 方法，我們的 OHTTP Gateway 將運行在 Cloudflare 全球邊緣網路的每個伺服器上，最大限度地減少中繼到閘道的延遲。如果您使用我們的 CDN，使用者請求可以由我們的 Gateway 解密，並在相同的 Cloudflare 硬體上由您的應用程式伺服器解析，從而節省了閘道到來源的延遲。
最後，請記住 OHTTP 的隱私模型要求中繼和應用程式伺服器由獨立、不勾結的各方營運。我們希望為客戶提供最好的隱私基礎設施選項。先前，將應用程式伺服器託管在 Cloudflare 後面的開發者無法使用我們的 OHTTP Relay，因為 Cloudflare 會同時看到客戶端元數據和解密後的請求內容，破壞了 OHTTP 的隱私模型。現在，開發者可以選擇 Cloudflare OHTTP Relay 或 Gateway 更適合他們的架構。
客戶端與應用程式伺服器之間的典型互動會洩露客戶端資訊。當客戶端和應用程式伺服器相互通信時，應用程式伺服器會得知客戶端的 IP 位址，因為傳送數據的每個封包都標有來源 IP——類似於信封上的「寄件人」標籤。應用程式伺服器也可以根據 TLS 版本或加密套件等屬性「指紋識別」客戶端。這些信號使得應用程式伺服器能夠將多個請求關聯回同一個使用者。
但是，如果我想建置一個對我的使用者了解不多的應用程式呢？例如：Flo Health 希望建置一個匿名模式，讓使用者能夠存取個人健康數據，而不會與可能的用戶識別資訊連結。
OHTTP 引入了一個稱為「中繼」的代理，它在客戶端和應用程式伺服器之間轉發請求和回應，以混淆客戶端身份免於被應用程式伺服器看見。中繼會看到 IP 位址和 TLS 指紋等客戶端識別資訊，但在轉發請求之前會將其移除。這可以防止應用程式伺服器將多個請求關聯回同一個使用者，並且意味著請求內容無法與使用者的 IP 位址相關聯。
例如，一次常規的客戶端-伺服器交換可能會洩露有關客戶端的以下資訊：
透過 OHTTP 中繼發送的請求將只會向接收請求的應用程式伺服器顯示中繼的資訊：
這意味著，對於每個請求，應用程式伺服器都不會得知最終使用者的位置和 TLS 指紋。此外，如果許多不同的使用者透過中繼發送請求，應用程式伺服器將無法區分哪些請求來自何人，從而限制了他們追蹤應用程式活動回溯到單一最終使用者的能力。這建立了一個強大的隱私邊界。
然而，真正使 OHTTP 與基本轉發代理區別開來的是客戶端和應用程式伺服器之間數據的加密。請求和回應使用混合公鑰加密 (Hybrid Public Key Encryption, HPKE) 進行封裝，因此只有客戶端和應用程式伺服器能看到明文，而中繼只能看到一堆密文。「閘道」位於中繼和應用程式伺服器之間，負責處理所有這些密碼學工作——解封裝請求、封裝回應——而應用程式伺服器只處理普通 HTTP。
這建立了一個「雙盲」隱私模型：中繼只看到客戶端識別資訊；閘道和應用程式伺服器只看到請求內容；沒有一方能同時看到兩者。
在建置我們的 OHTTP 閘道即服務時，我們的目標是將我們安全、高效能的隱私基礎設施帶給更廣泛的網際網路。效能和輕鬆上手至關重要。因此，我們將 Gateway 建置為一個部署在我們全球網路上的彈性服務。只需點擊幾下，您就可以在您的區域啟用 Gateway，並開始將 OHTTP 發送到 https://your-zone.com/.well-known/ohttp-gateway 。我們將自動擴展服務的規模，因此您無需擔心容量。
我們還考慮了一些其他使用者需求，這些需求來自我們從 OHTTP Relay 客戶在營運自己的 OHTTP 閘道時遇到的痛點。
首先：我們希望盡可能地抽象化 OHTTP 對您應用程式伺服器的複雜性。我們希望開發者能夠開始接收 OHTTP，同時如果他們選擇，也能繼續接收常規 HTTP 流量。因此，我們將 Gateway 設計為您區域的一項功能，客戶端將格式正確的 OHTTP 請求發送到您區域的 /.well-known/ohttp-gateway 端點。我們支援標準和分塊 OHTTP——我們建議使用分塊 OHTTP 以獲得更好的效能，因為它使我們能夠逐步處理請求（以「塊」的形式）。
我們的 Gateway 服務將攔截每個請求，解密它，向您的應用程式伺服器發出一個子請求，並將加密的回應返回給客戶端。所有非 OHTTP 請求將在不調用 Gateway 的情況下傳輸到您的伺服器。
將您的 Gateway 綁定到您的區域也能使我們保護您的 Gateway 免受濫用。向您的區域 `example.com` 發送請求的客戶端可能會發送到 `foo.example.com` 或 `bar.example.com`，但不能發送到 wikipedia.com。在您無需擔心此問題的情況下，這可以防止未經授權的客戶端利用您的區域來針對其他網域。
第二：無縫的金鑰管理至關重要。閘道需要維護一個公開的 HPKE 金鑰配置，以便客戶端可以加密請求，但安全地管理金鑰是一項挑戰。因此，我們將 Gateway 設計為為客戶完全管理所有金鑰，並透過與請求閘道不同的 IP 來響應 GET 請求到 /.well-known/ohttp-gateway 來提供公開金鑰。為了更強的隱私，客戶端可以下載金鑰。
第三：閘道需要能夠驗證中繼。由於閘道（按設計）對發送給定請求的客戶端了解甚少，因此它信任中繼來驗證客戶端並負責任地轉發流量。但是，您如何確保只有受信任的中繼可以將流量發送到您的閘道呢？
我們設計了 Gateway，以便 Cloudflare Access（Cloudflare 的零信任網路存取產品）在請求解密之前運行，使您能夠使用任何標準的 Access 策略來驗證傳入流量並保護您的 Gateway 免受濫用。選項包括相互 TLS、靜態服務憑證和自定義外部邏輯。
最後：錯誤時有發生，我們預計客戶可能會意外破壞 OHTTP 的隱私模型，方法是在 Cloudflare 上同時運行中繼和閘道。因此，為了保留 OHTTP 的信任分離，並確保 Cloudflare 永遠不會同時看到客戶端身份和解密後的內部請求，我們的 Gateway 將拒絕解密從 Cloudflare Workers 或 Cloudflare 上代理主機發送的請求。
如果您想使用 Cloudflare 的 OHTTP 產品套件，但您想知道為什麼要選擇 Cloudflare 的 OHTTP Gateway 而不是 OHTTP Relay，這裡有幾個考量因素。
首先，您希望您的應用程式伺服器託管在 Cloudflare 上嗎——例如，在我們的 CDN 後面或建置在 Workers 上？如果是這樣，OHTTP Gateway 是確保遵守 OHTTP 隱私模型的更好選擇。
其次，您的使用案例是什麼？如果您想從第三方客戶端和中繼接收 OHTTP 請求——例如，使用 Apple 的 LiveCallerID SDK——那麼 OHTTP Gateway 可能是更適合您的解決方案。
然後，您需要實施一個 OHTTP 客戶端。請參閱 ohttp.info 或我們的範例客戶端庫以獲取一些入門範例。建置客戶端時請注意：OHTTP 在網路層級提供隱私，並且不觸及內部請求主體。因此，為了保護使用者隱私，您有責任不在請求主體中發送識別資訊（例如使用者的電子郵件地址或使用者名稱）。
接下來，您需要自備中繼。中繼可以在任何基礎設施提供者上運行，而且它們很簡單：這裡有一些範例程式碼。挑戰以及您可能想要專用 OHTTP 中繼提供者的原因，是向使用者可驗證地承諾您不會檢查帶有客戶端識別資訊的日誌。否則，您將能夠將中繼上的客戶端與應用程式伺服器上的解密請求關聯起來。
