这会保护我免受 Etag 跟踪吗？答案

【问题标题】：Will this protect me from Etag tracking?这会保护我免受 Etag 跟踪吗？
【发布时间】：2013-12-18 13:52:49
【问题描述】：

背景：ETag 跟踪在here 中得到了很好的解释，在Wikipedia 上也有提及。

answer 我在回复“如何防止 ETags 跟踪？”时写道。驱使我写这个问题。

我有一个阻止 ETag 跟踪的浏览器端解决方案。它无需修改当前的 HTTP 协议即可工作。 这是 ETag 跟踪的可行解决方案吗？

我们没有告诉服务器我们的 ETag我们向服务器询问它的 ETag，并将它与我们已有的进行比较。

伪代码：

If (file_not_in_cache)
{
    page=http_get_request();     
    page.display();
    page.put_in_cache();
}
else
{
    page=load_from_cache();
    client_etag=page.extract_etag();
    server_etag=http_HEAD_request().extract_etag();

    //Instead of saying "my etag is xyz",
    //the client says: "what is YOUR etag, server?"

    if (server_etag==client_etag)
    {
        page.display();
    }
    else
    {
        page.remove_from_cache();
        page=http_get_request();     
        page.display();
        page.put_in_cache();
    }
}

HTTP 对话示例与我的解决方案：

客户：

HEAD /posts/46328
host: security.stackexchange.com

服务器：

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
ETag: "EVIl_UNIQUE_TRACKING_ETAG"
Content-Type: text/html
Content-Length: 131

案例1，客户端有一个相同的ETag：

Connection closes, client loads page from cache.

案例 2，客户端的 ETag 不匹配：

GET...... //and a normal http conversation begins.

确实需要修改 HTTP 规范的附加功能

将以下内容视为理论材料，HTTP 规范可能不会很快改变。

1.移除 HEAD 开销

值得注意的是，开销很小，服务器必须发送两次 HTTP 标头：一次响应 HEAD，一次响应 GET。一个理论上的解决方法是修改 HTTP 协议并添加一种请求无标头内容的新方法。然后客户端将仅请求 HEAD，然后仅在 ETag 不匹配时才请求内容。

2。阻止基于缓存的跟踪（或至少使其变得更加困难）

虽然 Sneftel 建议的解决方法不是 ETag 跟踪技术，但它确实可以跟踪人们，即使他们使用我建议的“HEAD, GET”序列。解决方案是限制 ETag 的可能值：ETag 必须是内容的校验和，而不是任何序列。客户端对此进行检查，如果校验和值与服务器发送的值不匹配，则不使用缓存。

旁注： 修复 2 还将消除以下 Evercookie 跟踪技术：pngData、etagData、cacheData。将其与 Chrome 的“仅在我退出浏览器之前保留本地数据”相结合，消除了除 Flash 和 Silverlight cookie 之外的所有 evercookie 跟踪技术。

【问题讨论】：

鉴于您在 StackOverflow 上发布了此内容，您要解决的实际编程问题是什么？这似乎是对 cmets 和意见的请求，这不是 SO 的目的，并且可能会在“征求意见”的原因下结束您的问题。
我试图通过修改浏览器请求页面的方式来阻止 etag 跟踪。这是一个编程问题，因为实现它涉及修改浏览器的工作方式，而不是修改 HTTP 协议。我不是在征求意见，我是在寻求对此修复的客观反对意见，并寻找可能阻止此修复工作的缺陷。但是，这与安全和网络高度相关，我同意它可能更适合在不同的站点上。我只能等待 SO 人的决定。
我在问题中省略了“意见”一词。
你是如何实现load_from_cache()的？我不熟悉任何允许直接访问缓存的 JavaScript 机制。此外，如果您在 HEAD 请求中未提供 ETag 或任何 cookie（或任何其他标识您自己的方式），您可能会获得一个新的 ETag，这似乎与清除缓存一样有用.
注意这是伪代码，我还没有实现 load_from_cache。思路是修改浏览器的源码，这和Javascript无关。关于您的第二个论点：除非内容更改，否则不应该获得新的 Etag，无论您的 HEAD 请求如何。如果您为每个请求获取一个新的 Etag，那么服务器正在做一些令人讨厌的事情，并且不为该特定请求使用缓存将是安全的事情。这比清除缓存更有用，因为它相当于只为 Etag 跟踪服务器清除缓存。

标签： http tracking privacy etag cookieless

【解决方案1】：

这听起来很合理，但存在变通方法。假设首页总是被赋予相同的 etag（这样返回的访问者总是会从缓存中加载它），但是页面本身在每次加载时都引用了一个不同名称的图像。然后，您对该图像的 GET 或 HEAD 请求将唯一标识您。可以说这不是基于 etag 的攻击，但它仍然使用您的缓存来识别您。

【讨论】：

好主意！我想我也找到了一种防御方法。我将修改我的问题以考虑到这一点。
问题已更新。假设应用了 HTTP 协议更改，人们会对缓存跟踪免疫吗？我坚信这是肯定的。
几个问题：（1）mtime有时被用作etag；这将阻止正确的缓存，因为它无法正确验证。 (2) MD5有时用于etag；这很容易受到碰撞攻击。
(1) 我在“2.防止基于缓存的跟踪”中提出的是标准化 Etag 应该是什么。 (2) 我看不出这与碰撞攻击有什么关系，您能进一步解释一下吗？
(2) 冲突攻击的存在意味着主机可以为您提供许多不同页面之一，所有这些页面都具有相同的哈希值。这将说服您使用缓存的（但对您而言是唯一的）页面来请求链接的资源。

【解决方案2】：

只要使用了任何缓存，就有潜在的漏洞利用，即使是 HTTP 更改。假设主页包含 100 张图片，每张图片都是从潜在的 2 张图片池中随机抽取的。

当用户返回网站时，她的浏览器会重新加载页面（因为校验和不匹配）。平均而言，100 张图像中的 25 张将被缓存。这种组合可以（几乎可以肯定）用于对用户进行单独指纹识别。

有趣的是，这几乎就是 DNA 亲子鉴定的工作原理。

【讨论】：

谢谢，这很有启发性。然而，它是关于利用缓存而不是直接利用 ETag。我的解决方案（没有 HTTP 更改）仍然适用于纯 ETag 攻击。您已经证明缓存跟踪确实更难停止，即使发生 HTTP 更改也是如此。我将发布一个关于基于缓存的跟踪的单独问题。
对您的观点非常不重要，但只是想知道：您是如何获得 25 号的？
抱歉，应该是 50。25 来自我之前考虑的一个想法，其中每对中的一个项目是每次加载时随机生成的。
这种特定技术在当前形式下会失败。平均而言：第一次访问后会请求 50 张图片，第二次访问后会请求 25 张，依此类推。在几次访问后，浏览器几乎肯定不会请求任何图片，并且会丢失跟踪。尽管您的观点仍然有效，但我看到了问题。
为了获得最大的实用性，将使用多组图像，并具有循环缓存到期日期。这将确保，对于合理的重访频率范围，至少其中一组将提供有效的指纹识别。

【解决方案3】：

服务器可以检测到您针对许多资源执行了 HEAD 请求，而该请求之后没有针对同一资源执行 GET。如果你在玩扑克，这就是一个判断。

仅通过缓存一些资源，您就可以存储信息。只要您不重新请求页面上指定的资源，服务器就可以推断出该信息。

以这种方式保护您的隐私是以每次访问都必须下载页面上的所有资源为代价的。如果您曾经缓存过任何东西，那么您就是在存储可以从您的请求中推断出的信息到服务器。

尤其是在移动设备上，您的带宽更昂贵且通常更慢，每次访问都下载所有页面资源可能是不切实际的。我认为在某种程度上，您必须接受在您与网站的交互中存在一些模式，这些模式可以被检测和分析以识别您的身份。

【讨论】：