I guess this is actually an instance where those Hollywood "guess the password one character at a time" animations would make sense.

1. To know the format of cookies used for the web site you are targetting. Specifically, whatever cookie contains authentication.

2. The ability to injection a request to the target web server while someone is connected (such as with JavaScript, an XSS, or plug-in).

3. Ability to monitor the SSL connection is it is transported across TCP.

Would have been fun if they called this the CPE1704TKS attack instead of CRIME: http://www.youtube.com/watch?v=NHWjlCaIrQo

Like AWS. (Cite: http://dl.acm.org/citation.cfm?id=1653687.)

[1] Lala people never send sensitive data over plain HTTP I'M NOT HEARING YOU.

I understand and agree with your comment about the secure flag, but if I understood ivanr's comment it doesn't apply.

As for manipulating cookies from the MITM perspective, here's one clunky way to do it: redirect the victim's browser to the plain-text version of the target web site, intercept that request, and set a new cookie (pretending to be the plain-text version of the target web site). The next request to the secure version of the target web site should contain the injected cookie. As tptacek mentioned in another comment, this approach would not work with a site that uses HTTP Strict Transport Security.

I think all three comments in this little subthread might be saying the same thing. Go nerddom!

That one was not cracked one character at a time in series, portions in the middle were discovered sooner. But, yeah, would have been a more appropriate, cooler name.

edit: tptacek is absolutely right; there isn't a way to defend against this in application code. All you can do is turn off TLS compression. This is NOT by any means the only approach, it's just the most obvious one.

Did you see the BEAST attack? Exactly one byte at a time: http://www.youtube.com/watch?v=BTqAIDVUvrU

You're right that Hollywood "guess the password one character at a time" animation makes sense here. It also makes sense for timing based attacks. Ie, if checking "AB" against the password takes longer than "A", you know the second character is B...

1. Attacker controls some parts of plaintext

2. Attacker's content is mixed with content attacker wants to discover

3. Attacker can make repeated trials against the same plaintext (not against same ciphertext stream or key)

4. Defender compresses content on the fly

There are probably other cryptosystems that have this flaw, but it's less inherent to TLS than it is to the HTTPS security model.

Variable time until some threshold number of repeat failures occurs (e.g. 3). After this, manipulate the comparison time in such a manner that someone attempting to do this sort of attack would come up with a dummy password. If they come up with said dummy password, alert the user of an attempted attack.

So I suspect the attack there cannot work on TLS, and in fact the demo code posted in a comment attacks local zlib, not TLS.

I think the actual attack, if it's along these lines, involves getting the server to echo back your guess of the cookie, so that the cookie and your guess are both on the same stream. Perhaps with TRACE?

Edit: Wait, I am. That wouldn't work because it'd compress the repeated subsequences. D'oh.

At least we can still do compression at the HTTP (or other higher-level protocol) level. That gets us most of the benefit anyway.

What would be the procedure if you use bzip2 (which is based on Burrows-Wheeler transformation) compression?

I do a lot of experimentation with new compression techniques for web demos, and I recently implemented my own compression algo from scratch based around the same building blocks as bzip2. The variance I saw was just staggering; a tiny change in my source material would totally warp the output.