News for hackers. Stuff that matters.
Re:Google disables compression for OpenSSL in Chrome - SSL e... by wladimir on Wednesday September 12, 2012 @11:10AM (#4511008)
As I understand it, only 2 and 3 are needed. The (secret) cookies are the part that is determined by the SSL compression exploit, by trying subsequent parts.

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...

Re:Google disables compression for OpenSSL in Chrome - SSL e... by nitrogen on Wednesday September 12, 2012 @11:31AM (#4511103)
What I meant was that the browser must have some cookies stored to send to the target, cookies that the attacker wants to discover.
Re:Google disables compression for OpenSSL in Chrome - SSL e... by tptacek on Wednesday September 12, 2012 @11:36AM (#4511127)
The attack as described by Thomas Pornin is indeed specific to HTTPS. Generalize it past HTTPS and its elements are:

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.