
SSL, Gone in 30 seconds - stock_toaster
http://breachattack.com
======
tptacek
Discussed yesterday:
[https://news.ycombinator.com/item?id=6141286](https://news.ycombinator.com/item?id=6141286)

What you want to know about BREACH is that it's an application of Thai Duong
and Juliano Rizzo's extremely clever CRIME attack, a traffic-analytic side
channel based on compression and attacker chosen plaintext, but instead of
targeting compression at the TLS layer, it targets Content-encoding: gzip.

Unlike CRIME, BREACH can't directly target cookies, which is usually what an
attacker targeting HTTPS/TLS is aiming for; BREACH can only decrypt secrets in
the response body. A common example people have tossed around is CSRF tokens.

~~~
peterwwillis
A fun tool to make would be a template engine for mining dynamic content in
arbitrary web pages. You could save a page and replace dynamic content with
logic that specifies the possible values and how to probe it. The tool could
use the attack to go section by section and decipher each piece of dynamic
content until you had discovered the entire page.

One example might be to decipher a bank statement page. First the tool would
guess the first section of dynamic content (account balance), then the second
(account name), then the third (account number), etc. Though I imagine banks
already have some rate limiting protection in place.

------
JshWright
For being a slightly less useful subset of CRIME, BREACH sure does have a
solid marketing plan...

~~~
AnIrishDuck
I'm not convinced that BREACH is less useful than the original CRIME TLS
exploit. With the original CRIME POC, you could just disable TLS compression.
Pow, problem solved.

BREACH is far more insidious, because there is no "easy" solution for many
people. Disabling HTTP compression is a huge performance hit. The alternative
is auditing every single endpoint to ensure that it won't leak attacker data
into the response, which is practically an impossible proposition.

Sure, attackers have to do a bit more work to identify a vulnerable endpoint.
But developers have to do _exponentially_ more work locking down all exposed
parts of their application. Not really a good tradeoff IMO.

EDIT: there's the added bonus that BREACH stomps all over the ideal
"isolation" between crypto and application code. In fact, BREACH may indicate
that such isolation is inherently impossible: you can't write safe application
code without knowledge of the crypto you're running on.

EDIT 2: s/daunting/impossible/

~~~
sdevlin
> The alternative is auditing every single endpoint to ensure that it won't
> leak attacker data into the response,

I think you're underestimating how common this is.

For example, view source on
[https://www.google.com/search?q=pajamas](https://www.google.com/search?q=pajamas)
and look at how many times "pajamas" appears on the page.

This is a simple example, but query string parameters (and other attacker-
controlled data) get reflected in server responses all the time. Eliminating
this behavior is not a realistic goal.

~~~
AnIrishDuck
You're absolutely right. Perhaps "impossible" would be a better word than
"daunting" in my OP.

------
casca
Interesting attack that uses the fact that when duplicate data is present in
the returned packets, it will be compressed so will make the packet size
smaller. This means that it's possible to quickly converge on secret session
tokens.

The mitigation suggestions are all at the application level which will make
fixes less likely as SSL/TLS is usually considered a security silver bullet.

~~~
laumars
Disabling compression is at the server level rather than code level (and it's
a real easy config change too). However I can see that being an unfavourable
solution for some of the busier sites.

~~~
cryptic
Adding a few random bytes to a response seems to be an easy fix and doesn't
require compression being disabled.

~~~
jmillikin
Adding a random amount of random bytes will not defeat the attack, it would
only slightly increase the amount of time required by making the side channel
noisier.

Adding a fixed amount of random bytes will have no benefit at all.

~~~
quizotic
Not following your assertion. Suppose the reported size was always a random
epsilon larger than the actual size. Choose epsilon so that its small enough
to benefit from compression and large enough to obscure the BREACH. Why
doesn't that work?

