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