- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 3 Nov 2016 14:08:07 +1100
- To: Matthew Kerwin <matthew@kerwin.net.au>
- Cc: Vlad Krasnov <vlad@cloudflare.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 3 November 2016 at 13:55, Matthew Kerwin <matthew@kerwin.net.au> wrote: > If it's pushed down to the transport layer, isn't it just an even less safe > version of draft-kerwin-http2-encoded-data? (I said no shared compression > context between different frames, this is about sharing contexts between > completely different streams!) That is certainly a valid way of looking at this. It's possibly true that you can avoid the nasty pitfalls here by only using this for streams that are safe. For instance, you might use this over static resources. BUT... just by altering the order of requests, the size of resources can change, particularly if you know where the compression window cuts off. That makes me very wary about making assertions about what is and isn't safe. Example: You only use this technique over a set of static images (which should already be compressed, but we're looking for entire images). The attacker is able to cause a browser to make requests. The attacker can therefore cause the window to be filled with images that it knows about. It can then use the size of the page load to learn things about the images that were in that page load. An attacker maybe can't force a full network fetch, so it might have to deal with caching but it can maybe find images that share pieces with images of interest. With a finite set of target images, you can get a lot of information, especially if you are able to repeat the trial.
Received on Thursday, 3 November 2016 03:08:40 UTC