New attack plucks secrets from HTTPS-protected pages

Thanks, I was wondering about that. BREACH sounds like a subset of CRIME.

Using that comment as a springboard:

CRIME is one of The Great crypto bug classes to be found in the last 10 years or so; it's a side channel leak based not on timing, error handling, or power consumption, but on pure traffic analysis. Seriously excellent work.

Importantly, and I think this a point Juliano and Thai undersold, the big issue with CRIME wasn't simply that it impacted TLS, but that it implicated an entire cryptographic implementation technique (one that I'd add Applied Cryptography recommends). The immediate feeling I got when I learned about CRIME was "this is going to take out a lot of systems"; it's a serious threat anywhere you have chosen plaintext and compression.

It's not surprising that there are other scenarios in TLS where CRIME works, but the big thing to learn from today's talk is that you should go out and look for other places that compress before encrypting.

Simply awesome work.

You're right. My mistake. Search functionality on sites will often exhibit this. Maybe even stylised 404 pages would too.

Like adding jitter to try and disrupt timing attacks, this increases the cost to the attacker but does not actually prevent the attack. If you send a@gmail.com a couple of times, you will get an average length. No matter how much noise, send it enough times and you can get statistical confidence in the average length.

There's also the issue that adding random incompressable junk to your packets sort of defeats the point of compressing them in the first place.

Indeed. You could do what CRIME does to TLS (I just discovered these attacks).

You could also add a random amount of random padding. It would slow down the attack linearly if the random amount is taken from a uniform distribution.

I wonder if it would be possible to make it slower by taking another distribution.

The way you implement it will be subject to a myriad of application-specific statistical analysis. To my mind, the best way to look at it is like a jigsaw puzzle.

If you just took out or added a couple pieces, the whole of the jigsaw remains the same, and it can be trivial to determine what the image is. But shuffle all the pieces into random positions each time and the picture is impossible to decipher.

Consider an HTML text that was 500KB, and included a social security number. You add some random padding in a couple places, but not much. There's still 499KB that the attacker probably already knows; he can probably filter out this familiar ciphertext until he's down to the ~1KB of ciphertext he's not positive about, and start drilling down from there. Don't put it past a clever hacker to find more techniques to discover the secret.

Randomize the whole thing as much as you can, and pray. (Or disable gzip compression for sensitive content)

Yeah, the important part is to randomize the output itself, in addition to padding. Even without the padding it makes for a significant challenge to determine just where your known plaintext is to compare from. But with enough attempts, if deflate eventually succeeds in shortening a message on a successful match, you could eventually find the matching message. Like you say, probably too long to be effective (depending on the number of random permutations and the size of the secret)

What about deterministic padding? As a (badly thought through) example: Hash the plaintext, then use the first couple of bits of that result as your padding size.

This should counteract averaging of requests. On the other hand, an attacker might work around this by adding a unique token in addition to their guess...

No, I know that part, but I mean that this method can only sniff headers, pretty much, as long as they're being compressed. They own the body, since they're injecting data into it, the only thing they don't own is the headers, which is the only thing they can guess. If HTTPS compresses headers separately, or not at all, it's useless.

For the attack to work you need to be able to eavesdrop on the ciphertext. Network protocols don't make any particular effort to prevent that, although the move from shared ethernet to switched ethernet has made it more difficult.

I think it's actually more limited than that ... they have to be able to modulate the response body through a request, which sounds really f'in difficult to do with a properly designed web application.

I'm pretty sure they need a server that responds to POST form requests with user-specified unchecked data from that form, in addition to secret data the attacker actually wants. And the more I think about it, the more I wonder how existing CSRF protections wouldn't block that already.

I really wish I could find more details on this attack; I like Ars Technica for general news but the technical details are lacking here.

Here is the attack:

Jim "Doctor Doom" Brosowski, an extraordinary hacker and renowned flip-cup player, sits in a Starbucks sipping his grande caramel macchiato. His laptop is open to a Youtube clip of cats dancing to "Stayin' Alive", while in the background a curious text box displays an application waiting for input.

Suddenly there's text flashing in the window. A Starbucks customer has just attempted to log into Hotmail! In a microsecond, the hacker's application sends packets that inject javascript code into their browser window, instructing the browser to open an iframe.

First the javascript will query a page with the user's actual e-mail address. The hacker can't see the response over the network because it's encrypted, but he can see the size of the encrypted message.

Then the previously-injected javascript will poll the iframe repeatedly with a specific URL and part of an e-mail address. As responses are returned from a web page, they will either be bigger or smaller, depending on if the compression algorithm has seen that requested text before. So by comparing the size of the original response with the size of these guessed responses, Jim can guess what the "correct" value from the original request was, piece by piece.

Since this attack can be done "in 30 seconds", it should be practical enough to perform in an open area such as a wifi cafe. For more lengthy attacks you'd need a more dedicated place to listen to traffic and inject HTML.

Another method besides injecting HTML into their browser would be to send them some spam to click on with a malicious website. But you still need to be able to listen to their responses, so it is not an attack everyone will be able to use. (But then again, that's the only time SSL/TLS really matters: against man-in-the-middle attacks)

This sounds like the most plausible theory, though it makes the attack pretty limited. It could bypass CSRF protections, which don't work with GETs.

So it sounds like an attacker needs an endpoint that contains sensitive information and puts information from a request's query parameters into the response body. I imagine tons of applications do this, but it's nowhere near as far reaching as CRIME.