都用HTTPS了,還能被查出瀏覽記錄?
最近,群里一個剛?cè)肼毜男』镆驗橛霉倦娔X訪問奇怪的網(wǎng)站,被約談了。他很困惑 —— 訪問的都是HTTPS
的網(wǎng)站,公司咋知道他訪問了啥?
實際上,由于網(wǎng)絡(luò)通信有很多層,即使加密通信,仍有很多途徑暴露你的訪問地址,比如:
DNS
查詢:通常DNS
查詢是不會加密的,所以,能看到你DNS
查詢的觀察者(比如運營商)是可以推斷出訪問的網(wǎng)站IP
地址:如果一個網(wǎng)站的IP
地址是獨一無二的,那么只需看到目標(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é)議的情況下,你的隱私是如何泄露的。
歡迎圍觀朋友圈、加入人類高質(zhì)量前端交流群,帶飛
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ù)進行加密,確保任何敏感信息在兩端(比如客戶端和服務(wù)器)之間安全傳輸,不被第三方竊取或篡改
所以理論上,結(jié)合了HTTP
和TLS
特性的HTTPS
,在數(shù)據(jù)傳輸過程是被加密的。但是,TLS
建立連接的過程卻不一定是加密的。
TLS的握手機制
當(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握手機制的缺點
雖然TLS
握手機制會建立安全的通信,但在握手初期,數(shù)據(jù)卻是明文發(fā)送的,這就造成隱私泄漏的風(fēng)險。
在握手初期,客戶端、服務(wù)端會依次發(fā)送、接收對方的打招呼信息。首先,客戶端會向服務(wù)端打招呼(發(fā)送client hello信息),該消息包含:
客戶端支持的
TLS
版本支持的加密套件
一串稱為客戶端隨機數(shù)(
client random
)的隨機字節(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
的擴展,會在TLS
握手時附帶上域名信息。由于打招呼的過程是明文發(fā)送的,所以在建立HTTPS
連接的過程中,中間人就能知道你訪問的域名信息。
企業(yè)內(nèi)部防火墻的訪問控制和安全策略,就是通過分析SNI
信息完成的。
雖然防火墻可能已經(jīng)有授信的證書,但可以先分析
SNI
,根據(jù)域名情況再判斷要不要進行深度檢查,而不是對所有流量都進行深度檢查
那么,這種情況下該如何保護個人隱私呢?
Encrypted ClientHello
Encrypted ClientHello(ECH
)是TLS
1.3的一個擴展,用于加密Client Hello
消息中的SNI
等信息。
當(dāng)用戶訪問一個啟用ECH
的服務(wù)器時,網(wǎng)管無法通過觀察SNI
來窺探域名信息。只有目標(biāo)服務(wù)器才能解密ECH
中的SNI
,從而保護了用戶的隱私。
當(dāng)然,對于授信的防火墻還是不行,但可以增加檢查的成本
開啟ECH
需要同時滿足:
服務(wù)器支持
TLS
的ECH
擴展客戶端支持
ECH
比如,cloudflare SNI測試頁支持ECH
擴展,當(dāng)你的瀏覽器不支持ECH
時,訪問該網(wǎng)站sni
會返回plaintext
:
對于chrome
,在chrome://flags/#encrypted-client-hello中,配置ECH
支持:
再訪問上述網(wǎng)站,sni
如果返回encrypted
則代表支持ECH
。
總結(jié)
雖然HTTPS
連接本身是加密的,但在建立HTTPS
的過程中(TLS
握手),是有數(shù)據(jù)明文傳輸?shù)?,其?code>SNI中包含了服務(wù)器的域名信息。
雖然SNI
信息的本意是解決同一IP下部署多個網(wǎng)站,每個網(wǎng)站對應(yīng)不同的SSL證書,但也會泄漏訪問的網(wǎng)站地址。
ECH
通過對TLS
握手過程中的敏感信息(主要是SNI
)進行加密,為用戶提供了更強的隱私保護。