Live data from Hacker News

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

chromiumcodereview.appspot.com

131–137 of 137 posts

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

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

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?

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.

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

#132

Earlier quoted context omitted.

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?

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.

Oops, yes of course, now I feel stupid for asking. Thanks.

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

#133
post #126
post #116

Earlier quoted context omitted.

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.

Probably, yeah. Thinking about it, one obvious approach might be to try and overlap the last step of guessing one byte with the first step of guessing the next byte, for instance.

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

#134
post #125
post #124

Earlier quoted context omitted.

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?

Pretty much, yes. With the proviso that if you didn't have HTTP Content-Type compression for your content before, then it might still have been compressed at the TLS layer, and won't be now.

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

#135

Earlier quoted context omitted.

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

except when they do! http://www.amazon.com/gp/help/customer/display.html/?nodeId=...

Doesn't do HTTPS, also I am skeptical of cross-site javascript shenanigans happening on the server-end of silk.

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

#136

Earlier quoted context omitted.

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.

Sure, they might use HTTPS, but how often do they load arbitrary pages with uncontrolled javascript?

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

#137

Earlier quoted context omitted.

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.

Sure, they might use HTTPS, but how often do they load arbitrary pages with uncontrolled javascript?

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...)
Post reply on HN