The Tor Network is a powerful tool for browsing the internet anonymously and evading online censorship and web filters. Unfortunately some organizations have developed technology that makes it difficult to access the Tor Network. This tutorial explains how to create your own private Tor Bridge to bypass these restrictions.
This tutorial focuses on configuring a tor bridge server, it does not explain the basics of running a Linux Server and it assumes that you have basic Linux shell knowledge.
Step 1: Leasing a server…
Before you can setup a Tor Bridge you will need to lease a server from somewhere. Ideally this server is located in a democracy with strong digital privacy laws. The United States and most European countries are a good fit for this.
I can’t afford a server, they sound expensive, what can I do about this?
You do not have to pay for an expensive server. Cloud computing providers such as Google Cloud, Microsoft Azure, and Amazon Web Services all offer a generous free tier. These free tiers include a small Virtual Machine and some bandwidth. It’s not enough to create a high traffic relay but should be enough for a small bridge for you and a few friends.
Why should I set up my own bridge instead of using a working public one?
If the public bridges distributed through BridgeDB or Email work for you then use those. There are more people using them and depending on the observer you are more likely to blend in with the crowd than when you are the only user connecting to an IP Address.
As a drawback the public bridges are slower. Some powerful censors have the majority of public bridges blocked off. China, for example, as been extremely effective at this.
You might not want to take away precious limited bandwidth from users whom a public bridge is their only option to connect to the Tor Network.
Step 2: Considerations
Your Tor Bridge should draw as little attention as possible from outside observers. Below are a few things you should consider during setup.
- Use a public cloud provider such as Google Compute Engine or Microsoft Azure. While WHOIS data reveals the IP Address is a cloud customer and not the provider themselves, there are too many legitimate websites running on public cloud providers to justify blocking the entire provider. It would cause too much collateral damage.
- The OBFS4 protocol is designed to look like an encrypted TLS Stream. TLS over TCP Port 443 (used for HTTPS) is one of the most common use cases. Therefore I’ve chosen to access the bridge through port 443, a random four-digit port number might draw undesired attention from an active network observer. The main challenge here is not running Tor or the OBFS4 process as root while allowing it to use a privileged port number below 1024. I choose to use iptables for port forwarding.
- By setting up a Tor Bridge on a public cloud provider, you give them the ability to create a complete history of every time you connect to the Tor Network and how much data you transferred. The cloud provider cannot see what you did while connected to Tor, however, you are still sharing timestamps of every time you connect to Tor as well as the amount of data transferred while connected to Tor. Everyone’s threat model is different, consider this when deciding if a public cloud provider is safe for you to use. Is this type of metadata worth protecting? What is the cost to protect it? How severe are the consequences if you fail to protect it?
- There are a few adversaries who will block an entire network (Russia blocked Google & AWS IP Addresses in an effort to try and block telegram) just to block one app. Whenever possible setup a few bridges across different networks with a diverse range of IP Addresses, locations, and subnets instead of just one. This again depends on how much cash you have to burn to prevent your adversary from knowing you use Tor and stopping the connections. For most adversaries, a single obfs4 bridge at any ISP should suffice.
- There are some theoretical attacks where someone controlling both your middle node and exit node, could create a fingerprint of which bridges you use, and attempt to correlate traffic with behavioral information.
Step 3: Spin-up your server
Create your server, I recommend using Debian as the operating system, and connect to it over SSH.
Step 4: Initial configuration checklist
Before doing anything else you should make sure that the following tasks are taken care of:
- All system updates are installed.
- SSH Key Authentication is configured, Password Authentication should be disabled.
- Look over the various suggestions at https://www.digitalocean.com/community/questions/best-practices-for-hardening-new-sever-in-2017 and apply the ones you feel are relevant to you. Remember less can be more – decide what’s best for you.
- It might be worth whitelisting IP Addresses allowed to connect to SSH.
Step 5: Install any necessary software packages
If you are following along with this tutorial’s suggestions and are using Debian you only need to run
sudo apt-get install tor obfs4proxy, on other service providers you may also need to run
sudo apt-get install iptables which we’ll use later in the tutorial for some port forwarding shenanigans.
Step 6: Configure the bridge
First things first let’s move the default torrc to a sample file so it’s not interfering with anything we configure. Run
sudo mv /etc/tor/torrc /etc/tor/torrc.sample in your SSH Shell.
sudo nano /etc/tor/torrc and start writing out your torrc. The torrc is one of the most simple configuration files I’ve seen. It’s pretty straight forward. Take a look at the following example:
## # OBFS4 Tor Bridge Configuration ## ExitPolicy reject *:* RunAsDaemon 1 ORPort xxxx BridgeRelay 1 PublishServerDescriptor 0 ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:xxxx ExtORPort auto ContactInfo xxxx Nickname xxxx
You need to pick random port numbers for ORPort and OBFS4 Port, along with setting a Nickname and providing a contact email address. You can safely leave the nickname and contact email address as xxxx since it’s a private bridge if you were running a public bridge you would want to set a recognizable nickname and email address so people can contact you if something isn’t working quite right on your bridge.
Something to consider: To minimize the enumeration risks of running a bridge I recommend picking completely random port numbers from your ORPort and OBFS4 port. While it’s not perfect and a full port scan could still reveal that you are running a bridge, the risk of detection by your adversary drops.
Your final torrc file will look something like the following:
## # OBFS4 Tor Bridge Configuration ## ExitPolicy reject *:* RunAsDaemon 1 ORPort 8817 BridgeRelay 1 PublishServerDescriptor 0 ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:2888 ExtORPort auto ContactInfo Nathaniel Suchy <email@example.com> Nickname nsuchy
Next up we will need to add a few firewall rules to allow you to access the bridge from port 443.
sudo iptables -I INPUT 1 -p tcp --dport 443 -j ACCEPT sudo iptables -I INPUT 1 -p tcp --dport 2888 -j ACCEPT sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 2888
sudo service tor restart in your SSH Terminal and you’re ready to configure your client (Tor Browser).
Step 7: Configure your client (Tor Browser)
Finally, it’s time to configure Tor Browser to connect to your bridge. First things first open Tor Browser and open “Tor Network Settings”, check the box “Tor is censored in my country”, click “Provide a bridge I know” and paste your bridge line.
What’s my bridge line?
To get your bridge line run
sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt in your SSH Terminal. Your response should look like the following:
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERT INCLUDED HERE> iat-mode=0
<IP Address> will be the IP Address provided to you by your service provider.
<PORT> will be 443.
<FINGERPRINT> can be found by running
sudo cat /var/lib/tor/fingerprint in your SSH Terminal – the response will be your bridge’s nickname followed by a space and a string of text, your bridge line should only include that string of text (leave out the nickname and space). Finally,
<CERT INCLUDED HERE> was already provided when getting your bridge line, no further action is required here. Your final bridge line will look like the following:
Bridge obfs4 184.108.40.206:443 A1B2C3D4E5F6G7H8I9JK0 cert=A1B2C3D4E5F6G7H8I9JK0 iat-mode=0
You can now give Tor Browser your bridge line and connect to the Tor Network unrestricted.
My bridge is stuck on connecting…
For security reasons most large cloud providers have a strict default set of firewall rules (AWS calls them “security groups”, check your providers documentation for details). You will need to allow traffic on
TCP:443 for your Tor Bridge to work.
I’m still stuck
For more detailed information on configuring Tor Bridges, check the following resources…
If you are still stuck and can’t get your bridge working, consider joining Tor’s IRC Chat #tor at irc.oftc.net and someone there will help you.