大家好,我卡頌。
最近,群里一個剛入職的小伙因為用公司電腦訪問奇怪的網站,被約談了。他很困惑 —— 訪問的都是HTTPS的網站,公司咋知道他訪問了啥?
實際上,由于網絡通信有很多層,即使加密通信,仍有很多途徑暴露你的訪問地址,比如:
除此之外,還有很多方式可以直接、間接知道你的網站訪問情況。
本文將聚焦在HTTPS協議本身,聊聊只考慮HTTPS協議的情況下,你的隱私是如何泄露的。
我們每天訪問的網站大部分是基于HTTPS協議的,簡單來說,HTTPS = HTTP + TLS,其中:
所以理論上,結合了HTTP和TLS特性的HTTPS,在數據傳輸過程是被加密的。但是,TLS建立連接的過程卻不一定是加密的。
當我們通過TLS傳遞加密的HTTP信息之前,需要先建立TLS連接,比如:
建立連接的過程被稱為「TLS握手」,根據TLS版本不同,握手的步驟會有所區別。
但總體來說,「TLS握手」是為了達到三個目的:
雖然TLS握手機制會建立安全的通信,但在握手初期,數據卻是明文發送的,這就造成「隱私泄漏」的風險。
在握手初期,客戶端、服務端會依次發送、接收對方的「打招呼信息」。首先,客戶端會向服務端打招呼(發送「client hello信息」),該消息包含:
服務端接收到上述消息后,會向客戶端打招呼(發送「server hello消息」),再回傳一些信息。
其中,SNI(Server Name Indication,服務器名稱指示)就包含了用戶訪問的網站域名。
那么,握手過程為什么要包含SNI呢?
這是因為,當多個網站托管在一臺服務器上并共享一個IP地址,且每個網站都有自己的SSL證書時,那就沒法通過IP地址判斷客戶端是想和哪個網站建立TLS連接,此時就需要「域名信息」輔助判斷。
打個比方,快遞員送貨上門時,如果快遞單只有收貨的小區地址(IP地址),沒有具體的門牌號(域名),那就沒法將快遞送到正確的客戶手上(與正確的網站建立TLS連接)。
所以,SNI作為TLS的擴展,會在TLS握手時附帶上域名信息。由于打招呼的過程是明文發送的,所以在建立HTTPS連接的過程中,中間人就能知道你訪問的域名信息。
企業內部防火墻的訪問控制和安全策略,就是通過分析SNI信息完成的。
雖然防火墻可能已經有授信的證書,但可以先分析SNI,根據域名情況再判斷要不要進行深度檢查,而不是對所有流量都進行深度檢查
那么,這種情況下該如何保護個人隱私呢?
Encrypted ClientHello[1](ECH)是TLS1.3的一個擴展,用于加密Client Hello消息中的SNI等信息。
當用戶訪問一個啟用ECH的服務器時,網管無法通過觀察SNI來窺探域名信息。只有目標服務器才能解密ECH中的SNI,從而保護了用戶的隱私。
當然,對于授信的防火墻還是不行,但可以增加檢查的成本
開啟ECH需要同時滿足:
比如,cloudflare SNI測試頁[2]支持ECH擴展,當你的瀏覽器不支持ECH時,訪問該網站sni會返回plaintext:
對于chrome,在chrome://flags/#encrypted-client-hello[3]中,配置ECH支持:
再訪問上述網站,sni如果返回encrypted則代表支持ECH。
雖然HTTPS連接本身是加密的,但在建立HTTPS的過程中(TLS握手),是有數據明文傳輸的,其中SNI中包含了服務器的域名信息。
雖然SNI信息的本意是解決「同一IP下部署多個網站,每個網站對應不同的SSL證書」,但也會泄漏「訪問的網站地址」。
ECH通過對TLS握手過程中的敏感信息(主要是SNI)進行加密,為用戶提供了更強的隱私保護。
[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。
本文鏈接:http://www.tebozhan.com/showinfo-26-5094-0.html都用HTTPS了,還能被查出瀏覽記錄?
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com