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

91–100 of 137 posts

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

#91

Post by tptacek »

peterwwillis wrote: post #90
tptacek wrote: post #59

Earlier quoted context omitted.

That protocols without security proofs can survive in the real world, and protocols with security proofs still fall to implementation bugs, and that if you were going to bet on incidence of protocol design flaws vs. implementation flaws, the safe bet is on implementation flaws.

The level of civility in this thread is great, but I would pay money to see a DEF CON panel debate between you two where you each had to take a shot every 8 minutes. We could get Mikko Hypponen to moderate and pour shots!

(a) I would lose the debate, (b) it would be boring, (c) I can drink Colin under the table.

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

#92

Post by tonyb »

abadidea wrote: post #11
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

No, I doubt that something closed in early 2010 has much to do with a new patch that has a rationale disabled from public viewing which implies it's a security emergency.

You are correct, I misread the code commit. The link to the 2010 bug was removed from the code, not added to it.

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

#93

Post by amalcon »

murbard2 wrote: post #89
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…

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?

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.

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

#94

Post by cryptlamex »

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.

Google, Yahoo, Twitter are vulnerable based on SSL Labs tool

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

#96

Post by njs12345 »

tonfa wrote: post #54

Does the attack apply to SPDY as well?

I think it does, although not precisely as described in the SO post above: in SPDY the request headers are compressed separately before any TLS compression would apply, so the attacker would have to put her guess of the cookie in the request headers or the URL (as the URL is sent as a pseudo-header in SPDY).

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

#97

Post by sausagefeet »

cperciva wrote: post #56
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.

My perspective is that we know how to design protocols which are provably secure. Your perspective is... I'm not quite sure, actually. Maybe you just don't believe in mathematical proofs? As you say, agree to disagree -- but I'm not going to stop pointing and laughing every time a new SSL/TLS vulnerability comes out. :-)

Have there been any proposed contenders to TLS/SSL?

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

#98

Post by tptacek »

amalcon wrote: post #93
murbard2 wrote: post #89

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?

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…

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.

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

#99

Post by Daniel_Newby »

sausagefeet wrote: post #97
cperciva wrote: post #56

Earlier quoted context omitted.

My perspective is that we know how to design protocols which are provably secure. Your perspective is... I'm not quite sure, actually. Maybe you just don't believe in mathematical proofs? As you say, agree to disagree -- but I'm not going to stop pointing and laughing every time a new SSL/TLS vulnerability comes out. :-)

Have there been any proposed contenders to TLS/SSL?

SSH and IPv6 come to mind.

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

#100

Post by bcoates »

tlogan wrote: post #85
jgrahamc wrote: post #2

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

This attack procedure applies only for dictionary based compressions. Correct? What would be the procedure if you use bzip2 (which is based on Burrows-Wheeler transformation) compression?

It shouldn't matter so long as redundancy between headers and body result in a smaller cyphertext.
Post reply on HN