Slashdot Mirror
BREACH Compression Attack Steals SSL Secrets
msm1267 writes "A serious attack against ciphertext secrets buried inside HTTPS responses has prompted an advisory from Homeland Security. The BREACH attack is an offshoot of CRIME, which was thought dead and buried after it was disclosed in September. Released at last week's Black Hat USA 2013, BREACH enables an attacker to read encrypted messages over the Web by injecting plaintext into an HTTPS request and measuring compression changes. Researchers Angelo Prado, Neal Harris and Yoel Gluck demonstrated the attack against Outlook Web Access (OWA) at Black Hat. Once the Web application was opened and the Breach attack was launched, within 30 seconds the attackers had extracted the secret. 'We are currently unaware of a practical solution to this problem,' said the CERT advisory, released one day after the Black Hat presentation."
Those guys are giving away all your exploits.
Sig Battery depleted. Reverting to safe mode.
Lets see, gotta have man in the middle AND requires the attacker and victim to be on the same network.
Piece of cake!
A bullet may have your name on it, but artillery is addressed to " Whom It May concern"
This is quite an ingenious attack, but I am very surprised it has taken people so long to find it, as it is very straightforward and easy to understand conceptually. Makes you wonder "how did I not think of that".
Although it may seem like the requirements of a successful attack are difficult to achieve, this may not be the case.
It is usually very easy to inject some plain-text in the source code of webpages.
On facebook:
https://www.facebook.com/photo.php/INJECT_WHATEVER_YOU_WANT_HERE/
If you view the source of that URL you can see the text "INJECT_WHATEVER_YOU_WANT_HERE" appears 3 times in the source code.
By appending the query string, on youtube:
https://www.youtube.com/watch?v=hLkugwOYbFw&INJECT_WHATEVER_YOU_WANT_HERE
And on google:
https://www.google.com/?INJECT_WHATEVER_YOU_WANT_HERE
That means that an attacker can extract secret information from a lot of the HTTPS pages that you're visiting.
When I first read about this attack, the first fix that came into my mind was to just append /* [random text of random size] */ to all text/html responses.
But this may cause troubles: if the random padding is too large, the purpose of compression
is defeated. If it is too small, workarounds may be found.
Maybe it is time to start thinking of algorithms that perform compression and encryption together, not separately?
They just make you visit a malicious website, at which point they can force you to make as many HTTPS requests as they want. They use img src IIRC.
Open the Net panel of Firebug on this page and then refresh it a couple of times. Order the HTTP requests by Size. You will see that the HTML of this page is takes the vast majority of bandwidth. Images are simply a "304 Not modified", whereas the HTML is a "200 OK" of ~41KB at this time.
So in case of Slashdot, HTML is the bandwidth bottleneck, not images.
You can start to figure out how to render the page as soon as you have the HTML (and javascript, css etc.). It's on the critical path, as the HTML is what tells you what else to download, like images. Any speed-up in transferring the HTML directly leads to lower latency on loading a webpage. Text compresses very well so the reduction is significant. The text is much larger than you think for large pages or even for small pages when you include javascript, css and so on. Even http headers are now being compressed and that on it's own turns out to be worthwhile. This is especially significant on mobile where bandwidth is low, latency is high and every bit transferred costs money (if you are not on an unlimited plan) and drains the battery.
Browse the web without Javascript and with an ad blocker. It's like moving from dialup to broadband.
While I loathe JavaScript on a professional level, I gotta say: It's time to give up the Lynx browser. There can't be that many interesting Gopher sites left!
Nevermind. RTFA for explanation.
See? Text compression in action!
"A government is a body of people usually -- notably -- ungoverned." -Shepherd Book
My personal view is that SSL provides adequate protection against casual passive observer. It would be very useful if we had means of communicating securely on the Internet, but we do not.
Go ahead and blame the technology for gross misuse and predictable outcome of errecting global trust anchors. SSL is plenty secure when used properly.
The DEFLATE and gzip formats allows multiple blocks of compressed data as well as blocks containing literals with no compression. Plus, just because the default implementation always looks for duplicate strings, doesn't mean you always have to do so. While it would add a heck of a lot of complexity, it should be possible for a web server to ignore duplicates that occur in sensitive strings, and output them in literal blocks so that they don't effect the frequency data of the rest of the stream. All without requiring any changes to browser implementations. This is far from simple, but could probably be done in a generic way for well known http headers.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
I believe you missed the key phrase "where it is most effective." The first sentence of the linked article:
Amdahl's law, also known as Amdahl's argument,[1] is used to find the maximum expected improvement to an overall system when only part of the system is improved.
The reference was to the utility of compression in this case, not the mechanics of it.
Write failed: Broken pipe