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。