不加密,不加密的wifi

不加密

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

為什么需要SNI

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

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

TLS 1.3 with Unencrypted SNI

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

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

TLS 1.3 with Encrypted SNI

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

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

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

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

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

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

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

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

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

但先等等，DNS說(shuō)真的

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

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

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

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