Privacy Gateway 包含三個主要元件：
- 用戶端：使用者的裝置，或設定為將請求轉寄到 Privacy Gateway 的任何用戶端。
- Privacy Gateway：由 Cloudflare 營運的一項服務，旨在在用戶端和閘道之間轉送請求，而無法觀察其中的內容。
- 應用程式伺服器：負責解密來自用戶端的請求，並對返回的回應進行加密的源站或應用程式 Web 伺服器。
如果您將請求資料想像為信件的內容，將 IP 位址和請求元資料想像為信封上的地址，那麼使用 Privacy Gateway 時，Cloudflare 能夠看到信封上的地址並將其安全地轉寄到目的地，而無法看到裡面的內容。
使用 Privacy Gateway 的 Oblivious HTTP 交易
稍微詳細一點，資料流如下所示：
- 用戶端使用應用程式伺服器的公開金鑰封裝 HTTP 請求，並透過 HTTPS 連線將其傳送至 Privacy Gateway。
- Privacy Gateway 透過其與應用程式伺服器的獨立 HTTPS 連線將請求轉寄到伺服器。
- 應用程式伺服器解封請求，將其轉寄到可以產生回應的目標伺服器。
- 應用程式伺服器向 Privacy Gateway 傳回封裝的回應，然後 Privacy Gateway 將結果轉寄給用戶端。
根據通訊協定中的規定，從用戶端到伺服器的請求使用 HPKE 加密，這是公開金鑰加密的最先進標準——您可以在此處閱讀更多相關資訊。我們已採取額外措施，透過對通訊協定進行正式分析來確保 OHTTP 使用 HPKE 的安全性，我們希望在未來幾週內發布更深入的分析。
Privacy Gateway 如何改善終端使用者隱私
此互動提供兩種類型的隱私，我們非正式地將其稱為請求隱私和用戶端隱私。
請求隱私意味著應用程式伺服器不會知曉 HTTP 請求會透露的資訊，例如 IP 位址、地理位置、TLS 和 HTTPS 指紋等。由於 Privacy Gateway 在其自身和應用程式伺服器之間使用單獨的 HTTPS 連線，因此向應用程式伺服器顯示的所有這些單個請求資訊都代表 Privacy Gateway 的資訊，而不是用戶端的資訊。但是，開發人員需要注意不要在請求內容中傳送個人識別資訊。例如，如果解封后的請求中包含使用者的電子郵件、電話號碼或信用卡資訊等資訊，則 Privacy Gateway 無法有意義地改善隱私。
用戶端隱私是一個更強大的概念。由於 Cloudflare 和應用程式伺服器沒有合謀分享單個使用者的資料，因此從伺服器的角度來看，每個單獨的交易都來自 Privacy Gateway 後方的某個未知用戶端。換句話說，正確設定的 Privacy Gateway 部署意味著應用程式無法將任何兩個請求連結到同一用戶端。特別是，使用 Privacy Gateway 時，需要有多個使用者才能產生用戶端隱私。如果只有一個終端使用者使用 Privacy Gateway，則它僅提供請求隱私（因為用戶端 IP 位址對閘道保持隱藏）。它不會提供用戶端隱私，因為伺服器會知道每個請求對應於相同的單個用戶端。用戶端隱私要求系統有許多使用者，這樣應用程式伺服器才無法進行確定。
如要更好地瞭解請求和用戶端隱私，請考慮用戶端和伺服器之間的以下 HTTP 請求：
具有大小為 1 的用戶端匿名集的標準 HTTP 設定
如果用戶端直接連線到伺服器（或 OHTTP 字詞中的「閘道」），伺服器可能會看到有關用戶端的資訊，包括 IP 位址、使用的 TLS 密碼以及基於該 IP 位址的位置資料度數：
- ipAddress: 192.0.2.33 # the client’s real IP address
- ASN: 7922
- AS Organization: Comcast Cable
- tlsCipher: AEAD-CHACHA20-POLY1305-SHA256 # potentially unique
- tlsVersion: TLSv1.3
- Country: US
- Region: California
- City: Campbell
|
這裡有很多敏感資訊，可能是終端使用者獨有的。換句話說，連線既不提供請求隱私，也不提供用戶端隱私。
使用 Privacy Gateway 時，用戶端不會直接連線到應用程式伺服器本身。相反，它們連線到 Privacy Gateway，由 Privacy Gateway 連線到伺服器。這意味著伺服器只能看到來自 Privacy Gateway 的連線，而不是看到來自用戶端的單個連線，從而產生不同的檢視：
- ipAddress: 104.16.5.5 # a Cloudflare IP
- ASN: 13335
- AS Organization: Cloudflare
- tlsCipher: ECDHE-ECDSA-AES128-GCM-SHA256 # shared across several clients
- tlsVersion: TLSv1.3
- Country: US
- Region: California
- City: Los Angeles
|
具有大小為 k 的用戶端匿名集的 Privacy Gateway 設定
這是請求隱私。有關用戶端位置和身份的所有資訊都對應用程式伺服器隱藏，而有關應用程式資料的所有詳細資訊都對 Privacy Gateway 隱藏。對於敏感應用程式和通訊協定（如 DNS），將此中繼資料與應用程式資料分開是改善終端使用者隱私的重要一步。
此外，應用程式應注意不要在其個人請求中洩露敏感的、針對每個用戶端的資訊。Privacy Gateway 無法保證應用程式不會在請求主體中傳送識別資訊（如電子郵件地址、全名等），因為它無法看到純文字應用程式資料。在請求中洩露使用者識別資訊的應用程式可能會侵犯用戶端隱私，但不會侵犯請求隱私。因此，與我們的完整應用程式層級隱私代理產品不同，Privacy Gateway 並非意味著可以用作任意應用程式和流量的通用代理型通訊協定。它旨在成為敏感應用程式的特殊用途通訊協定，包括 DNS（如 Oblivious DNS-over-HTTPS 所證明）、遙測資料或上面討論的通用 API 請求。
將 Privacy Gateway 整合到您的應用程式中
與 Privacy Gateway 整合要求應用程式實作 OHTTP 通訊協定的用戶端和伺服器端。讓我們來看看這需要些什麼。
伺服器整合
通訊協定的伺服器端部分負責兩個基本任務：
- 發佈用於請求封裝的公開金鑰；以及
- 解密封裝的用戶端請求，處理產生的請求，並加密相應的回應。
公開封裝金鑰（稱為金鑰設定）由金鑰標識元（這樣伺服器可以一次支援多個金鑰以進行輪換）、用於加密和解密的加密演算法識別碼以及公開金鑰組成：
HPKE Symmetric Algorithms {
HPKE KDF ID (16),
HPKE AEAD ID (16),
}
OHTTP Key Config {
Key Identifier (8),
HPKE KEM ID (16),
HPKE Public Key (Npk * 8),
HPKE Symmetric Algorithms Length (16),
HPKE Symmetric Algorithms (32..262140),
}
|
用戶端需要此公開金鑰來建立他們的請求，有很多方法可以做到這一點。伺服器可以修復公開金鑰，然後將其整合到它們的應用程式中，但這需要軟體更新來輪換金鑰。或者，用戶端可以透過其他方式探索公開金鑰。探索機制有很多，因威脅模型而異——如需更多詳細資訊，請參閱此文件。在開始時，一個簡單的方法是讓用戶端透過某些 API 直接從伺服器擷取公開金鑰。以下是我們的開放原始碼 OHTTP 伺服器提供的 API 片段：
func (s *GatewayResource) configHandler(w http.ResponseWriter, r *http.Request) {
config, err := s.Gateway.Config(s.keyID)
if err != nil {
http.Error(w, http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError)
return
}
w.Write(config.Marshal())
}
|
在解決公開金鑰的產生和分發問題後，伺服器就需要處理來自用戶端的封裝請求了。對於每個請求，伺服器需要解密請求，將純文字轉譯為可以解析的相應 HTTP 請求，然後將產生的回應加密並傳回用戶端。
以上資訊分享給大家，樂雲客戶若遇到相關問題，我們隨時歡迎尋求支援諮詢，將協助設定與瞭解用法，如果您尚未透過我們購買Cloudflare，亦歡迎先洽詢了解相關細節，我們將提供全中文支援，守護您的網站資安，提升您網站資訊安全防護力，讓您的網站/應用程式運作順暢，使用者都能安心上站互動與消費。
