As I talked about in Part 2 you can pretty easily spin up an onion service from your existing website using EOTK. The one I made for this site is here: https://odyoxebmwfaaphqc.onion/
But what if you want to have a dedicated space in the Tor network - one only accessible over Tor? That requires that you set up a server that can deliver hidden services. It's fairly straightforward.
- You need a server somewhere. You can do this from a Raspberry Pi at home, or a VPS you have on a cloud service. I'm using a server I have that I use a lot for testing purposes, on Digital Ocean, a cloud provider I like a lot.
- You need to make sure that the Tor client is installed and running. Here are the docs for Debian/Ubuntu
- Make sure you have a web server installed. I'm now using Nginx, although I used to be a die-hard Apache fan. Either will do.
- Configure your default config to listen to something like port 8080 (actually any port will do, just not 80)
- Add a file or two to the default web directory, and verify that you can get to that via a browser on http://localhost:port (use lynx if you're on a server w/o a GUI.)
- Follow these instructions from the Tor project. Basically, this includes:
- modifying torrc (usually at /etc/tor/torrc)
- restarting Tor (checking for errors)
If Tor restarted without errors, when you check /var/lib/tor/hidden_services/ (or wherever tor was installed) you'll see a file, called 'hostname'. That's the onion. For my test onion service, it's this: http://f6iu3ub5qst5x4usxoys6fwglm57n6tovacaqqhardpiwmgw5ijx7bqd.onion/ (I'll talk about why that's so long in Part 4.) You should now be able to visit that site via the Tor browser!
Setting up a Tor Relay
As I said in Part 1 Tor works by sending traffic through relays, and stripping off layers of encryption as it goes through them. So in order to work, Tor depends on relays, largely run by volunteers. There are 3 kinds of relays: Guard/middle relays, exit relays and bridge relays. Guard relays are the first relay in the chain, and middle relays are any but the first and last. Exit relays are the last one in the chain, thus most vulnerable (both technically and legally.) Bridge relays are relays that are not listed in the public directory of relays, and thus harder to be blocked.
Because exit relays are frought and vulnerable, and they suggest that organizations should run them, and bridge relays are the lowest impact (but have a high value), I figured I'd start with a bridge relay. One note: you can't run hidden services and relays on the same server.
It's fairly easy to set up. This is a good and detailed guide, I won't outline the steps here. Make sure to pay close attention to the relay type information.
My relay has been running for just a day. It takes a few days or so for it to actually start working a lot and used as a relay. There's a tool called Nyx which can allow you to monitor Tor traffic through your relay.
Mine Vanity .onion Addresses
As you can see so far, if you go with Tor's automated key generation, you'll have an onion address is something like a random string of characters. What if you wanted an address that's more like Facebook's facebookcorewwwi.onion? There are several tools that allow you to "mine" keys. What this means, basically, is you use your CPU and/or GPU to go through generated keys until you find a name that you like.
The two tools I know of the most are Shallot and eschalot. The bigger the prefix (so if you want yournamexxxxxxx.onion) the longer it will take. I've installed eschalot on a local Raspberry Pi, and just let it go for a while. But anything more than 7 characters, unless you have a massive cluster (like Facebook did,) will take longer than you want (many days.)
You'll need some dependencies (like gcc, probably ssl headers.) Both tools have good install instructions.
Now I've outlined most of the biggest aspects of Tor. But there are some miscellaneous aspects I'd like to cover, using Tor with Python, SSL certificates, .onion versions, and some other odds and ends, so onward to Part 4.