On Sun, Oct 20, 2013 at 2:32 PM, Bjoern Hoehrmann <[email protected]> wrote:
> > I was under the impression that TLS as currently deployed would still > let an attacker know roughly when and how many bytes are exchanged and > if the blogs are reasonably static and public that should be enough to > reconstruct which are being read, especially if you can capture repeat > visits (the knitting blog might feature small vector graphics with > knitting patterns, and the custom cars blog might have large photos, > so if the user downloads a lot, custom cars are much more likely). > > If the pattern of download is consistent and the passive surveillance system is keyed to look for that pattern, you're right that this is a risk. You can mitigate it as a user by downloading from multiple sites at the blog site--if you're looking at custom cars and support information and knitting, you're not going to trigger the pattern (or not as easily). A site that knows its data may be sensitive can also vary the data to avoid easy pattern matching; this might get easier with the deployment of HTTP 2.0, since multiple flows are multiplexed over a single TLS connection; deliver different in-line ads for the same content and you get different patterns. > (And in practise there are many more problems, like the blogs might be > on different hostnames and the DNS lookup gives you away, or they might > load resources from third-party hosts, so you can tell blogs that have > some video from a popular video site on them from those that have not, > simply from the client connecting to the video service after loading up > whatever blog they are interested in, and so on.) > Third party hosts are indeed a problem; it's no help if you avoid name.blogsite.example in favor of blogsite.example/name if you then point to a third party whose DNS name leaks. regards, Ted > -- > Björn Höhrmann · mailto:[email protected] · http://bjoern.hoehrmann.de > Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ >
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
