安全浏览协议如何未能保护用户隐私 - Trail of Bits博客

Trail of Bits博客
2019年10月30日
密码学

近期，安全研究人员发现苹果公司向腾讯发送所有中国用户的安全浏览数据。这一发现使得安全浏览协议的底层安全和隐私保障受到更严格审视。特别是，安全浏览声称通过提供所谓的k-匿名性来保护用户。本文将展示这种隐私定义在安全浏览上下文中某种程度上是无意义的。

在深入探讨k-匿名性为何不足之前，我们先来看看安全浏览协议的工作原理。

安全浏览如何工作？

早些时候，Google认为利用其对网络的了解向Web客户端提供恶意网站数据库会很有用。最初，用户会向Google提交其IP地址和相关URL，随后Google会对照恶意软件数据库进行检查。该方案称为查找API（Lookup API），至今仍可用。然而，人们很快对放弃如此多的隐私感到不安。这一合理关切导致了当前安全浏览方案（称为更新API（Update API））的开发，该方案被Google和腾讯使用。

从高层次看，Google维护一个恶意URL及其256位哈希的列表。为了在向浏览器分发此列表时节省带宽，他们只发送每个哈希的32位前缀。这意味着当用户的浏览器检查网站是否恶意时，可能会得到误报，因为许多256位URL哈希将包含相同的32位前缀。为了解决这个问题，如果发生匹配，浏览器将向Google发送相关的32位前缀，并获取包含该前缀的所有256位哈希的URL的完整列表。回顾一下，安全浏览更新API在用户每次尝试访问新URL时执行以下步骤：

1. 浏览器对URL进行哈希处理，并对照（本地）32位前缀列表进行检查。
2. 如果匹配，浏览器向Google发送32位前缀。
3. Google然后发回所有256位哈希包含该前缀的黑名单URL。
4. 如果更新后的列表中存在匹配，浏览器向用户发出警告。

直观上，这种安全浏览方案比原始方案更私密，因为Google只知道用户访问的每个潜在恶意网站的32位前缀。实际上，Google声称它为用户提供了所谓的k-匿名性——隐私分析师用来衡量识别信息唯一性的一种指标。让我们看看k-匿名性到底是什么，以及安全浏览在多大程度上满足这一定义。

什么是k-匿名性

传统上，k-匿名性被用于从数据库中移除个人识别信息。从高层次看，它涉及移除敏感数据，直到数据集中的每个人在特定特征上“看起来像”至少k个其他人。例如，如果我们有图1中的医疗记录表，我们可以修改姓名和年龄字段，使患者在姓名、年龄、性别和州方面实现2-匿名，如图2所示。

图1

任何试图使用此数据的人将获得执行某种统计分析所需的所有信息（表面上你的名字不会真正影响你患结核病的可能性），但数据库中的每个人将“看起来像”至少两个其他人。这样，试图去匿名化人们的攻击者将失败，因为他们无法区分看起来相似的三个条目。显然，k越大越好；如果攻击者是试图使用医疗数据作为提高保费理由的保险提供商，提供2-匿名性的数据库可能不够。在图2中，如果保险公司知道你在数据库中并且是来自加利福尼亚的52岁女性，他们将能够推断你患有癌症或心脏病，并开始向你收取更多费用。

图2

回到安全浏览：我们可以看到，将Google或腾讯可查看的URL限制为32位哈希前缀使得两个提供商都无法将你的请求与具有相同哈希前缀的任何其他URL区分开来。问题是，我们预计会发生多少次这样的碰撞？2015年，Gerbet等人得出结论，每个前缀在网络上大约出现14757次，这意味着安全浏览用户可以期望其浏览数据大致为14757-匿名。换句话说，Google/腾讯只知道你尝试访问的网站包含在大约14757个网站的集合中，这可能足够大以包含许多在政治（或商业）上不会非常暴露的通用网站。

为什么k-匿名性未能保护用户

尽管安全浏览满足k-匿名性的定义，但Google从这些查询中恢复你的浏览数据实际上并不难。这种不安全是由于k-匿名性的隐私保证没有考虑Google交叉引用多个安全浏览查询并缩小给定32位前缀对应特定网站的能力。

作为此类攻击的第一个例子，回想一下Google对安全浏览使用cookie，因此可以看到多个查询是否来自同一IP地址。现在，假设www.amazon.com和https://www.amazon.com/gp/cart/view.html?ref_=nav_cart与两个不同的恶意网站共享32位哈希前缀。如果用户快速连续访问Amazon和其购物车，Google将收到两个32位哈希前缀。由于用户不太可能连续访问两个不相关的恶意网站，Google可以合理确定他们在Amazon上购物。此攻击仅在两个相关网站都与恶意网站共享32位哈希前缀且用户在小时间窗口内访问它们时有效。然而，这个例子已经表明，当面对能够关联多个查询的对手时，k-匿名性并不是那么有用。

但情况实际上更糟，因为安全浏览协议经常强制用户同时提交几个高度相关的URL。这些多个查询的发生是因为许多URL在某种意义上“太具体”，Google无法跟踪，因为恶意网站创建新URL的速度比Google报告每个特定URL的速度快。为了解决这个问题，用户为每个查询提交一组“URL分解”，这是通过逐步剥离URL的部分来构建的。例如，当访问URL http://a.b.c/1/2时，浏览器将同时对照安全浏览数据库检查以下URL：

• a.b.c/1/2
• a.b.c/1/
• a.b.c/
• b.c/
• b.c/1/

使用完整的URL分解允许Google为用户提供高度信心，确保他们访问的网站不是恶意的。然而，一次性提交许多高度相关的32位哈希前缀破坏了安全浏览协议最初提供的大部分隐私。如果Google在同一查询中收到对应于a.b.c/和a.b.c/1的32位哈希前缀，它可以轻松去匿名化用户的浏览数据。即使在提交多个前缀不会导致完整URL恢复的情况下，也可能有足够的信息来了解用户浏览历史的敏感细节。

为了更具体，Gerbet等人表明，这种URL分解攻击可用于识别用户的色情内容偏好——压迫性政府肯定有兴趣监控这一点。更糟糕的是，由于这些恶意软件数据库未公开，很难确定哈希前缀是否未被恶意包含以跟踪用户。虽然我们可能信任Google不会操纵数据库以确定用户何时访问亲香港网站，但很容易想象腾讯会利用此漏洞。

展望未来

虽然安全浏览无疑为用户提供了真正的安全好处，但它未能保护他们免受想要监控其浏览习惯的公司或政府的侵害。不幸的是，这种隐私缺乏被协议为用户提供的弱但技术上精确的匿名性概念所掩盖。随着技术界和法律界围绕k-匿名性和差分隐私等工具团结起来，我们需要记住它们不是一刀切的技术，理论上满足此类定义的系统在实际部署时可能无法提供任何真正有意义的隐私。

如果你考虑在应用程序中使用差分隐私或k-匿名性等工具，我们的密码学服务团队可以帮助你驾驭这些系统固有的微妙之处。无论你需要协议设计帮助还是审计现有代码库，我们的团队都可以帮助你构建用户能够信任的东西。

如果你喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News

页面内容

• 安全浏览如何工作？
• 什么是k-匿名性
• 为什么k-匿名性未能保护用户
• 展望未来

近期文章

• 我们构建了MCP一直需要的安全层
• 利用废弃硬件中的零日漏洞
• 深入EthCC[8]：成为智能合约审计员
• 使用Vendetect大规模检测代码复制
• 构建安全消息传递很难：对Bitchat安全辩论的细致看法

© 2025 Trail of Bits。 使用Hugo和Mainroad主题生成。