这种攻击应该在 10 天后出现，但我猜他们使用了压缩。

SSL/TLS可选地支持数据压缩。在ClientHello消息中，客户端说明它知道的压缩算法列表，服务器在 中ServerHello以将要使用的压缩算法进行响应。压缩算法由一字节标识符指定，TLS 1.2 (RFC 5246) 仅定义null压缩方法（即根本不压缩）。其他文档指定了压缩方法，特别是RFC 3749，它定义了压缩方法 1，基于DEFLATE，LZ77 衍生物，它是 GZip 格式的核心，也是现代 Zip 档案的核心。使用压缩时，它会以长流的形式应用于所有传输的数据。特别是，当与 HTTPS 一起使用时，压缩将应用于流中所有连续的 HTTP 请求，包括标头。DEFLATE 通过定位重复的字节子序列来工作。

假设攻击者使用一些 JavaScript 代码可以向目标站点（例如银行）发送任意请求并在被攻击机器上运行；浏览器将使用该银行的用户 cookie 发送这些请求——攻击者所追求的 cookie 值。另外，假设攻击者可以观察到用户机器和银行之间的流量（很可能，攻击者可以访问与受害者相同的 Wi-Fi 热点 LAN；或者他劫持了路径上某处的路由器，可能靠近银行服务器）。

对于此示例，我们假设每个 HTTP 请求中的 cookie 如下所示：

饼干：秘密=7xc89f+94/wa

攻击者知道该Cookie: secret=部分并希望获得秘密值。所以他指示他的 JavaScript 代码发出一个请求，该请求在正文中包含序列Cookie: secret=0。HTTP 请求将如下所示：

POST / HTTP/1.1
Host: thebankserver.com
(...)
Cookie: secret=7xc89f+94/wa
(...)

Cookie: secret=0

当 DEFLATE 看到这一点时，它将识别重复的Cookie: secret=序列并用一个非常短的令牌表示第二个实例（一个声明“前一个序列的长度为 15 并且过去位于n字节）；DEFLATE 将不得不发出一个额外的令牌'0'。

请求转到服务器。从外部，攻击者的窃听部分看到一个不透明的 blob（SSL 加密数据），但他可以看到 blob长度（连接使用 RC4 时具有字节粒度；使用块密码时有一些填充，但攻击者可以调整他的请求的内容，以便他可以与块边界相匹配，因此，在实践中，攻击者可以知道压缩请求的长度）。

现在，攻击者再次尝试，Cookie: secret=1在请求正文中。然后，Cookie: secret=2，以此类推。所有这些请求都将压缩到相同的大小（几乎 - 与 DEFLATE 中使用的霍夫曼代码有一些细微差别），除了包含 的那个Cookie: secret=7，它压缩得更好（16 个字节的重复子序列而不是 15 个），因此会更短. 攻击者看到了这一点。因此，在几十个请求中，攻击者已经猜到了秘密值的第一个字节。

然后他只需要重复这个过程（Cookie: secret=70、Cookie: secret=71等）并逐字节获取完整的秘密。

我上面描述的是我在阅读文章时所想到的，该文章谈到了“可选功能”中的“信息泄漏”。我无法确定将作为 CRIME 攻击发布的内容是否真的基于压缩。但是，我看不出对压缩的攻击是如何起作用的。因此，无论 CRIME 是滥用压缩还是完全不同，您都应该关闭客户端（或服务器）的压缩支持。

请注意，我说的是 SSL 级别的压缩。HTTP还包括可选的压缩，但这种压缩仅适用于请求和响应的主体，而不是标头，因此不包括Cookie:标头行。HTTP级别的压缩很好。

（不得不删除 SSL 压缩是一种耻辱，因为它对降低带宽要求非常有用，尤其是当一个站点包含许多小图片或大量 Ajax 且有许多小请求时，所有这些都以极其相似的庞大 HTTP 版本开始标头。如果 JavaScript 的安全模型被修复以防止恶意代码向银行服务器发送任意请求会更好；不过我不确定这是否容易。）

编辑 2012/09/12：上面的攻击可以通过二分法进行一些优化。假设秘密值在 Base64 中，即每个未知字符有 64 个可能的值。攻击者可以发出一个包含 32 个副本的请求Cookie: secret=X（对于 32 个X字符变体）。如果其中之一与实际 cookie 匹配，则总压缩长度会比其他情况短。一旦攻击者知道未知字节属于他的字母表的哪一半，他就可以使用 16/16 拆分再次尝试，依此类推。在 6 次请求中，这归于未知字节值（因为 2 ⁶ = 64）。如果秘密值是十六进制，则 6 个请求变为 4 个请求（2 ⁴ = 16）。Dichotomy 解释了 Juliano Rizzo 最近的这个推特。

编辑 2012/09/13： 已确认。CRIME 攻击以类似于上面解释的方式滥用压缩。攻击者在其中插入假定的 cookie 副本的实际“主体”实际上可以是一个简单请求中的路径，可以由最基本的<img>标签触发；无需花哨的同源策略漏洞利用。

为了补充 Thomas Pornin 的出色答案，我想指出一些关于压缩和密码学的先前工作。看看下面的研究论文：

• 约翰凯尔西。 明文压缩与信息泄露。FSE 2002。

该论文描述了针对系统的选择明文攻击（a）在加密之前压缩数据，以及（b）窃听者可以观察到生成的密文的长度。

这些攻击在概念上与 Thomas Pornin 所描述的类似。该论文甚至提到 TLS 在加密之前使用可选压缩。但是，当时我认为没有人意识到这会导致通过 TLS 对 HTTP 进行攻击，或者攻击者可以了解通过 TLS 加密连接发送的秘密 cookie 的价值。该论文主要从抽象的角度而不是在 Web 的特定上下文中研究对压缩的攻击，并且非常理论化。因此，CRIME（或 Thomas Pornin 的攻击）仍然是这些想法的重要新颖延伸。

尽管如此，这是一篇有趣的论文，它预测了这里所讨论的一般类型的攻击，即使它没有意识到网络安全的后果。有趣的是，10 年前的研究文献中首次描述了一般问题，但安全社区花了很长时间才充分认识到这项工作的实际后果。加密肯定不容易，是吗？

只是为了增加托马斯的好答案，似乎要成功泄漏 cookie 值，实际发送的 POST 正文不仅应该是：

Cookie: secret=....

但应该包含更多来自 POST 标头的文本，如下所示：

POST / HTTP/1.1
Host: thebankserver.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1207.1 Safari/537.1
Accept: */*
Referer: https://thebankserver.com/
Cookie: secret=...

这个 POST 内容可以很容易地用 Javascript 构建（例如，他将通过navigator对象检索用户代理），因此在攻击场景中这不是问题。

在实践中，攻击者可以更多地改变正文，例如通过多次放置 cookie 值、放置多个 Cookie 标头、仅使用正文中的部分 POST 标头等。

基于@xorninja 代码，我构建了在正文中复制整个请求标头的自适应算法，并在下一个cookie 字符的结果不清楚时尝试迭代地缩短它。结果很有希望，现在至少检测到 8 个字符。. 当以这种方式无法检测到字符时，通过删除一个标头来缩短请求正文并继续该过程。它可以成功泄漏任意 cookie 值。随意改进。