When it comes to Tor, Onion services are the equivalent to a home business. You setup your business, you advertise it so people know about it & you get to conduct business. Onion services are used by a variety of businesses, some illegal, some under scrutiny, some for fun, some legal & some to help shield clients. I will not delve into those uses, but as a research topic, Onion services can be quite interesting in my opinion since they provide an exotic approach to providing online services with a free domain name, whilst hiding the location of the server and also providing end-to-end authentication.
In this article, we will explore the basic use of an Onion service v3 using the latest Tor version as of this writing and how to securely setup the service as well as how to securely operate the service. No matter if you’re running a tiny website for fun with some friends or some large business, taking the time to ensure the website is secure will come in handy when the time will come for a malicious actor to threaten it.
Basic Onion Service Setup
An important detail here is that Onion services only support TCP applications, UDP is NOT supported. So let’s assume we’ve already setup a simple website on the port 80 on the Debian operating system and we wish to make this website accessible via an Onion service. Do note, that the port and application we wish to make accessible via the Onion service could be anything, so long as it uses TCP.
We start by installing the Tor service with the following command:
sudo apt install tor;
Now that Tor is installed, we can configure it, specifically in the file /etc/tor/torrc. We uncomment the following lines to add an Onion service that will connect to our local web server:
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80
Now we can look at the file /var/lib/tor/hidden_service/hostname to find the onion address of our new Onion service. Do note that administrative privileges are required to read the file. Bellow is an example of an onion address for reference:
5ekxbftvqg26oir5wle3p27ax3wksbxcecnm6oemju7bjra2pn26s3qd.onion
Using the Tor Browser or another Tor utility, one can now connect to the website using this address. A small delay might be needed sometimes, never more then an hour, because of the time it takes for the information to spread through the Tor infrastructure. An interesting fact here, is that the Onion service can be hosted behind a traditional home firewall because it doesn’t require any “regular” network inbound connections to be opened when connecting to the Onion service.
Augmented Setup
An interesting detail here is that as simple as it is to setup an Onion service, it’s not as easy to secure one & will never be fully secure. The Tor network provides a vast amount of protections, mainly aimed at anonymity but like any defense, one layer isn’t enough. Defense in depth is an important principle here, which is the principle of having multiple layers of defenses aimed at slowing down the enemy. So keep in mind, the more layers of defenses you can add that are manageable realistically, the better for the security of your Onion service.
In the Tor configuration file, a few features are disabled by default at this moment, but when hosting an Onion service, could provide added security. The first one is “HiddenServiceEnableIntroDoSDefense”, which when set to “1” will enable Denial of Service(DoS) defenses at the introduction point, a good first step but that isn’t full proof and can create a bottlenecks at the introduction point.
The second feature is “HiddenServicePoWDefensesEnabled”, which when set to “1” will enable proof-of-work based DoS mitigations that include a client puzzle in the encrypted portion of this hidden service’s descriptor. In other words, this will add a sort of automated “puzzle” for Tor clients trying to connect to our Onion service, which will slow down connections and help protect against DoS attacks by making it harder computationally to do a DoS attack.
The third feature is “HiddenServiceAllowUnknownPorts”, which when set to “1” will provide a mild inconvenience to port scanners that are trying to determine which ports are open on the Onion service, in our case it would be only the port 80. But by making it harder for them to determine which ports are available, we yet add another defense layer which slows down the enemy that is trying to understand the infrastructure available on the Onion service.
Following this third feature, a detail should be brought up, an Onion service can support multiple ports simultaneously by simply adding another line like bellow, in this example for the port 22:
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 22 127.0.0.1:22
The ports also don’t need to be the same on the Onion facing side and the local side. Again, the IP of the service can also be another computer or any IP that is routable & valid. Another important detail is that a single Tor instance can also run multiple Onion services at the same time by adding another set of lines in the configuration. However do note that doing so will link them together if their up time is always the same. An external observer can easily deduce this.
Operational Security
When it comes to running a service that is supposed to be secure & anonymous, operational security is critical to the security of the service. If you have the most secure lock in the world, but you give out the password to everyone, you have no security. Do note that this article doesn’t provide an exhaustive list of things to help operational security nor a complete explanation of operational security.
A few pointers here that generally help:
- Always remember that the communications between the Onion service & the software providing the service, in this example it would be a web server, is only encrypted if the protocol provides encryption. Tor doesn’t add a layer of encryption beyond the Tor software.
- Don’t expose any of the services available on Tor on the internet, because then it’s exposed & correlation can be used to determine the association between the server and the Onion service.
- Regularly recheck for information leaks that might expose sensitive information that points to the location or identity of the server actually running the Onion service.
- The up time and downtime can be used to determine the location of the server via correlation, so try to scramble those metrics.
- If providing a website that is supposed to protect the user’s anonymity, using a valid HTTPS certificate will provide added security between the Tor Onion service and the web server.
- If possible, exclusively use protocols for Onion services that support encryption to ensure a fully encrypted connection from start to end.
- Don’t become complaisant. Security evolves in both defenses & attacks.
- Don’t run a Tor relay on the same server then the Onion service, relays are very public and can be used to determine a correlation between it & the Onion service.
- Loose lips sink ships. Be careful what information you share about the system to others.
An important part of security, is accepting the fact that no security is perfect. This is why it’s recommended to review safety measures following a regular scheme as well as testing the security for new flaws that are brought about by changes in the environment & it’s context of use. Since an Onion Service is constantly being exposed, it’s a good idea to always lookout for new attacks and new defense techniques as they become public. A good topic for further reading might be the Vanguards add-on or visiting the Tor blog.