目錄

• 您可能想知道
• 主要主題
• 重點洞見表
• 後續…

您可能想知道

• 加密 Client Hello（ECH）如何改變網路可以在 Android 裝置上看到的瀏覽資訊？

• 即使作業系統啟用了 ECH，還有哪些限制依然存在？

主要主題

Android 17 已在平台層級引入對加密 Client Hello（ECH）的支援，這是一項以隱私為重點的增強功能，可在 TLS 握手階段隱藏包含的網域名稱，避免中間網路觀察者看到。傳統上，當裝置開啟 HTTPS 連線時，連線的初始握手可能會透過 Server Name Indication（SNI）欄位洩露所請求網站的主機名稱。那個明文識別符會讓電信業者、Wi‑Fi 提供者和其他網路參與者得知裝置的連線目的地，即便後續的會話內容已加密。

ECH 改變了這種行為，透過加密 client hello 訊息來讓主機名稱對除目標伺服器外的其他人都不可見。用戶端會將網站名稱加密給目標發佈的公鑰；只有持有對應私鑰的最終伺服器能解密該值並判斷真實的主機名稱。對於網路觀察者來說，SNI 變成了一個不透明的標籤，而非可讀的網域，減少了裝置與伺服器之間路徑上可見的元資料量。

這一關鍵洞見顯著影響了對 TLS 隱私的理解： ECH 保護握手中的主機名稱標籤，但不會抹去連線的其他可觀察訊號。ECH 與私有 DNS 並行運作，私有 DNS 已經會使將名稱對應到 IP 位址的 DNS 查詢變得不那麼明顯，但 ECH 與那些保護措施是不同且互補的。

Android 與 Google 將此推廣描述為在主要行動作業系統上較早期的大規模 ECH 部署之一。該公司與其 Jigsaw 團隊及更廣泛的開發者社群協作者共同開發了這項功能。然而，只有當目標──網站或應用伺服器──在其端啟用 ECH 時，此保護才有效。Android 的平台支援使得用戶端在可用時預設使用 ECH，但對尚未採用 ECH 的伺服器的請求在握手期間仍會洩露主機名稱。

即使在使用 ECH 時，網路仍可觀察到其他元資料。伺服器的 IP 位址對位於用戶端與伺服器之間的任何路由節點仍然可見，傳輸資料的數量與時序也不會被 ECH 隱藏。從這些可觀察的資訊中，對手仍可對使用者活動做粗略推斷或將流量模式與已知服務相關聯。簡言之，ECH 加密了 TLS 握手中的一個特定且重要的標籤，但並不是對所有網路層級訊號的全面隱匿。

Google 已鼓勵開發者採用更新的網路函式庫（例如 OkHttp 5.5.0 及以後版本）並啟用 ECH，以便能讓保護在端到端上生效。網站與應用的採用情況是使用者能廣泛受益的決定性因素。在伺服器支援 ECH 達到臨界數量之前，許多連線仍會在網路上洩露主機名稱，儘管 Android 已具備在可能情況下將其加密的能力。

這項網路隱私改進的時機，與 Android 生態系中其他隱私與安全相關的發展同時發生。例如，Android 17 預設啟用憑證透明度（Certificate Transparency），並要求應用在掃描本地網路前請求權限──兩者皆旨在強化使用者對應用行為與身分驗證的控制與可見性。這些新增功能反映了在多個層面改善平台隱私的更廣泛努力，從憑證稽核到網路握手保護。

同時，關於裝置層級資料控制的法律與社會問題仍不斷浮現。近期受矚目的法律案件突顯了個人控制裝置內容權利與政府調查之間的緊張關係。這些案件強調技術性隱私改進只是情勢的一部分；法律保護與政策框架也會影響使用者有效主張資訊控制的能力。

重點洞見表

後續…

展望未來，隱私的進一步改進將取決於伺服器對 ECH 等協定的更廣泛採用、傳輸層互補創新，以及應用程式設計的改善。持續採用私有 DNS、ECH 與其他加密元資料技術可以減少網路觀察者可得的明文資訊，但若目標是大幅限制流量分析，還必須搭配可處理可觀察流量模式的系統，例如填充、流量整形或混合網路。

同等重要的是保護使用者資料免於不當存取的法律與政策措施，並對監控施加明確限制。隨著技術保護演進，制定政策者與平台廠商應協調，以在保障日常使用者隱私的同時，確保合乎法律且比例適當的存取程序。

投資於標準化且廣泛部署的加密實務，以及減少元資料外漏的研究，將在近期為使用者帶來最實際的隱私成效。Android 17 的推行是朝此方向的實際一步，但它只是加強網路使用者隱私所需的眾多元素之一。