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

101–110 of 137 posts

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

#101

Post by Daniel_Newby »

anonymous wrote: post #95

So, to summarize for the laypeople, if the user has Javascript and/or cookies disabled, this exploit will not work?

Hidden elements would probably work just as well.

It might even work with JacaScript turned. Have a page with nested iframes. Serve each one from a different IP address and have the server not answer right away. The server answers with the first iframe having a chosen URL while Eve snoops the wire. Eve tells the server which URL to use for the next iframe body that it sends. Repeat until the cookie is deduced. The server can use a nested tree of iframes to avoid having a bazillion iframes in the top level document.

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

#103

Post by fakjshflaskjhf »

anonymous wrote: post #95

So, to summarize for the laypeople, if the user has Javascript and/or cookies disabled, this exploit will not work?

Javascript just makes the attack faster, but it can be accomplished with raw html. Cookies are required though; it's what you are after when using this attack.

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

#104

Post by thatwonthelp »

tptacek wrote: post #19
ivanr wrote: post #9

Earlier quoted context omitted.

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.

That's why sites need to enable the Secure flag on their cookies, and to set the Strict-Transport-Security headers.

Won't help in this case.

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

#105

Post by tptacek »

thatwonthelp wrote: post #104
tptacek wrote: post #19

Earlier quoted context omitted.

That's why sites need to enable the Secure flag on their cookies, and to set the Strict-Transport-Security headers.

Won't help in this case.

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.

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

#106

Post by daeken »

bcoates wrote: post #100
tlogan wrote: post #85

Earlier quoted context omitted.

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.

Due to the nature of compression algorithms using BWT, changing a single byte in the uncompressed data might give you +/- 5 bytes difference in the size of the compressed data; that makes pulling off an attack like this much, much, much more difficult. Don't get me wrong, you'll get variance with deflate as well, but it's nowhere near the level of something like bzip2.

I do a lot of experimentation with new compression techniques for web demos, and I recently implemented my own compression algo from scratch based around the same building blocks as bzip2. The variance I saw was just staggering; a tiny change in my source material would totally warp the output.

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

#107

Post by bdr »

tptacek wrote: post #105
thatwonthelp wrote: post #104

Earlier quoted context omitted.

Won't help in this case.

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.

Oddly, GP's account was made for the purpose of writing that comment. I'm unsure what that means.

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

#108

Post by Dylan16807 »

JoachimSchipper wrote: post #81
__alexs wrote: post #61

Earlier quoted context omitted.

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!

> You better have an extremely low jitter connection! Like AWS. (Cite: http://dl.acm.org/citation.cfm?id=1653687. )

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

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

#109

Post by tryeng »

cperciva wrote: post #25
tptacek wrote: post #22

Earlier quoted context omitted.

What, compressing before encrypting?

Yes. There's absolutely zero excuse for including compression as part of a cryptographic protocol.

Compression itself in a cryptographic protocol is not the issue here. The problem starts when you let an attacker add chosen plain-text before or after the secret in the same compressed and encrypted stream.

Compression before encryption is not a problem if the sender is the only person that decides what is in the message to be sent. Compression doesn't make it vulnerable to chosen plain-text attacks either. Mixing victims's and attacker's data before compression and encryption will leak data, yes.

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

#110

Post by tlogan »

daeken wrote: post #106
bcoates wrote: post #100

Earlier quoted context omitted.

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

Due to the nature of compression algorithms using BWT, changing a single byte in the uncompressed data might give you +/- 5 bytes difference in the size of the compressed data; that makes pulling off an attack like this much, much, much more difficult. Don't get me wrong, you'll get variance with deflate as well, but it's nowhere near the level of something like bzip2. I do a lot of experimentation with new compressi…

I would love to see somebody proving or disproving whether BZip2 is susceptible to these type of attacks. My assumption is that small changes in MTF transformation and tweaks in creating encoding table will make it impossible to crack using this method.
Post reply on HN