Perhaps the most common motivation to use Tor is to achieve some privacy, and sometimes to resist censorship, but Tor gives more than that. Let’s see what else is there.
Security
TLS is often used to assist information security – for instance, to access your bank account over HTTPS, or to send passwords over some communication protocol. Unfortunately, public key infrastructure, which is used in most cases to verify TLS connections, is a mess: you should trust all the certificate authorities, whose signing certificates get leaked sometimes – governments, criminals, or janitors can just come and get those. There are other security issues, and in most cases you should pay to get a certificate (though “Let’s Encrypt” may finally change that soon, but it also has its own drawbacks), but even the idea of CA alone is rather appaling.
What certificates show, even if everything works as intended, is usually just that you have connected to a server controlled by someone who also controlled the corresponding domain name (or a server to which some of its DNS records pointed – because that’s how the initial verification happens) once upon a time. Therefore, you should also trust random DNS servers. A few other parties may be involved in that initial verification, so you actually should trust even more of random people in order to feel safe with it. Actually, it is the best-case scenario, with DNSSEC; regular DNS allows DNS spoofing, making that initial verification even less secure.
Another way is SSH, though its common use cases are different. It uses the “trust on first use” model, where you don’t check the address, but simply should verify a fingerprint of the server certificate on the first connection, and then it gets stored locally. The only problem is that virtually nobody actually does that, accepting anything. Basically, to use it properly, people should accompany each server address with a fingerprint of its certificate – but with such an approach, even TLS may be reliable.
And then we have Tor with its hidden services. Cutting out anonymity and routing, essentially an .onion name is a fingerprint of service’s public key. Simply and elegantly, verification happens on access, and by providing an address you also provide a fingerprint, which is the same thing.
There are other distributed networks which adopt the same approach, but Tor is relatively big (hence fast) and mature (hence stable). Though even this approach is not perfect: once you change the key, the address changes. Another major drawback is that you don’t get human-meaningful names (see Zooko’s triangle), which makes it virtually impossible to remember domain names, and potentially leads to scam resources with similar names.
But keep in mind that there is no single approach that is strictly “better” than others: normally one should consider all the pros and cons of each option for a situation at hand.
Routing
Nowadays, not everyone can enjoy the luxury of a dedicated IP address. Though IPv6 is supposed to deal with the lack of addresses, ISPs don’t really care about providing that, since most users don’t need it, and don’t even know what it is – so a lot of users are trapped behind NAT.
But Tor comes to rescue once again! Instead of using an IP address, one may just set a hidden service for the server, and use SOCKS with torsocks — or simply torify — to invoke the client. In case of a website, the client may just be the Tor Browser.
Example
Let’s set everything and see how it works.
Installation
Download and install Tor. It is recommended to get a fresh version, since there may be security updates, so the version from your system repositories may be outdated and not secure. On the other hand, if your distribution applies security patches quickly, it may be better to use a version from repositories, which will have a better chance to actually be updated.
Hidden service configuration
There is a howto, Configuring Hidden Services for Tor, so we just follow its steps, more or less: nc -vlp 52113 to run a basic TCP server, add a service into /etc/tor/torrc:
HiddenServiceDir /var/lib/tor/test-service/
HiddenServicePort 31125 0.0.0.0:52113Reload (or restart) Tor, obtain the hostname:
$ sudo systemctl reload tor
$ sudo cat /var/lib/tor/test-service/hostname
w5lbbmohoi4dpm2w.onionOptionally, you may want to bruteforce a key that gives a readable hash – so that it would be clear which hash corresponds to which service, and closer to usual domain names. There is a few programs for that, including Shallot and scallion; it is only practical to bruteforce exact fingerprint prefixes up to 7-8 characters, but sometimes such programs allow you to use regexps, or to try various alternatives from a word list.
Connecting to a hidden service
Finally, torify nc -v w5lbbmohoi4dpm2w.onion 31125. Simple as that, now you should be able to exchange messages between the two netcat instances, connected over Tor.
Actually, the almighty netcat also provides a --chat option, allowing you to easily set a multi-user chat.