

Crack in Internet's foundation of trust allows HTTPS session hijacking - aspratley
http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/

======
gaunab
So for this to work, an attacker needs to be a Man In The Middle, and get the
attacked client to execute some malicious Javascript, which in turn crafts
requests to a target site which uses TLS and SPDY. The MITM intercepts and
compares the encrypted and compressed payload for recurring patterns that
result when using DEFLATE. By playing with the crafted requests, he can e.g.
guess cookie values that were added by the browser to the request (as many XSS
attacks work) by comparing the lengths of the encrypted payloads.

See [http://security.blogoverflow.com/2012/09/how-can-you-
protect...](http://security.blogoverflow.com/2012/09/how-can-you-protect-
yourself-from-crime-beasts-successor/) for technical details.

This seems to be a very basic attack, wondering why this attack vector wasn't
publicly known much earlier...

~~~
pilif
> This seems to be a very basic attack, wondering why this attack vector
> wasn't publicly known much earlier...

in hindsight everything looks very basic. If this was so simple, why didn't
_you_ come up with it?

~~~
tptacek
Maybe "basic" isn't the word I would use, but I thought the same thing. This
is one of those vulnerabilities that is completely obvious... in retrospect.

------
hendrik-xdest
Ah, so that's why Google removed TLS compression with Chrome as discussed
here: <http://news.ycombinator.com/item?id=4510829>

------
dumbdumbdumb
1\. User disables Javascript

2\. User's browser cannot automatically request resources (e.g. via img src
tag). Either user prefers to download images manually (e.g. as text-based
browser allow) or because he has fine-grained control over his name lookups
(e.g. a managed HOSTS file or authoritative nameserver on localhost). User
request the resources he wants specifically (how many would deliberately
choose to download an ad?). He does not leave download choices to browser
authors and web developers.

3\. User's browser does not advertise compression support. User does not allow
web pages to issue HTTP requests e.g. via Javacript. User downloads JSON
directly and parses it to obtain the desired resource URL's.

4\. User has no desire to compress HTTP headers. User is not interested in
SPDY.

What if someone has automated this sort of common sense approach so that it's
so simple your grandmother would find it easy to use?

Would this make security consultants, browser authors and web developers
upset?

------
pestaa
Could this be worked around with some added random-length non-redundant data
so that the 3rd party can draw no conclusions from the varying responses?

Of course this works as long as the additional deceit doesn't defeat the
advantages of compression and even then it still feels like security through
obscurity.

~~~
nhaehnle
This is not an effective workaround. Without your suggestion, the length of
encrypted packages is f(x), where x is the chosen plaintext, and f(x) happens
to be smaller if x correctly guesses one character of the secret.

With your suggestion, the length of encrypted packages is f(x) + E, where E is
a random variable (noise) _that does not depend on x_.

Because of that, an attacker simply has to repeat the attack sufficiently many
times to gather statistics on package lengths until there is one value of x
for which packages are clearly shorter on average than for the rest. This is
very similar to the type of sampling you would do in a timing attack.

So your suggestion does make the attack slightly more complicated, but
qualitatively, the system remains broken.

~~~
StavrosK
How about padding to a multiple of X bytes?

~~~
yk
The attacker controls at least part of the body such that he can select the
length of the message. If the attacker pads his guess such that the total
message length is N _X+1, then for a successful guess the message length is N_
X and for a non successful one (N+1) * X. You would need too give the message
a random length independent of the body to make this attack unfeasibly.

------
colinmarc
I don't see how this attack would work on SPDY, unless you could add arbitrary
headers to the request. CRIME works because the entire request is compressed
together, whereas in SPDY the header block is compressed separately.

~~~
yuliyp
The URL can be attacker-controlled

------
protobluffers
I never liked SPDY to begin with. It always seemed to be gratuitously
promoting a "new" protocol when many of the speed gains can be had from simply
paying better attention to existing protocols, e.g. using pipelining for
multiple resources from the same domain. A lot of the "slowness" of the web
comes from ignorance and laziness, not lack of capable protocols. It was
disturbing how much mindshare SPDY seemed to be getting just based on hype.

And TLS always seemed like a replacement for SSL, when what's really needed
are _alternatives_ to the SSL model, not a GNU clone that proclaims it can do
the same or better.

This is just my opinion. I apologise if it offends anyone.

Fortunately there are alternatives. You just have to look beyond the hype.

~~~
makomk
You're confusing SSL and TLS with OpenSSL and gnutls. TLS is basically a
revised version of SSL developed by the same groups and through the same
processes as SSL. The GNU project subsequently created gnutls, which is an
implementation of both SSL and TLS just like OpenSSL is - the only reason it's
named after TLS and the older libraries are named after SSL is because the
older ones predate TLS.

~~~
protobluffers
s/clone/revised version/

------
peterwwillis
What I hate about this vuln is there's no practical fix for many web servers
because there was never an option to disable the TLS compression. They're
rushing to backport those options now. The good thing is it seems the top
three browsers don't even use TLS compression [anymore].

