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

61–70 of 137 posts

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

#61

Post by __alexs »

cperciva wrote: post #29
jgrahamc wrote: post #5

Earlier quoted context omitted.

You need three things: 1. To know the format of cookies used for the web site you are targetting. Specifically, whatever cookie contains authentication. 2. The ability to injection a request to the target web server while someone is connected (such as with JavaScript, an XSS, or plug-in). 3. Ability to monitor the SSL connection is it is transported across TCP. Would have been fun if they called this the CPE1704TKS a…

You don't even need (3) if you can do enough trials and have an accurate clock. Compression by its very nature drips timing side channels.

Due to the padding of even compressed SSL segments only having timing data will significantly complicate things. You'll be trying to measure the variance in deflate compressing different blocks with single byte differences. You better have an extremely low jitter connection!

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

#62

Post by jlgreco »

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.

That "Guess the password one char at a time" thing also occurs in real life when people forget to use constant time comparison functions.

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

#63

Post by geofft »

jgrahamc wrote: post #2

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

Stupid question: does TLS's compression use the _same_ compression state for both directions of the connection? That seems hard to me, because they could be sending information in parallel, and there's no provision for syncing streams.

So I suspect the attack there cannot work on TLS, and in fact the demo code posted in a comment attacks local zlib, not TLS.

I think the actual attack, if it's along these lines, involves getting the server to echo back your guess of the cookie, so that the cookie and your guess are both on the same stream. Perhaps with TRACE?

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

#64

Post by ivanr »

moxie wrote: post #57
nitrogen wrote: post #4

Earlier quoted context omitted.

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.

You also need the client and server to both support TLS compression. But there aren't any major sites (that I know of) which do support TLS compression.

In my quick test, about 42% of the sites in the SSL Pulse data set (~180k SSL sites in Alexa's top 1m) support compression. For example, mail.yahoo.com does.

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

#65

Post by __alexs »

amalcon wrote: post #52
jgrahamc wrote: post #2

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

Interesting. The attacker would also need to push the request size up to the next block boundary, but it should work. At least we can still do compression at the HTTP (or other higher-level protocol) level. That gets us most of the benefit anyway.

I suspect most TLS libraries will flush the compression buffer after each write call so its highly likely that every request will end on a deflate block boundary already.

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

#66

Post by geofft »

tptacek wrote: post #53
cperciva wrote: post #48

Earlier quoted context omitted.

compression [...] looks to have gained its earliest adoption in SSL/TLS at about the same time as Elliptic Curve 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 irritat…

Your perspective on HTTPS/TLS is that it has a history of vulnerabilities because it is poorly designed. 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.

Vulnerabilities don't arise by study, they arise because of vulnerabilities. We have plenty of well-studied crypto that is fine, ranging from SHA to Kerberos.

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.

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

#67

Post by tptacek »

geofft wrote: post #63
jgrahamc wrote: post #2

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

Stupid question: does TLS's compression use the _same_ compression state for both directions of the connection? That seems hard to me, because they could be sending information in parallel, and there's no provision for syncing streams. So I suspect the attack there cannot work on TLS, and in fact the demo code posted in a comment attacks local zlib, not TLS. I think the actual attack, if it's along these lines, invol…

The attack Pornin outlined involves only the client TX stream, which the attacker shares with the defender by virtue of content-controlled Javascript.

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

#68

Post by tptacek »

geofft wrote: post #66
tptacek wrote: post #53

Earlier quoted context omitted.

Your perspective on HTTPS/TLS is that it has a history of vulnerabilities because it is poorly designed. 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.

Vulnerabilities don't arise by study, they arise because of vulnerabilities. We have plenty of well-studied crypto that is fine, ranging from SHA to Kerberos. 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.

SHA? The Secure Hash Algorithm? The Secure Hash Algorithm with the length extension property? The Secure Hash Algorithm with the length extension property that was specifically forbidden from the SHA-3 contestants because it creates implementation vulnerabilities in the real world? That SHA?

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?

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

#70

Post by geofft »

cryptbe wrote: post #44

Problem 1 in Stanford's crypto class [1]: Data compression is often used in data storage or transmission. Suppose you want to use data compression in conjunction with encryption. Does it make more sense to A. Compress the data and then encrypt the result, or B. Encrypt the data and then compress the result. Now we know the correct answer is Neither. [1] http://crypto.stanford.edu/~dabo/cs255/hw_and_proj/hw1.pdf

Well, B makes no sense. A makes sense, but might have leaks, that depending on use case (and in particular, whether the attacker can execute chosen plaintext attacks like in SSL) may or may not weaken the system, but it still makes sense.

For a confusing example of a fairly leaky cryptosystem involving compression that works well in practice and has a proof of security that is aware of the leak, see Douceur et al.'s "convergent encryption".

http://research.microsoft.com/apps/mobile/publication.aspx?i...

Post reply on HN