News for hackers. Stuff that matters.

A comment on Google disables compression for OpenSSL in Chrome - SSL exploit coming?. Parent comment

Re:Google disables compression for OpenSSL in Chrome - SSL e... by jgrahamc on Wednesday September 12, 2012 @11:09AM (#4511002)
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

[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by cperciva on Wednesday September 12, 2012 @11:47AM (#4511194)
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.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by __alexs on Wednesday September 12, 2012 @12:35PM (#4511498)
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!
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by caf on Wednesday September 12, 2012 @09:55PM (#4514372)
Low jitter is not a requirement for timing side-channel attacks. As long as the jitter is uncorrelated with the timing difference that you're after, you can filter the signal from the noise.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by JoachimSchipper on Wednesday September 12, 2012 @01:54PM (#4511931)
> You better have an extremely low jitter connection!

Like AWS. (Cite: http://dl.acm.org/citation.cfm?id=1653687.)

[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by __alexs on Wednesday September 12, 2012 @02:11PM (#4512060)
I doubt youd even have to break SSL using that attack. Lots of people do SSL termination at the load balancer.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by Dylan16807 on Wednesday September 12, 2012 @06:08PM (#4513515)
Okay, but people don't run web browsers on AWS.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by abadidea on Wednesday September 12, 2012 @07:47PM (#4513930)
except when they do! http://www.amazon.com/gp/help/customer/display.html/?nodeId=...
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by Dylan16807 on Friday September 14, 2012 @12:24AM (#4520064)
Doesn't do HTTPS, also I am skeptical of cross-site javascript shenanigans happening on the server-end of silk.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by JoachimSchipper on Thursday September 13, 2012 @05:53AM (#4515403)
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.

[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by Dylan16807 on Friday September 14, 2012 @12:24AM (#4520067)
Sure, they might use HTTPS, but how often do they load arbitrary pages with uncontrolled javascript?
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by JoachimSchipper on Friday September 14, 2012 @04:27AM (#4520736)
Pretty much never. How often do they make requests that are at least partially attacker-controlled, though? (Note that variants on https://www.someapi.com/...?username=foo contain attacker-controlled data...)
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by ivanr on Wednesday September 12, 2012 @11:18AM (#4511047)
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.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by tptacek on Wednesday September 12, 2012 @11:38AM (#4511135)
That's why sites need to enable the Secure flag on their cookies, and to set the Strict-Transport-Security headers.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by thatwonthelp on Wednesday September 12, 2012 @04:35PM (#4513052)
Won't help in this case.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by tptacek on Wednesday September 12, 2012 @04:46PM (#4513121)
I don't know what you're saying. If you're saying that the "Secure" flag won't defend against CRIME, nobody is saying that. I'm saying that the "Secure" flag and HSTS mitigates SSL-stripping.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by tlrobinson on Wednesday September 12, 2012 @07:04PM (#4513761)
I think both ivanr and thatwonthelp were suggesting that any non-secure site (same origin or not) can be hijacked in order to make the requests necessary for this attack.

I understand and agree with your comment about the secure flag, but if I understood ivanr's comment it doesn't apply.

[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by bdr on Wednesday September 12, 2012 @05:20PM (#4513291)
Oddly, GP's account was made for the purpose of writing that comment. I'm unsure what that means.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by xhrpost on Wednesday September 12, 2012 @11:33AM (#4511112)
I think you're correct here but how would you manipulate the cookies being sent when sending XSS requests from a different domain?
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by cstejerean on Wednesday September 12, 2012 @11:46AM (#4511182)
you don't need to manipulate the cookies being sent, only the body of the message. The browser will send the correct cookie in the header, you control the body, and use the length of the message to determine how close the cookie value in the body is getting to the one in the header.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by ivanr on Wednesday September 12, 2012 @01:35PM (#4511796)
For CRIME, I don't think that it's necessary to control the cookies. Having control of other parts of the request should be sufficient (e.g., using request headers, request body, etc).

As for manipulating cookies from the MITM perspective, here's one clunky way to do it: redirect the victim's browser to the plain-text version of the target web site, intercept that request, and set a new cookie (pretending to be the plain-text version of the target web site). The next request to the secure version of the target web site should contain the injected cookie. As tptacek mentioned in another comment, this approach would not work with a site that uses HTTP Strict Transport Security.

[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by tptacek on Wednesday September 12, 2012 @01:46PM (#4511867)
The attack as Pornin outlines it does not involve controlling the cookie header, but rather on being able to get content into the client's TX stream that happens to match the cookie header; think in terms of things like query args and post data.

I think all three comments in this little subthread might be saying the same thing. Go nerddom!

[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by thwarted on Wednesday September 12, 2012 @11:22AM (#4511064)
Would have been fun if they called this the CPE1704TKS attack

That one was not cracked one character at a time in series, portions in the middle were discovered sooner. But, yeah, would have been a more appropriate, cooler name.

[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by murbard2 on Wednesday September 12, 2012 @02:55PM (#4512361)
Are there credible situations where you would be able to do (2) but not able to simply read the cookie from the DOM and send it to an attacker controlled website?
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by amalcon on Wednesday September 12, 2012 @03:10PM (#4512483)
An attacker can build a hidden form that submits to a URL at the victim site, and submit it repeatedly using javascript. Alternatively an attacker could put the test content in the URL (we don't care if it 404s), which would work just as well and allow them to use a series of script-free pages full of images.

edit: tptacek is absolutely right; there isn't a way to defend against this in application code. All you can do is turn off TLS compression. This is NOT by any means the only approach, it's just the most obvious one.

[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by tptacek on Wednesday September 12, 2012 @03:21PM (#4512563)
Careful: you're outlining the attack well, but you wouldn't want to give someone the impression that defending against CSRF also defends against attacks like BEAST.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by jgeralnik on Thursday September 13, 2012 @07:22AM (#4515595)
You can't read the cookie for the victim website from a malicious site. What you can do is send POST/GET requests to which the browser will attach the appropriate cookies.
[ Parent | on HN ]
Re:Google disables compression for OpenSSL in Chrome - SSL e... by murbard2 on Thursday September 13, 2012 @09:51AM (#4516104)
Oops, yes of course, now I feel stupid for asking. Thanks.
[ Parent | on HN ]