Android 17 的 ECH 隱私升級：網站名稱藏起來了，但哪些資料仍會曝光？

Android 17 最具影響力的網路隱私更新之一，是在平台層級支援 加密用戶端 Hello（Encrypted Client Hello，ECH）。這項 TLS 1.3 擴充功能會加密安全連線開頭通常會暴露的主機名稱，降低 Wi-Fi 業者、網路供應商及其他網路觀察者得知使用者正連線至哪個網站或服務的機會。46

不過，ECH 並不等於完全匿名。它只在整條連線具備支援時才有效：裝置必須執行 Android 17 或以上版本，應用程式使用支援 ECH 的網路函式庫，而目的地服務也必須在伺服器端部署 ECH。25

ECH 到底加密了什麼？

傳統 TLS 連線會在初始握手中傳送 伺服器名稱指示（Server Name Indication，SNI），其中包含用戶端想連線的主機名稱。ECH 會利用目的地服務發布的設定與金鑰材料，加密 ClientHello 中這段敏感資訊。目的地伺服器可以解密，網路上的觀察者則只會看到外層握手，而不是實際要造訪的主機名稱。416

這項差異很重要。HTTPS 已經會加密網頁內容，但網站名稱本身仍可能在連線初始階段洩漏，讓網路業者或其他觀察者推測使用者正在使用哪項服務。ECH 的目的，就是減少這類特定的 metadata 洩漏，前提是目的地支援該標準。56

網路觀察者仍然看得到什麼？

ECH 並不會加密連線的每一層資訊。視觀察者所在的位置與連線情況而定，以下資料仍可能可見：

• 裝置的來源 IP 位址。
• 目的地 IP 位址；它可能只對應到 CDN 或主機代管業者，也有時能指向特定服務。
• 連線時間、封包大小及流量總量。
• 若 DNS 查詢沒有另外受到保護，DNS 查詢內容也可能洩漏目的地資訊。

因此，ECH 不應被描述成 VPN 或匿名系統。Google 將 ECH 與 Private DNS 視為互補的防護：ECH 隱藏 TLS 握手中的主機名稱，加密 DNS 則協助保護將網域名稱解析為 IP 位址的另一個步驟。兩者本身都不會隱藏裝置的 IP 位址。612

Android 17 的 ECH 要求與預設行為

Android 17 提供網路函式庫實作 ECH 所需的平台支援與 API，包括查詢含有 ECH 設定的 HTTPS DNS 記錄能力。4

但實際能否獲得保護，仍取決於三項條件：

1. 裝置執行 Android 17 或以上版本。
2. 應用程式使用支援 ECH 的網路堆疊。 Android 文件列出的例子包括 HttpEngine、WebView 和 OkHttp；但作業系統提供支援，並不代表每個網路函式庫都已具備 ECH 能力。23
3. 遠端伺服器已部署 ECH。 如果服務端沒有完成設定，用戶端就無法加密要連線的主機名稱。25

對以 Android 17 或以上版本為目標平台的應用程式而言，只要網路函式庫與遠端伺服器都支援 ECH，TLS 連線就會使用 ECH。若 ECH 因故無法使用，應用程式設定的網域加密政策會決定連線是否可以繼續，或必須直接中止，以避免不安全的 fallback。12

ECH GREASE 是什麼？

Android 的網域加密政策不只是單純的「開啟」或「關閉」ECH。當網域加密已啟用，但伺服器尚未支援真正的 ECH 時，Android 可以改送 ECH GREASE。這個擴充功能本身刻意設計成無法運作，但外觀上類似 ECH 流量。

其作用包括提升相容性，以及降低簡單流量分類的準確度：網路系統不應只因為一次連線沒有成功使用 ECH，就推斷用戶端從未嘗試 ECH。不過，GREASE 不會像成功的 ECH 那樣隱藏主機名稱；它是相容性機制，不能取代伺服器端部署。1

如果應用程式停用網域加密，Android 的 NetworkSecurityPolicy 文件指出，ECH 與 GREASE 都不應使用。相關 API 也提供包括「啟用」和「必要」在內的網域加密模式；在必要模式下，若 ECH 無法啟用，連線應該 fail closed，也就是直接失敗。1

開發者需要做什麼？

Android 17 的平台支援不會自動替所有應用程式的流量加密主機名稱。開發者應該：

• 確認應用程式使用的網路函式庫已整合 ECH 支援。235
• 在 Network Security Config 或同等設定中配置網域加密政策。15
• 確認函式庫能取得並使用目的地服務公布的 ECH 設定。Android 已提供查詢含有 ECH 設定之 HTTPS DNS 記錄的平台 API。4
• 分別測試支援與不支援 ECH 的伺服器，並決定應用程式要允許 fallback，還是要求 ECH；若無法使用就直接中止連線。1

伺服器營運者同樣必須部署 ECH，並發布用戶端所需的設定。這項服務端依賴，是 Android 的平台支援不會立刻讓所有應用程式與所有網站名稱都隱形的主要原因。516

Google 表示，正與 Jigsaw、業界參與者、服務供應商及應用程式開發者合作，擴大 ECH 的採用範圍。更大的目標，是透過共用的網路基礎設施，讓應用程式也能使用主機名稱保護，而不只限於經過特殊設定的瀏覽器。46

Android 17 其他網路防護

存取區域網路需要執行階段權限

以 Android 17 或以上版本為目標平台的應用程式，在探索或連線至區域網路裝置前，必須要求 ACCESS_LOCAL_NETWORK 執行階段權限。這項權限屬於既有的 NEARBY_DEVICES 權限群組，因此已授予該群組其他權限的使用者，可能不會再次看到群組層級的提示。217

這項變更旨在減少應用程式在使用者不知情下掃描區域網路，進而進行追蹤、建立裝置指紋，或尋找具弱點的網路設備。需要連線至智慧家庭裝置、投放接收器或其他區域網路設備的應用程式，則必須宣告並要求這項權限。1719

憑證透明度預設啟用

Android 17 會在 TLS 連線中預設啟用 憑證透明度（Certificate Transparency，CT）。CT 要求公開憑證被記錄在公開且可稽核的日誌中，有助於揭露錯誤簽發或不當簽發的憑證。應用程式仍可透過網路安全設定，在全域或特定網域停用這項功能。3

電信商可限制不安全的 2G 連線

Android 17 也針對 2G 行動網路安全性較弱的問題加入防護。在支援的裝置與電信網路上，電信商可以預設限制或停用 2G 連線，降低使用者遭遇偽造基地台與 SMS blaster 攻擊的風險。實際行為仍取決於電信商及裝置支援情況。8

實際隱私效果：有改善，但不是隱身斗篷

只要用戶端與伺服器都支援，ECH 確實能從 TLS 握手的重要部分移除網站主機名稱，降低網路觀察者直接得知使用者造訪哪個網站或使用哪項服務的機會。

但 DNS 設定、目的地 IP 位址、連線時間、封包大小與流量總量，仍可能提供線索。若要進一步保護網域名稱，ECH 應搭配加密 DNS；若要避免透過 IP 位址辨識裝置，則需要 VPN、Proxy 或 Tor 等獨立工具。

最準確的理解是：Android 17 讓網路觀察者更難讀取使用者連線的網站與服務名稱，但 ECH 並未涵蓋其他層級的連線 metadata，也不會單獨提供匿名或 IP 位址隱藏功能。