How to use Tor web browser securely? [Freedom fighting]

[anon]

I guess everybody heard about Harvard student used Tor to send an 'anonymous' bomb threat http://www.forbes.com/sites/runasandvik ... mb-threat/. What he did wrong?. So Tor is not secure?... anyway, got busted, by the way im a journalist, i dont have much technical background about the best practices of how to use Tor browser. Could anybody provide me a list of how to use correctly Tor web browser?. Since my work represent a highly risk to me and my family i need to know how not screwing up because of my job.

[Pattern_Juggled]

Baneki shared out, on twitter, this useful link to an OpSec-based analysis of what (likely) happened with the Harvard case. To facilitate discussion here, I'm going to echo the text into the thread so it's available locally, as well.

Additionally, here's a rather fine-grained discussion on Tor, Tor's structural weak spots, and the relative value of Tor as compared to network security services (like cryptostorm) implemented deeper within the OSI layers. A collection of published literature on the topic can be found here.

Unfortunately, I'm likely all but useless in providing advice on do's and don'ts that constructive from a nontechnical perspective; I'm too close to this branch of tech to be able to step back and summarize effectively (or so I'm often told - which likely means that this criticism is correct). I will say that the effectiveness of traffic analysis against Tor is something that, personally, makes me leery of recommending it widely.

For those with an intuitive understanding of the topological models underlying various network security frameworks, it's fairly obvious how to deploy Tor without leaving obvious OpSec holes. For actual human beings who don't sit & fiddle with network architectures on a daily basis, this is much less likely to be the case.

Sorta can't help but point out an obvious - but still valid - fact: had he been using cryptostorm, he'd not have been caught; just sayin'...

Here's the first postmortem; full formatting & embedded links are found in the original version, linked to below in the title line - if you'd like to read it entire, that's the place to go:

On catching the Harvard bomb threat suspect using Tor
December 18, 2013 | #OopsSec | @ageis


The announcement of a criminal complaint by the U.S. attorney’s office in Massachusetts against one Harvard University student named Eldo Kim has the public musing on why one would deem this an appropriate method of delaying final exams, but for anonymity/privacy advocates as well as practitioners of OPSEC (operational security), what’s more interesting is the way he was caught.

The messages were allegedly sent around 8:30AM Monday morning to offices including the Harvard University Police Department and Harvard Crimson. They originated from a service called GuerillaMail, which advertises disposable, temporary e-mail addresses. According to the affidavit of FBI agent Thomas M. Dalton, “investigation yielded information that the person who sent the e-mail messages accessed Guerrilla Mail by using. . .Tor.” and that “Harvard University was able to determine. . .Eldo Kim accessed Tor using Harvard’s wireless network.”

Of course, Tor is the premier online anonymity software, which routes a user’s connection through several “nodes”, and if used correctly, is able to conceal their true location and identity. So does this mean that Tor is broken? Not at all. The affidavit is lacking in crucial detail about how Eldo Kim was identified, but here’s how it could have happened.

A Tor circuit is defined by the nodes that a message traverses and where it enters and exits, employing a concept called onion routing. While the list of Tor exit nodes is publicly available, “relays” where connections enter are known as well. The IP address of the exit node used by the suspect was included in a header labeled ‘X-Originating-IP’ which is tacked onto e-mails sent from GuerillaMail by default, and that IP also would have appeared in their access logs. On the other hand the address of the entry node, and the suspect’s connection to it, could be observed by Harvard via metadata analysis of a traffic flow log on their network during the time in question. It’s trivial to correlate an IP address with Tor at either end of the equation.

Harvard University is presumed to retain logs of recent network activity, and furthermore, users of their WiFi network are required to authenticate with their registered campus ID. It sounds like network administrators merely looked to see who was using the Tor protocol, or connecting to a known Tor relay’s IP address at the time the e-mails were sent. They would have settled upon Kim because his identification and computer’s MAC address was attached to the activity, and the list of people accessing Tor on campus during that time-frame, and thus the number of suspects to be questioned, is probably very small.

Security researcher @thegrugq has more to say on the police investigator’s point of view: “Clearly finals week makes it likely it is a student. Secondly, the casual phrasing of the target locations suggests someone who is familiar with the campus, again pointing towards a student. At this point, the student population that had exams scheduled for any of those locations would be the collective pool of suspects (the only people with motive). Since the emails were sent 30 minutes before the exam, that means it was likely someone who was within a sub-30m travel range of those exam halls so he can maintain his cover as a student prepared to take the exam… i.e. someone who is likely on the campus grounds already.”

The text of the actual bomb threat would have been indecipherable and unable to be captured as it traveled between Kim’s computer and the servers of GuerillaMail, since layers of encryption are applied to data in transit via Tor, and they employ SSL/HTTPS on their website. GuerillaMail had little to proffer the FBI other than the fact the message originated from Tor and when. Yet, after receipt of the e-mail and determining it was from a Tor user, authorities were able to go back in time and correlate it with Tor activity on their network, without being certain about content. They don’t even need deep packet inspection to do this, just a list of source and destination IP addresses and ports.

This raises important questions about the extent of logging and monitoring which is done by Harvard, and whether their practices are conducive to students’ privacy.

The policy titled Computer Rules and Responsibilities from Harvard’s IT department reads: “HUIT reserves the right to scan the Harvard network and systems connected to it to assist in identifying and protecting against exploitable security vulnerabilities (e.g., viruses) and to preserve network integrity and availability of resources (e.g., sufficient bandwidth).”

Upon being questioned by the FBI, Kim allegedly confessed. This is key because without that, his action might be difficult to prove definitively, since he could have been accessing the Tor network at 8:30AM on Monday for some other purpose. Until that confession, the authorities were likely only guessing, and the perpetrator could have been any other Tor user or Harvard student.

thegrugq says, “He had a clear technical plan on how he was going to do it, but I think he didn’t really account for the things that would happen afterwards.” thegrugq believes it’s likely Kim wasn’t prepared for handling the interview, which he would have faced at some point even without Tor, although “it should be noted that the FBI are trained manipulative interrogation professionals.” It seems as though the guy panicked about the exam, sent the e-mails at the last minute, but didn’t think it through fully.

Tor has seen efforts by the NSA to break it, which have not succeeded. Only in select cases using vulnerabilities that target web browsers and servers, such as a high-profile Firefox JavaScript exploit used to shut down Freedom Hosting this past fall, have authorities been able to unmask Tor users.

In this case, it’s likely that Eldo Kim’s OPSEC mistakes led to his downfall. Ultimately he may have been caught because he used Tor, rather than in spite of the fact he did. To disguise that you’re connecting to Tor, one needs to do extra configuration and use “private/obfuscated bridges” in order to avoid known entrance nodes. If he desired to not be caught, as his use of Tor indicates, he could have taken more steps to cover his tracks, such as connecting from someplace off-campus or with a VPN. He definitely shouldn’t have used the university WiFi, which would’ve easily compromised his security.

[Pattern_Juggled]

The inimitable grugq has also presented an OpSec-based review of this case; as it's fairly intricate, my suggestion is to simply pop over to his blog and read it in situ - pulling back to this thread any tidbits that may require additional discussion.

[DesuStrike]

My totally uneducated tl;dr answer would be:

1. Don't use an obscure browser. Best use the provided bundle and don't modify it, so you don't tell on yourself via browser fingerprinting.

2. Don't use tor to route through EVERYTHING. As long as you stay in *.onion land you might be safe but everything that has a destination outside that is visible to observation. And this is where TOR breaks. For example if you fetch your mails from 10 specific mail servers every n minutes and fetch a set of RSS feed every other n minutes (and so on) your traffic behavior will become a "fingerprint" by itself.
Now do the same thing only one fucking time without TOR and those dragnet bastards can match those "fingerprints" up and got you on your balls!

3. There is way more to consider, so read those links provided by PJ and Baneki!

As I said: Uneducated advice from my personal knowledge. If somebody knows better and thinks I talk major BS just jump in and correct it but I'm pretty sure I got that right.

[Kantura]

I'd say that DesuStrike makes an extremely powerful observation. I'll try and expand upon it.

Hypothetically:

I use services in "(G)overnment Friendly" territory. They have only ever been accessed via my residential IP. Suddenly they're accessed by a TOR IP. The service will have been keeping logs and they will probably have a fingerprint of my machine, my search terms, and usage stats. These fingerprints will inevitably correlate between my residential IP and the TOR IP if I don't take steps to ensure my security.

If those services can make a connection between the fingerprint of my residential IP and my TOR IP then any servers within the network I'm accessing - let's say the big G - while I'm using the TOR IP has the potential to have a fair idea of who I am with use of re-identification techniques.

"BROKEN PROMISES OF PRIVACY: RESPONDING TO THE SURPRISING FAILURE OF ANONYMIZATION".

SSRN-id1450006.pdf

(473.28 KiB) Downloaded 1611 times

I considered this paper to be revealing rather sophisticated techniques upon my initial reading of it but it has become more of an introduction to the concept of re-identification when considered in relation to the data and power that the elite corporations hold over us in these times

Consider the enormity of Google and the expansive net that their servers lay down over the entire internet. There's a percentage of sites out there that refuse to even load without a script phoning home to Google. (Better still are the sites that display their information momentarily - then black out because they just realised your configuration was anathema to their information gathering effort)

Things get really interesting when you consider the storage companies such as Akamai who are receiving requests from everybody all the time. (Check your TCP log to bear witness to the incredible scope and prevalence of Akamai - The damn thing clings to your network with more ferocity than a face-hugger)

Those storage services have doubtlessly established a fingerprint for you during your common use of the net while using your residential IP. It doesn't matter from where you access links to the information you're after because quite often, the data itself is housed in one of the major centralised storage providers, and those storage providers are designed to know exactly where {who?} you are. (Doing some research on these central storage providers, who they are, with whom they're affiliated and then proceeding to hypothesise upon what they may be capable of could provide invaluable security lessons for those of us who wish to avoid the re-identification process)

Once you start using an anonymiser, you're almost forced to kiss your old life good bye and resurrect yourself with a new profile, fingerprint and identity if you wish to continue using snitch-services...which, let's be honest, if the service is mainstream, they're typically snitch-ware. Infact, they make money out of it. Snitching has become a component part of their business model and if for no other reason, we are honour bound to let these people know that we don't take kindly to snitches, for-profit or otherwise, any more than we take kindly to governments who force us to pay taxes that are used to consistently shaft us.

In real life, snitches tend to end up buried in deep holes. Since when did snitches who happen to hide behind digital pseudonyms cease to be part and parcel of "real life"?