- 1 Tor Hidden Services - EASY
- 1.1 Introduction
- 1.2 Hidden Webserver
- 1.2.1 Whonix-Gateway
- 1.2.2 Whonix-Workstation
- 1.2.3 Debugging
- 1.3 Tips settings up any hidden service
- 1.4 Important Upstream Bugs
- 2 Tor Hidden Services - ADVANCED
- 3 References
Tor Hidden Services - EASY
Be sure to read and understand Tor: Hidden Service Protocol (general information) and Configuring Hidden Services for Tor (standard setup, no isolated proxy) first. Note that hidden services are always only reachable using Tor or tunnel services, such as tor2web, (be careful).
You do not need SSL , because connections to Tor hidden services are end-to-end encrypted by default.  This is handy, as you do not have to bother with self signed certificates or certificate authorities.
Another interesting property is they can serve as a drop-in Global Server Load Balancing and Layer 3 DDoS-resistance solution. This raises the bar to withstanding attacks that the entire Tor network can tolerate. Same with I2P Eepsties. Tor can be also considered a very simple to configure encrypted transport alternative to IPSec.
An adversary can see whether the service (and presumably Tor) is up and running or not.
Below on this page is an example for a Hidden Webserver. On the VoIP page is an example for a Hidden VoIP Mumble Server.
Even if someone hacks your hidden server software (lighttpd, thttpd, apache, etc.), the attacker can not steal your hidden service key or bypass Tor, see Attack on Whonix. The key is stored on the Whonix-Gateway. Once you cleaned your Whonix-Workstation, no one can impersonate your hidden service anymore.
While using Whonix we're quite confident that there are no IP/DNS leaks, but hardening the server software is still left to the user. In the Security Guide and in the Advanced Security Guide you'll find pointers for hardening.
Beware of application level leaks. See Protocol-Leak-Protection and Fingerprinting-Protection for definition. Some of these instructions are paraphrased from Sarah Jamie Lewis' write-up after running OnionScan on the Onion web. All credit goes to her. OnionScan is an open source pen-testing suite that exposes misconfiguration errors that expose Hidden Servers. Do run it before your service goes live.
- Avoid Apache. It has much more functionality, leak potential and attack surface than smaller and lighter alternatives. Nginx is a recommended alternative, its good practice to setup access to your site through reverse proxies to mitigate layer 7 DoS attacks and information leaks about your setup.
- Disable banners for SSH, FTP, SMTP and HTTP servers which leak info about the a daemon's name and version. If your SSH instance is for private use, use it with an Authenticated Hidden Service to protect your server from brute-force and remote exploitation.
- As a rule, each service you host should get its own dedicated onion address to prevent correlation between multiple instances running in the same VM.
- ALPaCA is an advanced website fingerprinting client/server mitigation in development that applies server-side padding to requests sent out to Tor Browser. Once ts ready, service operators can run it to protect against this class of correlation attacks.
- If you are using the Apache web server, it is advised to install libapache2-mod-removeip as well. A combination of Apache and mediawiki without libapache2-mod-removeip being installed, wouldn't be the optimal case, since mediawiki by default puts IPs of anonymous editors in the public accessible editor logs. The IP would be 10.152.152.10. That could not be used to identify you, because that is not your real external IP address, but it would identify the server as a hidden service behind a Whonix-Gateway.
Therefore any instructions on how to hide the IP address for your specific server software should be applied. Also other hardening instructions are recommended to apply. For example,
- If you are using the Apache web server, see the following footnotes. 
|You are better off not using Apache! We do not have a suggestion for a privacy friendly web server yet. That is still TODO. See ticket, document identity correlation attacks and defenses / Removing Apache Recommendation. Help welcome!|
On your Whonix-Gateway:
Step 1: open /etc/tor/torrc
Step 2: edit /etc/tor/torrc
(all Whonix platforms)
You need to add two settings to /etc/tor/torrc.
- A HiddenServiceDir configuration directive declaring where hidden services files (hostname file and private key file) should be stored.
- A HiddenServicePort configuration directive declaring,
- the virtual port and
- the IP and port of the Whonix-Workstation that will run a server service that processing incoming hidden service connections.
To do that, add the following two lines.
The IP-of-Qubes-Whonix-Workstation-AppVM needs to be replaced with the actual IP address. To find out the IP address of the Qubes-Whonix-Workstation AppVM, the following command can be run within the Qubes-Whonix-Workstation AppVM:
HiddenServiceDir /var/lib/tor/hidden_service/ HiddenServicePort 80 IP-of-Qubes-Whonix-Workstation-AppVM:80
HiddenServiceDir /var/lib/tor/hidden_service/ HiddenServicePort 80 10.152.152.11:80
(all Whonix platforms)
Step 3: make changes to /etc/tor/torrc take effect
Step 4: get your onion hostname
To get your Tor hidden service url.
sudo cat /var/lib/tor/hidden_service/hostname
Reminder: Always backup the hidden service key. This is necessary in order to restore it on another machine, on a newer Whonix-Gateway, after HDD/SSD failure, etc. Follow the instructions below to find its location; root permission is required to access it.
On your Whonix-Workstation:
Step 1: Install Server Software
Run the following commands to install lighttpd.
sudo apt-get update
sudo apt-get install lighttpd
Step 2: Open Whonix-Workstation Firewall Port
Non-Qubes-Whonix: You can skip this.
Open firewall port access for the application between Whonix-Gateway and Whonix-Workstation.
sudo iptables -I INPUT 5 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
Unless setting up a web server, change the port number from 80 to whatever the application requires.
To make the firewall rule persistent, add the rule to the rc.local file and make it executable.
kdesudo kwrite /rw/config/rc.local
Add the following in the rc.local file.
#!/bin/sh sudo iptables -I INPUT 5 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
Make the rc.local file executable.
sudo chmod +x /rw/config/rc.local
TODO: Update for Whonix 14 (not yet released) EXTERNAL_OPEN_PORTS.
Step 3: Final Notes
Note, that it may take up to 30 minutes (or so?) until a fresh .onion domain gets reachable.
sudo ls -la /var/lib/tor/hidden_service/
In case you manually restored your hidden_service keys as root, Tor will fail to start. The folder must be owned by debian-tor. In that case, fix the permissions.
sudo chown debian-tor:debian-tor /var/lib/tor/hidden_service/
Check if the service is available on 127.0.0.1:80.
## Circumventing Whonix curl stream isolation wrapper. UWT_DEV_PASSTHROUGH=1 curl 127.0.0.1:80
Qubes-Whonix: In Qubes-Whonix-Workstation, check if the service is available on Qubes-Whonix-Workstation IP, port 80.
## Circumventing Whonix curl stream isolation wrapper. UWT_DEV_PASSTHROUGH=1 curl $(qubesdb-read /qubes-ip):80
Non-Qubes-Whonix: In Whonix-Workstation, check if the service is available on 10.152.152.11:80.
## Circumventing Whonix curl stream isolation wrapper. UWT_DEV_PASSTHROUGH=1 curl 10.152.152.11:80
Note: Tor Browser will allow connections to 127.0.0.1:80 but not to 10.152.152.11:80.
Please test the example Hidden Webserver above first. It helps understanding this in general and will ease debugging.
Quoted from the Tor manual:
HiddenServiceDir DIRECTORY Store data files for a hidden service in DIRECTORY. Every hidden service must have a separate directory. You may use this option multiple times to specify multiple services. DIRECTORY must be an existing directory.
Quoted from the Tor manual:
HiddenServicePort VIRTPORT [TARGET] Configure a virtual port VIRTPORT for a hidden service. You may use this option multiple times; each time applies to the service using the most recent hiddenservicedir. By default, this option maps the virtual port to the same port on 127.0.0.1 over TCP. You may override the target port, address, or both by specifying a target of addr, port, or addr:port. You may also have multiple lines with the same VIRTPORT: when a user connects to that VIRTPORT, one of the TARGETs from those lines will be chosen at random.
Read the Security Guide.
Important Upstream Bugs
- HS intro points overloaded with CREATE cells cause connectivity failures
- Possible bug, if too many people try to access the same hidden service
Tor Hidden Services - ADVANCED
How Onion Services Connections Work
To understand how onion services work, a simple overview of the process is outlined below. 
Step 1. Onion services advertise their existence in the Tor network. This is done by randomly picking some relays and building circuits, before asking these relays to act as introduction points by providing the service's public key. The onion server's location (IP address) is shielded.
Step 2. The onion service generates a onion service descriptor containing the public key and a summary of introduction points. This is signed with its private key and then uploaded to a distributed hash table, so users can find the service when searching for a .onion resource.  This also forms an important verification mechanism for the user to confirm they are talking to the right onion service.
Step 3. The user who learnt that the .onion resource exists requests more information from the database, by downloading the descriptor from the distributed hash table. If the descriptor exists, the user now knows the introduction points and the right public key to use. The user also creates a Tor circuit to another randomly picked relay to use as a rendezvous point (with a one-time secret).
Step 4. If the descriptor is present and the rendezvous point is ready, the user assembles an "introduce message". This is encrypted to the onion service's public key and includes the rendezvous point address and the one-time secret. The user requests this be delivered to the onion service (via a Tor circuit) anonymously, so the IP address remains hidden.
Step 5. The onion service decrypts the user's introduce message and finds the rendezvous point address and one-time secret in it. The service creates a circuit to the rendezvous point and sends the one-time secret to it in a rendezvous message. The onion service must use the same set of entry guards when creating circuits, to prevent attackers from forcing onion services to use corrupt relays as an entry node (and learning the onion server's IP address via timing analysis).
Step 6. The rendezvous point notifies the user the successful connection has been established. Both the user and onion service use their circuits to the rendezvous point for communication. The rendezvous point relays end-to-end encrypted messages from user to service and vice versa.
Use of .onion addresses leads to a 6 relay arrangement: 3 picked by the user (with the third used as a rendezvous point), and 3 picked by the onion service. The final successful connection between a user and a onion service is represented in the picture below.
Figure: Alice (User) and Bob (Onion Service) Successful Connection 
Hidden Services Security
Not Whonix specific! Talking about Tor in general.
How safe are Tor Hidden Services?
This is a difficult question. Therefore state relevant facts, quotes and links here.
- At time of writing there are no known attacks used in the wild constantly deanonymizing Tor hidden services.
- 80 bit name hash and RSA-1024 sized keys
- Quote Mike Perry ): http://email@example.com/msg05418.html
- Quote Mike Perry: http://firstname.lastname@example.org/msg05462.html
- Also see, The Tor Project Blog: Hidden Services need some love.
- Non-Hidden Hidden Services Considered Harmful: Attacks and Detection 
Hidden Service Authentication
By default Hidden Service names are known to the public as they are broadcast to Hidden Service directories. This information becomes sequestered in search crawlers allowing anyone to try and connect and probe your Hidden Server even if this wasn't your intention.
To set up a Hidden service in a private mode, only accessible by just you or additionally your trusted associates, there is a little known feature in Tor feature known as Hidden Services Authentication.  When activated, no one (not even the Hidden Service Directories) can derive your .onion address from the descriptors nor can they know the introduction points to your server and consequently will not be able to connect to you.
This feature allows the HS operator to generate multiple shared secrets - giving access to different parties which is revocable. Configurable with the "stealth" auth type used with HiddenServiceAuthorizeClient. Meaning that clients who are banned will no longer know about the HS' introduction points anymore.
See the following example. Adjust it for your purposes and add it.
HiddenServiceDir /var/lib/tor/hidden_service/ HiddenServicePort 22 127.0.0.1:22 HiddenServicePort 5900 127.0.0.1:5900 ## syntax: ## HiddenServiceAuthorizeClient auth-type client-name,client-name,… ## The auth-type can either be 'basic' for a general-purpose authorization protocol or 'stealth' for a less scalable protocol that also hides service activity from unauthorized clients. ## Valid client names are 1 to 16 characters long and only use characters in A-Za-z0-9+-_ (no spaces). HiddenServiceAuthorizeClient stealth 1234567890123456
To get your Tor hidden service url and password, run.
sudo cat /var/lib/tor/hidden_service/hostname
Should show something like this.
xxxxxxxxxxxxxxxx.onion 0123456789012345678901 # client: 1234567890123456
This is the authentication cookie that was generated by Tor that should be shared with the one supposed being allowed to connect,
- preferably face-to-face or,
- or via OpenPGP encrypted e-mail or OTR encrypted chat over Tor involving both parties.
Note that you can generate a unique authentication cookie for every individual or group you grant access to. This gives you the ability to revoke access if the need arises. It is an all or none rule for granting access to a hidden service. If you want to limit that on a subdomain level you are advised to implement it by compartmentalizing your services under different Hidden service addresses running on a Multiple Workstation setup.
HidServAuth <onion-address> <auth-cookie>
Notes about End-to-end security of Hidden Services
Hidden services are not really "end-to-end" encrypted, they encrypted only Tor to End. (or "Tor to Tor") The communication between the browser or server and Tor is sent in clear text. This doesn't really constitute a security issue, as localhost (or Workstation to Gateway on an isolated network), is supposed to be secure. But it has some security implications:
With hidden services alone, without TLS enabled, the adversary only needs to compromise Whonix-Gateway to get knowledge of the content of the connection and the clients identity/location. To compromise the content of the connection, the adversary only needs to compromise either the gateway or the workstation.
With hidden services, and TLS enabled, an adversary needs to compromise Whonix-Workstation to gain knowledge of the content of the connection. The adversary would have to compromise Whonix-Gateway as well, to gain knowledge of the client's identity/location.
It is possible to use hidden services and TLS at the same time, i.e. https://****************.onion. There are only a very few hidden services reachable over TLS. For example https://pad.riseup.net/ can be reached over https://5jp7xtmox6jyoqd5.onion/. But since this only offers benefits to users of Whonix (and other Tor gateway implementations), there is no demand. It would provide some nice defense in depth as it eliminates a single point of failure.
It would open the question, how would the certificate be verified?
That's simple for private sites, where server and clients know each other. They simply verify it over preshared secure channel, for example, a meeting.
And public hidden services? It is unlikely, that certificate authorities will give out certificates for .onion sites. Startssl.com declined, because .onion is no .gTLD, see Bug #6116: apply for .onion gTLD at IANA. Although you could try asking other certificate authorities, if they offer SSL certificates for people who can prove that they own a .onion domain. You can prove, that you have control over the domain by editing its contents on their request.
But CAs should not be relied on anyway. See chapter SSL.
Hidden Services with Whonix are still safer than running Tor and the server software on the same host, because even when misconfigured, there can be, by design, no IP or DNS leaks.
- To be exact, only tor-to-tor, see Notes about End-to-end security of Hidden Services.
- [https://petsymposium.org/2017/papers/issue2/paper54-2017-2-source.pdf Website Fingerprinting Defenses at the Application Layer]
sudo apt-get install libapache2-mod-removeip
- Since it is easy to know that the internal LAN IP 10.152.152.10 is usually used by Whonix-Gateway.
(Source: old forum)
NameVirtualHost 127.0.0.1:80 Listen 127.0.0.1:80 ServerName localhost
Now Apache is not listening on, but only on . So now we somehow need to redirect to .
It can be done with a firewall rule or netcat:
sudo ncat -l 10.152.152.10 80 -c 'ncat 127.0.0.1 80'
- This is currently a 16 character name, but will be increased to 54 characters in the near-medium term to upgrade the cryptographic strength of .onion services. See: https://blog.torproject.org/blog/cooking-onions-names-your-onions
- http://tor.stackexchange.com/questions/219/how-to-use-hidden-service-authentication How to use Hidden Service Authentication?
Impressum | Datenschutz | Haftungsausschluss
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.