On the risks of serving whenever you surf

by sjmurdoch | December 23, 2009

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.

Comments

Please note that the comment area below has been archived.

December 25, 2009

Permalink

"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."

This idea sounds good.Will it be put into practice soon? I'm a Chinese user.

December 25, 2009

Permalink

I've had a bridge running for a few months here but it looks to have gone quiet since the 24th December. Maybe China has blocked my address, I don't know. Is there a way I can test for that? It looks like inbound connections are being reset on their end (DPI intercept?) before a connection can be established.

  1. bridge < syn < user<br />
  2. bridge > syn ack > user<br />
  3. bridge < rst ack < user<br />
  4. bridge < rst ack < user<br />
  5. bridge < ack < user<br />
  6. bridge > rst > user<br />
  7. bridge < rst ack < user<br />
  8. bridge < rst < user

or

  1. bridge < syn < user<br />
  2. bridge > syn ack > user<br />
  3. bridge < ack < user<br />
  4. bridge < rst ack < user<br />
  5. bridge < psh ack < user (ssl packet)<br />
  6. bridge < rst ack < user<br />
  7. bridge < rst < user<br />
  8. bridge < rst < user<br />
  9. bridge < rst ack < user<br />
  10. bridge < rst < user

(etc...)

Not sure what to make of it really. I don't think I've changed anything this side... (?)

* sorry it's a little off-topic *

December 26, 2009

Permalink

The current stable release of Incognito has a related problem, where unplugging and plugging in the ethernet cord at eth0 will cause an unauthorized tor server to start leaking your IP onto the internet:

NOTICE (1 of 1) Received reload signal (hup). Reloading config.
NOTICE (1 of 1) Opening OR listener on 0.0.0.0:9001
NOTICE (1 of 1) Opening Directory listener on 0.0.0.0:9030
NOTICE (1 of 1) Your Tor server's identity key fingerprint is 'REDACTED'
NOTICE (1 of 2) Now checking whether ORPort REDACTED:9001 and DirPort REDACTED:9030 are reachable... (this may take up to 20 m
NOTICE (2 of 2) inutes -- look for log messages indicating success)
WARN (1 of 2) Your server (REDACTED:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, p
WARN (2 of 2) orts, address, /etc/hosts file, etc.
WARN (1 of 2) Your server (REDACTED:9030) has not managed to confirm that its DirPort is reachable. Please check your firewalls,
WARN (2 of 2) ports, address, /etc/hosts file, etc.

It is contacting my real external IP from my exit node to see if my new unwanted server is reachable. This is a problem in any case, as it is unauthorized, but it is a very serious problem if I am using StrictExitNodes. I have just been completely identified and my potential anonymity drops to zero.

It appears that any hup will cause this behavior. And hups start to happen for various reasons after the system has been running for several hours or a day.

I'm not sure this is the place to be asking questions about Incog distro.

The Incog distro's message forum is at:

http://www.linuxquestions.org/questions/incognito-85/

I wish you the best of luck with any tor distro you use, especially from anonymous sources. I wouldn't trust any of them where closed binaries are used and where you personally didn't roll them. No disrespect to the honest and good intentioned distro maintainers out there but in today's world the philosophy is: trust no one unless you've seen the source yourself, especially when it comes to privacy soft.

January 01, 2010

Permalink

一月 02 13:24:44.031 [Notice] Now checking whether ORPort 220.170.52.39:443 and DirPort 220.170.52.39:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success)
一月 02 13:24:53.437 [Notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
一月 02 13:26:18.671 [Notice] Your DNS provider gave an answer for "bsk2xlrnxhi.invalid", which is not supposed to exist. Apparently they are hijacking DNS failures. Trying to correct for this. We've noticed 1 possibly bad address so far.
一月 02 13:26:19.187 [Notice] Your DNS provider has given "222.246.129.82" as an answer for 11 different invalid addresses. Apparently they are hijacking DNS failures. I'll try to correct for this by treating future occurrences of "222.246.129.82" as 'not found'.
一月 02 13:44:33.546 [Warning] Your server (220.170.52.39:443) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

ps:i run tor as a relay in China using a adsl internet conection.it seems that something don't work,i don't know...

It seems your relay is not working because your orport is not reachable. If you're inside china, this is expected, since China is actively blocking public tor relays.

As for the dns errors, your ISP gives answers when it should give nxdomain responses.