Yes. There's absolutely zero excuse for including compression as part of a cryptographic protocol.
It's easy for me to believe that you've internalized "minimize data-dependent branches in crypto code" and thus wouldn't have designed a compressed encrypted transport.
It is very hard for me to believe that you would have spotted this flaw immediately had anyone pointed out to you that TLS supported compression.
There is well-regarded (though not by me) crypto advice recommending that people compress before encrypting, to destroy structure in the plaintext.
"... 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."
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.
But compression in TLS is not a relic of the 1990s; it's something that looks to have gained its earliest adoption in SSL/TLS at about the same time as Elliptic Curve.
My issue here isn't that you're wrong; it's that I think this is an extremely clever attack that says something profound about designing cryptosystems, and I wouldn't want to see Thai's and Juliano's (or Pornin's, if he's "wrong" about the prediction) work minimized by a glib comment about TLS.
I guess by that point they had thrown in everything but the kitchen sink, and decided they might as well throw in the kitchen sink too.
I wouldn't want to see Thai's and Juliano's (or Pornin's, if he's "wrong" about the prediction) work minimized by a glib comment about TLS.
Oh, of course. I'm just irritated (as usual) by the fact that people continue to use SSL/TLS "because it's the standard" despite the fact that it's a phenomenally broken standard. There's places where you can't avoid it (HTTPS), but where it can be avoided...
My perspective on HTTPS/TLS is that it has a history of vulnerabilities because it is the most carefully studied cryptosystem in human history.
I agree to disagree with you on this.
Your perspective is... I'm not quite sure, actually. Maybe you just don't believe in mathematical proofs?
As you say, agree to disagree -- but I'm not going to stop pointing and laughing every time a new SSL/TLS vulnerability comes out. :-)
There's a reason why I don't drink -- type 1 diabetes and large quantities of alcohol don't interoperate well.
I work in an area where bugs are very scary, so we use formal verification, and that's on top of having many more testers than developers.
From the perspective of this naive outsider, I'd would have expected FV to be worth it for security sensitive protocols. Is it that the protocols are too complex to be verified, or is it just not considered to be worth the effort?
Colin is right that we know how to prove that cryptographic systems have certain security properties. The academic literature is filled with laments about TLS and proofs of fixed versions of it.
Also, how does one compare a cryptographic hash function core to an entire cryptographic protocol to produce a statement about the fallibility of crypto design?
(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).
Compression before encryption is not a problem if the sender is the only person that decides what is in the message to be sent. Compression doesn't make it vulnerable to chosen plain-text attacks either. Mixing victims's and attacker's data before compression and encryption will leak data, yes.
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.
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.