SSL, Gone in 30 seconds | Hacker News Reader

SSL, Gone in 30 seconds

breachattack.com

79 pointsstock_toaster13 comments

Discussed yesterday: 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.

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.

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

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/

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

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

It's harder to mitigate than CRIME, but CRIME was leaps and bounds more useful. Since you were guaranteed to have control over some reflected plaintext in the request, life was much easier. With BREACH, you have to first find a plaintext reflection, and there are certainly many page where one simply does not exist.

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.

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.

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

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.

Can you quantify "slightly"?

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?

Reply on news.ycombinator.com