How Tor Works: Onion Routing from Entry to Exit

Onion Routing Basics

Tor (The Onion Router) was originally developed by the U.S. Naval Research Laboratory in the mid-1990s, and it was released as open-source software in 2003. The fundamental goal is simple to state and hard to achieve: separate the identity of the person communicating from the content of their communication. A VPN hides what you do from your ISP but your VPN provider sees everything. Tor is designed so that no single entity in the network knows both who you are and what you are doing.

The name "onion routing" comes from the layered encryption model. When you send a request through Tor, your Tor client wraps it in multiple layers of encryption, one for each relay in the path. Each relay peels off one layer, reads just enough information to know where to send the packet next, and forwards it. No relay sees the full picture.

This is a fundamentally different architecture than a VPN. A VPN is a single encrypted hop to a provider you trust. Tor is three encrypted hops through relays that do not need to be trusted individually, because none of them has enough information to compromise your privacy on its own.

The Three-Hop Model

sequenceDiagram
    participant User as Your Device
    participant Guard as Entry Guard
    participant Middle as Middle Relay
    participant Exit as Exit Node
    participant Dest as Destination
    
    User->>Guard: Layer 3 encryption (knows your IP)
    Note over Guard: Peels layer 3
Knows: your IP + middle relay
Does NOT know: destination
    Guard->>Middle: Layer 2 encryption
    Note over Middle: Peels layer 2
Knows: guard + exit node
Does NOT know: your IP or destination
    Middle->>Exit: Layer 1 encryption
    Note over Exit: Peels layer 1
Knows: destination + middle relay
Does NOT know: your IP
    Exit->>Dest: Unencrypted request (or HTTPS)
    Dest->>Exit: Response
    Exit->>Middle: Re-encrypted
    Middle->>Guard: Re-encrypted
    Guard->>User: Re-encrypted

The three-hop model ensures no single relay knows both your identity and your destination

Tor uses exactly three relays for each circuit. This is not arbitrary. Two hops would mean the first relay knows your IP and the second relay knows your destination, and if those two relays colluded (or were operated by the same entity), your anonymity would be broken. Three hops create a separation: the entry knows who you are but not where you are going, the exit knows where you are going but not who you are, and the middle relay prevents the entry and exit from knowing about each other directly.

Adding more than three hops would increase latency without meaningfully improving security. An adversary who can perform traffic correlation attacks (monitoring both ends of the connection) can break anonymity regardless of how many intermediate hops exist. Three hops is the pragmatic balance between performance and the security properties Tor aims to provide.

Entry Guards: Your First Hop

The entry guard (also called a guard node) is the first relay in your Tor circuit. It is the only relay that knows your real IP address. Because of this privileged position, Tor treats guard selection with particular care.

In earlier versions of Tor, circuits selected all three relays randomly from the available pool for each new circuit. This created a statistical problem: if an adversary operated even a small fraction of the network's relays, you would eventually rotate onto a circuit where the adversary controlled both the entry and exit, enabling a correlation attack. With random selection, this was essentially guaranteed over time.

Guard nodes solve this by making the entry relay sticky. Your Tor client selects a small set of entry guards and uses them for an extended period (currently around two to three months by default). This means that if your guards are honest, you are safe. If your guards are compromised, you are compromised, but the probability of selecting a compromised guard is calculated once rather than repeatedly for every circuit.

The math works out in favor of persistent guards. With random rotation, the probability of eventually using a malicious entry approaches certainty over time. With persistent guards, the risk is a one-time probability that remains constant.

Middle Relays: The Anonymous Core

Middle relays are the least discussed component of a Tor circuit, but they serve an essential function. The middle relay knows only the identity of the guard that sent it traffic and the exit node it should forward traffic to. It does not know the user's IP address, and it does not know the final destination.

Middle relays are selected randomly from the available relay pool for each new circuit. Because they never see the user's IP or the destination, they are lower-risk positions in the network. Running a middle relay is the safest way to contribute bandwidth to the Tor network, because the operator never handles traffic that exits to the regular internet.

The middle relay exists primarily to prevent the entry guard and exit node from being directly connected. Without a middle relay, an adversary controlling both the entry and exit of a two-hop circuit could trivially correlate traffic. The middle relay forces an additional layer of separation.

Exit Nodes: Where Traffic Meets the Internet

The exit node is where Tor traffic leaves the Tor network and enters the regular internet. This is the most sensitive and most misunderstood position in the Tor architecture.

When you visit a website through Tor, the exit node makes the actual connection to that website on your behalf. The website sees the exit node's IP address, not yours. The exit node can see the destination and the content of your traffic if you are not using HTTPS.

This is a critical point that many Tor users miss: Tor encrypts traffic within the Tor network, but the exit node decrypts the final layer. If you visit an HTTP (not HTTPS) website through Tor, the exit node can read everything, including login credentials, form submissions, and page content. The exit node cannot determine your IP address, but it can see what you are doing.

graph TD
    subgraph Tor_Network["Inside Tor Network"]
        A[Your Device] -->|Encrypted| B[Entry Guard]
        B -->|Encrypted| C[Middle Relay]
        C -->|Encrypted| D[Exit Node]
    end
    
    subgraph Clear_Internet["Regular Internet"]
        D -->|HTTP = Plaintext!| E[HTTP Website]
        D -->|HTTPS = Encrypted| F[HTTPS Website]
    end
    
    subgraph Exit_Sees["What Exit Node Sees"]
        G[HTTP Traffic: Full content visible]
        H[HTTPS Traffic: Encrypted, destination visible]
    end
    
    D -.-> G
    D -.-> H

Traffic is encrypted inside Tor, but HTTP traffic is visible to the exit node in plaintext

This has real consequences. In 2007, security researcher Dan Egerstad operated five Tor exit nodes and intercepted credentials for over 100 email accounts belonging to embassies and government agencies. The users assumed Tor provided end-to-end encryption. It does not. Tor provides anonymity (hiding who you are), but confidentiality between the exit node and the destination depends entirely on whether the connection uses HTTPS or another form of end-to-end encryption.

Running an exit node is legally risky because the traffic that emerges appears to originate from the exit node operator's IP address. Exit node operators have received abuse complaints, DMCA notices, and in some cases law enforcement attention for traffic that merely passed through their relay. Organizations like the Tor Project and the Electronic Frontier Foundation provide legal resources for exit node operators, but the risk is real.

How Tor Builds Circuits

When your Tor client starts, it downloads a consensus document from the Tor directory authorities. This document contains information about all known relays in the network, including their bandwidth capacity, exit policies, flags (such as Guard, Exit, Stable, Fast), and cryptographic keys.

Using this information, your client builds circuits proactively before you need them. A fresh circuit is built approximately every 10 minutes, and circuits are rotated for new connections to prevent long-lived circuits from accumulating enough traffic to enable correlation attacks.

The circuit building process uses a telescoping construction. Your client performs a Diffie-Hellman key exchange with the guard node to establish an encrypted channel. Through that channel, it extends the circuit to the middle relay with another key exchange. Through the guard and middle relay, it extends to the exit node with a third key exchange. At the end of this process, your client shares a unique symmetric key with each relay, and no relay knows the keys shared with the other relays.

This is why the encryption is layered. When you send a request, your client encrypts it with the exit node's key, then encrypts that result with the middle relay's key, then encrypts that result with the guard's key. Each relay decrypts one layer and forwards the result.

Onion Services (.onion)

Onion services (formerly called hidden services) take Tor's anonymity model a step further. Instead of just hiding the identity of the client, onion services hide the identity of the server as well. Neither party knows the other's IP address.

An onion service works by selecting several relays as "introduction points" and publishing their addresses (signed with the service's key) to a distributed hash table within the Tor network. When a client wants to connect, it looks up these introduction points, selects a relay as a "rendezvous point," and tells the introduction point to ask the onion service to connect to the rendezvous point. Both parties build Tor circuits to the rendezvous point, and the connection is established without either party revealing their IP address to the other.

The .onion address is derived from the service's public key (in v3 onion addresses, it is a 56-character base32 encoding of the public key, a checksum, and a version number). This means the address itself is a cryptographic commitment, you cannot impersonate an onion service without possessing its private key.

Onion services are not exclusively used for illicit purposes, despite their reputation. Facebook operates a Tor onion service (facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion). The New York Times, BBC, and ProPublica all operate onion services. These exist to allow users in censored regions to access journalism without revealing that they are doing so.

What Tor Does Not Protect Against

Tor provides strong anonymity under its threat model, but that threat model has boundaries. Understanding them is essential for using Tor safely.

Browser-based tracking. If you log into your Google account through Tor, Google knows who you are regardless of your IP address. Cookies, login sessions, and browser fingerprinting can all de-anonymize you. The Tor Browser is configured to resist fingerprinting (by normalizing window size, fonts, and other attributes), but using a regular browser with Tor defeats most of these protections.

Endpoint security. Tor protects network-layer anonymity. If your device is compromised with malware, the malware can read your traffic before it enters the Tor tunnel, capture screenshots, log keystrokes, and exfiltrate data through a direct connection that bypasses Tor entirely.

User behavior. The most common way Tor users are de-anonymized is through their own behavior. Posting identifying information, reusing pseudonyms across Tor and non-Tor contexts, or accessing personal accounts through Tor all create linkability that no amount of network-layer anonymity can fix.

JavaScript exploitation. The FBI has used JavaScript-based exploits to de-anonymize Tor users on multiple occasions. The most well-known example is the 2013 Freedom Hosting takedown, where the FBI deployed a JavaScript exploit through compromised onion services that reported users' real IP addresses back to an FBI server. The Tor Browser's security slider can disable JavaScript, but many websites require it.

Traffic Analysis and Correlation Attacks

The most significant theoretical weakness of Tor is traffic correlation. If an adversary can observe your connection entering the Tor network (at the guard) and the corresponding traffic exiting the network (at the exit node), they can correlate the two through timing and volume analysis even without breaking the encryption.

graph TD
    subgraph Adversary_View["Global Adversary View"]
        A[User's ISP] -->|Timing: 14:22:03.451| B[Tor Entry]
        C[Tor Exit] -->|Timing: 14:22:03.623| D[Destination ISP]
    end
    
    subgraph Correlation["Correlation Analysis"]
        E[Match traffic volume patterns]
        F[Match timing patterns]
        G[Match packet sizes]
        E --> H{Statistical correlation}
        F --> H
        G --> H
        H -->|High confidence| I[User identified]
    end
    
    subgraph Defense["Tor's Defenses"]
        J[Circuit rotation every 10 min]
        K[Traffic padding - limited]
        L[Guard persistence reduces exposure]
    end

A global adversary observing both ends of a Tor circuit can correlate traffic through timing analysis

This is not a theoretical concern. Research has repeatedly demonstrated that traffic correlation is practical with surprisingly low false-positive rates. A 2013 paper by researchers at Georgetown and the Naval Research Lab estimated that a moderate adversary (controlling a fraction of the internet's autonomous systems) could de-anonymize approximately 80% of Tor users within six months through passive traffic analysis.

Tor does not claim to protect against a global passive adversary. Its threat model explicitly assumes that the adversary cannot observe all links in the network simultaneously. Against local adversaries, ISPs, or even most nation-states that lack total network visibility, Tor's anonymity properties hold.

Efforts to mitigate traffic analysis include traffic padding (adding dummy traffic to obscure patterns) and various designs for anonymous communication that are resistant to correlation attacks. But these remain active research areas, and deployed Tor does not implement strong traffic analysis resistance.

Using Tor Safely

Using Tor effectively requires understanding what it protects and adjusting your behavior accordingly.

Use the Tor Browser. It is a modified version of Firefox that is preconfigured to use Tor and to resist browser fingerprinting. Using Tor through a regular browser leaks information that can de-anonymize you. The Tor Browser normalizes your window size, disables or restricts JavaScript features that enable fingerprinting, and isolates cookies per-site.

Do not log into personal accounts through Tor if anonymity matters. The moment you log into Gmail, Facebook, or any service linked to your real identity, the anonymity Tor provides for that session is gone.

Use HTTPS whenever possible. Tor protects your anonymity (who you are), but HTTPS protects your confidentiality (what you are doing). Without HTTPS, the exit node can read your traffic in plaintext.

Consider using Tails or Whonix for sensitive operations. Tails is a live operating system that routes all traffic through Tor and leaves no trace on the host computer. Whonix uses two virtual machines (a gateway that routes through Tor and a workstation that can only access the network through the gateway) to prevent IP leaks even if the workstation is compromised.

Tor is a powerful anonymity tool, but it is not magic. It protects network-layer anonymity against a well-defined class of adversaries. Against adversaries outside that class, or against users who undermine their own anonymity through their behavior, Tor's protections can be insufficient. The key is knowing which category your situation falls into.

For wireless security research and packet analysis, tools like the BLEShark Nano let you examine BLE, WiFi, and IR protocols at the physical layer - the kind of hands-on investigation that complements network-layer tools like Tor.