Last time, we took a look at basic browsing with Tor, the anonymizing Web relay network. At the very end of that article, we touched on how to actively participate in Tor by running your own relay. That’s when your local copy of Tor functions as a node in the network, funneling encrypted Tor traffic peer-to-peer to help increase the overall Tor network’s bandwidth. But there is even more you can do, such as running invisible services and bridges for those who need even more privacy than vanilla Tor provides out of the box.
As a refresher, all active Tor nodes are called “relays” — they pass packets between other relays. Each connection is encrypted, and no relay knows the starting point or ultimate destination of any of the traffic it relays. That’s what makes Tor impossible to snoop: the route is calculated out-of-band (so to speak), and no one on the network knows it so no one else can steal it.
But the end-user’s HTTP (or IM, or IRC, or whatever else) traffic does have to enter the Tor network somewhere. By default, whenever you launch Tor, it requests addresses of some Tor network “on-ramp” relays. Although the topography of the Tor network is constantly changing, and although the connection between the user and the on-ramp is encrypted, these addresses are public information, so adversaries could still watch the user’s connection and interfere somehow — even by crude means such as switching off the user’s connectivity.
Bridging the Privacy Gap
The solution is to have secret, unpublished on-ramp relays. The Tor project calls them bridges, in order to denote the distinction. How many bridges there are is unknown, because there is no list. The most an ISP or attacker can do to block Tor is cut off access to the public relays, but if a user has the address of a Tor bridge, he or she can still connect.
Running a Tor bridge is as simple as running a normal Tor relay. The simplest way is to install the Vidalia GUI client, which allows you to start and stop Tor functionality on demand. The project recommends you use the latest files directly from them, rather than use a distribution’s package management system, because security fixes can take too long to pass through distro review. The Linux/Unix download page links to repositories for Debian-based, RPM-based, and Gentoo distributions, as well as the three BSD flavors and source packages.
Note that this is not the “Browser Bundle” which is geared towards end-users only. You’ll need to install the “vidalia” package, which will pull in the necessary Tor dependencies. Launch Vidalia, then choose the “Setup Relaying” button. Selecting “Relay traffic for the Tor network” configures your node as a standard relay. “Help censored users reach the Tor network” is the bridge option.
There are a few options to consider in the “Basic Settings” tab. Stick with the default relay port (9001) unless you know that your ISP blocks it. Unless you have a compelling reason not to, the project also wants you to provide some sort of contact information — but it is not published. Your IP address and port number are all that Tor users see. By default, you should check “Mirror the Relay Directory,” because this is how Tor users establish connections. At the very bottom, you see “Automatically distribute my bridge address.” To run a generic bridge, leave this checked. If, however, you are setting up your bridge for the benefit of some particular friend (including yourself), you can leave it unchecked — but you will need to tell the person in question your bridge IP address and port number.
You’ll notice that the “Exit Policies” tab is grayed-out when you configure a bridge. When running a normal relay, you can set options here to limit access to particular types of traffic or block specific site requests from exiting the network at your node. But since a bridge is an entry point, those options do not apply.
That’s all there is to bridge setup. To use a bridge as your own entry point to the Tor network, visit Vidalia’s Network tab. Check the “My ISP blocks connections to the Tor network” option, which will reveal a list box where you can enter individual bridges. If someone you know is running an unpublished bridge, you can enter it directly. Otherwise, you will need to request bridge information from the Tor project.
How that works securely is a bit complicated. You can request a bridge list by visiting a special SSL-encrypted page on the Tor site; my understanding is that the project keeps track of what bridges it sends to what requesting IPs, so that evildoers cannot harvest the entire bridge collection. You can also send an email to the Tor project, and as long as you use one of the few well-known email address domains, it will return a set of bridge IDs. I assume that this information is also tracked; how to allow access to bridges without compromising their security is a hard problem.
But however you get them, simply enter the bridge IP:port information into Vidalia’s Network tab, and you can browse and network without getting blocked. All bridge IDs consist of a an IP address and port number separated by a colon, and optionally can provide a cryptographic fingerprint, although this feature does not seem to be in widespread usage.
Are You Being Served?
Essentially, bridges simply offer an alternate, harder-to-block access method to the Tor network. A more intriguing use of the software is to run an IP-based service that can only be accessed through Tor (as opposed to the Internet at large). You can publish a Web site, run a POP/IMAP/IRC server, or even make an SSH server accessible, all without ever revealing your address to visitors, and even from behind a firewall.
How is that possible? The actual traffic is routed through the Tor network, just like any other Tor data. The tricky part is making the service reachable. Tor does this by maintaining a distributed hash table of services, each of which is identified by a pseudo-random host name in the .onion domain. Whenever a new service launches, it connects to a few Tor relays (like any other relay would), then tells the hash database which relays those are. When a client makes a request to the ABCDEFWXYZ.onion host, the hash database picks one of the relays associated with the service and forwards the request on. The relays involved never know that the packets they are carrying are destined for a particular service, because the data is mixed in with all other Tor-based, encrypted traffic.
There are a few other checks-and-balances involved to protect everyone; if you’re interested, the entire protocol is documented on the Tor Web site. There you can also find a link to the Tor hidden service search engine (based on DuckDuckGo), as well as an example Web site run by the project. A key point to remember, however, is that you must be running Tor on the client side to access these services, because they are accessible only within the Tor network.
It is also important to remember that the hidden service should probably only connect to Tor on the server-side, too — in can be extremely tricky to try and run a normal Web server setup and a Tor-based .onion site from the same Apache configuration, plus, someone who finds the hidden content on your existing IP could then prove that you are the host, which defeats the purpose of running a “hidden” service entirely.
Tor recommends you take a look at a lightweight Web server like thttpd. Whichever HTTP server you choose, you should make it accessible only to localhost. Next, in your .torrc configuration file, find the location-hidden services block, and add a pair of lines like
HiddenServiceDir /some/path/to/a/place/where/you/can/keep/files/for.your/hidden_service/ HiddenServicePort 80 127.0.0.1:5222
The HiddenServiceDir directory is merely a location where Tor will dump a text file containing the .onion address for your service. The HiddenServicePort line has three parts: the “fake” port number advertised to visitors (80 here, to serve as a standard Web server), the address to bind to (here, 127.0.0.1, which is localhost), and the local port number (5222). You can also provide this information in Vidalia, in the Setup: Services tab.
Now, when you restart Tor, it will fetch a .onion host name for you, and save a private key file in your HiddenServiceDir directory. This key verifies that you are, in fact, the service listed in the distributed hash database, so that clients can connect with confidence — so don’t lose it. That’s all there is to it; you can set up as many services as you like, running anything that you care to configure and that can be ferried by Tor.
How you spread the word about your service is another matter — if you post about it on the public Internet, your foes can almost certainly associate you with it. There are in-Tor-only message boards, however, as well as community forums where people often post links to .onion services. Of course, that’s assuming you want to publish your content. As with bridges, you may also need to make something available only to specific people, or only for a short amount of time, in which case person-to-person is probably best.
Bridgebuilding and More
There is definitely a trade-off involved with both of these techniques. You cannot simply run an invisible Tor bridge and expect dissidents to find it and use it — they will have to set up and run Tor. Likewise, you cannot run an anonymous Web server dishing out Truth by the barrel-full to the whole wide world — you can only make it accessible to other people running Tor. Nevertheless, these are both exciting opportunities that without Tor wouldn’t exist at all. The initial Tor concept didn’t include either — it just goes to show you that a solid technology like Tor has more and better uses than casual Web surfing, as long as users are willing to push the boundaries. Who knows what else can be built on top of Tor?
