Is my understanding correct that the attack described there requires all of 1. cookies associated with the target, 2. the ability to monitor the length of requests to the target, and 3. the ability to send requests to the target (e.g. JavaScript injection, malicious website)?
I guess this is actually an instance where those Hollywood "guess the password one character at a time" animations would make sense.
Due to the padding of even compressed SSL segments only having timing data will significantly complicate things. You'll be trying to measure the variance in deflate compressing different blocks with single byte differences. You better have an extremely low jitter connection!
Low jitter is not a requirement for timing side-channel attacks. As long as the jitter is uncorrelated with the timing difference that you're after, you can filter the signal from the noise.
Pretty much never. How often do they make requests that are at least partially attacker-controlled, though? (Note that variants on https://www.someapi.com/...?username=foo contain attacker-controlled data...)
To expand on your second point, if you have 3, then in many cases you also have the ability to intercept and modify non-encrypted traffic. Meaning, if the victim is using a secure web site and a non-secure site at the same time, the MITM can infiltrate the non-secure site and use it to generate requests to the secure site.
I don't know what you're saying. If you're saying that the "Secure" flag won't defend against CRIME, nobody is saying that. I'm saying that the "Secure" flag and HSTS mitigates SSL-stripping.
I think both ivanr and thatwonthelp were suggesting that any non-secure site (same origin or not) can be hijacked in order to make the requests necessary for this attack.
I understand and agree with your comment about the secure flag, but if I understood ivanr's comment it doesn't apply.
you don't need to manipulate the cookies being sent, only the body of the message. The browser will send the correct cookie in the header, you control the body, and use the length of the message to determine how close the cookie value in the body is getting to the one in the header.
For CRIME, I don't think that it's necessary to control the cookies. Having control of other parts of the request should be sufficient (e.g., using request headers, request body, etc).
As for manipulating cookies from the MITM perspective, here's one clunky way to do it: redirect the victim's browser to the plain-text version of the target web site, intercept that request, and set a new cookie (pretending to be the plain-text version of the target web site). The next request to the secure version of the target web site should contain the injected cookie. As tptacek mentioned in another comment, this approach would not work with a site that uses HTTP Strict Transport Security.
The attack as Pornin outlines it does not involve controlling the cookie header, but rather on being able to get content into the client's TX stream that happens to match the cookie header; think in terms of things like query args and post data.
I think all three comments in this little subthread might be saying the same thing. Go nerddom!
Would have been fun if they called this the CPE1704TKS attack
That one was not cracked one character at a time in series, portions in the middle were discovered sooner. But, yeah, would have been a more appropriate, cooler name.
Are there credible situations where you would be able to do (2) but not able to simply read the cookie from the DOM and send it to an attacker controlled website?
An attacker can build a hidden form that submits to a URL at the victim site, and submit it repeatedly using javascript. Alternatively an attacker could put the test content in the URL (we don't care if it 404s), which would work just as well and allow them to use a series of script-free pages full of images.
edit: tptacek is absolutely right; there isn't a way to defend against this in application code. All you can do is turn off TLS compression. This is NOT by any means the only approach, it's just the most obvious one.
Careful: you're outlining the attack well, but you wouldn't want to give someone the impression that defending against CSRF also defends against attacks like BEAST.
You can't read the cookie for the victim website from a malicious site. What you can do is send POST/GET requests to which the browser will attach the appropriate cookies.
As I understand it, only 2 and 3 are needed. The (secret) cookies are the part that is determined by the SSL compression exploit, by trying subsequent parts.
You're right that Hollywood "guess the password one character at a time" animation makes sense here. It also makes sense for timing based attacks. Ie, if checking "AB" against the password takes longer than "A", you know the second character is B...
Variable time until some threshold number of repeat failures occurs (e.g. 3). After this, manipulate the comparison time in such a manner that someone attempting to do this sort of attack would come up with a dummy password. If they come up with said dummy password, alert the user of an attempted attack.
You also need the client and server to both support TLS compression. But there aren't any major sites (that I know of) which do support TLS compression.
In my quick test, about 42% of the sites in the SSL Pulse data set (~180k SSL sites in Alexa's top 1m) support compression. For example, mail.yahoo.com does.
I guess this is actually an instance where those Hollywood "guess the password one character at a time" animations would make sense.