
Google disables compression for OpenSSL in Chrome - SSL exploit coming? - EwanToo
https://chromiumcodereview.appspot.com/10825183
======
jgrahamc
Yes.

See: <http://security.stackexchange.com/a/19914>

~~~
nitrogen
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.

~~~
jgrahamc
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 attack instead of
CRIME: <http://www.youtube.com/watch?v=NHWjlCaIrQo>

~~~
ivanr
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.

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

~~~
ivanr
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.

~~~
tptacek
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!

------
cperciva
I think it's time for me to write a blog post entitled "on the provable
security of spiped".

Seriously, we know how to build secure cryptographic protocols. Unfortunately,
step #1 is "don't try to be backwards compatible with the horribly broken
things people were doing in the 1990s".

~~~
tptacek
What, compressing before encrypting?

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

~~~
tptacek
Can you point to an instance where you said anything like that, here or
anywhere else, before last week?

It's easy for me to believe that you've internalized "minimize data-dependent
branches in crypto code" and thus wouldn't have designed a compressed
encrypted transport.

It is very hard for me to believe that you would have spotted this flaw
immediately had anyone pointed out to you that TLS supported compression.

There is well-regarded (though not by me) crypto advice _recommending_ that
people compress before encrypting, to destroy structure in the plaintext.

~~~
sanxiyn
This paper published in 2002 does discuss this attack.
<http://www.iacr.org/cryptodb/data/paper.php?pubkey=3091>

"... both the SSH and TLS protocols support an option for on-the-fly
compression. Potential security implications of using compression algorithms
are of practical importance to people designing systems that might use both
compression and encryption."

~~~
tptacek
Yep. Great paper. Thanks for finding this.

------
tptacek
You think you have a handle on how hard it is to get crypto right. Then you
get a result like this. As an expert (not me; I'm not smart enough to say
this) would put it: "if attacker data is mixed with defender data, none of the
branches in the cryptosystem code can depend on the content".

~~~
ZoFreX
I think crypto is possibly the best example in all of software development
and/or computer science of how dangerous "unknown unknowns" are, and how a
little knowledge is a dangerous thing (although threads are a serious
competitor for the latter trophy).

I've studied cryptography theory, and I've implemented various ciphers and
attacks, and the more I learn the more certain I become that I would never,
ever use any of my own crypto code in production.

------
pbiggar
Reading the title, I thought that Chrome was turning of gzip based compression
for HTTP bodies when using SSL. According to
<http://security.stackexchange.com/a/19914> (linked above by jgrahamc), it is
in fact header compression that is TLS specific. So a giant sigh of relief
from me.

~~~
wladimir
Thanks for noting this. I also got this wrong on the first reading. Having to
drop gzip compression of the content would be terrible. I fathom that header
compression helps if you have many requests (polling etc), but for most
websites it is much less influential in bandwidth usage.

------
cryptbe
Problem 1 in Stanford's crypto class [1]:

Data compression is often used in data storage or transmission. Suppose you
want to use data compression in conjunction with encryption. Does it make more
sense to

A. Compress the data and then encrypt the result, or

B. Encrypt the data and then compress the result.

Now we know the correct answer is Neither.

[1] <http://crypto.stanford.edu/~dabo/cs255/hw_and_proj/hw1.pdf>

~~~
tptacek
If you're encrypting and storing files, the answer is (A). The question is, in
light of this result, frustratingly imprecise.

------
Reflejo
Relevant: <http://www.ekoparty.org/2012/juliano-rizzo.php>

~~~
tlrobinson
_"The good news is we've got working patches for most of the issues. The bad
news is some of them might contribute to global warming"_

Disabling compression could certainly contribute to global warming in a
relatively small way...

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

~~~
riannucci
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 :/

------
tonyb
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>

~~~
abadidea
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.

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

------
shanemhansen
While this is probably security related, disabling compression is actually a
good practice for clients which make a large number of SSL requests (like a
browser). OpenSSL allocates alot of memory per connection for
compression/decompression. See
[http://journal.paul.querna.org/articles/2011/04/05/openssl-m...](http://journal.paul.querna.org/articles/2011/04/05/openssl-
memory-use/) for a great discussion of why SSL_OP_NO_COMPRESSION might make
sense for you.

Even if you don't have direct access to the library code creating SSL objects,
there are still some tricks with ctypes, ffi, dlopen that have the same
effect.

------
tonfa
Does the attack apply to SPDY as well?

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

------
ivanr
It would be interesting to know if there were any changes in the SPDY
implementation. It too supports compression before encryption and may be
affected by the same problem.

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

~~~
Daniel_Newby
Hidden <iframe> 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.

------
alanh
Is this a disabling of compression on both ends? No DEFLATE on either requests
or responses?

Will a site using HTTPS be able to serve compressed assets (like javascript &
css)?

If not, we’ll urgently need a way for site devs to whitelist precomputed (and
thus immune) static assets for compression.

~~~
caf
It's a disabling of the optional compression at the TLS layer. HTTP content
compression is not affected.

~~~
alanh
So what, exactly, is no longer compressed? Merely the headers themselves, and
the content is not affected?

~~~
caf
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.

------
cryptlamex
CRIME researcher says 4 request are enough to decrypt:
<https://twitter.com/julianor/status/245943430570704896>

~~~
Daniel_Newby
To decrypt _each byte_.

------
sanxiyn
man sshd_config.

Compression: Specifies whether compression is allowed, or delayed until the
user has authenticated successfully. The argument must be "yes", "delayed", or
"no". The default is "delayed".

I don't know why they chose "delayed" as default, but this seems to prevent
this attack.

~~~
tptacek
The SSH protocol is nothing like TLS. The SSH security model is nothing like
the TLS security model. Pornin's guess about Thai and Juliano's attack does
not break the TLS authentication model; it breaks the confidentiality
guarantees TLS makes to the application layer. If you authenticated TLS with
certificates the way SSH authenticates with keys, you wouldn't worry about the
compression attack.

So, not so much.

