Re:New attack plucks secrets from HTTPS-protected pages
by tptacek on Thursday August 01, 2013 @02:41PM
(#6142443)
For what it's worth, it's not "quite an assumption"; it's an almost universal property of web applications of any significant size.
Re:New attack plucks secrets from HTTPS-protected pages
by tomfitz on Sunday August 04, 2013 @08:21AM
(#6155418)
You're right. My mistake. Search functionality on sites will often exhibit this. Maybe even stylised 404 pages would too.
Re:New attack plucks secrets from HTTPS-protected pages
by citrin_ru on Thursday August 01, 2013 @04:52PM
(#6143453)
It seems to be <!-- small random string with random length --> in html sent by server, will be useful to protect from this attack. Length of response will be always different, and this difference can't be guessed by attacker.
Re:New attack plucks secrets from HTTPS-protected pages
by lmkg on Thursday August 01, 2013 @08:11PM
(#6144573)
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 [email protected] 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.
Suppose the target web server has an endpoint /foo?probeMe=bar such that the HTTPS response will include 'bar' in the HTML. (Quite an assumption, sure.)
Suppose the target web server compresses its responses.
Suppose the attacker can make requests to the target web server, on behalf of the target user (e.g. when the target user is on an attacker-controlled webpage, and the attacker can make AJAX requests to the target web server).
In the case that the HTTP response already contains 'bar', and doesn't contain 'cbs', then a HTTP response to /foo?probeMe=bar will have a shorter length, than a HTTP response to /foo?probeMe=cbs , since compression will mean 'bar' is deduplicated.
Using this, the attacker is able to mount an Oracle attack. That is, if they know something of the form *@gmail.com , and they want to know the whole email address, they can make 26 probes, with probeMe set to: [email protected], [email protected], ..., [email protected]
and whichever produces the shortest response is part of the response.
Suppose the shortest is the probe for [email protected] . They try another letter: [email protected], [email protected], ..., [email protected] . Again, one probe will have a shorter response than the rest.
They continue, until they find [email protected] .
Now they know [email protected] appears in the response. Success!