Google disables compression for OpenSSL in Chrome - SSL exploit coming? • Hacker News Board

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.

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

#5

Post by jgrahamc » Wed, Sep 12, 2012, 3:09 PM UTC

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.

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 attack instead of CRIME: http://www.youtube.com/watch?v=NHWjlCaIrQo

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

#6

Post by ChuckMcM » Wed, Sep 12, 2012, 3:09 PM UTC

jgrahamc wrote: post #2

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

Very interesting, using differential analysis on the compression output is pretty clever.

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

#7

Post by wladimir » Wed, Sep 12, 2012, 3:10 PM UTC

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.

As I understand it, only 2 and 3 are needed. The (secret) cookies are the part that is determined by the SSL compression exploit, by trying subsequent parts.

You're right that Hollywood "guess the password one character at a time" animation makes sense here. It also makes sense for timing based attacks. Ie, if checking "AB" against the password takes longer than "A", you know the second character is B...

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

#8

Post by tonyb » Wed, Sep 12, 2012, 3:12 PM UTC

Doesn't look like this has anything to do with an exploit. It is because some older web servers who don't support TLS also don't support compression.

See:http://code.google.com/p/chromium/issues/detail?id=31628

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

#9

Post by ivanr » Wed, Sep 12, 2012, 3:18 PM UTC

jgrahamc wrote: post #5

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 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…

To expand on your second point, if you have 3, then in many cases you also have the ability to intercept and modify non-encrypted traffic. Meaning, if the victim is using a secure web site and a non-secure site at the same time, the MITM can infiltrate the non-secure site and use it to generate requests to the secure site.

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

#10

Post by EwanToo » Wed, Sep 12, 2012, 3:19 PM UTC

tonyb wrote: post #8

Doesn't look like this has anything to do with an exploit. It is because some older web servers who don't support TLS also don't support compression. See: http://code.google.com/p/chromium/issues/detail?id=31628

That's always possible, but why would the bug report linked from the code change be private then?

http://code.google.com/p/chromium/issues/detail?id=139744