In the first part of this blog entry I discussed the mechanics of the Onion Routing protocol and how Tor provides anonymity. This section is going to focus on the do’s and dont’s of using Tor and how it’s not always an infallible line of defence against prying eyes.

Perhaps the most revealing document about the efficacy of Tor (at least at the time of the document’s publishing, circa 2012) was the Snowdon-leaked NSA presentation entitled ‘Tor Stinks’ (slides available: http://www.theguardian.com/world/interactive/2013/oct/04/tor-stinks-nsa-presentation-document). The key points from the slides can be summarised thus:

• The Tor protocol is fundamentally effective in achieving anonymity
• De-anonymising some users is possible
• ‘Dumb’ users will always be vulnerable (labelled as ‘EPIC FAIL’ by the presentation)
• The NSA and GCHQ operate nodes designed to de-anonymise users
• Traffic analysis attacks are the most effective and tractable tool of de-anonymisation

If we are to assume that intelligence agencies such as the NSA and GCHQ are amongst the (if not the) most well resourced and educated attackers, then the Tor Stinks presentation is testament to just how well Tor works. Nonetheless, as the presentation stated: ‘dumb’ users will always be vulnerable. So, what constitutes a dumb user and, if an individual ever wanted to use Tor, how could they avoid being dumb? In answering this, I’m going to digress into the ‘attacks’ against Tor, which I believe are essential in understanding both what makes a user fall into the ‘dumb’ category and more importantly, why.

The attacks against Tor can be classified into two types: passive and active. Passive attacks are generally observational and the most common and effective passive attacks are end-to-end timing and end-to-end size analysis, collectively known as traffic analysis. Essentially, if an attacker can view that a user sends x data to the Tor network and sees x data leave the Tor network y time later, they can induce (i.e. assume with high likelihood) that the x data belonged to that user, thus de-anonymising them.

Active attacks, by contrast, involve more direct manipulation of Tor or vulnerable services and software employed by the user. For example, if an attacker controlled all the nodes in a Tor circuit, they could simply view the traffic in real time. This attack is largely considered intractable, even for an attacker with the resources of the NSA or GCHQ (by their own admission in the Tor Stinks presentation – whether this has changed hitherto is up to speculation): the victim would have to go through an entirely attacker controlled circuit; only one non-attacker controlled node would break the chain.

Another example of an active attack includes attacking the users browser software, which is exactly what the FBI did in 2012 (http://www.wired.com/2013/09/freedom-hosting-fbi/). They took control and comprised several websites that can only be accesed via Tor and used them as a delivery mechanism to infect the (then) vulnerable browser included in the Tor bundle. Once infected, the users machine simply sent the user’s IP address to an FBI server over normal HTTP, thus revealing them.

As documented in the Tor stinks presentation, traffic analysis is the overall tool of choice for the NSA, with man-in-the-middle and web server compromises the active attack choices. In fact, The Tor Project themselves admit that Tor itself isn’t able to defend against traffic analysis versus an attacker with visibility over both the entry and exit destinations of an individual’s Tor traffic. (https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting).

The efficacy of traffic analysis was made clear in the case of a Harvard student, Eldo Kim, who emailed in a bomb threat over Tor to avoid a Final exam; Kim was swiftly identified as the prime suspect and confessed to the crime. Whilst Kim used a temporary, anonymous email account routed through Tor to hide his actions, to connect to Tor he used the Harvard Wi-Fi service, complete with his usual Harvard account details. Harvard was simply able to cross-reference users that were using both Tor and its wireless internet around the time the bomb threats were received: likely only one person – oh hey Kim. Whilst they couldn’t guarantee it was indeed Kim who sent the threat (he could have argued he was using Tor for something else), this evidence made it pretty damn likely and Kim subsequently confessed. As security researcher Bruce Schnier described in his article regarding this exact case, (https://www.schneier.com/blog/archives/2013/12/tor_user_identi.html) ‘Tor didn’t break; Kim did’.

Had Kim connected to Tor from a wifi openzone an hour away from home from a secure laptop using an up-to-date Linux distro, it is possible (and arguably likely) he would have gone uncaught. In this regard, Traffic analysis is not a result of a flaw in the Tor design itself. Its effectiveness hinges on two factors: the fact that a threat model such as a western government agency has both the resources and legal clout to support significant ‘visbility’ over the internet (and so can view traffic both entering and exiting Tor) and that a large proportion of Tor users don’t take (or more likely simply aren’t aware of) the precautionary actions that render traffic analysis and on-demand identification largely intractable.

Had Kim connected to Tor from a wifi openzone an hour away from home from a secure laptop using an up-to-date Linux distro, it is possible (and arguably likely) he would have gone uncaught. In this regard, Traffic analysis is not a result of a flaw in the Tor design itself. Its effectiveness hinges on two factors: the fact that a threat model such as a western government agency has both the resources and legal clout to support significant ‘visbility’ over the internet (and so can view traffic both entering and exiting Tor) and that a large proportion of Tor users don’t take (or more likely simply aren’t aware of) the precautionary actions that render traffic analysis and on-demand identification largely intractable.

So, what are these precautionary actions? The first steps are ‘physical’ actions: don’t connect to Tor from home. Just don’t. Use a public wifi service and, if you want to achieve amongst the highest degree of anonymity feasibility possible, wear non-descript clothing whilst rotating connection sites and accessing Tor at ‘random’ times; avoid an identifiable pattern of usage. This way the friendly Starbucks Barista can’t say ‘oh yeah that guy comes in from four to six pm everyday and just sits on his computer’ when the NSA comes a’knocking. This level of pedantry is only really warranted for those who suspect they are being actively and intensively monitored, (think Will Smith’s character in Enemy of the State) or the super paranoid. In this instance, it would also be advisable to leave your mobile phone on and at home – making it impossible to cross-reference the mobile phone’s geolocation with the location/s where Tor was accessed. There are probably myriad more precautions one can adopt in the realm of the physical world to prevent access and location cross-referencing, but I’m not a super spy (despite my James Bond-esque panache), and researching and listing them all is beyond the scope of this article.

With the physical steps out of the way, let’s address how one should actually use Tor to minimise the threat of traffic analysis. The summarised answer: create an entirely new persona when using Tor and never ever cross your ‘real’ persona with your Tor one. Accessing a Tor service and then accessing your personal Facebook account on the same computer is a sure-fire way to de-anonymisation.

With all the aforementioned steps in place, traffic analysis becomes increasingly both more difficult and less effective. But what about the other attacks against Tor (such as active attacks)? Defences that the user can employ (some active attacks are out of the users’ locus of control) involve securing their computer (read: using a patched Linux distro), being vigilant against the websites they visit and items they download, and disabling services such as JavaScript, Flash and Java, which are all frequently used as attack vectors. With all these steps in place, many of the active attacks are instantly thwarted.

To conclude part two of this blog entry, Tor is a robust service, but it can’t defend against everything. Information leakage is everywhere and Tor will only anonymise a user so far – the rest is down to their own meticulous attention to detail and well thought-out usage habits. Nonetheless, if they were to use Tor on a securely locked down computer and coupled this with extreme pedantry and obsessive lifestyle choices, I believe an individual could remain pretty much completely anonymous.