The Tor network processes over 400 Gbps of traffic daily, routed through approximately 7,000 volunteer-operated relays across every continent except Antarctica. It is the most widely deployed anonymity network in existence, and its design — onion routing — has been copied, adapted, and analyzed for over two decades. Understanding how Tor actually works at the protocol level is not academic. Every darknet operator, every privacy-conscious user, and every security researcher needs to know exactly where the protections end and the vulnerabilities begin.
Tor is not magic. It is engineering. The protections are precise, bounded, and well-documented. The vulnerabilities are equally precise. Knowing both is the difference between effective anonymity and catastrophic exposure.
Onion Routing: The Core Concept
Onion routing is a protocol for anonymous communication over a public network. The client wraps data in multiple encryption layers — one per relay in the circuit — with each layer containing routing instructions for that specific node. As the data traverses the circuit, each relay decrypts its layer, learns where to forward the payload, and passes the remaining encrypted bundle onward. By the final hop, all layers are peeled away and the plaintext reaches its destination.
The critical property: no single relay knows both the origin and the destination. The entry relay (guard) knows the client's IP but not the destination. The exit relay knows the destination but not the client's IP. The middle relay bridges the two, knowing neither. This separation of knowledge is enforced cryptographically, not by policy.
Circuit Construction
A Tor circuit is built incrementally through a process called telescoping. The client does not know the full path in advance. It discovers relays one at a time, extending the circuit hop by hop.
$ curl --socks5-hostname 127.0.0.1:9050 \
http://[directory-authority].onion/tor/status-vote/current/consensus
# Step 2: Select guard from consensus (bandwidth-weighted random)
$ # Client creates TLS connection to guard: 185.220.101.x:443
[TLS handshake with guard relay] [Diffie-Hellman key exchange -> session key K1] [Circuit created: client -> guard]
# Step 3: Extend through guard to middle relay
$ # Client tells guard: "Extend to [middle], here's the onion skin"
[Guard forwards extend cell to middle relay] [DH exchange -> session key K2] [Circuit extended: client -> guard -> middle]
# Step 4: Extend through middle to exit relay
$ # Client tells middle: "Extend to [exit], here's the onion skin"
[Middle forwards extend cell to exit relay] [DH exchange -> session key K3] [Circuit complete: client -> guard -> middle -> exit]
# Now: data cell encrypted with K3, then K2, then K1
$ # Each relay peels one layer, forwarding the rest
Each hop uses a separate Diffie-Hellman key exchange negotiated over the existing encrypted tunnel. This ensures that no relay along the path learns the keys used by any other relay. A compromised guard cannot decrypt traffic passing through the middle or exit nodes because it lacks their session keys.
Tor Node Roles
| Node Type | Role | Knows Client IP? | Knows Destination? | Key Property |
|---|---|---|---|---|
| Guard (Entry) | First node; accepts client TLS connection | ✓ | ✗ | Long-term selection; rotated every 2-3 months |
| Middle | Intermediate relay; bridges guard and exit | ✗ | ✗ | Highest bandwidth; no direct exposure to clearnet |
| Exit | Final node; decrypts and connects to destination | ✗ | ✓ | Visible to destination servers; subject to abuse complaints |
The guard node is the most security-critical relay in the circuit. In Tor's early design, clients selected a random entry node for each circuit, which made them vulnerable to profiling attacks by adversaries who controlled many relays. The guard node design fixes this: the client selects a small set of guards upon first connecting and uses them persistently for months. An adversary who does not control the user's guard during that window cannot force the client to use a malicious entry node.
Directory Authorities and Consensus
Tor's nine directory authorities are the network's trust anchors. These servers, operated by trusted community members, continuously probe all advertised relays to measure bandwidth, uptime, and reliability. They publish signed relay descriptors containing each relay's fingerprint, IP address, exit policy, and flags (Guard, Exit, Stable, Fast, etc.).
Every hour, the authorities run a consensus algorithm to produce a single signed network consensus document. This document is the authoritative list of all active relays and their weighted flags. Tor clients download the consensus (from an authority or a cache) to build a fresh view of the network. The consensus enables clients to select relays probabilistically, weighted by bandwidth contribution, distributing load across the network while preventing a small number of malicious relays from disproportionately attracting traffic.
Encryption Layers
When a client sends a data cell to example.com, it encrypts the payload three times — once with each relay's session key. The guard decrypts the outer layer, sees instructions to forward to the middle relay, and passes the remaining two-layer-encrypted payload onward. The middle relay decrypts its layer, finds instructions to forward to the exit, and passes the single-layer payload. The exit relay performs the final decryption and sends the plaintext HTTP request to example.com. The response follows the reverse path, accumulating encryption layers at each hop back to the client.
Tor uses a hybrid cryptosystem. Asymmetric cryptography (RSA-2048 or Curve25519) is used only during circuit establishment for key exchange. Once session keys are negotiated, all data is encrypted with AES-128 in CTR mode using symmetric session keys. Symmetric encryption is orders of magnitude faster than asymmetric encryption, making low-latency streaming possible.
The key exchange protocol matters. Modern Tor circuits use the ntor handshake (based on Curve25519 and SHA-256), which provides forward secrecy: if a relay's long-term private key is later compromised, past session keys cannot be recovered. Older circuits using the TAP handshake (RSA-1024 with DH) do not provide this property. As of 2026, all Tor circuits use ntor by default.
Hidden Services (Onion Services v3)
Tor hidden services allow servers to offer TCP services without revealing their IP address. The v3 protocol (HSv3, deployed in 2018) replaced the deprecated v2 design with significant security improvements. The .onion address itself is a cryptographic identifier: 56 base32 characters encoding a 256-bit Ed25519 public key hash, a version byte, and a checksum. The address functions as a self-authenticating identifier — connecting to an .onion address cryptographically proves you are speaking to the correct service, eliminating the need for traditional TLS certificates.
A hidden service establishes its presence by selecting introduction points from the Tor network and advertising them through a distributed hash table (HSDir system). When a client wants to connect, it fetches the service descriptor from the HSDir, learns the introduction points, and builds a rendezvous point. The client and service connect through this rendezvous point, with all traffic encrypted end-to-end.
Limitations and Threats
Tor's most significant vulnerability is end-to-end timing analysis. An adversary who monitors both the guard node and the destination server can correlate traffic timing and volume patterns to confirm that a specific client is communicating with a specific server. This attack does not break Tor's cryptography — it bypasses it entirely by observing metadata that the protocol inherently leaks.
Exit node eavesdropping is another practical threat. Because the exit node decrypts traffic before forwarding it, a malicious exit operator can capture unencrypted data. The defense is universal TLS: every website visited over Tor should use HTTPS. Tor Browser enforces HTTPS-Everywhere by default, but users should verify the padlock icon before entering sensitive data.
Website fingerprinting attacks exploit Tor's low-latency design. An attacker who observes the encrypted traffic stream between a client and the guard node can sometimes identify which website the client is visiting based on packet sizes, timing, and counts — even with all content encrypted. Advanced defenses like traffic morphing and constant-rate padding are being researched, but no deployed solution fully eliminates this vulnerability.