How the Tor Network Works: Onion Routing and Internet Anonymity

The Tor network (short for The Onion Router) is a free, open-source anonymity network that allows people to browse the internet without revealing their identity or location. It works by separating identification from routing: instead of connecting directly to a destination server, your traffic is relayed through a series of volunteer-operated servers around the world, with each relay only knowing its immediate neighbor in the chain. No single relay ever knows both who you are and what you are accessing.

Tor was originally developed in the mid-1990s at the U.S. Naval Research Laboratory by mathematicians Paul Syverson and computer scientists Michael Reed and David Goldschlag. The underlying technique — onion routing — was designed to protect U.S. intelligence communications online. The Tor Project was founded as a nonprofit in 2006, and today the network is used by journalists, activists, whistleblowers, privacy-conscious individuals, and anyone who needs to circumvent censorship or surveillance.

From a networking perspective, Tor traffic is ordinary TLS-encrypted TCP traffic. Tor relays are just servers with IP addresses announced in BGP by various autonomous systems worldwide. But the protocol layered on top of that infrastructure creates something remarkable: a system where the network itself cannot determine who is talking to whom.

How Onion Routing Works

The core idea behind Tor is onion routing — a technique where a message is wrapped in multiple layers of encryption, like the layers of an onion. Each relay in the circuit peels off exactly one layer, revealing only the address of the next relay. By the time the message reaches the destination, all layers have been removed, and no relay along the path has seen the full picture.

Here is how it works step by step:

1. The Tor client (running on your computer) selects three relays from the Tor network: a guard node (entry), a middle relay, and an exit relay.
2. The client obtains the public encryption key for each relay from the Tor directory.
3. The client encrypts the message three times, in reverse order — first with the exit relay's key, then with the middle relay's key, then with the guard node's key. This produces a layered ciphertext.
4. The client sends this fully-wrapped message to the guard node. The guard node decrypts the outer layer using its private key. This reveals the address of the middle relay but not the message content or the final destination.
5. The guard node forwards the twice-encrypted message to the middle relay. The middle relay decrypts one more layer, revealing the address of the exit relay. The middle relay knows neither the client's IP nor the destination.
6. The middle relay forwards the singly-encrypted message to the exit relay. The exit relay decrypts the final layer, revealing the original message and the destination server's address. The exit relay sends the request to the destination on behalf of the client.
7. The response follows the same path in reverse, with each relay adding a layer of encryption. The client strips all three layers to read the response.

The critical insight is the separation of knowledge. The guard node knows who you are (your IP address) but not what you are doing. The exit relay knows what site is being accessed but not who is accessing it. The middle relay knows neither. This is why three hops are used — it is the minimum number needed to ensure that no single relay can link the sender to the destination.

In practice, the encryption is more nuanced than simple layering. During circuit construction, the client negotiates a separate symmetric session key with each relay using ephemeral Diffie-Hellman key exchange (specifically, Curve25519). These session keys are used to encrypt and decrypt data at each hop. The initial key exchange is done using the relay's long-term identity key for authentication, but the session keys provide forward secrecy — even if a relay's long-term key is later compromised, past sessions cannot be decrypted.

Circuit Construction

Before any data can be anonymized, the Tor client must build a circuit — a path through three relays. This is a multi-step process that involves consulting the Tor directory, selecting relays, and negotiating encryption keys with each one.

The Tor Directory System

Tor relies on a set of directory authorities — nine hardcoded, trusted servers operated by known, independent individuals and organizations in the Tor community. These authorities collectively maintain a list of all relays in the network, their capabilities, bandwidth, uptime, and public keys. Every hour, the directory authorities vote on the current state of the network and produce a consensus document — a signed list of all active relays and their properties.

Tor clients download this consensus document periodically (typically every few hours) and use it to select relays for building circuits. The consensus includes each relay's flags — labels like Guard, Exit, Stable, Fast, and HSDir — which indicate the relay's role and quality. A relay earns the Guard flag by demonstrating sustained uptime and sufficient bandwidth. The Exit flag indicates the relay allows traffic to exit to the regular internet.

Relay Selection

When building a circuit, the client does not choose relays uniformly at random. Instead, selection is bandwidth-weighted: relays with more bandwidth are more likely to be chosen, which balances load across the network and ensures that high-capacity relays carry a proportional share of traffic. Without bandwidth weighting, a small number of fast relays would be underutilized while slow relays would be overwhelmed.

The client also applies several constraints:

• No two relays in the same circuit may be in the same /16 subnet (for IPv4) or the same autonomous system — this prevents a single network operator from observing multiple hops of a circuit.
• No two relays may belong to the same relay family — operators who run multiple relays can declare them as a family, and Tor avoids using two family members in the same circuit.
• The guard node must have the Guard flag, and the exit relay must have the Exit flag with an exit policy that permits connections to the destination.

Building the Circuit Incrementally

The circuit is built one hop at a time, which is essential for security:

1. The client connects to the guard node via a TLS connection and performs a Diffie-Hellman key exchange to establish a shared session key. This creates a one-hop circuit.
2. Through this encrypted tunnel, the client sends a request to the guard node asking it to extend the circuit to the middle relay. The guard node connects to the middle relay, and the client negotiates a separate session key with the middle relay. The guard node cannot read this negotiation because it is encrypted end-to-end between the client and the middle relay.
3. Through the two-hop tunnel, the client extends the circuit one more time to the exit relay, negotiating a third session key. Neither the guard nor the middle relay can read this negotiation.

At the end of this process, the client has a three-hop circuit with three independent session keys. Each relay only knows the key it shares with the client. The entire construction takes a few hundred milliseconds under good network conditions.

Circuit Lifetime and Rotation

Circuits are not permanent. Tor rotates circuits regularly to limit the window of vulnerability:

• General circuits are kept for about 10 minutes, then new circuits are built for new connections.
• Long-lived streams (such as SSH connections or ongoing downloads) continue to use their existing circuit until the stream finishes.
• Guard nodes are rotated much more slowly — a client typically keeps the same guard for 2-3 months. Frequent guard rotation would actually weaken anonymity because it increases the probability that the client will eventually pick a malicious guard.

Pre-built circuits are maintained so that new connections can be served immediately without the delay of circuit construction.

Types of Tor Relays

Not all relays in the Tor network are equal. Each serves a distinct role, and the security properties of the network depend on having a diverse, distributed set of each type.

Guard (Entry) Nodes

The guard node is the first relay in a circuit and the only relay that sees the client's real IP address. Because of this sensitive position, Tor is very selective about which relays earn the Guard flag — they must demonstrate high uptime, adequate bandwidth, and stability over a sustained period. The client uses a small, persistent set of guard nodes (called its guard set) for months at a time rather than rotating through many guards.

This persistence might seem counterintuitive — wouldn't using a different entry point every time be safer? The answer is no. If you rotate guards frequently, then over time you will inevitably connect through a malicious guard. Once you do, a malicious guard that also controls (or can observe) the exit relay can correlate your traffic by timing analysis. By sticking with a small set of guards, you either always avoid the malicious guard or always use it — the latter is bad, but the probability of that outcome is proportional to the fraction of malicious guards in the network, which is low. Frequent rotation would make correlation a certainty given enough time.

Middle Relays

Middle relays are the workhorses of the Tor network. They sit between the guard and the exit, forwarding encrypted traffic in both directions. A middle relay knows only the addresses of the relay before it and the relay after it — it never sees the client's IP or the destination. Running a middle relay carries essentially no legal risk, making it the easiest way to contribute to the Tor network.

Exit Relays

The exit relay is the last hop in a circuit. It decrypts the final layer of onion encryption and sends the traffic to the destination server on the open internet. It is the only relay that sees the actual content of unencrypted requests (such as plain HTTP). The destination server sees the exit relay's IP address as the source of the connection.

Each exit relay publishes an exit policy — a list of destination IP addresses and ports it is willing to connect to. Many exit relays restrict their policy to common ports like 80 (HTTP) and 443 (HTTPS) and block ports associated with email (to prevent spam) or peer-to-peer file sharing.

Exit relay operators bear the greatest legal burden in the Tor ecosystem. Because the traffic appears to originate from their IP address, they may receive abuse complaints, DMCA takedown notices, or law enforcement inquiries for traffic they merely forwarded. Most exit relay operators maintain a Tor exit notice page on port 80 explaining that the IP is a Tor exit relay, and organizations like the EFF provide legal guidance for operators.

Bridges

Bridges are unlisted entry points into the Tor network. Unlike guard nodes, whose IP addresses are published in the public Tor consensus, bridge addresses are distributed privately. This makes bridges essential for users in countries where Tor is actively blocked — censors cannot easily block bridges if they do not know the IP addresses.

Bridges can use pluggable transports — protocol obfuscation layers that make Tor traffic look like something else entirely. The most widely used pluggable transport, obfs4, makes Tor traffic indistinguishable from random noise. Others, like meek, tunnel Tor traffic inside HTTPS connections to major cloud providers (like Cloudflare or Amazon), making it look like ordinary web traffic to a CDN. Censors would have to block the entire cloud provider to block the bridge — a costly tradeoff.

Directory Authorities

The nine directory authorities are the backbone of Tor's trust model. They are hardcoded into the Tor client source code and operated by trusted community members in multiple jurisdictions. Each authority independently measures the network, and a consensus is reached by majority vote. If a majority of directory authorities are compromised, the network's integrity is at risk — but distributing them across different countries and operators makes this extremely difficult.

Tor and the Network Layer

From the perspective of BGP and internet routing, Tor traffic is completely invisible. Tor relays are just servers with ordinary IP addresses, hosted in data centers around the world, their prefixes announced by autonomous systems like any other server. A Tor relay in Germany might be in Hetzner (AS24940), another in the United States might be in AWS (AS16509), and a third in France might be in Scaleway (AS12876).

When you connect to the Tor network, your traffic first goes from your ISP to the guard node — traversing however many autonomous systems are in the AS path between them, crossing Internet Exchange Points, passing through transit providers. The connection from the guard to the middle relay and from the middle relay to the exit relay each independently traverse the BGP routing fabric. A single Tor circuit may cross a dozen or more AS boundaries.

On the wire, a connection to a Tor relay looks like an ordinary TLS connection to a server on port 443 (or port 9001, the default Tor ORPort). An ISP monitoring a user's traffic sees a TLS connection to a known IP address — and since the IP addresses of non-bridge relays are public, the ISP can determine that the user is connecting to the Tor network. However, the ISP cannot see which sites the user is visiting, because the actual destination is hidden behind two more encrypted hops.

This is where the relationship between Tor and BGP becomes particularly interesting for security. The diversity of autonomous systems hosting Tor relays is a critical factor in the network's security. If a single AS hosts a disproportionate share of guard and exit relays, the operator of that AS can observe both ends of many circuits and potentially perform traffic correlation attacks. Tor's relay selection algorithm takes this into account — it avoids placing two relays from the same /16 network or the same AS family in the same circuit.

AS-Aware Path Selection and AS Diversity

Research into Tor's security has increasingly focused on AS-level adversaries — entities that control an autonomous system and can passively observe all traffic entering and leaving it. Unlike a single malicious relay, an AS-level adversary can observe traffic at the network layer without operating any Tor relays at all.

Consider this scenario: a user's ISP is AS-A, and the destination website is hosted in AS-B. If AS-A and AS-B happen to be the same network, or if a transit AS carries traffic on both the client-to-guard and exit-to-destination paths, that AS can see both ends of the communication and correlate them by timing, even though the Tor circuit itself passes through three separate relays in three different ASes.

This is not hypothetical. Academic papers like "Users get routed: traffic correlation on Tor by realistic adversaries" (Johnson et al., 2013) demonstrated that large transit ASes — particularly Tier-1 networks like those with ASNs you can look up in the looking glass — are in a position to observe significant fractions of Tor circuit endpoints.

To address this, researchers have proposed AS-aware path selection — modifying Tor's relay selection to consider the AS-level paths between the client, the guard, the exit, and the destination. Instead of only avoiding relays in the same AS, the circuit builder would also avoid circuits where the same AS appears on the network-layer path between the client and the guard and on the path between the exit and the destination. This requires knowledge of BGP routing tables — the very data that tools like this BGP looking glass provide.

The practical challenges are significant. BGP paths are not static — they change due to routing events, peering changes, and traffic engineering. A circuit that is AS-safe when built may become vulnerable minutes later when a BGP update shifts the path through a different transit AS. Nevertheless, AS diversity remains one of the most important security properties of the Tor network, and the Tor Project actively monitors the distribution of relays across autonomous systems.

Performance: Why Tor Is Slow

Users of Tor immediately notice its performance cost. A typical web page that loads in 200 milliseconds over a direct connection might take 2-5 seconds through Tor. Several factors contribute to this:

• Three hops — Every request and response must traverse three relays. If each relay adds 30-50ms of latency (processing time plus network latency to the next hop), the round trip adds 180-300ms compared to a direct connection. The actual latency is often higher because relays are geographically distributed — a circuit might go from New York to Frankfurt to Tokyo to São Paulo before reaching a server in London.
• Bandwidth constraints — Tor relays are volunteer-operated, and many have limited bandwidth. The total network capacity is roughly 300 Gbit/s shared among approximately 2 million daily users. By comparison, a single large CDN like Cloudflare (AS13335) handles orders of magnitude more traffic.
• Circuit construction overhead — Building a three-hop circuit requires multiple round trips and cryptographic key exchanges. Tor mitigates this by pre-building circuits, but the first connection after launching Tor still experiences this delay.
• TCP-over-TCP problem — Tor encapsulates TCP streams inside other TCP streams. Each hop uses a separate TCP connection, and TCP's congestion control at each layer can interact poorly — a packet loss on the outer TCP connection can cause retransmissions that cascade through the inner connections, leading to severe performance degradation under congestion.
• Encryption overhead — Each cell (the 512-byte fixed-size unit Tor uses) must be encrypted or decrypted three times. On modern hardware with AES-NI support this is minimal, but it adds up at scale.

The Tor Project has made significant improvements over the years. Congestion control (introduced in Tor 0.4.7, 2022) replaced the old fixed-window flow control with an algorithm inspired by TCP Vegas, allowing relays to dynamically adjust their sending rate based on observed round-trip times. This dramatically improved throughput for bulk transfers. Single-stream downloads that previously topped out at 1-2 Mbit/s can now reach 10+ Mbit/s on circuits with sufficient relay capacity.

Threat Model: What Tor Protects Against

Understanding Tor's security requires understanding its threat model — the set of adversaries it is designed to defend against, and the ones it explicitly does not claim to defeat.

What Tor Defends Against

• Local network observer — Your ISP, Wi-Fi provider, or anyone monitoring your local network can see that you are using Tor (unless you use bridges with pluggable transports), but they cannot see which sites you visit, what data you send, or what content you receive.
• Destination server — The website you visit sees traffic coming from a Tor exit relay's IP, not your real IP. It cannot determine your location, your ISP, or your identity from the connection alone.
• Single malicious relay — If one relay in your circuit is compromised, the attacker still cannot link you to your destination. They see only one hop of the three-hop path.
• Network surveillance — Mass surveillance systems that capture traffic at specific network points see only encrypted TLS traffic between Tor relays. They can observe that Tor is being used but not how it is being used.

What Tor Does Not Defend Against

• Global passive adversary — An adversary that can observe all network links simultaneously (such as a sufficiently powerful nation-state) could theoretically perform traffic correlation: matching the timing and volume of traffic entering the Tor network at the guard with traffic leaving at the exit. Tor's design assumes that no single entity has this capability, but the assumption grows weaker as surveillance technology improves.
• Traffic correlation attacks — Even without global visibility, an adversary that controls or observes both the client's ISP and the destination's network can correlate traffic patterns. If you send a 5MB file through Tor, the adversary sees 5MB enter the Tor network at one point and 5MB exit at another point at roughly the same time — strong circumstantial evidence linking the two endpoints.
• Malicious exit relay — An attacker operating an exit relay can observe all unencrypted traffic passing through it. If you visit a plain HTTP site (no HTTPS), the exit relay can read the content, inject malicious code, or steal credentials. This is why using HTTPS over Tor is essential — TLS encrypts the data end-to-end between your browser and the destination, so the exit relay sees only the encrypted stream.
• Browser fingerprinting — Websites can identify users based on browser properties: screen resolution, installed fonts, JavaScript engine behavior, timezone, language settings, and dozens of other signals. These fingerprints are often unique enough to track individuals even without IP addresses. Tor Browser exists specifically to counter this threat (discussed below).
• User behavior — Tor cannot protect you from yourself. Logging into your real email account over Tor, posting personally identifiable information, or using Tor and non-Tor connections simultaneously for the same activity can all de-anonymize you regardless of the network-level protections.

Tor Browser

The Tor Browser is a modified version of Mozilla Firefox that comes pre-configured to route all traffic through the Tor network. But it does far more than simply proxy traffic — it implements dozens of anti-fingerprinting protections that are essential for anonymity on the modern web.

Key protections include:

• Uniform window size — Tor Browser rounds the browser window to a standard size on startup (multiples of 200x100 pixels), preventing websites from fingerprinting users based on unique window dimensions. Users are encouraged not to maximize the window.
• Font fingerprinting protection — The browser restricts which fonts are available to web pages, using a standard set rather than whatever fonts happen to be installed on the user's system.
• Canvas fingerprinting defense — HTML5 canvas operations are intercepted to prevent scripts from extracting unique rendering signatures from the graphics subsystem.
• WebRTC disabled — WebRTC (used for video calls and peer-to-peer connections) can leak the user's real IP address even when using a proxy. Tor Browser disables it entirely.
• JavaScript isolation — Each website gets its own JavaScript context, preventing cross-site tracking via shared state.
• No plugins — Browser plugins like Flash (now defunct) and Java were historically major sources of IP leaks and fingerprinting. Tor Browser blocks them all.
• First-party isolation — Cookies, cache, and other stored data are isolated per top-level domain, preventing tracking networks from correlating your activity across sites.
• Clock precision reduction — Precise timestamps can be used for fingerprinting and timing attacks. Tor Browser reduces the resolution of JavaScript time functions.

The goal is to make every Tor Browser user look identical to websites. If all users have the same browser version, window size, fonts, and JavaScript behavior, a fingerprint reveals nothing about the individual. This is called uniformity as anonymity — you are anonymous because you look like everyone else.

Onion Services (Hidden Services)

Tor is not only used to access the regular internet anonymously — it also supports onion services (formerly called hidden services), which are servers that can be accessed only through the Tor network. Onion service addresses end in .onion and consist of a 56-character base32-encoded string derived from the service's public key (in the v3 onion service protocol).

Onion services provide mutual anonymity: neither the client nor the server knows the other's IP address. This is achieved through a sophisticated protocol involving rendezvous points:

1. The onion service builds circuits to several relays and designates them as introduction points. It publishes these introduction points (signed with its identity key) to a distributed hash table stored on relays with the HSDir flag.
2. A client wanting to access the onion service looks up the introduction points in the distributed hash table, then builds its own circuit to a relay and designates it as a rendezvous point.
3. The client sends a rendezvous cookie to the onion service through an introduction point. The onion service connects to the rendezvous point through its own three-hop circuit.
4. The rendezvous point connects the two circuits together, and encrypted data flows between client and server — each through a separate three-hop circuit. The total path is six hops long.

Onion services provide several unique properties: they are resistant to censorship (no IP address to block), they provide end-to-end encryption without needing a TLS certificate from a CA, and they authenticate the server cryptographically (the .onion address is derived from the server's public key, so connecting to an address proves you are talking to the holder of the corresponding private key).

Tor Browser and HTTPS: Defense in Depth

A common question is whether HTTPS is still necessary when using Tor, since Tor already encrypts traffic. The answer is emphatically yes. Tor encrypts traffic within the Tor network — between your client and the exit relay. But the connection from the exit relay to the destination server is a normal internet connection. If the destination uses plain HTTP, the exit relay and anyone between the exit relay and the destination can read the traffic in the clear.

HTTPS provides end-to-end encryption between your browser and the destination server. Combined with Tor, this means:

• Your ISP sees a TLS connection to a Tor guard — no content visible.
• The guard, middle, and exit relays see encrypted Tor cells — no content visible.
• The exit relay sees a TLS connection to the destination — it can see the destination IP and that you are using HTTPS, but not the content of the request or response.
• The destination server sees the request content but only the exit relay's IP address, not yours.

With both Tor and HTTPS, no single point in the entire chain sees both your identity and your traffic content. This is defense in depth — the two systems complement each other.

Tor and Censorship Resistance

In countries where internet access is heavily censored — such as China, Iran, Russia, and Turkmenistan — governments actively try to block Tor. Their methods have grown increasingly sophisticated:

• IP blocking — The simplest approach: download the public list of Tor relay IPs and block them at the national firewall. This is trivially defeated by bridges, whose IPs are not published.
• Deep packet inspection (DPI) — Firewalls can analyze the TLS handshake patterns of Tor traffic and identify it even though the content is encrypted. The TLS Client Hello messages in Tor connections have distinctive characteristics. Pluggable transports like obfs4 counter this by randomizing the traffic patterns.
• Active probing — China's Great Firewall sends probe connections to suspected Tor relays and bridges. If a server responds with a valid Tor handshake, its IP is blocked. Modern bridges use defenses against active probing — they do not respond to connections that do not present the correct bridge credential.
• Snowflake — A relatively new pluggable transport that uses WebRTC to create ephemeral proxy connections through volunteers running a browser extension. Blocking Snowflake requires blocking WebRTC entirely, which would break many legitimate web applications.

The Network by the Numbers

As of 2024, the Tor network consists of approximately:

• ~7,000 relays contributing roughly 300 Gbit/s of aggregate bandwidth
• ~2,000 bridges providing censorship-resistant access
• ~2 million daily users worldwide
• 9 directory authorities maintaining the consensus
• Relays hosted across hundreds of autonomous systems in dozens of countries

The geographic and AS distribution of relays is critical to the network's security. Germany and the Netherlands historically host the largest share of Tor relay bandwidth, partly due to favorable hosting costs and legal environments. Organizations like DFN (AS680) (the German Research Network) and hosting providers like Hetzner (AS24940) host significant numbers of relays. The Tor Project publishes relay metrics at metrics.torproject.org, including per-AS relay counts.

See It in Action

Tor relay IP addresses are publicly listed, which means you can look them up in a BGP looking glass to see which autonomous systems host them, what AS paths lead to them, and how they are connected to the rest of the internet. This gives you a concrete view of the infrastructure that underpins the anonymity network.

Try these lookups to explore the BGP-level view of Tor infrastructure:

• Look up AS24940 — Hetzner Online, one of the largest Tor relay hosting providers
• Look up AS16509 — Amazon Web Services, hosts many cloud-based Tor relays
• Look up AS13335 — Cloudflare, whose network sees significant Tor exit traffic
• Look up AS680 — DFN (German Research Network), a major Tor relay host
• Look up AS12876 — Scaleway, a European cloud provider with many relays

You can also look up any specific Tor relay IP address to see its BGP route, origin AS, and AS path. The looking glass will show you the same routing information that the global internet uses to deliver traffic to and from that relay — the very routing fabric on top of which Tor's anonymity layer operates. Every Tor circuit you build traverses this BGP infrastructure, crossing autonomous system boundaries at each hop, relying on the same BGP routing that carries all other internet traffic.