WebRTC洩漏IP位址的真相及其影響

Teh 更新時間 2024年12月12日

在過去的幾次討論中，我們提到了「WebRTC洩露您的IP位址」這一主題，尤其是在我報道《紐約時報》的相關行為以及我的WebRTC-Notifier時。這個主題時不時會在部落格圈中引發轟動，最近又有相關討論出現，因此我們來更新一下關於這一問題的看法。

VPN外洩問題的最新研究

最近，voidsec發布了一篇名為《VPN Leak》的部落格文章，強調在測試的100多款VPN服務中，有19款存在透過WebRTC洩漏IP位址的問題。這篇文章雖然在一些WebRTC的細節上不夠準確，但研究結果仍然引人關注。其核心是有人逐一測試了一長串服務的行為。雖然這個研究任務不算激動人心，但這樣的詳盡研究往往能發現一些有趣的東西。

WebRTC與代理程式的關係

谷歌WebRTC負責人Justin Uberti提到一個有趣的現象：許多被列為脆弱的服務都在名稱中包含「proxy」。很多這樣的服務其實是Chrome擴充程式。安裝其中一些擴充功能後發現，它們只是改變了代理設定。那麼，我們來看看WebRTC和代理的關係。

測試SOCKS代理

測試WebRTC在SOCKS代理後行為最簡單的方法是什麼？如果您安裝了ssh並且有一個可以測試的主機，這其實很簡單：

bash ssh -D localhost:3128 your-host

上述命令將在3128連接埠上執行一個本地SOCKS代理。然後更改Chrome或系統的代理設定以使用它。接下來運行提供的測試網站…

這將顯示我ssh連接的主機的IP位址以及我實際的公共IP位址。這讓我感到非常驚訝，因為我以為這個問題早已解決。

RTCWeb IP處理

WebRTC IP處理草案解釋了由於WebRTC允許網頁在ICE過程中枚舉IP位址而產生的問題，並規定了一些代表效能和隱私之間不同權衡的模式。模式4是最嚴格的，它在設定代理時阻止UDP：

模式4：強制使用代理：這與模式3相同，但所有WebRTC媒體流量都必須通過設定的代理。如果代理不支援UDP（如所有HTTP和大多數SOCKS [RFC1928]代理），或WebRTC實作不支援UDP代理，則會停用UDP，並使用TCP透過代理程式傳送和接收媒體。使用TCP將導致媒體品質下降，以及與透過代理伺服器發送所有WebRTC媒體相關的效能考量。

如何讓Chrome使用代理？

重新閱讀草案後發現，Chrome的行為符合規定，模式4並不是預設模式，因此不應期望它會自動路由到代理。

那麼… 是否有Chrome API可以使其依照模式4的規定行為？事實證明是有的：

webRTCIPHandlingPolicy

自Chrome 48起，使用者可以指定媒體效能/隱私權衡，這會影響WebRTC流量的路由以及暴露多少本地位址資訊。此首選項的值為IPHandlingPolicy，預設為default。

它有一個名為disable_non_proxied_udp的模式。自2016年1月發布的Chrome 48以來，這個API一直可用。

Chrome網路限制器擴充

最簡單的方式來更改此模式進行測試是使用WebRTC團隊在2015年底發布的網路限制器擴充。在選項中選擇：

使用我的代理伺服器（如果存在）

然後再次造訪測試網站。它將不再顯示WebRTC的本機IP位址：

洩漏停止！至少公共IP位址洩漏得到了遏制…

Firefox的設置

在Firefox中，有不同的設定可以讓使用者輕鬆更改：

media.peerconnection.ice.default_address_only – 將此設定為true基本上提供模式2。
media.peerconnection.ice.no_host – 將此設為true並與default_address_only一起使用則提供模式3。
media.peerconnection.ice.proxy_only – 將此設定為true強制使用模式4，停用UDP。