不加密,不加密的wifi

不加密

加密SNI，連同Cloudflare已經免費提供的其他互聯網安全功能，將使在互聯網上（惡意）檢查內容和跟蹤用戶變得更加困難。繼續往下讀，來了解它是如何工作的吧。

為什么需要SNI

TLS服務器名稱指示（SNI）擴展最初是在2003年標準化的，它允許服務器在同一組IP地址上托管多個啟用了TLS的站點，要求客戶端在初始TLS握手期間指定要連接到哪個站點。例如，如果沒有SNI，服務器就不知道要向客戶端提供哪個證書，或者要向連接應用什么配置。

客戶端將包含其連接到的站點主機名的SNI擴展添加到ClientHello消息。它在TLS握手期間將ClientHello發國際快遞服務器。不幸的是，由于客戶端和服務器此時不共享加密密鑰，因此ClientHello消息未被加密發快遞。

TLS 1.3 with Unencrypted SNI

這意味著該網路上的觀察者（例如互聯網服務提供商、咖啡店老板或防火墻）可以攔截明文ClientHello消息，并確定客戶端要連接到哪個網站。這使得觀察者可以跟蹤用戶正在訪問的站點。

但是，使用了SNI加密，即使ClientHello的其余部分以明文形式發快遞，客戶端也會加密SNI。

TLS 1.3 with Encrypted SNI

那么為什么以前無法對原始SNI進行加密，現在卻又可以加密了呢如果客戶端和服務器尚未協商，加密密鑰又從何而來

如果必須先有雞后有蛋，那么你的雞又在哪里呢

與許多其他Internet功能一樣，答案就是“DNS”。

服務器在已知的DNS記錄上發布一個公鑰，客戶端可以在連接之前獲取該公鑰（A、AAAA和其他記錄已經是這樣做的了）。然后，客戶端將ClientHello中的SNI擴展替換為“加密的SNI”擴展，該擴展不同于原來的SNI擴展，而是使用對稱加密密鑰（用服務器公共密鑰派生的密鑰）進行加密的，如下所述。擁有私鑰的服務器也可以派生對稱加密密鑰，然后可以解密擴展并終止連接（或將其轉發到后端服務器）。因為只有客戶端和它所連接的服務器可以派生加密密鑰，所以加密的SNI不能被第三方解密和訪問。

請務必注意，這是TLS 1.3及更高版本的擴展，不適用于該協議的早期版本。原因很簡單：TLS 1.3引入的一項更改（存在問題）內容是將服務器發快遞的證書消息移至TLS握手的加密部分（這在1.3之前是以明文形式發快遞的）。如果沒有對協議進行根本性的更改，攻擊者仍然可以通過簡單地觀察在網絡上發快遞的明文證書來確定服務器的身份。

底層加密機制涉及使用DiffieHellman密鑰交換算法，該算法允許客戶端和服務器在不受信任的通道上生成共享密鑰。因此，已加密的SNI加密密鑰是在客戶端上計算得出的，通過使用服務器的公共密鑰（實際上是DiffieHellman半靜態密鑰共享的公共部分）和由服務器生成的臨時DiffieHellman共享的私有部分（動態地由客戶端本身生成，且在ClientHello發國際快遞服務器后立即被丟棄）。額外的數據（例如客戶端作為其ClientHello消息的一部分發快遞的一些加密參數）也混合到加密過程中，以達到更好的加密效果。

然后，客戶端的ESNI擴展將不僅包括實際的加密SNI位，還包括客戶端的公鑰共享，用于加密的密碼套件以及服務器的ESNI DNS記錄的摘要。另一方面，服務器使用其自己的私鑰共享和客戶端共享的公共部分來生成加密密鑰并解密擴展。

雖然這看起來可能過于復雜，但這可以確保加密密鑰以密碼方式綁定到為其生成的特定TLS會話，并且不能跨多個連接重復使用。這樣可以防止攻擊者觀察到客戶端發快遞的加密擴展，從而避免攻擊者在單獨的會話中捕獲它并將其重新放到服務器，暴露用戶試圖連接到的網站的身份（這被稱為“剪切和粘貼”攻擊）。

然而，服務器私鑰的妥協將危及派生自服務器私鑰的所有ESNI對稱密鑰（這將使觀察者可以解密以前收集的加密數據），這就是為什么Cloudflare的SNI加密執行每小時輪轉服務器秘鑰以提高安全性，但同時也會跟蹤幾個小時前的秘鑰，以便DNS完成緩存和響應延遲。因此，密鑰稍微過時的客戶端仍然可以毫無問題地使用ESNI（但最終所有密鑰都會被丟棄和遺忘）。

但先等等，DNS說真的

細心的讀者可能已經意識到，僅使用DNS（默認情況下為未加密）將使整個加密SNI的想法完全沒有意義：路徑上的觀察者將能夠簡單地通過觀察客戶端本身發快遞的純文本DNS查詢來確定客戶端連接到哪個網站，無論連接中是否使用了加密的SNI。

但是隨著DNS的一些特性的引入，例如DNS over TLS（DoT）以及DNS over HTTPS（DoH），以及有向用戶提供這些特性的公共DNS解析器（例如Cloudflare自己的1.1.1.1），DNS查詢現在可以被加密并且防止被觀察者和追蹤者窺視。

然而，盡管在一定程度上（因為仍存在有害的解析器）來自DoT/DoH DNS解析器的請求是可以被信任的，但一個下定決心的攻擊者仍然有可能通過攔截解析器與權威DNS服務器的通信并注入惡意數據來毒害解析器的緩存。也就是說，除非權威服務器和解析器都支持DNSSEC [1]，DNS解析器的請求才可以被信任。順便說一句，Cloudflare的權威DNS服務器可以對返回給解析器的響應進行簽名，而1.1.1.1解析器可以驗證這些響應。

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。