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

81–90 of 137 posts

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

#81

Post by JoachimSchipper »

__alexs wrote: post #61
cperciva wrote: post #29

Earlier quoted context omitted.

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.

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.)

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

#84

Post by __alexs »

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. )

I doubt youd even have to break SSL using that attack. Lots of people do SSL termination at the load balancer.

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

#85

Post by tlogan »

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?

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

#86

Post by mindslight »

tptacek wrote: post #80
mindslight wrote: post #78

Earlier quoted context omitted.

It's not so much that the data itself is in motion, but that online secrecy/authentication necessarily implies widely-available encryption/verification oracles. Oracles with possible implementation vulnerabilities (/features) that can be abused to answer questions such as "What's the encrypted encoding of the secret++X" or "How long does it take to check if X is valid" ?

Data in motion creates opportunities for adaptive chosen plaintext attacks that aren't present in data-at-rest scenarios. An "oracle" is a basic characteristic of a cryptosystem, not a flaw, but the "oracle attacks" you're thinking of are instances of adaptive attacks.

But it's not the fact that the data is being transported that's leading to new attacks, it's that the parties are online and responding to arbitrary messages sent by the attacker. The data itself isn't creating problems - what's new is the ability for the attacker to ask interactive questions of the parties.

When authenticating messages, a receiver necessarily gains the ability to reject a message as invalid. Adaptive chosen plaintext attacks arise when this rejection ends up containing more information than a simple Y/N. From the perspective of an attacker, the verifier becomes an oracle capable of answering say "How many bytes are valid", leading to a sub-brute-force attack.

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

#87

Post by krickle »

bloaf wrote: post #76
jlgreco wrote: post #62

Earlier quoted context omitted.

That "Guess the password one char at a time" thing also occurs in real life when people forget to use constant time comparison functions.

A better comparison function: Variable time until some threshold number of repeat failures occurs (e.g. 3). After this, manipulate the comparison time in such a manner that someone attempting to do this sort of attack would come up with a dummy password. If they come up with said dummy password, alert the user of an attempted attack.

Cool idea, but remember the botnets. I also am not sure what we gain by verifying their class of attempt if we're already defending against it.

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

#88

Post by riannucci »

forgotusername wrote: post #71

Colour me stupid, but is there something to prevent inserting indeterminate padding while sending headers? e.g. imagine a request like GET / HTTP/1.0 X-Pad: GET / HTTP/aaaaaaa Where X-Pad randomly repeats previous bytes, and perhaps 0..8 bytes of random/repeating variable-length data. By randomizing the effectiveness of the compression, surely this attack can be generally prevented by the browser? You could argue tha…

I'm fairly certain this could be defeated with a little differential cryptanalysis. Similar approaches to defeating side-channel attacks on smart card power usage have been tried and defeated :/

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

#89

Post by murbard2 »

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…

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?

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

#90

Post by peterwwillis »

tptacek wrote: post #59
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. :-)

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