Mozilla 宣布已為 Firefox 穩定版用戶啟用對 ECH（加密用戶端問候）機制的支持，該機制繼續開發 ESNI（加密伺服器名稱指示）技術，旨在對有關 TLS 會話參數的資訊（例如請求的網域名稱）進行加密。處理 ECH 的程式碼最初是在 Firefox 85 中新增的，但預設已停用。 Chrome 自 Chrome 115 發布以來一直在逐步增加對 ECH 的支援。
除了與…聯繫 服務器 請求的網域資訊會透過 DNS 洩漏。為了獲得全面保護，除了 ECH 之外，您還必須使用 DNS over HTTPS 或 DNS over TLS 來加密 DNS 流量。如果您未在設定中啟用 DNS over HTTPS，Firefox 將無法使用 ECH。您可以在此頁面上檢查您的瀏覽器是否支援 ECH。
Firefox 預設啟動 ECH 支援的因素之一是 Cloudflare 幾天前在其內容交付網路中包含了 ECH 支援。從實際角度來看，由於使用 ECH 時有關請求主機的資料對分析是隱藏的，因此使用 Cloudflare CDN 過濾和阻止不需要的網站現在需要阻止整個 Cloudflare 網路、阻止所有使用 ECH 的請求，或者在使用者的系統上使用偽根憑證組織 HTTPS 攔截。
最初，為了在一個 IP 位址上組織多個 HTTPS 網站的工作，使用了 SNI TLS 擴展，其中在建立加密通訊通道之前傳輸的 ClientHello 訊息中指示了所請求主機的名稱。此功能使得在連接處理的早期階段跨虛擬主機分發請求成為可能，但它也允許互聯網提供商選擇性地過濾 HTTPS 流量並分析用戶打開的網站，這使得在使用 HTTPS 時無法實現完全的保密性。
為了解決這個問題並防止洩漏所請求站點的信息，後來提出了 ESNI 擴展，透過主機名稱實現資料加密。 在 ESNI 的實施過程中，人們發現所提出的機制並沒有涵蓋所有可能的主機資料外洩來源，且其使用不足以確保 HTTPS 會話的完全機密性。 特別是，當恢復先前建立的會話時，在PSK（預先共用金鑰）TLS擴充的參數中繼續指定明文網域。 此外，實施 ESNI 的努力已發現相容性和擴展問題，這些問題阻礙了 ESNI 的廣泛採用。
考慮到 ESNI 已發現的缺點，開發了一種新的通用 ECH 機制，允許對任何 TLS 擴充的參數進行加密。從技術上講，ECH 和 ESNI 之間的主要區別在於，它不是對單一欄位進行加密，而是對整個 ClientHello 訊息進行一次性加密。 ECH 涉及將 ClientHello 分成兩個單獨的訊息 - 加密的 ClientHelloInner（SNI Inner）訊息和未加密的基本 ClientHelloOuter（SNI Outer）訊息。未加密的 SNI Outer 攜帶非敏感數據，例如 TLS 版本和使用的密碼列表，以及與請求網域的實際名稱不重疊的通用網域。例如，對於所有 Cloudflare 用戶端，未加密的 SNI Outer 包含通用主機“cloudflare-ech.com”，而實際要求的主機名稱在加密的 SNI Inner 中傳輸，無法進行分析。
ECH 也採用了不同的加密金鑰分發方案：公鑰資訊透過 HTTPSSVC DNS 記錄而非 TXT 記錄進行傳輸。基於 HPKE（混合公鑰加密）機制的端對端認證加密用於取得和加密金鑰。 ECH 還支援從伺服器安全重傳金鑰，這可在金鑰輪換時使用。 服務器 並解決從 DNS 快取中檢索過期金鑰的問題。
來源： opennet.ru
