0

所以你VPN泄露的原因是WebRTC?

已有 610 阅读此文人 - - 行业解读 -

–不应该怪罪WebRTC,而你们所谓的VPN才是元凶

作者:Philipp Hancke(原文链接

翻译:刘通

原标题:So your VPN is leaking because of Chrome’s WebRTC…

 

我们已经多次报道了“WebRTC泄露你IP地址”的相关问题。这个话题在博客中一次又一次的出现,每次都会带来巨大的震撼和恐慌。最近这种情况再次发生,所以本文时对这个所谓问题的观察更新。

leak1

最近voidsec的一篇名为VPN泄露的文章,重点指出了一百多个VPN服务中有十九个通过WebRTC泄露IP地址。虽然文章中关于WebRTC的一些细节并不完全正确,但是其中得到的结果仍然令人感兴趣。本质上就是一个人一个接一个地测试每个VPN服务,然后记录下它们的表现。这并不是一个让人感兴趣的研究,但像这样的详尽研究通常会发现一些有趣的结果。

Google WebRTC负责人Justin Uberti之处了一件有趣的事情:很多被列为易受攻击的服务都有名义上的“代理”。其中很多是Chrome扩展程序。安装其中的一些扩展程序仅仅是改变了代理设置。那么,让我们来看看WebRTC和代理。

测试SOCKS代理

测试WebRTC在SOCKS代理后的表现最简单的办法是什么呢?如果你安装了ssh并且主机使用它进行测试非常容易:

 

1ssh -D localhost:3128 your-host

 

上述指令在端口3128上运行本地SOCKS代理。更改你的Chrome或系统代理设置以使用它。现在运行提供的测试网站。

leak2

这显示了我登记的主机IP地址以及我的实际公共IP地址。这是非常令人惊讶的,我还以为这个问题我很久以前就解决了。

RTCWeb IP处理

WebRTC IP处理草案中解释了WebRTC引起的问题,允许网页列举IP地址作为 ICE过程的一部分,并指定了代表性和隐私之间不同权衡的多种模式。模式4是最严格的。它在代理设置时阻止UDP:

模式4:强制代理:这与模式3相同,但所有WebRTC媒体流量都通过代理(如果已配置)强制进行。 如果代理不支持UDP(就像所有HTTP和大多数SOCKS [RFC1928]代理一样),或者WebRTC实现不支持UDP代理,则UDP的使用将被禁用,并且TCP将用于发送和 通过代理接收媒体。 除了与通过代理服务器发送所有WebRTC媒体相关的任何性能考虑外,使用TCP将导致媒体质量下降。https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-06#section-5.2

如何让Chrome使用代理?

再读一遍草案,Chrome的行为与此处指定的相同,模式4不是默认模式,所以不应指望它自动路由到代理。

那么是否有Chrome API让它的行为与模式4中指定的一样?事实上有这项:

webRTCIPHandlingPolicy

从Chrome 48版本开始。

允许用户指定影响WebRTC流量路由方式的媒体性能/隐私权衡,以及公开多少本地地址信息。此首选项的值为IPHandlingPolicy类型,作为默认值。

https://developer.chrome.com/extensions/privacy#property-network

它有一个名为disable_non_proxied_udp的模式。 自2016年1月发布Chrome 48以来,该API已经可用。

Chrome网络限制器扩展(Network Limiter Extension)

切换到此模式进行测试的最简单方法是使用WebRTC团队在2015年底发布的Network Limiter扩展。在选项中选择:

leak3

然后再次进入测试网站。 它将不再显示来自WebRTC的本地IP地址:

leak4

不发生泄漏的情况了!至少只有公共IP地址会泄漏。

Firefox浏览器呢?

在Firefox中有不同的设置。扩展可以更改这些设置的about:config值,或者用户可以轻松地自行完成此操作:

# media.peerconnection. ice.default_address_only – 将此设置为true从本质上提供模式2

# media.peerconnection. ice.no_host – 设置此项及default_address_only提供模式3

# media.peerconnection. ice.proxy_only – 将其设置为true会强制改为模式4,且禁用UDP

确保你的VPN提供商使用浏览器的隐私设置

如果那些易受攻击的“VPN”提供商实际上使用Chrome提供的隐私选项,那么这种泄露有可能就会避免。

如果你是其中一个被列为易受攻击的扩展程序的开发人员,请务必使用可用的API。请注意,由此可能导致更多媒体流量通过你的代理服务器。如果你遇到这种情况的话,请不要在你的营销材料中将其错误地归咎于WebRTC。





加入WebRTC技术交流群,免费获得学习资料,交流经验
群号:659922087
q群
期待你一针见血的评论,Come on!

不用想啦,马上 "登录"  发表自已的想法.