Jim February 14, 2012 8:17 PM

Very respectfully Bruce,

Can you give us a bit more context about these articles that you find interesting, please?

Daniel February 14, 2012 11:20 PM

I understand the link discusses a proof on concept but I fail to be impressed. As I understand it this is the key “The tool tries to match the image sizes to the recorded (x,y,z)-triplets in the database and then tries to cluster the results into a specific region.”

This seems less like a PoC for traffic analysis and more like “hey guys a figured out a flaw in Google Maps design”. Maybe that his point. That Google Maps has a weakness that makes traffic analysis over SSL possible (at least in theory). But honestly, if being able to figure out someone stock portfolio via traffic analysis doesn’t scare the bejesus out of his target audience, I’m not sure locating lost Fido in the suburbs of Paris will.

bob February 15, 2012 2:59 AM


Did you try clicking on the link. Given the article, particularly one with such a clean headline, I’m not sure what you mean by “context”.

atrisk February 15, 2012 4:26 AM

He tries to make a point, so the example is not that relevant.
Suppose he used a bank site as testcase.
Without being able to see any of your data, I conjecture he could track your moves through the site, see if you have savings accounts, stocks, .. etc. The IRS could find that interesting enough, imho.
You can find other sites were this type of information leak would prove valuable to third parties.

David February 15, 2012 6:30 AM

I actually attended Vincent’s presentation at RuxCon (in Melbourne, Australia) and wrote my own review of his presentation.

The article was written within an hour or so of Berg’s presentation, so I apologise for the somewhat breathless nature of the report.

However, as others have mentioned just above, this certainly opens up the idea of side-channel attacks to a whole slew of possible targets (as a related example, I recall someone writing recently of a traffic analysis method to detect what you’re searching for by analysing the dynamic drop-down that Google so generously provides in some browsers).

Dom De Vitto February 17, 2012 9:59 AM

This is exactly why OpenSSH inserts extra padded data into the flows, to prevent timing attacks, and compression/content/size mapping attempts.

If you’re worried about this, just have every response your server transmits include a X-ignore-this: header full of other stuff to pad all responses to the same (compressed) size. It’ll mess with performance, but that’s a fix.

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.