兩年前為了更好地保護用戶隱私，Mozilla 在 Firefox Nightly 版本中開始 實驗測試 ESNI 功能。不過由於 ESNI 存在諸多安全隱患，Mozilla 近日宣布自 Firefox 85 版本開始將會遷移到 Encrypted Client Hello (ECH)上。
ESNI 全稱是加密伺服器名稱指示（Encrypted Server Name Indication），是 TLS 的一些擴充協議，主要是為了解決主機名稱洩漏的問題。該協議在通信過程開始的時候，由客戶端在 TLS Client Hello 訊息中，以明文傳送要連接的伺服器主機名稱，以連接到特定伺服器，並選擇使用的憑證。
▲ TLS 1.3 握手過程
▲ 帶 ESNI 的 TLS 1.3 握手過程
▲ 使用 ECH 的 TLS 1.3 握手過程
自從 ESNI 規範草案在 IETF 上發布以來，分析表明僅僅加密 SNI 擴展提供的保護是不完整的。舉個例子：在會話恢復過程中，Pre-Shared Key 擴展可以合法地包含一個與 ESNI 加密的伺服器名稱完全相同的明文副本。
而伴隨著越來越多的網站普及 HTTPS，依然採用明文的 SNI 成為新的隱私漏洞。通過明文 SNI，ISP 或任何網絡中間人將會知道你訪問了哪個網站。ESNI 方法將需要每個擴展的加密變體，具有潛在的隱私影響，即使這樣也會暴露廣告中的擴展集。
為了解決 ESNI 的問題，最近發布的規範不再只加密 SNI 擴展，而是對整個 Client Hello 信息進行加密，因此名稱從 ESNI 改成 ECH。任何涉及隱私的擴展現在都可以歸入一個加密的 "ClientHelloInner"，而這個 "ClientHelloInner "本身就被宣傳為未加密的 "ClientHelloOuter "的擴展。如果伺服器支持ECH並成功解密，"內層"Client Hello就會被用作TLS連接的基礎。
ECH還改變了密鑰分配和加密故事。支持ECH的TLS伺服器現在通過HTTPSSVC DNS 記錄來宣傳其公鑰，而 ESNI則使用TXT記錄來實現這一目的。由於ECH採用了混合式公鑰加密規範，而不是定義自己的方案，因此密鑰推導和加密變得更加強大。
重要的是，ECH 還增加了重試機制，以提高伺服器密鑰輪換和DNS緩存的可靠性。目前，ESNI在從DNS接收到陳舊的密鑰後可能會失敗，ECH可以安全地恢復，因為客戶端直接從伺服器接收更新的密鑰。
為了更好的保護用戶隱私，Mozilla 宣布正與 Cloudflare 和其他公司積極合作，在 IETF 上對加密 Client Hello 規範進行標準化。Firefox 85 用 ECH draft-08 取代了 ESNI，並且即將對 draft-09 進行另一次更新（目標是進行更廣泛的互操作性測試和部署）。
之前在 Firefox 中啟用過 ESNI 的用戶可能會注意到，ESNI 的 about:config 選項已經不存在了。雖然 Mozilla 建議用戶等待 ECH 被默認啟用，但有些用戶可能會希望提前啟用該功能。用戶可以在 about:config 中通過將 network.dns.echconfig.enabled 和 network.dns.use_https_rr_as_altsvc 設置為 true 來實現，這將允許 Firefox 在支持ECH的伺服器上使用ECH。
去年 12 月，就有用戶反饋 Firefox Nightly 不再支持 ESNI