中國已開始阻止使用 TLS 1.3 和 ESNI 建立的 HTTPS 連接

中國 實施的 阻塞 所有使用 TLS 1.3 協定和 ESNI（加密伺服器名稱指示）TLS 擴展的 HTTPS 連接，該擴充功能提供有關所請求主機的資料加密。 對於從中國到外界以及從外界到中國建立的連接，都會在中轉路由器上進行阻止。

阻止是透過將封包從客戶端丟棄到伺服器來完成的，而不是先前由 SNI 內容選擇性阻止執行的 RST 封包替換。 當觸發 ESNI 封包後，來源 IP、目的 IP 和目的連接埠號碼組合對應的所有網路封包也會被封鎖 120 到 180 秒。 基於舊版 TLS 和 TLS 1.3（不含 ESNI）的 HTTPS 連線照常允許通過。

讓我們回想一下，為了在多個 HTTPS 站點的一個 IP 位址上組織工作，開發了 SNI 擴展，該擴展在安裝加密通訊通道之前傳輸的 ClientHello 訊息中以明文形式傳輸主機名稱。 此功能使得網路供應商可以選擇性地過濾 HTTPS 流量並分析使用者開啟的網站，但在使用 HTTPS 時無法實現完全保密。

新的 TLS 擴充 ECH（以前稱為 ESNI）可與 TLS 1.3 結合使用，消除了此缺點，並完全消除了分析 HTTPS 連線時所請求網站的資訊外洩。 與透過內容交付網路進行存取相結合，ECH/ESNI 的使用還可以向提供者隱藏所要求資源的 IP 位址。 流量檢查系統只會看到 CDN 的請求，並且無法在沒有 TLS 會話欺騙的情況下套用阻止，在這種情況下，有關憑證欺騙的相應通知將顯示在使用者的瀏覽器中。 DNS 仍然是可能的洩漏管道，但用戶端可以使用 DNS-over-HTTPS 或 DNS-over-TLS 來隱藏用戶端的 DNS 存取。

研究人員已經 透露 有幾種解決方法可以繞過客戶端和伺服器端的中文阻止，但它們可能變得無關緊要，只能被視為臨時措施。 例如，目前僅包含 ESNI 擴充 ID 0xffce（加密伺服器名稱）的資料包，該資料包用於 標準草案第五版，但目前封包的目前識別碼為 0xff02 (encrypted_client_hello)，建議在 ECH 規範第七稿.

另一種解決方法是使用非標準連接協商過程，例如，如果提前發送序號不正確的附加SYN 資料包，則阻塞不起作用、使用資料包碎片標誌進行操作、發送同時包含FIN 和SYN 的數據包設定標誌、以不正確的控制量取代 RST 資料包或在使用 SYN 和 ACK 標誌的資料包連接協商開始之前發送。 所描述的方法已經以工具包插件的形式實現 日內瓦, 發達 繞過審查方法。

來源： opennet.ru