04 Apr 2019 - tsp
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:
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
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:
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.
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.
After installing TOR and doing some basic configuration in
/usr/local/etc/tor/torrc which should include:
ClientOnly 0to enable relaying traffic. This counters traffic analysis
ExitPolicy reject *:*
Now you can easily configure a hidden service by providing at least two configuration options:
HiddenServiceDirstarts 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:
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:80to 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
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
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 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
After restarting TOR it will have created authentication cookies as well as
addresses for all clients inside the hostname file of your
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.