Google disables compression for OpenSSL in Chrome - SSL exploit coming?

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.

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.

I'm not claiming that I'd have noticed this particular attack. I'm saying that having compression in a supposedly secure transport layer was an obviously bad idea even before it was clear how it could be exploited. I don't need to get into a car accident to know that driving at night with my car's headlights turned off is a bad idea.

There is well-regarded (though not by me) crypto advice recommending that people compress before encrypting, to destroy structure in the plaintext.

There's a huge difference between compressing data and compressing an authentication channel. This is why compression should not be included in the secure channel -- it should be left up to the higher-level code to decide if compression is (a) completely pointless or (b) will leak information dangerously.

"... both the SSH and TLS protocols support an option for on-the-fly compression. Potential security implications of using compression algorithms are of practical importance to people designing systems that might use both compression and encryption."

A conceptual purist like Colin Percival would argue, correctly, that if there's an attack against a cryptosystem that benefits from knowing the distribution of bytes in the plaintext, that's a damning statement about the cryptosystem itself.

But compression does "break" some exploits.

(Even if HTTP probably just got lucky here rather than deliberately making the right choice, it's still the only layer that had the chance to make the right choice).

In theory, protocols which fall to attacks when attackers have control of some of the message are said to be vulnerable to "chosen plaintext attacks" (if the attacker only gets 1 shot per message) or "adaptive chosen plaintext attacks" (if the attacker gets many bites at the same apple). Sound protocols don't have feasible adaptive chosen plaintext attacks.

In practice, most protocols can be coerced into carrying some data controlled by attackers. Sneaking some attacker-controlled data into a message is a very low bar for an attacker to clear.

It's true that content-controlled Javascript code makes it distinctively easy for an attacker to spirit their data into the plaintext, but don't let that confuse you. For the HTTPS/TLS cryptosystem to be sound, attackers can't use this property to decrypt the content they didn't add to the message.

These days, even when we don't include cryptographic fingerprints (e.g., with the hash-and-encrypt construction C = E(M || H(M)) ) there's enough structure in compression format headers to allow an attacker to recognize if he has the right key... and he isn't going to be running a brute-force attack anyway.