1. Introduction

We've seen that Tor network is constituted from Tor nodes, through which we tunnel our traffic to reach anonymity. So far we didn't bother with terminology, because it wasn't important; all we wanted to achieve was anonymity, which we did. But when we're trying to configure a Tor Relay, then the Tor project really gets interesting and we can't really ignore the terminology. Here are the most frequently used expressions:

Tor Node:

• Exactly the same as Tor Relay, the terms are used interchangeably.

Tor Normal Relay:

• A single machine in a Tor network.

Tor Bridge Relay:

• Are normal relays that are not listed under the Tor directory, which means that they can be considerably harder to block. We can use bridge relay when our ISP is blocking the use of Tor, but we still want to connect to it. The only difference between normal and bridge relay is that the relay is listed in a public directory, while a bridge is not.

Tor Exit/Non-Exit Relay:

• A Tor relay can be configured to be an exit or non-exit relay. A non-exit relay is a relay that doesn't directly communicate with the target network, but acts as an intermediary node in the Tor network. The exit relay is also an intermediary node, but can also be an exit node, which means that it can directly communicate with the target website. We also know that connections from exit node to the target website are unencrypted, so we can see whole traffic passing through and monitor it.

2. Tor Relays

In the following section we'll try to explain how to run a Tor relay. First we need to know that we can set-up a Tor relay practically on any operating system. If you have any spare bandwidth, you really should contribute to the Tor community by setting up a Tor relay, since it's very easy and free. But beware, by setting-up Tor relay of any kind, your external IP will be seen by the clients trying to connect to your relay.

We can very easily configure a Tor relay with a Vidalia graphical user interface by clicking on Settings –> Sharing --> "Relay traffic for the Tor network (exit relay)". This can be seen in the picture below:

We can see that there are a couple of options we can set:

Basic Settings:

• "Nickname": the nickname for our relay, in our case it is abracadabra.
• "Contact Info": our contact information if something goes wrong, so the developers can contact us. I deliberately deleted the email address from the above picture, but remember     that you have to put it in there.
• "Attempt to automatically configure port forwarding": If we click on the Test button it will automatically test whether we have the right ports opened in our firewall that is most probably implemented in our home router. For most of the home users, this test will fail, since we don't have the appropriate ports opened. In order for this test to succeed we must open the appropriate ports. The Test button functionality can also automatically detect the presence of any open ports and use those to tunnel traffic through. But let's still figure out which ports should be opened by default, with that option disabled. At a bare minimum we need to open port 9001 for relay, as seen in the above picture. If we enabled the mirroring of the relay directory then we also need to open port 9030, which can also be seen in the above picture.

Bandwidth Limits:

• How much bandwidth we would like to set aside for Tor.

Exit Policies:

• Configure which services we would like the clients to be able to reach through our Tor relay. We can choose from: websites (port 80), secure websites (port 443), mail systems (ports 110, 143, 25), instant messaging, IRC and other services.

But we must discuss the most important thing when setting up Tor relay: Should we set up an exit or non-exit Tor relay? In the introduction we already discussed the difference between the two, and the following points are summarized from [1] and should present a clear picture of whether we want to run an exit or non-exit relay.

1. Don't run an exit node from a home Internet connection, because it will draw attention to your home network. Usually, this shouldn't be too problematic, but in some countries there have been equipment seizures on accounts running an exit node. A better way of giving something back to the Tor community while still using a home Internet connection is setting up a non-exit node or a bridge node.
2. Use a separate IP for the Tor node and don't route your normal traffic through the same network as the traffic from Tor. This allows your ISP to easily recognize abuse complaints as opposed to terminating your entire Internet connectivity.
3. Register a reverse DNS name like tor-proxy.yourdomain.com, where you should also put some information about Tor, so other people know what it is.
4. Configure exit policy rules. You should block traffic like BitTorrent, which really shouldn't be used over Tor, because of its high-bandwidth requirements.

It's pretty clear that unless we know what we're doing, we should run non-exit node rather the exit node. So far we've configured Tor relay with the use of Vidalia GUI, but if we would like to do it manually, we can edit /etc/tor/torrc and add the following configuration variables: `` DataDirectory /home/user/tor/Data/Tor ``

DirPort 9030

ORPort 9001

ExitPolicy accept *:80,accept *:443,reject *:*

Nickname Unnamed

RelayBandwidthBurst 10485760

RelayBandwidthRate 5242880

Let's describe the configuration variables – summarized from [2]:

• DirPort

  • Advertise the directory service running on this port. If set to auto, the Tor will automatically pick a port for us.
• ORPort

  • Advertise this port to listen for connections from Tor clients and servers. This option is required if we want to run Tor relay ourselves. If set to auto, the Tor will automatically pick a port for us.
• ExitPolicy

  • If we're running an exit-node, then this policy specifies what we would like to accept or deny. The most basic configuration values are to accept or deny packets based on their destination port number.
• Nickname

  • Sets the nickname of our relay.
• RelayBandwidthBurst

  • Limits the number of bursts for relayed traffic to a given number of bytes in each direction.
• RelayBandwidthRate

  • Specifies an average number of bytes allowed to be relayed through this node.

After we're done setting up our relay node, we should save the settings and restart Tor. This process should create Tor relay's private keys, which are stored in the keys/secret_id_key in our DataDirectory. If we display the contents of DataDirectory, we can see that the private keys are indeed present, which is shown in the picture below:

The commands presented in the picture were issued a few moments after the Tor relay had been configured and started. We can see that the current date is a few minutes after the creation time of the private keys, which indicates that those two keys were recently created. Those two keys are critical to the operation of our relay, since they are used for encryption/decryption of the traffic passing through our relay. If someone could get their hands on those two private keys, then he could decrypt all the traffic that passes through our relay, which breaks Tor's anonymity.

Let's present one of the keys here, so we can get a better picture of the contents of those two files. The contents of the secret_id_file private key file are shown in the following picture:

We can see that the secret_id_key file contains only the RSA private key used for encryption/decryption of traffic passing through a relay.

When we restart Tor, we should notice that it takes a little bit longer to start because it's setting up and starting Tor relay. But this isn't a very good indication that Tor relay is up and running, so we'll have to check the logs. In the logs, we should have the following lines that indicate Tor relay was started successfully:

`` [Notice] Tor v0.2.2.37 (git-fce6eb1c44e87bc2). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux x86_64) ``

[Notice] Initialized libevent version 2.0.19-stable using method epoll. Good.
[Notice] Opening OR listener on 0.0.0.0:9001
[Notice] Opening Directory listener on 0.0.0.0:9030
[Notice] Opening Socks listener on 127.0.0.1:0
[Notice] Socks listener listening on port 51220.
[Notice] Opening Control listener on 127.0.0.1:0
[Notice] Control listener listening on port 45896.
[Notice] OpenSSL OpenSSL 1.0.1c 10 May 2012 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
[Notice] Your Tor server's identity key fingerprint is 'test 0B01A29C23F7C70E52D28AD5A9E70237143B7D4C'
[Notice] We now have enough directory information to build circuits.
[Notice] Bootstrapped 80%: Connecting to the Tor network.
[Notice] New control connection opened.
[Notice] Guessed our IP address as xxx.xxx.xxx.xxx (source: 208.83.223.34).
[Notice] Bootstrapped 85%: Finishing handshake with first hop.
[Notice] Bootstrapped 90%: Establishing a Tor circuit.
[Notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[Notice] Bootstrapped 100%: Done.
[Notice] Now checking whether ORPort xxx.xxx.xxx.xxx:9001 and DirPort xxx.xxx.xxx.xxx:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success)
[Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
[Notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.

The last few lines say that the Tor is checking whether the ORPort and DirPort are reachable from the outside, which they are, since the log message says Excellent. If this check fails then we need to check our firewalls and open ports 9001 and 9030. We can also see that Tor published server descriptor to the server directory to let the clients know that it's open for business and they can connect through it. Server descriptor contains information like the address, ports, keys, etc.

In the Message Log we can see the picture attached below; it says that Tor and Relay are running fine, which enhances our belief that everything is working fine.

If we're still not satisfied and would like to see our relay in action, we need to wait about an hour for relay to be added into the directory, then we can search for it on the Relay Search website. If we enter 'abracadabra' in the search box and press Search, our relay should be displayed. This can be seen in the following picture:

We searched for the search string "abracadabra", which is the nickname of our relay, so it is up and running. I've masked my external IP with xxx.xxx.xxx.xxx, but the address is there, so this is another confirmation that your relay isn't anonymous and its external IP is visible. The picture above also shows us what ports the relay will let through (80 and 443), the available bandwidth and the version of Tor running, plus some weird looking string "CwGinCP3xw5S0orVqecCNxQ7fUw", which I'm not sure what it means.

The picture we presented above also has a link "b20yYC0pV6WSYHT0mq+h6i27Ke0", which points to https://metrics.torproject.org/serverdesc?desc-id=6f6d32602d2957a5926074f49aafa1ea2dbb29ed. This address reveals the information shown on the picture below:

The picture contains a ton of information about our Tor relay, like nickname, external IP address and used port. This information is required if we want to run relay, otherwise how would clients know the IP address of the relay to connect to? It has to be seen on the normal Internet. The picture also reveals our public keys for onion-key and signing-key used for encrypting the data. It also shows the acceptable and rejected IP addresses as well as other information.

There is another web application that can discover and display Tor relays and bridges and is accessible here: Tor Atlas. The application provides useful information about the relays as well as their history, but is not as detailed as metric.torproject.org. The picture of the Atlas search query is presented below:

The nickname of the relay is abracadabra, bandwidth is 59.39 KB, and IP+port are also visible. There are also flags which identify the type of service. The flags are specifying the following things in order:

• this is exit node
• it's fast
• it's running
• it's V2DIR
• it's valid

3. Conclusion

We've seen enough information that we can decide whether we would like to help the Tor community and run a Tor relay. Home users should at least set-up a non-exit relay or a bridge, since those two options won't attract so much attention.

References:

[1] Tips for Running an Exit Node with Minimal Harassment, accessible on https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment.

[2] Tor Manual, accessible on https://www.torproject.org/docs/tor-manual.html.en.