tor
Onion Routing Explained: How Tor Hides Your Traffic
Onion routing explained — three-relay circuits, layered encryption, what each node sees, hidden services, and the known limits of the design.
The protocol behind The Onion Router wraps payloads in nested encryption and routes them through volunteer relays; each hop peels one layer. Ten minutes of mechanics pays off whenever you need to know where Tor helps and where it does not.
The TL;DR Analogy
Imagine you want to send a letter anonymously. You write the letter, seal it in Envelope C addressed to the recipient. You seal that inside Envelope B addressed to a middleman who will forward it. You seal that inside Envelope A addressed to a first-hop forwarder.
The forwarder (Envelope A) opens their layer and sees only "forward this to Middleman B." They can't see what's inside Envelope B or C. Middleman B opens their layer and sees only "forward this to the recipient." The recipient gets Envelope C and sees your letter — but has no idea where Envelope A came from.
That's onion routing. Each "envelope" is a layer of encryption. Each forwarder is a Tor relay. Nobody except the final destination reads the contents — and nobody in the chain has the full picture.
Three Relays: Guard, Middle, Exit
A standard Tor circuit uses exactly three relays, chosen from the public Tor consensus — a list of approximately 7,000 volunteer-run relays (as of 2024) distributed across dozens of countries. Each relay has a specific role:
Guard relay (entry node): The first hop. Your Tor client connects directly to the guard relay, so the guard relay knows your real IP address. It does not know your destination — it only knows the address of the middle relay to forward your encrypted data to. Guard relays are selected with a bias toward relays with good uptime and bandwidth, and they stay fixed for 2–3 months per client (to prevent guard-churn attacks).
Middle relay: The second hop. The middle relay knows it received traffic from a guard relay and should forward it to an exit relay. It doesn't know your IP or your destination. It's the most anonymous position in the circuit — nobody has a strong reason to run a middle relay for malicious purposes, since it can't see much.
Exit relay: The third hop. The exit relay knows the destination address — it has to, because it makes the actual connection to the site you're visiting. It does not know your IP address. This is the relay that appears in server logs as the "user's IP." Exit relay operators are the most legally exposed position — they appear to be the traffic's origin to the destination server.
How Encryption Layers Peel
Your Tor client builds the circuit before sending any traffic. Here's the process:
- Your client establishes an encrypted connection to the guard relay and negotiates a session key — call it Key G.
- Through that encrypted tunnel, it extends the circuit to the middle relay and negotiates Key M.
- Through both tunnels, it extends to the exit relay and negotiates Key E.
When you request a web page, your client wraps the request like this:
- Encrypt with Key E → the exit relay can decrypt this
- Encrypt the result with Key M → the middle relay can decrypt this
- Encrypt the result with Key G → the guard relay can decrypt this
The guard relay peels layer G, sees "forward to middle relay," and forwards the still-encrypted blob. The middle relay peels layer M, sees "forward to exit relay," and forwards. The exit relay peels layer E, reads the destination, and makes the actual connection to the server.
Response traffic flows the same process in reverse — wrapped in three encryption layers, peeled one at a time at each relay back to your client. The formal cryptographic specification is in the Tor design paper maintained by the Tor Project.
What Each Relay Sees (vs Doesn't See)
| Relay | Knows your IP | Knows the destination | Reads traffic content |
|---|---|---|---|
| Guard | Yes | No | No |
| Middle | No | No | No |
| Exit | No | Yes | If non-HTTPS: yes |
The exit relay is the one to watch. For HTTPS sites, traffic between the exit relay and the destination is encrypted by TLS — the exit relay sees the destination hostname but not the content. For plain HTTP sites, the exit relay sees everything. This is why Tor Browser enforces HTTPS-Only Mode: not to protect you from your ISP, but to protect your traffic from your own exit relay.
Hidden Services (.onion): Onion Routing Without an Exit Node
When you access a .onion address, there's no exit node at all. Both you and the .onion service build partial circuits toward a shared "rendezvous point" inside the Tor network. The rendezvous point connects the two circuits without either side knowing the other's IP address.
This is how .onion services achieve server-side anonymity — not just client-side. The server's IP address is never exposed to the network; the rendezvous point only knows two partial circuits that meet in the middle. .onion addresses are long, cryptographic identifiers (v3 onion addresses are 56 characters of base32-encoded public key hash) that authenticate the service without a centralized directory.
The design means that both the user and the hidden service are protected. Neither can be deanonymized by an observer at the rendezvous point. The Tor Project's hidden services documentation covers the full protocol.
Limits and Known Attacks
Onion routing has specific, documented weaknesses. Being honest about them is part of every accurate threat model.
Traffic correlation (end-to-end confirmation attack): An adversary who controls or observes both the network path into your guard relay and the network path out of your exit relay can correlate timing signatures to confirm that you're communicating with a specific destination. This requires observing both ends simultaneously — a capability that nation-state intelligence agencies have and most adversaries don't. The Tor Project's research blog has covered this attack class since 2005.
Malicious relays: Anyone can run a Tor relay. Malicious actors do. A malicious exit relay can read non-HTTPS traffic. A malicious guard relay knows your IP. Malicious relays can attempt Sybil attacks — running many relays to increase the probability of controlling both the guard and exit in a single circuit. The Tor Project actively monitors relay behavior and removes malicious relays, but detection isn't perfect.
Browser-level attacks: Onion routing secures the transport. It doesn't protect against vulnerabilities in the browser that processes the destination's content. A JavaScript exploit on a compromised .onion service can leak your real IP regardless of how well the Tor circuit is constructed. This is why Safest security level exists.
Timing and volume analysis: Even without breaking individual circuits, an adversary observing large-scale traffic patterns can make probabilistic inferences about usage. This is a research-level concern rather than a practical daily threat for most users.
For the broader context of how these limits affect your choices, see the Tor Browser setup guide and our Tor vs VPN comparison. Privacyguides.org maintains a well-sourced overview of Tor's properties and limitations that's worth reading alongside this one.
Frequently Asked Questions
Why does Tor use exactly three hops?
Three is the minimum that achieves the core property: the guard knows your IP but not your destination; the exit knows your destination but not your IP; and no single relay knows both. More hops would add latency and reduce speed without proportionally improving anonymity for most threat models. Two hops would break the property — a guard-plus-exit would know both. Three is the principled minimum.
Does using Tor make me completely anonymous?
No. Tor provides strong anonymity at the network layer against passive observers and most adversaries. It doesn't protect against browser fingerprinting at Standard security level, against malicious JavaScript, against OPSEC mistakes, or against traffic correlation attacks by adversaries watching both ends. "Completely anonymous" is a misleading goal — the practical question is "anonymous against which adversary?" Review the threat modeling guide for that framing.
Can I run a Tor relay to help the network?
Yes, and the Tor Project actively needs volunteers. Running a middle relay is the lowest-risk option — middle relays never connect to destination sites, so there's no abuse attribution risk. Running an exit relay is legal in most jurisdictions but does expose the operator to complaints about traffic originating from their IP. The Tor Project's relay documentation covers setup and legal context.
How is a .onion address different from a regular URL?
A v3 .onion address (the current format as of 2021) is a 56-character base32-encoded string derived from the public key of the hidden service. It's both the address and the authentication — connecting to the right .onion address cryptographically proves you're talking to the right service, without relying on certificate authorities. There's no centralized registry; the address is the key.