大家好，我卡頌。

最近，群里一個剛?cè)肼毜男』镆驗橛霉倦娔X訪問奇怪的網(wǎng)站，被約談了。他很困惑 —— 訪問的都是HTTPS的網(wǎng)站，公司咋知道他訪問了啥？

實際上，由于網(wǎng)絡(luò)通信有很多層，即使加密通信，仍有很多途徑暴露你的訪問地址，比如：

• DNS查詢：通常DNS查詢是不會加密的，所以，能看到你DNS查詢的觀察者（比如運(yùn)營商）是可以推斷出訪問的網(wǎng)站
• IP地址：如果一個網(wǎng)站的IP地址是獨(dú)一無二的，那么只需看到目標(biāo) IP地址，就能推斷出用戶正在訪問哪個網(wǎng)站。當(dāng)然，這種方式對于多網(wǎng)站共享同一個IP地址（比如CDN）的情況不好使
• 流量分析：當(dāng)訪問一些網(wǎng)站的特定頁面，可能導(dǎo)致特定大小和順序的數(shù)據(jù)包，這種模式可能被用來識別訪問的網(wǎng)站
• cookies或其他存儲：如果你的瀏覽器有某個網(wǎng)站的cookies，顯然這代表你曾訪問過該網(wǎng)站，其他存儲信息（比如localStorage）同理

除此之外，還有很多方式可以直接、間接知道你的網(wǎng)站訪問情況。

本文將聚焦在HTTPS協(xié)議本身，聊聊只考慮HTTPS協(xié)議的情況下，你的隱私是如何泄露的。

HTTPS簡介

我們每天訪問的網(wǎng)站大部分是基于HTTPS協(xié)議的，簡單來說，HTTPS = HTTP + TLS，其中：

• HTTP是一種應(yīng)用層協(xié)議，用于在互聯(lián)網(wǎng)上傳輸超文本（比如網(wǎng)頁內(nèi)容）。由于HTTP是明文傳遞，所以并不安全
• TLS是一種安全協(xié)議。TLS在傳輸層對數(shù)據(jù)進(jìn)行加密，確保任何敏感信息在兩端（比如客戶端和服務(wù)器）之間安全傳輸，不被第三方竊取或篡改

所以理論上，結(jié)合了HTTP和TLS特性的HTTPS，在數(shù)據(jù)傳輸過程是被加密的。但是，TLS建立連接的過程卻不一定是加密的。

TLS的握手機(jī)制

當(dāng)我們通過TLS傳遞加密的HTTP信息之前，需要先建立TLS連接，比如：

• 當(dāng)用戶首次訪問一個HTTPS網(wǎng)站，瀏覽器開始查詢網(wǎng)站服務(wù)器時，會發(fā)生TLS連接
• 當(dāng)頁面請求API時，會發(fā)生TLS連接

建立連接的過程被稱為「TLS握手」，根據(jù)TLS版本不同，握手的步驟會有所區(qū)別。

但總體來說，「TLS握手」是為了達(dá)到三個目的：

• 協(xié)商協(xié)議和加密套件：通信的兩端確認(rèn)接下來使用的TLS版本及加密套件。
• 驗證省份：為了防止“中間人”攻擊，握手過程中，服務(wù)器會向客戶端發(fā)送其證書，包含服務(wù)器公鑰和證書授權(quán)中心（即CA）簽名的身份信息?？蛻舳丝梢允褂眠@些信息驗證服務(wù)器的身份。
• 生成會話密鑰：生成用于「加密接下來數(shù)據(jù)傳輸」的密鑰。

TLS握手機(jī)制的缺點(diǎn)

雖然TLS握手機(jī)制會建立安全的通信，但在握手初期，數(shù)據(jù)卻是明文發(fā)送的，這就造成「隱私泄漏」的風(fēng)險。

在握手初期，客戶端、服務(wù)端會依次發(fā)送、接收對方的「打招呼信息」。首先，客戶端會向服務(wù)端打招呼（發(fā)送「client hello信息」），該消息包含：

• 客戶端支持的TLS版本
• 支持的加密套件
• 一串稱為「客戶端隨機(jī)數(shù)」（client random）的隨機(jī)字節(jié)
• SNI等一些服務(wù)器信息

服務(wù)端接收到上述消息后，會向客戶端打招呼（發(fā)送「server hello消息」），再回傳一些信息。

其中，SNI（Server Name Indication，服務(wù)器名稱指示）就包含了用戶訪問的網(wǎng)站域名。

那么，握手過程為什么要包含SNI呢？

這是因為，當(dāng)多個網(wǎng)站托管在一臺服務(wù)器上并共享一個IP地址，且每個網(wǎng)站都有自己的SSL證書時，那就沒法通過IP地址判斷客戶端是想和哪個網(wǎng)站建立TLS連接，此時就需要「域名信息」輔助判斷。

打個比方，快遞員送貨上門時，如果快遞單只有收貨的小區(qū)地址（IP地址），沒有具體的門牌號（域名），那就沒法將快遞送到正確的客戶手上（與正確的網(wǎng)站建立TLS連接）。

所以，SNI作為TLS的擴(kuò)展，會在TLS握手時附帶上域名信息。由于打招呼的過程是明文發(fā)送的，所以在建立HTTPS連接的過程中，中間人就能知道你訪問的域名信息。

企業(yè)內(nèi)部防火墻的訪問控制和安全策略，就是通過分析SNI信息完成的。

雖然防火墻可能已經(jīng)有授信的證書，但可以先分析SNI，根據(jù)域名情況再判斷要不要進(jìn)行深度檢查，而不是對所有流量都進(jìn)行深度檢查

那么，這種情況下該如何保護(hù)個人隱私呢？

Encrypted ClientHello

Encrypted ClientHello[1]（ECH）是TLS1.3的一個擴(kuò)展，用于加密Client Hello消息中的SNI等信息。

當(dāng)用戶訪問一個啟用ECH的服務(wù)器時，網(wǎng)管無法通過觀察SNI來窺探域名信息。只有目標(biāo)服務(wù)器才能解密ECH中的SNI，從而保護(hù)了用戶的隱私。

當(dāng)然，對于授信的防火墻還是不行，但可以增加檢查的成本

開啟ECH需要同時滿足：

• 服務(wù)器支持TLS的ECH擴(kuò)展
• 客戶端支持ECH

比如，cloudflare SNI測試頁[2]支持ECH擴(kuò)展，當(dāng)你的瀏覽器不支持ECH時，訪問該網(wǎng)站sni會返回plaintext：

對于chrome，在chrome://flags/#encrypted-client-hello[3]中，配置ECH支持：

再訪問上述網(wǎng)站，sni如果返回encrypted則代表支持ECH。

總結(jié)

雖然HTTPS連接本身是加密的，但在建立HTTPS的過程中（TLS握手），是有數(shù)據(jù)明文傳輸?shù)?，其中SNI中包含了服務(wù)器的域名信息。

雖然SNI信息的本意是解決「同一IP下部署多個網(wǎng)站，每個網(wǎng)站對應(yīng)不同的SSL證書」，但也會泄漏「訪問的網(wǎng)站地址」。

ECH通過對TLS握手過程中的敏感信息（主要是SNI）進(jìn)行加密，為用戶提供了更強(qiáng)的隱私保護(hù)。

參考資料

[1]Encrypted ClientHello:https://blog.cloudflare.com/encrypted-client-hello/。

[2]cloudflare SNI測試頁:https://crypto.cloudflare.com/cdn-cgi/trace。

[3]chrome://flags/#encrypted-client-hello:chrome://flags/#encrypted-client-hello。