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

Trail of Bits博客
安全浏览如何未能保护用户隐私
Trail of Bits
2019年10月30日
密码学

近期，安全研究人员发现苹果将所有中国用户的安全浏览数据发送给腾讯。这一发现使得安全浏览协议的底层安全和隐私保障受到更严格的审查。特别是，安全浏览声称通过提供所谓的k-匿名性来保护用户。在本文中，我们将展示这种隐私定义在安全浏览的背景下有些无意义。在深入探讨k-匿名性为何不足之前，让我们先看看安全浏览协议的工作原理。

安全浏览如何工作？

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

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

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

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

什么是k-匿名性

传统上，k-匿名性被用于从数据库中删除个人识别信息。从高层次看，它涉及删除敏感数据，直到数据集中的每个人在特定特征上“看起来像”至少k其他人。例如，如果我们有图1中的医疗记录表，我们可以修改Name和Age字段，使患者在Name、Age、Gender和State方面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-匿名性未能保护用户
展望未来

近期文章
构建安全消息传递很难：对Bitchat安全辩论的 nuanced 看法
用Deptective调查你的依赖项
系好安全带，Buttercup，AIxCC的评分回合正在进行中！
使你的智能合约超越私钥风险成熟
Go解析器中意外的安全隐患

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