不加密,不加密的wifi-ESG跨境

不加密,不加密的wifi

不加密

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

為什么需要SNI

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

客戶端將包含其連接到的站點(diǎn)主機(jī)名的SNI擴(kuò)展添加到ClientHello消息。它在TLS握手期間將ClientHello發(fā)國際快遞服務(wù)器。不幸的是，由于客戶端和服務(wù)器此時(shí)不共享加密密鑰，因此ClientHello消息未被加密發(fā)快遞。

TLS 1.3 with Unencrypted SNI

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

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

TLS 1.3 with Encrypted SNI

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

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

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

服務(wù)器在已知的DNS記錄上發(fā)布一個(gè)公鑰，客戶端可以在連接之前獲取該公鑰（A、AAAA和其他記錄已經(jīng)是這樣做的了）。然后，客戶端將ClientHello中的SNI擴(kuò)展替換為“加密的SNI”擴(kuò)展，該擴(kuò)展不同于原來的SNI擴(kuò)展，而是使用對稱加密密鑰（用服務(wù)器公共密鑰派生的密鑰）進(jìn)行加密的，如下所述。擁有私鑰的服務(wù)器也可以派生對稱加密密鑰，然后可以解密擴(kuò)展并終止連接（或?qū)⑵滢D(zhuǎn)發(fā)到后端服務(wù)器）。因?yàn)橹挥锌蛻舳撕退B接的服務(wù)器可以派生加密密鑰，所以加密的SNI不能被第三方解密和訪問。

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

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

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

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

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

但先等等，DNS說真的

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

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

然而，盡管在一定程度上（因?yàn)槿源嬖谟泻Φ慕馕銎鳎﹣碜訢oT/DoH DNS解析器的請求是可以被信任的，但一個(gè)下定決心的攻擊者仍然有可能通過攔截解析器與權(quán)威DNS服務(wù)器的通信并注入惡意數(shù)據(jù)來毒害解析器的緩存。也就是說，除非權(quán)威服務(wù)器和解析器都支持DNSSEC [1]，DNS解析器的請求才可以被信任。順便說一句，Cloudflare的權(quán)威DNS服務(wù)器可以對返回給解析器的響應(yīng)進(jìn)行簽名，而1.1.1.1解析器可以驗(yàn)證這些響應(yīng)。

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