I was confused about that too. They don't make the request, they force you to make the request (by putting a bunch of them as pixels in an HTML email, or by getting you to trigger some JS). I'm still not clear on how they see the traffic -- I guess the attack relies on having a packet sniffer that can see the encrypted packets go by?

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)

Thanks for the explanation. Please excuse my ignorance, but I want to understand something: the 'html injection' phase would be done by some sort of response spoofing? Also, given that I can write arbitrary javascript to their window, can't I just do something like form.onsubmit(function(){ //send credentials to my private server }); ?

Injection typically involves sniffing their connection and determining the right bits of the connection to be able to spoof your own fake response. It can be done in-between an existing connection or at the start of one.

Browsers have developed all kinds of protections to prevent different kinds of attack. In general, if your cookies have been set with the HttpOnly flag, malicious javascript can not submit someone's cookies to any site other than the original domain (as far as the browser can tell). You can't even view the cookies in javascript to be able to submit them somehow else.

But HTML forms on plaintext pages can be spoofed or injected to submit them to a fake server using SSL or to the real server without SSL, making it easy to view the form data and the server's response. If the site doesn't set the "secure" token on the cookie, existing session credentials can be viewed as well without needing to observe or force the user to log in. This is how the sslstrip program works, and why many people look to new technologies like HSTS to better protect users against these attacks.

The SSL attack in the OP could be used against a site that employed HSTS to capture data from the body of a response if sslstrip failed. If you just want cookie data, the original CRIME attack would be better as it technically works on the headers AND the body, but CRIME depends on TLS compression being enabled, while this attack uses the compression of the body (that every website uses).

>Also, given that I can write arbitrary javascript to their window, can't I just do something like form.onsubmit(function(){ //send credentials to my private server }); ?

You didn't address this question of his, it seems. I would agree that in the scenario you're explaining, it would make far more sense for an attacker to simply modify the non-HTTPS landing page in such a way that the user hands his credentials in plaintext straight to the attacker.

From what I can tell, for BREACH, you don't actually need to inject Javascript into any page belonging to the domain you want to extract secrets from; you simply need to force the user to load a hidden iframe that you control. That iframe will then make repeated GET requests to HTTPS endpoints (which does not violate the same origin policy, so this iframe can be hosted on any arbitrary domain).

Thanks! Minor nitpicks: this would fail if the login page were itself on HTTPS (as most login pages should be). Also, Hotmail no longer exists.

Hotmail was a joke :) But almost all browsers try HTTP before they try HTTPS, which is where the attack commonly comes in (or you intercept their primary request, or sslstrip, etc). Exceptions are if they're Chrome and have a whitelisted set of URLs, or support HSTS, or explicitly specified by the user or a bookmark.

The point is, the attack is there and it works, even if it doesn't work in 100% of cases.

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.

Most forms maintain the data that was entered by the user when there is a validation error. Say the attacker is after csrf token they could just use one of the fields in the form for entering their guess and it will be included in the responce.

You could do this more easily if the page included data from the GET query, something like a name or a search query or something like that, which gets echoed in the response.

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.

Arp spoofing works even over switched ethernet. With it, you can convince other machines that yours is their gateway, and then you can not only see, but modify all their network traffic.

https://en.wikipedia.org/wiki/ARP_spoofing

The rise of wifi means there is still a lot of shared ethernet.

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.

This attack is on HTTP compression, which covers only the body of the request, not the headers [1].

1. http://en.wikipedia.org/wiki/Http_compression

Yeah, so you'll have to be able to write to, but not read, the body of the request, observe the ciphertext on the wire and guess things in the body only. So this is only good for CSRF tokens and the like, and only if you can write to the plaintext you want to guess but not just outright read it.

The attack builds on the CRIME attack, which is discussed in more technical detail here:

http://zoompf.com/2012/09/explaining-the-crime-weakness-in-s...

That page suggests that guessing known text like an SSN or email address contained in the body would give them an opening to break the encryption entirely, but I don't know enough about crypto to know if that's actually a possibility.

I guess I thought they were guessing the POST data from a login form -but I see what you are saying. The POST request in URL encoded form or multi-part form data is not compressed anyway, only the response is affected by deflate. So I am curious too, how a password would be in the gzip dictionary, since it should never be sent back to the browser in compressed form.

I think the idea is to find e.g. a query string parameter that gets reflected back in the response's HTML along with a target secret. The attacker can then spawn requests and monitor the size of the response.

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.

In many web application frameworks, CSRF tokens are session scoped. So an attack might look like this:

  1. User logs in to target web app (e.g. hapless.com).
  2. User visits your malicious content (e.g. evil.com).
  3. Your page does a BREACH attack, issuing tons of HTTPS GET requests (by creating images in JavaScript, maybe) to hapless.com with query string parameters that manipulate the response.
  4. You observe the responses and recover the CSRF token.
  5. You attack the user with a standard CSRF attack on evil.com or elsewhere.

Note that this attack requires the user to interact with attacker-controlled content via a MITM'd connection.

> I imagine tons of applications do this, but it's nowhere near as far reaching as CRIME.

This is very common in web applications. Echoing query string parameters in the server response is the basis for reflected cross-site scripting, for example. And in a complex web application, tons of pages will have CSRF tokens embedded somewhere.

I do agree that CRIME is a much more dangerous attack.

Yeah, the more I think about this, the worse it is. It's certainly not as general as the original CRIME TLS exploit, but that almost makes it more insidious.

The big problem is that there's no blanket solution to this like there was with the TLS break. Then you could just turn off TLS compression, which wasn't a huge deal. Now, turning off HTTP compression is a much bigger problem. You're going to take a huge performance hit. The alternative is auditing every route in your application to ensure that it won't leak attacker info into a response - a very daunting proposition.

They create these POST requests by tricking the user into opening a malicious web page or email that they control. From that page they use JavaScript, I presume, to send a POST to the target website and monitor the packets by eavesdropping on the encrypted data upstream from the user.

So I suspect that having JavaScript disabled by default on untrusted domains would be a decent safeguard against this.