Schneier on Security

Clive Robinson • May 21, 2010 2:03 AM

Although this reseach might be exercising an old bug there is a message it is screaming out that we should not ignore.

Firstly - the attack is an early example in a class of enumerating / fingerprinting attack on browser history. As others have noted there are better attacks, so we know it's following Bruce's Maxim.

Secondly the fact that its old and of limited capability but still quite successful should be setting of alarm bells in security minded heads about what improved methods in the class of attack are capable of.

Thirdly this class of attack can be used to enumarate private networks that have no direct connection to the outside world. Thus it shows a method by which information can cross air gap security.

Forthly it gets around certain privacy enhancing technology such as TOR in ways users may not realise.

Fifthly it can be used in MITM type upstream attacks in an almost transparent manner (think of pae redirection and some of the Phorm techneiques).

Then there is the user issue. The history function is there because it is usefull to users in many ways that means giving it up on the UI side is going to be a strugle as is using "cleaning" software. The loss of functionality will not be acceptable to many power users.

This means that the issue has to be fixed on the non UI side. And this is a lowlevel in some cases protocol effecting issue.

Now I don't know about what some of you think but it has "fire alarm" level warnings ringing in my head. The reason being that just about every tie we try to fix a protocol issue we break lots of things and they in turm open up lots of security holes...

Clive Robinson • May 21, 2010 7:07 AM

@ snxue-v,

"so, use TOR is better"

Possibly not for a couple of reasons.

Firstly TOR can be subverted between you and the TOR entry node and between the TOR exit node and the destination site.

Unless both you and the site you are browsing use appropriate measures to ensure the communication channel cannot be attributed (which it appears it cannot for various reasons due to things such as choke point issues). Then a national observer can firstly deduce you have been to the site, but not nessaceraly what contnet.

They can the position themselves as a Man In The Middle at some point upstream of you (say at your ISP) and when you next browse not through TOR or via a protected channel they can do a simple page intercept and use this old attack to interegate your browser to enumerate / fingerprint it's history about which pages on the site you visited through TOR...

You will note I say "National Observer" this does not imply a Government per say but any organisation that has sufficient coverage to have the TOR entry and exit points within it's view of the Internet.

Thus a national ISP could well have access to the entry and exit nodes of a TOR network even if the trafic in the TOR network is routed internationaly.

Traffic flow analysis aided by "timing jitter injection" will fairly easily identify the two TOR end points (and yes there is research work to show this that has been presented at PET and other conferances).

Clive Robinson • May 27, 2010 2:01 AM

@ Hoo,

"But if there is an eye on your gateway or router..."

If they are on the gateway they will always be able to see you are activly using the network. The further the eye is up stream of you the less chance they have of seeing everything or of digging it out of the network noise.

What else they can see (ie packet size, timing, headers, content) is dependant on what software you use on your computer.

However there are issues with how much you can hide things like packet timing some are human some technical.

For instance there is a technical problem of "time out window" that is built in at various levels that decides on when the response is "lost" and thus retried or dropped.

Likewise is the human issue of not liking slow or unresponsive behavior on the network even if it is for the users protection...

Thus in theory you will nearly always leak sufficient information in an "interactive" session for a suitably attentive watcher "to nail your hide to the tree".

There are ways this leaking issue can be reduced and also reduce latency.

For instance a minor change or two to "HTTP traffic" would reduce the amount of traffic from a site to your browser. That is if part of the protocol was to send a tagged list of objects with time stamps the browser would only need to download what was not in it's own cache.

So for instance this blog page, if your browser only requested the data after the time of your last download it would just get this and one or two other comments not the whole page...

However to work effectivly it needs proper enforcment of objects and their tagging at the server end which is something that currently not done thus prevents it.