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

121–130 of 137 posts

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

#121

Post by caf »

tlb wrote: post #46
cperciva wrote: post #25

Earlier quoted context omitted.

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

You'd have the same problem if HTTP supported compression of the request headers & body. It's because it only supports compression of the response body that there isn't any leakage already.

This is true, but it reinforces why the compression should not be done at the secure transport layer, and should instead be left to higher levels: only HTTP knows which parts of the request are potentially unsafe to include in the same compression state.

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

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

#122

Post by caf »

zimbatm wrote: post #58
cperciva wrote: post #25

Earlier quoted context omitted.

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

What's the issue with that ? Isn't it possible to design a compression algorithm that is efficient and less predictable at the same time ? Or is it more of a general concept that I don't know of ?

It's because compression inherently creates a side-channel: the size of the message is now a function of the plaintext contents.

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

#123

Post by caf »

forgotusername wrote: post #71

Colour me stupid, but is there something to prevent inserting indeterminate padding while sending headers? e.g. imagine a request like GET / HTTP/1.0 X-Pad: GET / HTTP/aaaaaaa Where X-Pad randomly repeats previous bytes, and perhaps 0..8 bytes of random/repeating variable-length data. By randomizing the effectiveness of the compression, surely this attack can be generally prevented by the browser? You could argue tha…

There's no point - you're better off just disabling TLS compression and doing whatever compression of the body-only at the HTTP level.

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

#124

Post by caf »

alanh wrote: post #112

Is this a disabling of compression on both ends? No DEFLATE on either requests or responses? Will a site using HTTPS be able to serve compressed assets (like javascript & css)? If not, we’ll urgently need a way for site devs to whitelist precomputed (and thus immune) static assets for compression.

It's a disabling of the optional compression at the TLS layer. HTTP content compression is not affected.

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

#125

Post by alanh »

caf wrote: post #124
alanh wrote: post #112

Is this a disabling of compression on both ends? No DEFLATE on either requests or responses? Will a site using HTTPS be able to serve compressed assets (like javascript & css)? If not, we’ll urgently need a way for site devs to whitelist precomputed (and thus immune) static assets for compression.

It's a disabling of the optional compression at the TLS layer. HTTP content compression is not affected.

So what, exactly, is no longer compressed? Merely the headers themselves, and the content is not affected?

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

#126

Post by comex »

makomk wrote: post #116
jgrahamc wrote: post #2

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

Unless I'm missing something, I reckon there's a really obvious improvement on that, but Stack Exchange doesn't let new users leave comments. Think of the old puzzle where you've got 9 bags of gold coins which weight 10 grams each and one bag of shaved coins which weigh only 9 grams each and you need to figure out which bag has the shaved coins in only one weighing. You should be able do the same thing here - add one…

You could still probably get more than a bit per request along those lines with some experimentation.

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

#128

Post by shanemhansen »

While this is probably security related, disabling compression is actually a good practice for clients which make a large number of SSL requests (like a browser). OpenSSL allocates alot of memory per connection for compression/decompression. See http://journal.paul.querna.org/articles/2011/04/05/openssl-m... for a great discussion of why SSL_OP_NO_COMPRESSION might make sense for you.

Even if you don't have direct access to the library code creating SSL objects, there are still some tricks with ctypes, ffi, dlopen that have the same effect.

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

#129

Post by wladimir »

pbiggar wrote: post #28

Reading the title, I thought that Chrome was turning of gzip based compression for HTTP bodies when using SSL. According to http://security.stackexchange.com/a/19914 (linked above by jgrahamc), it is in fact header compression that is TLS specific. So a giant sigh of relief from me.

Thanks for noting this. I also got this wrong on the first reading. Having to drop gzip compression of the content would be terrible. I fathom that header compression helps if you have many requests (polling etc), but for most websites it is much less influential in bandwidth usage.

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

#130

Post by JoachimSchipper »

Dylan16807 wrote: post #108
JoachimSchipper wrote: post #81

Earlier quoted context omitted.

> You better have an extremely low jitter connection! Like AWS. (Cite: http://dl.acm.org/citation.cfm?id=1653687. )

Okay, but people don't run web browsers on AWS.

People do run HTTPS clients on AWS, though. Web APIs tend to [1] require exactly that.

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

Post reply on HN