On the risks of serving whenever you surf

Bridge nodes are one of Tor's key architectural components for allowing wide access to the network. These act like normal Tor nodes, except there is no centralized list available to download, so it's harder to block access to all of them. Users who cannot access the Tor network in the normal way can find the IP addresses of a few bridges, and connect to the rest of the Tor network via these nodes. The bridge node IP addresses are distributed in a way such that anyone should be able to find a few, but it should be difficult for someone to find (and block access to) them all. Currently they are available by email or the web, but more strategies are being considered, such as instant messaging or MMORPGs.

For the bridge system to work well, Tor needs lots of volunteers to run bridge nodes, as otherwise there would be so few that they could all be easily discovered and blocked. To increase the number of such nodes, it has been made easy to set up a bridge, just by clicking the "Help censored users reach the Tor network" in the Vidalia preferences. More could be done however. For example, the default Tor configuration could be set to make Tor clients automatically a bridge if they are reachable from the Internet and sufficiently reliable.

A positive aspect of this approach is that there would be vastly more bridges, improving both accessibility and performance of the Tor network. It may also improve the security of Tor clients which act as bridges. For example, doing so gives the client plausible deniability – traffic coming from a Tor node might be generated by the node operator, but it might be from somewhere else. There may be however other ways in which it could harm security.

This was the subject of a recent paper, presented at the 2009 Workshop on Privacy in the Electronic Society by Jon McLachlan and Nicholas Hopper "On the risks of serving whenever you surf". This paper presented a potential attack, which made use of three aspects of Tor's bridge architecture:

• By making use of a set of proxy servers, including Tor itself, it is possible to find quite a large number of bridge IP addresses
• It is possible to probe when a bridge node (and thus the user's PC) is running
• Traffic flows going through a Tor node affect each other – a high bandwidth flow will cause others to slow down.

By combining these aspects, the authors suggest that it might be possible to de-anonymize a pseudonymous Tor user who is also running a bridge. The basic technique is to find a list of candidate IP addresses, by trying to find as many bridge IP addresses as possible (the authors found about 3% in their tests). Then, over a few weeks or months, the attacker monitors what the pseudonymous Tor user is doing (e.g. blogging), and simultaneously whether the bridge nodes are running. If the user does something, and a bridge node is down, then clearly that bridge does not belong to the user. Eventually there are only a few candidate IP addresses left, and so the attack moves to the next stage.

Here, the attacker uses a variant of the clogging attack, in which the performance of a Tor node is monitored, while the pseudonymous Tor user is sent lots of data. If the performance of the node drops dramatically, at exactly the same time that the pseudonymous Tor user is being attacked, then it is likely that node is on the path in use. In this way, the candidate IP addresses can be trimmed down leaving one or very few nodes which are likely that of the Tor user being attacked.

There are a few ways in which Tor users can defend against this attack, and the authors of the paper suggest a few modifications to Tor which do improve the situation. In addition, bridge node operators can defend themselves by leaving their node running even when they are not using it for anonymous browsing. The attack also relies on being able to track a user over a long period of time, so long-term pseudonyms are problematic (for other reasons too). In the specific case of blogging, one good idea is to post entries with a random delay, to hide exactly when they were published, as suggested by Global Voices.

The paper goes into much more detail than covered in this blog post, so do read it if you would like to find out more about how precisely how the experiments were performed. For example, the experiments perform the clogging attack on nodes with fast network connections and comparatively slow CPUs, and their proposed defence makes this assumption. In the case of many bridge nodes, for example on domestic DSL lines, the situation could be very different, and variants of the attack might circumvent their protection. While this paper is an excellent start, there is much more that can be done in analyzing and defending against these style of attacks.

bridge < syn < user<br />
bridge > syn ack > user<br />
bridge < rst ack < user<br />
bridge < rst ack < user<br />
bridge < ack < user<br />
bridge > rst > user<br />
bridge < rst ack < user<br />
bridge < rst < user

bridge < syn < user<br />
bridge > syn ack > user<br />
bridge < ack < user<br />
bridge < rst ack < user<br />
bridge < psh ack < user (ssl packet)<br />
bridge < rst ack < user<br />
bridge < rst < user<br />
bridge < rst < user<br />
bridge < rst ack < user<br />
bridge < rst < user