Tor

a network that routes traffic through volunteer relays

What it is

Tor keeps the question of who is talking to whom away from anyone watching the wire, by passing each connection through a chain of machines so that none of them learns both where the traffic started and where it ends. The chain is chosen by the client, a program called tor that runs on the reader’s own computer, and it is usually three relays long: a guard that the client keeps reusing as its way in, a middle relay, and an exit that makes the final connection to the destination. The client builds this circuit one hop at a time and agrees a separate key with each relay, then wraps every piece of data in one layer of encryption per hop. Each relay removes its own layer and learns only the neighbour before it and the neighbour after it. Those nested layers are the onion in the title of the design paper, The Second-Generation Onion Router. In conversation the relays as a whole are the Tor network, tor in lower case is the program, and Tor Browser is the browser packaged to use it.

Data moves in cells of a fixed size, so a relay sees a stream of uniform blocks rather than the shape of the original packets. Many TCP connections share one circuit: new connections reuse it for about ten minutes before the client builds a fresh one, while a long connection stays where it started. Applications reach the client through a local SOCKS proxy, and only TCP travels this way; the design paper states plainly that it does not tunnel protocols such as UDP. Volunteers run the relays, each publishing a descriptor with its keys, address, bandwidth and exit policy; a small set of directory authorities votes on which to list and signs the result as a consensus document that every client fetches before picking a path.

Why it matters

For anyone who runs a public website, Tor is first a fact about the audience. A reader who arrives over Tor appears to come from an exit relay’s address rather than their own, and the list of relays is public by design, because every client needs it to choose a path. A site can therefore recognise Tor traffic and treat it differently. The Tor Project’s own position is that operators have the right to block it, even if it hopes they will not. The decision that remains is what to do with those readers: serve them like everyone else, slow them down, put a challenge in front of them, or give them a way in that never leaves the Tor network at all, which is what an onion address does.

It pays to be exact about what Tor promises, because its design paper lists what it leaves out. It does not claim to defeat an observer who can watch both ends of a connection and compare timing and volume, and the project’s documentation adds that researchers know no practical low-latency design that reliably does. It does not try to hide that someone is using Tor, only what they use it for. And it does not encrypt the last stretch, from the exit relay to the destination.

Set beside a VPN, the trust is arranged differently. A VPN provider sees both the user and the destination and is asked to look away. On Tor no single relay sees both, and the client refuses to put two relays from the same declared family, or from the same /16 of IPv4 addresses, on one path. The price is latency, since every request crosses three volunteer machines, so pages that are light and need few round trips serve Tor readers best. Offering an onion address costs one more daemon, one more private key to guard and no open inbound port, which is why it fits on small infrastructure.

What it looks like in practice

The company’s own site can be read over Tor. The command-line page publishes the onion address next to a curl command that fetches the Markdown text through a local tor client. The address is deliberately plain http://: an onion address is the service’s own public key, so the circuit is authenticated and encrypted before any HTTP is spoken, and a certificate would only prove again what the address already proves.

An onion service is one more resident daemon, and it had to fit on the company’s one production host: a single core with about 464 MB of usable memory that already terminates TLS for seven domains and runs a git forge. Room for a tor process was measured rather than argued, over a day of samples on that 512 MB host: the smallest amount of available memory seen was about 310 MB of the 464, swap use was 2.6 per cent and the processor sat idle 99.7 per cent of the time, so Tor went on beside the rest.

The privacy notice records what follows from offering that door. The Gemini and Gopher copies of the site have a daily count of requests and nothing else. Over Tor nothing at all is counted, and no setting exists that would allow it, because knowing who read an onion address is the one thing the protocol exists to prevent. The notice says the company would rather not know than be able to.

Where it goes wrong

The name is looked up outside Tor. A program that sends its connections to a SOCKS proxy may still resolve the hostname itself first, through the ordinary resolver, and that lookup tells the local network and the DNS provider which site is being visited. The connection then travels through Tor, but the destination has already leaked. In curl the difference is a single option: with --socks5 the name is resolved locally, with --socks5-hostname it is handed to the proxy, and the exit relay resolves it.

# Resolves the name locally, then connects through the proxy
curl -s --socks5 127.0.0.1:9050 https://example.org/
# Hands the name to tor; the exit relay looks it up
curl -s --socks5-hostname 127.0.0.1:9050 https://example.org/

Plain text after the exit. Tor encrypts the hops between relays, not the last one. The exit opens an ordinary TCP connection to the destination and sends what the application gave it, so a login form submitted over plain HTTP is readable by that exit’s operator and by anyone on the network beyond it. Serve HTTPS for everything that leaves the Tor network. An onion service sidesteps the question because its traffic never leaves.

One address stands for many readers. Rate limits and bans keyed on the client address treat an exit relay as a single visitor, though many people use it at once. A limit tuned for one person locks out everyone whose circuit happens to end there, and a ban earned by one abuser lands on all of them. Decide on purpose how exit addresses are treated instead of letting a generic per-address rule decide.

Identity travels inside the circuit. Tor hides the network address and does nothing about what the application says. Signing in to a personal account, a distinctive browser setup or a document that fetches something on opening links the session to a person, however many relays sit in between. The project’s own documentation notes that application traffic still needs scrubbing on the user’s side, which is the job Tor Browser takes on and an ordinary browser pointed at the proxy does not.

An exit relay on a home connection. Guard and middle relays rarely draw abuse complaints. The exit is where destinations see traffic coming from, so complaints and the occasional legal enquiry go to whoever runs it, and the Tor Project’s relay guide says not to run one from home. A volunteer with a single home address can run a bridge instead, an unlisted relay that the same guide recommends for that situation.

Expecting UDP to work. Voice calls, many games and tools that send their own DNS lookups rely on UDP, and Tor carries only TCP streams. Those programs do not work through it, and one that is not forced through the proxy may simply connect directly, outside Tor, without saying so.

Further reading

Glossary