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

71–80 of 137 posts

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

#71

Post by forgotusername »

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 that given enough samples the noise could be filtered and the attack still remains, but the same could be said the same for many successful patches over the years (TCP sequence number randomization, Kaminsky's DNS issue, etc.), and the number of samples required would be pretty infeasible.

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

#72

Post by luu »

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.

If you've got a provably secure protocol, what's the problem with formally verifying the implementation of the protocol?

I work in an area where bugs are very scary, so we use formal verification, and that's on top of having many more testers than developers.

From the perspective of this naive outsider, I'd would have expected FV to be worth it for security sensitive protocols. Is it that the protocols are too complex to be verified, or is it just not considered to be worth the effort?

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

#74

Post by tptacek »

luu wrote: post #72
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.

If you've got a provably secure protocol, what's the problem with formally verifying the implementation of the protocol? I work in an area where bugs are very scary, so we use formal verification, and that's on top of having many more testers than developers. From the perspective of this naive outsider, I'd would have expected FV to be worth it for security sensitive protocols. Is it that the protocols are too comple…

I'm not making an argument against formal methods. I'm saying that if you replaced TLS with a protocol with a design proof, you could easily end up less secure.

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

#75

Post by geofft »

tptacek wrote: post #67
geofft wrote: post #63

Earlier quoted context omitted.

Stupid question: does TLS's compression use the _same_ compression state for both directions of the connection? That seems hard to me, because they could be sending information in parallel, and there's no provision for syncing streams. So I suspect the attack there cannot work on TLS, and in fact the demo code posted in a comment attacks local zlib, not TLS. I think the actual attack, if it's along these lines, invol…

The attack Pornin outlined involves only the client TX stream, which the attacker shares with the defender by virtue of content-controlled Javascript.

Oh, I got Set-Cookie and Cookie mixed up in my head. You're right.

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

#76

Post by bloaf »

jlgreco wrote: post #62
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.

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.

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

#77

Post by ivanr »

xhrpost wrote: post #16
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.

I think you're correct here but how would you manipulate the cookies being sent when sending XSS requests from a different domain?

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.

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

#78

Post by mindslight »

tptacek wrote: post #45
cperciva wrote: post #42

Earlier quoted context omitted.

FWIW, that advice made more sense pre-internet, when compression formats were tighter and encryption was weaker -- the idea was that an attacker might find the key but not recognize that he successfully decrypted the data. These days, even when we don't include cryptographic fingerprints (e.g., with the hash-and-encrypt construction C = E(M || H(M)) ) there's enough structure in compression format headers to allow an…

Strong agree. One of the big philosophical problems in cryptographic engineering seems to be that much of it was designed to address data-at-rest, but most of the practical problems are about data-in-motion, and those are two different problems.

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" ?

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

#79

Post by tptacek »

ivanr wrote: post #77
xhrpost wrote: post #16

Earlier quoted context omitted.

I think you're correct here but how would you manipulate the cookies being sent when sending XSS requests from a different domain?

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 p…

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!

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

#80

Post by tptacek »

mindslight wrote: post #78
tptacek wrote: post #45

Earlier quoted context omitted.

Strong agree. One of the big philosophical problems in cryptographic engineering seems to be that much of it was designed to address data-at-rest, but most of the practical problems are about data-in-motion, and those are two different problems.

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