How to setup an TOR hidden service

Why does one want to setup a hidden service?

Of course the reason may be that one wants to hide who operates a hidden service by using the anonymization mechanisms of TOR. But there are many other reasons why one may want to use TOR hidden services:

• First there is of course metadata anonymization which reduces the ability of network providers to analyze yours and your clients traffic to detect what they are doing. This may be either motivated by legality of your actions or just by the basic idea that nobody should care and should know what you are doing out of privacy concerns
• TOR provides a security layer. All encryption is done using the same technologies that SSL/TLS offers. For TLS connections the server on the other side uses a certificate to proofe it’s identity. Most of the time people don’t validate these certificates directly but via a certificate authority infrastructure. In this case one has to trust the certificate authority (CA) to correctly sign and never attest identity to a third party. One could of course validate the fingerprints of all certificates manually or use another kind of certificate pinning than that’s currently supported by most browsers but this information is normally not directly visible. TOR hidden services on the other hand use a part of this certificate fingerprint as service identifier (the .onion URI). This means that you are including the fingerprint of the certificate in your requests which automatically includes a fingerprint verification of the other sides identity.
• TOR hidden services can announce themselves even behind firewalls or from NATed networks. They can announce themselves independent on any static IP addresses. So they may provide a convenient way to reach into any dynamic networks.
• TOR stealth hidden services extend the concept a little bit further. Instead of just publishing a hidden service descriptor under the fingerprint of the servers certificate they also introduce client keys which are then used to encrypt these identifiers. Only the clients which are authorized (each gets its own onion URI and own authentication token) can read the service descriptors so only these clients know that this service exists and at which node it exists. Hence the name stealth hidden service. This also provides an addition client authentication layer.

The configuration presented here only allows a single server to serve the hidden service - but as has been shown by prominent services like Facebook with their facebookcorewwwi.onion service it is also possible to use load balancers like OnionBalance

Please note that this article does not encourage you to use TOR hidden services for illegal activity. The above points should have listed enough reasons to use TOR even for legal content

Principles

Onion URIs

Basically onion URIs are generated randomly. If one wants to get a specific prefix one has to generate keys till the fingerprint is equal to this specific prefix. The longer the prefix gets the longer the generation of such keys takes. This of course reduces the randomness of the keys a little bit. If one really wants to do that the following tools might be interesting:

• Shallot which is the oldest CPU based key generator
• Scallion which is a GPU based generator implemented in .NET (i.e. Windows only)
• Eschalot which is a unix tool that tries to use wordlists to generate the keys.

Note that there are of course drawbacks when using such generated keys. Additional to the fact that they may take multiple hours or days (if long enough even weeks or years) to generate they use different parameters like the public exponent and are thus easily spotable on the network.

Anonymity

If you really do this so the hoster and operator stays anonymous (of course most administartors won’t do it because of that) you have to be really catious to not leak any publically available information to the outside world. This also includes things like not using a shared webserver with virtual hosts, not using TLS/SSL certificates handed out by some certificate authority (for hidden services you really don’t require any anyways because authenticity is already established via the TOR service keys).

Note: This of course does not mean that you shoudn’t enforce HTTPS via TLS/SSL to clearnet sites. Safe TOR operation requires that. You don’t require TLS/SSL to hidden services though.

This means that you should setup your webserver in a way to not leak any information (a virtual machine which only has TOR connection for example). And even then there are sometimes sidechannels like traffic analysis (you should operate your node as relay to counter that), thermal sidechannels and many more. Just be warned that this is really not easy.

Required software

• Your webserver (should be already running)
• TOR (for example on FreeBSD: security/tor via packages or ports)

After installing TOR and doing some basic configuration in /usr/local/etc/tor/torrc which should include:

Basic configuration

• Setting ClientOnly 0 to enable relaying traffic. This counters traffic analysis
• If you have a firewall in place that restricts outgoing traffic: FascistFirewall 1
• If you have IPv6 connectivity available it’s nice to enable that too (but don’t do that if you run your endpoint to be anonymous): ClientUseIPv6 1
• In case you don’t want to run an exit node (and if you don’t know the juristical implications you don’t want to) set ExitPolicy reject *:*

Configuring a standard hidden service

Now you can easily configure a hidden service by providing at least two configuration options:

• The HiddenServiceDir starts the declaration of a hidden service. Multiple services may be declared after each other, each one starting with the HiddenServiceDir. Just create an directory that is read- and writeable by the TOR process (for example: HiddenServiceDir /etc/tor/service1/)
• For each Port that you want to be reachable from the TOR network network you have to provide a port mapping via HiddenServicePort. This takes the port from the side of the TOR client as first argument and an destination address that you want to forward to as the second. For example one can set HiddenServicePort 80 127.0.0.1:80 to forward all requests from port 80 on the public side to port 80 on the local host

Then restart or reload your TOR client. The client will automatically create two files in your hidden service directory. These are hostname and private_key. The first one contains the hostname that you can use to reach your service via the TOR network. The second one contains your private key. Never give away the second one.

In case you use vhosts on your webserver don’t forget to add an ServerAlias to the specific vhost to respond to the onion requests. If you don’t use vhosts but only serve the default one (in case you want anonymity this is of course the way to go) you can ignore that step.

Stealth hidden services

Stealth hidden services go a little bit further. They require the clients to authenticate themselves. To configure them you need to add a HiddenServiceAuthorizeClient line to your hidden service configuration. This option lists a comma separated list of client names that should be allowed to access the service. For example HiddenServiceAuthorizeClient client1,client2,client3

After restarting TOR it will have created authentication cookies as well as addresses for all clients inside the hostname file of your HiddenServiceDir Take the one that corresponds to your client and put it in the clients torrc with the following format:

HidServAuth <onionurl> <cookiekey> # client: clientname1

Then restart TOR on the client. After that you can reach the service via the client specific onion URI(s).

From an outside view the hidden service is now offline if they don’t have specific client credentials and the specific onion URI.

This article is tagged:

• Cryptography
• Security
• Administration
• FreeBSD