WebRTC 洩漏:為什麼即使使用代理,你的真實位址仍可能曝光
WebRTC 的存在,是為了讓瀏覽器之間能直接通話與分享螢幕。為此,它們需要找出自己可被連上的位址,而這個探索過程,正是所謂「WebRTC 洩漏」所指的對象。
用一段話說明 ICE 候選
當頁面建立 RTCPeerConnection 並開始發出 offer 時,瀏覽器會蒐集候選:其他對等端可能用來連上它的方式。host 候選是本機網路介面的位址。server-reflexive(srflx)候選,則是 STUN 伺服器看到請求來自的公開位址。relay 候選是 TURN 伺服器的位址。每個候選都會以一行包含位址的文字交給頁面,腳本因此得以讀取它,完全不需要真的進行任何通話。
洩漏發生在哪裡
重要的是 srflx 候選。為了取得它,瀏覽器會向 STUN 伺服器傳送一個小型 UDP 封包,伺服器則回覆它所看到的位址。如果你的 HTTP 流量經過代理,但 UDP 流量沒有,STUN 伺服器看到的就是你的真實連線,頁面現在也得到了一個與網頁伺服器所看到的不一致的位址。這種不一致正是典型的洩漏。診斷頁面可以透過比較兩者來呈現這一點。
請注意哪些事情有發生、哪些沒有。沒有擷取任何媒體,也不涉及任何麥克風或相機權限。封包會送往頁面指定的任何 STUN 伺服器,因此該伺服器和你連線的任何伺服器一樣,看得到你的位址。
瀏覽器改變了什麼
過去,host 候選會暴露像 192.168.1.23 這樣的私有區域網路位址,這對辨識家用網路的指紋很有用。現代瀏覽器會把它們換成以 .local 結尾、隨機產生的 mDNS 名稱,因此頁面看到的是不透明的名稱,而不是位址。診斷工具回報「已由瀏覽器遮蔽」時,說的就是這類情況。Firefox 與 Brave 也提供設定,可阻止在代理之外蒐集候選,有些擴充功能則會完全封鎖 WebRTC。
對代理安全的設定
有三種做法可行,代價各不相同。停用 WebRTC 能避免洩漏,但會讓所有需要它的網站無法運作。強制 WebRTC 只使用代理的路徑(部分瀏覽器中的「對代理安全」模式),在代理支援 UDP 或 TURN 時可維持通話運作,否則就完全不會產生公開候選。讓 WebRTC 照常運作,只有在代理承載所有流量時才正確,系統層級的 VPN 通常就是如此。
哪一種才正確,取決於工作內容。對於必須看起來位於單一地點的隔離瀏覽器設定檔,規則很簡單:WebRTC 所暴露的位址,必須與網頁伺服器所看到的位址相同,否則就完全不要暴露。除此之外的任何情況,都是網站不需要任何特殊工具就能察覺的矛盾。
解讀結果
診斷會顯示它在幾秒內觀察到的候選,並將其中任何公開位址與頁面被連上時的位址相比較。「未暴露」加上一些已遮蔽的候選,對於將 WebRTC 限制在代理內的瀏覽器來說,是正常且健康的結果。若公開位址與頁面的位址不同,就是需要修正的問題。
