Apple的iCloud Private Relay,官方说明书上写得明明白白——它不是VPN,只保护Safari网页浏览、DNS解析和未加密HTTP连接这三类流量。但很少有用户真去读那份说明书。多数人打开这个开关,以为自己从此在网上"隐身"了。

8月5日,安全研究员Talal Haj BakryTommy Mysk抛出一个说法:WebKit里的三个功能能绕过Private Relay,把用户真实IP原样暴露。他们还搭了个测试网站,TechCrunch实测确认,自己的IP确实能被看到。这事听起来像一次重大漏洞,但拆开看,水没那么浅,也没那么深。

双中继架构,以及苹果早就画好的边界

Private Relay的设计思路是双中继:入口中继由Apple运营,知道你是谁,但不知道你去哪;出口中继由第三方运营,知道你去哪,但不知道你是谁。两边都拼不出完整画像,这套逻辑从2021年随iCloud+推出起就没变过。

官方文档写得直白:它只保护Safari网页浏览、DNS查询、应用产生的未加密HTTP连接,不覆盖App的全部加密流量、本地网络、蜂窝相关服务,也不能让你伪装成别的国家。企业和学校网络主动屏蔽Private Relay,这也是苹果自己列出的已知限制之一。

换句话说,苹果从一开始就没打算让它替代VPN。

Private Relay 双中继架构 用户设备 真实IP 入口中继(Apple) 知道IP 不知目的地 出口中继(第三方) 知道目的地 不知IP 目标 网站 覆盖范围 Safari网页浏览 · DNS解析 · 未加密HTTP 不覆盖 App全部加密流量 · 本地网络 · 蜂窝服务(彩信/热点/语音信箱) 数据来源:Apple官方文档

三个WebKit功能:漏洞还是被重新包装的局限

研究者说问题出在WebKit的三个功能上,iOS所有浏览器都基于WebKit,理论上不止Safari受影响。档案信息显示,被提到的路径很可能包括WebRTC——这条路径在安全圈不算新闻,WebRTC走ICE/STUN协商时经常绕开为HTTP流量设计的代理层,不少VPN和代理产品都在这上面栽过跟头,技术上完全可信。

但另一条路径涉及WebSocket,理论上应该走Safari的合规HTTPS网络栈。如果它真的绕过了Private Relay,那才是意料之外的新缺陷。目前没有第三方复现,没有抓包记录或服务器端连接日志佐证,苹果也没发布安全公告或CVE。两条路径的证据强度并不对等,报道把它们打包成"三个WebKit功能导致泄露",听起来像一次系统性坍塌,拆开看可能是一条老问题加一条尚待验证的新说法。

WebRTC漏水是老账,WebSocket漏水才是新闻——但新闻部分证据还没交齐。
两条泄露路径,证据不对等 WebRTC路径 ICE/STUN常见绕行方式 行业内已知问题 技术可信 老账 WebSocket路径 无独立复现 无抓包/日志证据 无官方确认 待验证

不通报苹果,顺手卖自己的浏览器

Mysk公开表示,选择不走负责任披露流程,直接发博客加建测试站,理由是过去跟苹果打交道经常遇到数月拖延、沟通模糊,甚至被否认问题存在。这个理由在安全研究圈不算新鲜,不少人对大厂的漏洞响应流程失去信任,转而选择"先公开、后追责"。

但同时要看到,Mysk和同事开发的隐私浏览器Psylo,借着这次曝光顺势宣布"已加入缓解措施"。一边说苹果的产品有洞,一边说自己的产品已经补好,这两句话摆在同一个时间点上,很难让人完全排除产品背书的意图。

  • 风险.普通用户若把这次曝光当成"Private Relay已被攻破"的定论,转而全额信任一个新面孔的隐私浏览器,可能只是换了一个更难核查的信任对象。

对iCloud+订阅用户来说,真正该记住的是苹果官方从没承诺过的那件事:Private Relay不管App流量、不管本地网络、不管蜂窝服务,这些从2021年推出起就写在文档里,不是这次才冒出来的新漏洞。如果你需要的是全流量隐藏,该用VPN,这次事件之前就该这么用。

真正值得盯的,是WebSocket那条路径最终有没有独立复现、苹果会不会给出正式回应。坐实了,那是WebKit的新麻烦;没坐实,这次爆料更像是借着大厂拖延症的口碑,把一份已知的局限重新包了层"泄露"的名字。名不正则言不顺,这次"漏洞"二字,用得有点急。