兩年前為了更好地保護用戶隱私，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