Nathan Evans did the last talk on the first night of Defcon called De-TOR-iorate Anonymity. It had a lot of people sweating on the Tor mailing list and even generated a huge debate about whether Tor should even be attempted to be used on a multi-purpose system versus a dedicated machine or virtual machine like JanusVM or AnonymOS. The information was pretty thick to process at the time, but a few minutes later, it finally sunk in. Here's how it works.

Overview of Tor

A quick review of how Tor works. Tor is a anonymity tool that creates a circuit of proxy servers to relay connections through. For instance, in the figure below we see Alice trying to connect to Bob. Alice sends traffic to node 1, node 1 relays that traffic to node 5, node 5 relays that traffic to node 8 and node 8 finally sends the request to Bob. If Bob replies, the data travels back the direction that it came. Simple enough?

Overview of Attack

Nathan's attack would fall under the "partitioning" label as the goal of the attack is to partition the Tor network smaller and smaller until it can find the entry node the user is coming from. Because this attack assumes you have control of the exit node, obtaining the entry node confirms the second node used as a relay thus showing every node in a user's circuit. This makes Tor as anonymous as a single proxy.

Circular Circuits

Nathan found that an attacker can create looped circuits. That is Node 1 relays to Node 2 and then relays to Node 3 but at Node 3 an EXTEND command is issued so the circuit length is increased infinitely. This causes the queue of traffic waiting to be relayed to fill up and the latency to increase by a large amount.

Why it works

Doing a DoS attack and measuring the latency is not new. It was actually talked about at last year's Defcon. The difference with this attack is the attacker actually creates circular circuits so nodes are actually looping traffic back to the beginning instead of relaying properly.

This is why the attack worked:

• Tor is hard coded to only uses 3 nodes in a circuit(debatable whether or not to change)
• Tor does not provide padding to keep latency at the same rate (and never will)
• Tor allows for infinite circuit lengths (to be fixed in proposal 110)

The Attack

To attack the network, he used the following environment

1. a "Bad Exit Node" owned by the attacker
2. Tor client used to generate circular circuits (Defined as "DoS Client")
3. Web server to act as the destination and to keep track of latency (Defined as "DoS Server")
4. Normal user that is using the Bad Exit Node ("Alice")

The attack is done by a denial-of-service attack on many nodes using circular circuits discussed above. If the user's latency stays low during a circular circuit creation, then the attacker knows that the entry node is NOT one of the DoS'd relays and tries different nodes. In this case, latency is measured by injecting a javascript command to ping a web server collecting stats. The process of generating circular circuits and recording the results is repeated until the user's latency increases substantially at which time the attacker knows that the entry node is one of the three nodes used in the last DoS attack.

Example

In this figure, you can see that Alice is trying to connect to Bob via nodes 1, 5, and the Bad Exit Node that is owned by the attacker. During this time the attacker is creating circular circuits between 1, 2, and 3 which generate large amounts of traffic causing a slow down.

The Fix

Tor has been been updated at least 3 times since writing this blog. Among many other bug fixes and feature additions are the changes related to Proposal 110. This is the proposal to change Tor to handle circular circuits. The proposal splits up relay requests into "Relay" and "Relay_Early." Relay requests do not have the ability to issue the EXTEND command that is used to generate the circular circuits and Relay_Early can as these would be the beginning of the circuits.

The 0.2.0.30 version also makes an addition to block "risky" extend cells.

Relays now reject risky extend cells: if the extend cell includes a digest of all zeroes, or asks to extend back to the relay that sent the extend cell, tear down the circuit. Ideas suggested by rovv.

The fix is not complete. They are still implementing parts of proposal 110. They have to maintain backwards compatibility in case a version 1 circuit is created.

External Links

http://www.torproject.org - Tor Project Website
https://www.torproject.org/svn/trunk/doc/spec/proposals/110-avoid-infinite-circuits.txt - Details of the proposal for the fix
http://archives.seul.org/or/talk/Aug-2008/msg00148.html - just for accuracy's sake, Roger Dingledine's follow up to my explanation on the or-talk list
http://web.cs.du.edu/~natevans/ - Nathan Evan's website. Nothing there really
https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-evans-grothoff.pdf - Original powerpoint presentation called De-Tor-iorate Anonymity
https://www.torproject.org/svn/trunk/ChangeLog - the always updating changelog of Tor

Coming back from Defcon, one subject I'm now very well versed in is Tor and other anonymity networks. After sitting through what my friend called the “ten hours of tor,” I learned a lot about the inner workings and the future of what Tor has planned.

What is tor

Tor is a service that aims to allow a user's online activity to be anonymous and untraceable. It is a project that creates a network of servers to route traffic in a way to make it harder for attackers to find out where the traffic is going, or where it originated from. This is an example of what's called an onion routing network and in fact, it's the first and original one created. [If you're interested in other onion routing projects, check out JAP [http://anon.inf.tu-dresden.de/index_en.html].]

How does it work?

The Navy came up with the idea of “Onion Routing” but the EFF took the project over and this is currently how it works:

1. The Tor service is installed on the client
2. The client system is configured so that it uses the Tor service correctly and is sometimes used in conjunction with a program like Privoxy which is a web proxy server that further protects the end user
3. When the Tor service is started, it downloads a list of directory servers which keep track where valid nodes exist on the network
4. The user makes a remote request like accessing a website
5. The client establishes a circuit of nodes based on the kind of traffic you are generating [HTTP can connect to nodes that go up and down often while SSH would rather use a node that has been up for days] and it is used for the rest of the session.
6. While creating the circuit, the first node is remembered as the client's “guard node” and will be used for all future circuits relating to that type of traffic [HTTP vs SSH] while the “relay nodes”, the ones in between the guard nodes and the exit nodes, are chosen at random.
7. The traffic is then encrypted as many times as there are nodes in the circuit and forwarded over TLS/SSL
8. The first node, the guard node, removes a layer of encryption and forwards it to the next relay node in the circuit
9. This continues through the rest of the circuit until it reaches the last node, the “exit node” at which time the information is decrypted into the original data that was sent from the client.
10. The exit node forwards the information to the remote host that the client was trying to connect to and if a response from this host is required, the data travels through the same circuit backwards to the client.

When implemented correctly, the final result is that the client's traffic remains anonymous and untraceable. For the most part, that goal is successful except when you introduce adversaries to the network.

Current Challenges

The goal of anonymizing all traffic for all users at all times and doing so while relying on anonymous volunteers that have the ability to change the code is a daunting task to say the least. The main troubles the Tor developers are facing, stems from what Nick Mathewson and Roger Dingledine called “malicous nodes.” These are people that have set up Tor servers that are working “differently” than their designed purpose causing harm to the end user. In fact, Nick Mathewson and Mike Perry based some of their presentation on security challenges they are facing and how they are defending against them but although that was the most interesting part, I'm going to skip over them for now. If you'd like to see read through the presentation that Mike Perry published, you can head here: [link]

Legality of Tor:

I was explaining to a friend how Tor worked and he asked me, “Wouldn't it be possible for you to get in trouble if you were an exit node, and a Tor user was doing something illegal.” My immediate response was no you can't get in trouble because the nodes do not contain any data but then he also reminded me that to the ISP, it would look like it was coming to you. I didn't have a good response so I did some research. Here is Tor and the EFF's response to that issues:

Can EFF promise that I won't get in trouble for running a Tor server?

No. All new technologies create legal uncertainties, and Tor is no exception to the rule. Presently, no court has ever considered any case involving the Tor technology, and we therefore cannot guarantee that you will never face any legal liability as a result of running a Tor server. However, EFF believes so strongly that those running Tor servers shouldn't be liable for traffic that passes through the server that we're running our own Tor server.
[link]

There has been a case in Germany where Tor servers were confiscated during a child pornography crack down, but all the servers were returned within one days time. [link] As of today there still is no law in any country that states what legal protection or responsibility a person has involving running a Tor server but Kevin Bankston of the EFF has gone on to point out this:

Tor servers meet the definition of an Internet service provider, which means that operators are not required to know what data passed through the server... ...While it is possible for the operator of an exit node to see the data, it would likely increase their liability, because if the operator became aware of illegal activity, they would have to report it

What's planned for Tor

Roger Dingledine, Nick Mathewson, and Mike Perry outlined the future of Tor and some really cool things. Some, under request from Roger Dingledine I will not post because they are designed to circumvent firewalls and if they become publicized can be counter attacked. But one of the most interesting services that I've seen is having content hosted on the Tor network using what they called “hidden services.”

Hidden services

Tor has not only worked on forwarding information through the network and back out to the internet, but providing routing to endpoints that reside inside of the network. They call these hidden services and an example would be hosting a website. How it works is a web server connects to the Tor network and appears to users as a .onion pseudo-domain name. This is an exciting idea that is only released in the alpha stages but it looks to me to be in the same realm as the Freenet project.

Conclusions

Day 2 of Defcon was Tor day for me. There were a lot of interesting things going on that some of my friend went to but I was really interested in Tor and meeting the developers behind it. Tor is an awesome service and it's crazy to me to think about what they've created and how far they've come. I think they are facing only half the adversity they will be facing if they ever become more public. I can imagine laws being created to make using Tor illegal especially during the times we live in. I can especially envision the types of censorship that Roger Dingledine talked about but it's awesome that they are already taking preventative measures now.

External Links:

http://tor.eff.org – Tor main homepage

http://tor.eff.org/eff/tor-legal-faq.html.en – EFF's legal FAQ about Tor

http://anon.inf.tu-dresden.de/index_en.html – JAP: a German anonymity service kind of like Tor that is java based

http://www.securityfocus.com/news/11447/2 – article about an attacked on the Tor network

http://fscked.org/transient/SecuringTheTorNetwork.pdf - a temporary link to Mike Perry's presentation

http://yro.slashdot.org/yro/06/09/11/1050215.shtml - The slashdot article about the Tor servers being confiscated