4 ms·
My understanding of the attack: Suppose the target web server has an endpoint /foo?probeMe=bar such that the HTTPS response will include 'bar' in the HTML. (Qu
by tomfitz 13y ago
My understanding of the attack:
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:
a@gmail.com, b@gmail.com, ..., z@gmail.com
and whichever produces the shortest response is part of the response.
Suppose the shortest is the probe for probeMe=y@gmail.com . They try another letter:
ay@gmail.com, by@gmail.com, ..., zy@gmail.com . Again, one probe will have a shorter response than the rest.
They continue, until they find larry@gmail.com .
Now they know larry@gmail.com appears in the response. Success!
- tptacek 13y agoFor what it's worth, it's not "quite an assumption"; it's an almost universal property of web applications of any significant size.
- tomfitz 13y agoYou're right. My mistake. Search functionality on sites will often exhibit this. Maybe even stylised 404 pages would too.
- citrin_ru 13y agoIt 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.
- lmkg 13y agoLike 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.