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 保持在代理之内的浏览器,“未暴露”并伴有一些被屏蔽的候选,是正常且健康的结果。与页面地址不同的公网地址,才是需要修复的问题。
