SNI 檢查：審查者如何在 HTTPS 中看到你的目的地

想像你在郵寄一封信。信封上寫著收件人地址，郵差可以看到你寄往何處，即使信紙本身用密碼鎖定也一樣。HTTPS 就像那個密碼鎖——它加密了你與網站之間的對話內容——但信封上的地址仍然是可見的。那個地址就是 SNI，而許多國家的審查者利用這個漏洞來阻止人們訪問特定網站，即使他們使用了 HTTPS。

認識 SNI：網域名稱的明文洩露

SNI 是「伺服器名稱指示」(Server Name Indication) 的縮寫。當你的瀏覽器連接到一個網站時，在建立加密連線之前，它必須先告訴伺服器：「我想連接到 example.com。」這個訊息被稱為 TLS 握手的一部分，它以完全的明文形式發送——任何能看到你網路流量的人都可以讀取它。

為什麼需要在明文中發送？原因很實際。數十年前，網際網路上的大多數伺服器有獨立的 IP 位址，每個 IP 對應一個網站。但 IP 位址數量有限，而網站數量是無限的。所以網站託管公司開始在同一台伺服器上放置多個網站，所有網站共享一個 IP 位址。當你的瀏覽器連接到該 IP 時，伺服器不知道你想訪問哪個網站——除非你告訴它。這就是 SNI 的用途：在握手早期以明文形式宣告你的目的地。

這個設計在一個沒有普遍審查的網際網路中是合理的。但在實踐中，它成為了一個監視和阻止的切口點。

審查者如何使用 SNI 進行阻止

許多政府和網際網路服務供應商在網路的關鍵點監視 SNI 欄位。當他們看到連接到被列入黑名單的網域時，他們可以立即丟棄該連線，導致連接失敗。使用者看到的只是「無法連接到網站」的錯誤，可能永遠不會意識到是什麼被阻止了。

這種方法有幾個吸引審查者的特點：首先，它在應用層之下工作，這意味著它在你的瀏覽器甚至知道發生了什麼之前就阻止了連線。其次，它不需要檢查加密的內容——只需要讀一個明文欄位。第三，它很難繞過，因為 SNI 在加密開始前就被發送了。

已知使用 SNI 檢查進行網站阻止的國家包括中國、伊朗、俄羅斯和土耳其，儘管實施方法和廣泛程度各不相同。互聯網中立的國家也可能使用 SNI 檢查來執行法庭命令或網際網路服務供應商層級的過濾。

為什麼 HTTPS 加密沒有幫助

HTPTS 保護你的內容——瀏覽器傳送的內容、你填寫的表單、你訪問的網頁路徑。但它不保護你進行通訊的基本事實，即你連接到哪個域名。想像一個鎖著的箱子裝滿了信件：沒有人能打開箱子讀取信件，但他們可以看到箱子上寫著收件人的名字。SNI 就是那個標籤。

VPN 和代理確實隱藏 SNI，通過將所有連線路由到單一端點，審查者只能看到你連接到 VPN 伺服器的 IP，而不是最終的目的地。但這需要信任 VPN 營運商，也會改變你的流量路由和延遲。

修復：加密用戶端 Hello 和 ESNI

網際網路工程師已經為這個問題開發了解決方案：在 TLS 1.3 中引入的加密用戶端 Hello (Encrypted Client Hello, ECH)，以及早期的嘗試如加密伺服器名稱指示 (Encrypted SNI, ESNI)。

ECH 的概念很簡單：在發送 SNI 之前，你的瀏覽器使用伺服器的公鑰對整個握手的第一部分進行加密，包括 SNI。這樣，審查者只能看到你連接到的 IP，而不是網域名稱。

但採用很緩慢。雖然現代瀏覽器支援 ECH，但許多伺服器和網際網路基礎設施還沒有啟用它。中間人代理（在企業網路中監視流量的裝置）有時會乾擾 ECH。而且，啟用 ECH 需要網站所有者主動設定；沒有默認啟用它。

審查者也已經在適應。一些機構開始監視 ECH 流量的模式或流量量，試圖推斷被訪問的網站，儘管這遠不如直接檢查 SNI 可靠。

理解權衡

SNI 檢查是一個真實的安全問題，但沒有完美的解決方案。ECH 提高了隱私，但並非對所有連線都有效。VPN 隱藏 SNI，但引入了其他信任和效能考量。使用者應該瞭解自己使用的工具的限制，而不是假設 HTTPS 或任何單一技術提供完整的隱私。

關鍵是理解層級：加密保護內容，但不保護元數據——關於通訊本身的訊息。SNI 是元數據。完整的隱私需要在多個層級進行思考：你使用什麼網域、你的 IP 是什麼、你發送多少數據、何時發送。

下一步探索

SNI 檢查是網際網路審查如何運作的一個重要例子。要更深入地瞭解，你應該探索 TLS 握手本身的工作原理、DNS 和網域解析如何被審查者利用，以及不同國家實施審查的具體方法。最重要的是，記住：理解這些技術如何被使用是保護自己和他人的第一步。