Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

chromiumcodereview.appspot.com

Post reply on HN
Print view View original

31–40 of 137 posts

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

#31

Post by tptacek »

sanxiyn wrote: post #24

man sshd_config. Compression: Specifies whether compression is allowed, or delayed until the user has authenticated successfully. The argument must be "yes", "delayed", or "no". The default is "delayed". I don't know why they chose "delayed" as default, but this seems to prevent this attack.

The SSH protocol is nothing like TLS. The SSH security model is nothing like the TLS security model. Pornin's guess about Thai and Juliano's attack does not break the TLS authentication model; it breaks the confidentiality guarantees TLS makes to the application layer. If you authenticated TLS with certificates the way SSH authenticates with keys, you wouldn't worry about the compression attack.

So, not so much.

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

#32

Post by tptacek »

ZoFreX wrote: post #30
tptacek wrote: post #22

Earlier quoted context omitted.

What, compressing before encrypting?

Note to anyone that doesn't do much crypto: You have to compress before encrypting, compressing after encrypting has no effect. (Reason: because encrypted data is [should be] indistinguishable from random data, and random data does not compress)

You're right, but again: there's advice people get to compress deliberately, not to save space in messages but to make cryptanalysis more difficult.

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

#33

Post by rfergie »

tptacek wrote: post #22
cperciva wrote: post #21

I think it's time for me to write a blog post entitled "on the provable security of spiped". Seriously, we know how to build secure cryptographic protocols. Unfortunately, step #1 is "don't try to be backwards compatible with the horribly broken things people were doing in the 1990s".

What, compressing before encrypting?

I thought compressing after encryption was a waste of time because encrypted text shouldn't contain compressible patterns

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

#35

Post by cperciva »

tptacek wrote: post #26
cperciva wrote: post #25

Earlier quoted context omitted.

Yes. There's absolutely zero excuse for including compression as part of a cryptographic protocol.

Can you point to an instance where you said anything like that, here or anywhere else, before last week? 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.…

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.

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.

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

#37

Post by cryptbe »

nitrogen wrote: post #4
jgrahamc wrote: post #2

Yes. See: http://security.stackexchange.com/a/19914

Is my understanding correct that the attack described there requires all of 1. cookies associated with the target, 2. the ability to monitor the length of requests to the target, and 3. the ability to send requests to the target (e.g. JavaScript injection, malicious website)? I guess this is actually an instance where those Hollywood "guess the password one character at a time" animations would make sense.

> Hollywood "guess the password one character at a time" animations

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

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

#38

Post by sanxiyn »

tptacek wrote: post #26
cperciva wrote: post #25

Earlier quoted context omitted.

Yes. There's absolutely zero excuse for including compression as part of a cryptographic protocol.

Can you point to an instance where you said anything like that, here or anywhere else, before last week? 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.…

This paper published in 2002 does discuss this attack. http://www.iacr.org/cryptodb/data/paper.php?pubkey=3091

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

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

#39

Post by ZoFreX »

tptacek wrote: post #14

You think you have a handle on how hard it is to get crypto right. Then you get a result like this. As an expert (not me; I'm not smart enough to say this) would put it: "if attacker data is mixed with defender data, none of the branches in the cryptosystem code can depend on the content".

I think crypto is possibly the best example in all of software development and/or computer science of how dangerous "unknown unknowns" are, and how a little knowledge is a dangerous thing (although threads are a serious competitor for the latter trophy).

I've studied cryptography theory, and I've implemented various ciphers and attacks, and the more I learn the more certain I become that I would never, ever use any of my own crypto code in production.

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

#40

Post by zurn »

cperciva wrote: post #25
tptacek wrote: post #22

Earlier quoted context omitted.

What, compressing before encrypting?

Yes. There's absolutely zero excuse for including compression as part of a cryptographic protocol.

The excuses I've heard for it include 1) can't do compression after the crypto, and 2) it reduces ciphertext available to attackers. SSH and PGP do it too.
Post reply on HN