How Tor Actually Works

Tor is often described in vague terms: it bounces traffic through several relays, wraps it in layers of encryption, and hides who is talking to whom. That description is directionally correct, but it leaves out the parts that matter when you actually want to understand the system. How does the client know which relays exist. How are circuits built. What exactly is encrypted at each hop. Why is the exit relay special. How do onion services work without exposing a public server IP. Why can Tor hide your network location and still fail badly if the browser leaks identity through other channels.

Those questions live in protocol details, not slogans. Tor is not magical invisibility. It is a network design that tries to separate knowledge so that no single relay learns both the source and destination of a connection. The client knows the whole path. The guard relay knows the client IP but not the final destination. The exit relay knows the destination but not the original client. Middle relays mostly see encrypted forwarding state. If the assumptions hold, linking both ends becomes much harder.

This article explains the system from the point of view of the software and the network. We will cover directory authorities, relay descriptors, guard nodes, layered encryption, circuit extension, stream multiplexing, exits, onion services, hidden service descriptors, and the attack surfaces that still matter in practice. The examples use the public Tor network as it actually runs, including the fact that many important relays are hosted in European data centres and universities.

The Threat Model Is About Linkability

Tor is trying to solve one problem above all others: prevent an observer from linking a client to the destination it contacts. The destination might be a public website. It might be an onion service. Either way, the system tries to make "who talked to whom" difficult to reconstruct.

This is not the same as encrypting content. HTTPS already encrypts content between the client and the server. Tor adds a separate anonymity layer around connection metadata. A normal HTTPS connection hides the HTTP payload from intermediate routers, but the ISP still knows the client contacted example.com at a certain time. Tor tries to hide that relationship.

That threat model has boundaries:

• Tor does not stop a website from identifying you if you log in with your real account.
• Tor does not fix browser fingerprinting by itself.
• Tor does not stop malware running on the endpoint from exfiltrating data.
• Tor does not make timing correlation impossible for a sufficiently strong adversary.

If you understand those limits first, the protocol choices make more sense. Tor is reducing linkability under network observation, not promising perfect secrecy in every layer of the stack.

The Network Starts With Directory Authorities

The Tor client needs a trusted way to learn which relays exist and what properties they have. It gets that from a small set of directory authorities. These are long standing trusted servers hard coded into Tor Browser and Tor clients.

Authorities do several jobs:

• collect relay descriptors
• test relay reachability
• vote on relay flags and status
• publish a signed consensus document

Each relay publishes a descriptor containing information such as:

• relay identity key
• supported protocols
• exit policy
• bandwidth estimate
• address and ORPort

The authorities periodically vote on the network view. Their signed votes are combined into a consensus document. Clients download that consensus and use it as the authoritative map of the network.

This is centralised trust, and Tor accepts that trade off. A fully decentralised discovery design would be much harder to secure and much easier to poison. By keeping a small known set of authorities, the network gains a stable bootstrapping mechanism at the cost of depending on those operators and their key material.

The Consensus Document Is The Client's Map Of The Network

When people say "the client downloads the relay list", that compresses a lot of structure into one phrase. The consensus is not just a flat table of IP addresses. It is a signed summary of the usable network at a point in time.

In broad terms it includes:

• relay identities
• IP addresses and ORPorts
• flags such as Guard, Exit, Fast, Stable, Running, and Valid
• bandwidth weights used for path selection
• policy information that influences which relays fit a circuit role

Clients do not trust an arbitrary relay claiming to be fast or stable. They trust the authority produced consensus view. That separation matters because relay operators have incentives to exaggerate capacity or misrepresent policy if the network were naive.

The client also downloads relay descriptors, which provide more detailed metadata than the consensus alone. Descriptors include relay keys, protocol support, contact text if provided, and more detailed exit policy lines. The consensus tells the client which relays are broadly acceptable. Descriptors fill in the details needed to build an actual circuit.

This bootstrapping phase is one reason Tor startup is not instant. Before the browser can build circuits safely, it needs a current view of the relay network. If the consensus is stale or unreachable, the client cannot make sound path decisions.

Relay Roles Are Not Symmetric

A Tor circuit usually has three relays:

1. guard
2. middle
3. exit

These roles are not interchangeable.

The guard relay is the first hop from the client. It sees the client's IP address because it terminates the TLS like Tor link from the client into the network. It does not know the final destination because the payload is still wrapped for downstream relays.

The middle relay forwards traffic between guard and exit. It sees only its adjacent peers, not both ends.

The exit relay is the last hop before the open internet. It connects to the final destination unless the destination is an onion service. It can see the destination address and the plaintext payload if the user is not using end to end encryption such as HTTPS.

This is why exit relays are operationally sensitive. They are the point where traffic leaves Tor and touches the ordinary internet. Abuse complaints, scanning traffic, and legal pressure often land on exit operators. Running a non exit middle relay is much easier politically and operationally than running an exit.

Guard Nodes Exist To Reduce Exposure

Early anonymity systems rotated entry relays frequently. That sounds intuitive: if the first hop changes often, maybe tracking becomes harder. In practice it creates a different problem. Every time the client picks a new first hop, it risks choosing a malicious entry. Over time the chance of eventually choosing one becomes large.

Tor therefore uses long lived guard nodes. A client selects a small set of guards and sticks to them for an extended period. This reduces the number of relays that ever see the client IP.

The trade off is clear:

• fewer guards means fewer chances to choose a malicious one
• if a chosen guard is malicious, it sees a lot of the client's traffic over time

Tor accepts this because the probability story is better. A careful long term guard policy narrows the exposure surface. The design is not "nobody sees the client". The design is "only a very small set of relays ever have the chance to see the client, and only one of them is used at a time".

Circuit Construction Uses Incremental Key Agreement

The Tor client does not just choose three relays and send one packet with all hops listed. It builds the circuit step by step. The client first establishes a Tor connection to the guard, then extends through that guard to the middle, then through both to the exit.

At each extension step the client performs a key agreement with the next relay. Historically Tor used TAP based on RSA and Diffie Hellman. Modern Tor uses ntor, which is based on Curve25519 and designed for forward secrecy and better authentication properties.

The result is that the client shares a different session key with each hop:

• one with the guard
• one with the middle
• one with the exit

These keys are then used to wrap cells in layers, which is where the "onion" idea becomes literal.

Tor Builds On TLS Like Relay Links Before It Builds Onion Circuits

There are two distinct protection layers in Tor and it helps to separate them mentally. First, the client establishes a TLS protected link to the guard relay, and relays establish TLS protected links to one another. That protects relay to relay transport on the wire from ordinary passive observers.

Second, inside those TLS links, relay cells carry the onion encrypted circuit payload. That is the anonymity layer. The TLS link stops a local observer from trivially reading Tor control and relay cells. The onion layers stop individual relays from learning more circuit context than their role allows.

Without the outer TLS transport, a network observer between Athens and the chosen guard could inspect raw Tor cell traffic much more directly. Without the inner onion structure, the guard itself would learn too much about downstream activity. Both layers matter, but they solve different problems.

That distinction also helps explain why "Tor is encrypted" is both true and incomplete. Yes, relay links are encrypted. Yes, circuit payloads are wrapped in hop specific layers. But the final destination payload still depends on whether the application itself is using TLS or another end to end protocol once traffic leaves the exit.

Onion Encryption Means Each Relay Peels One Layer

Tor traffic moves in fixed size cells. A classic Tor cell is 512 bytes, though newer protocol variants also use larger relay payload formats. Fixed size cells help make traffic analysis harder by avoiding obvious packet size variation at the relay layer.

When the client wants to send a relay cell through a three hop circuit, it encrypts the payload three times:

1. with the exit session key
2. with the middle session key
3. with the guard session key

The guard removes only its outer layer and forwards the result. The middle removes its layer and forwards again. The exit removes the final layer and sees the relay command to connect to the destination or pass application data onward.

On the return path the opposite happens. Each relay adds integrity protected relay layer wrapping back toward the client. The client peels the layers and reconstructs the payload.

The important property is knowledge separation:

• the guard knows the client and next relay
• the middle knows previous and next relay
• the exit knows previous relay and destination

No one relay is supposed to know both the origin and the destination.

Cells And Relay Commands Are The Real Unit Of Tor Traffic

Tor does not forward arbitrary byte streams at the relay layer. It forwards cells. A cell contains a circuit identifier, a command, and a payload area. Relay cells then carry higher level relay commands such as beginning a stream, sending data, ending a stream, extending the circuit, and reporting connection state.

This fixed unit design is important because it gives the protocol a consistent framing layer independent of the application traffic. A relay is not interpreting HTTP or SMTP. It is parsing Tor cells, checking which circuit they belong to, applying or removing the appropriate cryptographic layer, and forwarding them onward.

The fixed size structure also helps avoid simple packet size leakage inside the relay network. It does not eliminate traffic analysis, but it does stop the protocol from broadcasting application level message sizes directly at each hop.

Tor Multiplexes Streams Over Circuits

A Tor circuit is not identical to a single TCP connection to one destination. The client can open multiple streams over the same circuit. For example, several HTTP requests may share one built circuit for a while.

This improves performance because building a circuit is expensive. It requires relay selection, incremental extension, and key establishment. Reusing a circuit for multiple streams amortises that cost.

At the same time it introduces linkability within the client's own activity. If several destinations are contacted over one circuit close together, an exit relay may infer they belong to the same client session even if it still does not know the client IP. Tor Browser therefore uses isolation strategies to separate some traffic classes, reducing accidental correlation between unrelated browsing contexts.

Exit Relays Are Where End To End Encryption Still Matters

If a Tor user connects to an ordinary HTTP site, the exit relay can read and modify the plaintext. Tor protects the path inside the network, not the application payload after it leaves the exit.

If the user connects to an HTTPS site, the exit relay sees:

• destination IP or hostname
• TCP port
• TLS handshake metadata visible before encryption details take over

but it cannot read the encrypted HTTP body and headers once the TLS session is established. This is why HTTPS remains necessary on Tor. Tor is not a substitute for end to end application encryption.

The exit relay also influences reputation and reachability. Some websites challenge or block Tor exits because abuse appears to come from them. That is not because Tor is breaking HTTPS. It is because many users share a relatively small pool of public exit IP addresses, which look noisy or suspicious to destination services.

DNS Resolution At The Exit Changes What The Destination Learns

When a client visits a normal website over Tor, the DNS lookup for that destination is typically performed from the exit side rather than from the user's local network. That matters because it prevents the local ISP or campus resolver from learning the clearnet hostname directly as part of the ordinary browsing flow.

It also means the destination side of the world sees a coherent picture from the exit relay:

• the DNS query source
• the TCP connection source
• the TLS handshake source

All of that appears to originate from the exit environment rather than from the original client location. This is useful for anonymity, but it also reinforces why exit operators occupy such a sensitive position. They are the boundary where Tor traffic becomes ordinary internet traffic again, including the boundary where name resolution meets destination connectivity.

For onion services this issue disappears because no public DNS resolution is involved. For clearnet access, however, DNS handling is part of the anonymity story, not an incidental implementation detail.

Onion Services Avoid The Exit Relay Entirely

An onion service, often still informally called a hidden service, works differently. The server does not expose a public IP to the client. Instead both client and service meet through Tor relays using rendezvous logic.

The service first chooses several introduction points in the Tor network and publishes a signed descriptor that lists them. That descriptor is stored in distributed hash table style onion service directories. The client, after deriving where the descriptor should live, fetches it and learns the introduction points.

To connect, the client:

1. builds a circuit to a chosen introduction point
2. builds a separate circuit to a chosen rendezvous point
3. sends a message through the introduction point asking the service to meet at the rendezvous point
4. the service builds its own circuit to that rendezvous point
5. once both sides are attached, traffic flows through the rendezvous relay

No exit relay is involved because the destination is also inside Tor. The client never learns the service IP. The service never learns the client IP. The rendezvous point knows it is relaying for two Tor circuits, but not the real identities behind them.

This is one of Tor's most elegant properties. For an ordinary internet destination, some relay has to hand traffic to the public network and that relay inevitably becomes operationally sensitive. For an onion service, both endpoints stay inside Tor and the public handoff point disappears entirely.

Onion Service Discovery Uses A Distributed Placement Scheme

The service cannot simply publish its introduction points at one hard coded directory server because that would create an obvious choke point. Instead, onion service descriptors are placed at positions in the Tor directory space derived from the service identity and the current time period.

The effect is that:

• clients can deterministically compute where to look
• services can deterministically compute where to publish
• no single central directory stores every onion descriptor permanently in one place

Descriptor placement rotates over time, which limits some persistence attacks and spreads responsibility across multiple hidden service directory relays. The details are more involved than ordinary DNS because the goal is not only reachability but also limiting who learns what about the service.

This again reflects Tor's broader design habit. Rather than give one component global knowledge, it divides discovery, connection setup, and forwarding into narrower pieces so each relay role sees only a limited slice.

Onion Addresses Are Derived From Public Keys

Modern onion addresses, the long 56 character onion strings, are not arbitrary labels. They are derived from the service's public key material. In version 3 onion services, the address encodes:

• the service public key
• a checksum
• a version byte

This means the name itself is cryptographically tied to the service identity. If you know the onion address, you know which key should authenticate the service. There is no public CA hierarchy equivalent to ordinary web PKI here. The address is self authenticating.

That design avoids DNS and certificate dependency, but it creates usability costs. Human memorable onion names are hard. Discovery often depends on directories, links, or copy and paste from trusted channels.

Performance Is Limited By Layering And Path Length

Tor adds latency for obvious reasons:

• more hops
• more cryptographic operations
• volunteer operated relays with uneven bandwidth
• TCP over TCP style inefficiencies at the application level

A request going from Barcelona through a guard in Germany, a middle relay in the Netherlands, and an exit in Sweden before reaching a site in Finland simply travels farther and through more queues than a direct connection. The protocol accepts that cost because anonymity requires relay separation.

Bandwidth is also limited by the slowest relay on the circuit and by congestion across the network. Tor therefore uses bandwidth weights from the consensus and relay level flow control to try to steer traffic sanely. Still, it is an anonymity network, not a low latency accelerator.

Circuit Lifetime Is A Trade Off Between Freshness And Linkability

Tor does not build one circuit at startup and keep it forever. It rotates circuits over time and opens new ones for new streams according to browser isolation and lifetime rules. The reason is that using one path indefinitely would make long term correlation inside the network easier. At the same time, rebuilding too often would increase latency and expose the client to more relay choices.

So the system balances several goals:

• do not reuse one circuit so long that everything links together
• do not rebuild so often that browsing becomes unusably slow
• keep some streams isolated from each other
• avoid unnecessary exposure to many entry candidates

This is a recurring Tor design pattern. There is rarely one perfect rule. Most behaviours are compromises between anonymity surface, performance, and operational simplicity.

What A Local Observer Can Still Learn

A local network observer such as an ISP, campus network, or employer can usually see that the client is connecting to a Tor guard relay unless bridges or pluggable transports are used. The observer may not know the final destination, but the fact of Tor usage itself can be visible.

Tor therefore supports bridges, which are relays not listed in the public consensus, and pluggable transports such as obfs4 that try to make Tor traffic look less distinctive on the wire. These tools address censorship and blocking rather than the core anonymity path design.

If a censor knows the IPs of public guards and blocks them, ordinary Tor connections fail. Bridges are a way to create less obvious entry points. If the censor uses traffic fingerprinting, pluggable transports try to blur the protocol signature.

Global Correlation Is The Hard Problem

The classic serious attack on Tor is traffic correlation. If an adversary can observe both the client side and the destination side with enough precision, it can try to match patterns in timing and volume. This does not require breaking the onion encryption. It relies on statistical linkage.

For example, if one observer sees a burst pattern entering the Tor network from a client in Vienna and another observer sees a very similar burst pattern leaving an exit toward a site in Prague, correlation may be possible. The stronger and broader the observer, the harder Tor's job becomes.

Tor's design makes this more difficult by using many relays, fixed size cells, and path separation, but it does not make it impossible under a sufficiently capable network adversary. This is why honest explanations of Tor always distinguish between:

• protection against ordinary local observation
• resistance against partial network visibility
• weaker guarantees against a truly global passive observer

The system is strong, but it is not omnipotent.

Website Fingerprinting And Timing Analysis Still Matter

Even if the adversary cannot observe both ends of the network perfectly, traffic analysis can still extract signal from packet timing and volume patterns. Website fingerprinting research studies exactly this problem: can an observer watching only the client side infer which site was visited based on burst shape and sequence length.

The answer is often partly yes. Modern websites have distinctive loading patterns. A page with many large scripts, a specific image count, or a particular request waterfall can leave a recognisable trace even through Tor. Defences such as padding and normalised browser behaviour help, but the problem does not disappear completely.

This is why Tor Browser tries to reduce variability above the network layer. If every user had wildly different font sets, extension behaviour, and resource loading order, the traffic shape and browser fingerprint would become much easier to classify together. Network anonymity and application standardisation reinforce each other.

For a strong adversary, timing remains one of the hardest categories of leakage to suppress without imposing very heavy latency and bandwidth costs. Tor therefore reduces the signal where practical, but it does not claim to erase it fully.

Bridges And Pluggable Transports Help Users Reach Tor At All

Bridges solve a different problem from onion routing itself. They do not make the internal circuit design more anonymous. They help users get into the Tor network when public relays are blocked or when plain Tor traffic is easy to fingerprint.

A bridge is an entry relay that is not published in the normal public relay list. Because it is less visible, it is harder for censors to block at scale. Pluggable transports then alter how the traffic looks on the wire so it is less obviously classifiable as Tor.

This matters because some threat models begin before the first guard hop. If the local network observer can block all public guards or flag any recognisable Tor handshake immediately, the client never even reaches the onion routing stage. Bridges and transports are therefore about reachability and censorship resistance, not a replacement for the core anonymity design.

Relays Need Reputation, Capacity, And Policy Control

Tor cannot treat every relay as identical. Some are stable and fast. Some are unreliable. Some permit exits only to specific ports. Some are bridges. Some are suitable as guards because they are stable enough to stay online for long periods.

The consensus therefore carries flags such as:

• Guard
• Exit
• Fast
• Stable
• Running
• Valid

Clients use these flags when selecting paths. Exit policy matters especially. An exit relay may allow ports 80 and 443 but refuse many others. If a client wants to connect to a destination port that the chosen exit disallows, the stream will fail or a different exit must be used.

This is one reason Tor path selection is more constrained than "pick any three nodes". The network is trying to balance anonymity, capacity, and actual reachability.

Path selection also has to consider diversity. If a circuit used relays from the same operator family, the same hosting provider, or the same network region too often, the chance of correlated observation would rise. Tor therefore includes rules to reduce obviously bad combinations, even if that means ignoring some otherwise fast relay candidates.

This does not eliminate concentration risk. Many important relays still live in a relatively small set of data centres and university or non profit hosting environments. But explicit diversity rules are better than pretending all relays are equally independent.

Browser Side Leaks Can Undo Network Side Anonymity

The Tor path can be correct and the user can still lose anonymity if the application leaks identity. Some common failure classes are:

• logging in to personal accounts
• opening documents that make direct network requests outside Tor
• browser fingerprinting through fonts, canvas, timing, or extensions
• JavaScript enabled sites correlating behaviour patterns
• clipboard and download habits that identify the user across sessions

Tor Browser exists because generic browsers are not built for anonymity. It standardises many observable properties to make users look more alike. Window size bucketing, controlled font exposure, and careful defaults are not cosmetic choices. They are anonymity set protection.

This is also why installing extra browser extensions is discouraged. A unique extension set becomes a fingerprint. At the network layer Tor may have hidden your IP. At the browser layer you may have built a rare profile that points back to you.

Operational discipline matters just as much. If a user opens Tor Browser and then logs into a personal email account, reuses a unique pseudonym used elsewhere, uploads a document with identifying metadata, or copies text patterns that are obviously tied to one identity, the network can be perfect and the anonymity goal can still fail. Tor protects the route. It does not create a separate human identity for the user. Good Tor usage therefore includes browser hardening, account separation, and careful treatment of files and credentials outside the browser itself.

Onion Services Have Their Own Attack Surface

Onion services avoid exit relays, but that does not make them invulnerable. Important attack surfaces include:

• deanonymising the service through operational mistakes outside Tor
• denial of service against introduction points
• descriptor harvesting and service enumeration
• traffic confirmation if the adversary can observe both service side and client side
• application layer fingerprinting of the service itself

An onion site that also leaks the same image assets, headers, time zone behaviour, or admin panel characteristics as a clearnet site can sometimes be linked by investigators or researchers. The network address may be hidden while the application fingerprint remains unique.

Tor Solves A Narrow Layer Well, Which Is Why Operational Hygiene Matters

One reason Tor is frequently misunderstood is that users ask it to solve every privacy problem at once. It does not. It solves a narrow but difficult layer of the problem: route level linkability. That is valuable precisely because network metadata is so revealing. But once that layer is handled, many other layers remain.

An investigator or adversary may still work through:

• browser fingerprinting
• account reuse
• behavioural timing patterns
• file metadata
• payment records
• physical seizure of the endpoint

This is not a criticism of Tor. It is a reminder that strong systems often solve one class of problem precisely rather than every class vaguely. Tor's network design is coherent because it keeps that scope tight. The user then has to match that precision with equally careful behaviour above the network layer.

A Clearnet Request Walk Through Makes The Roles Concrete

Consider a Tor Browser user in Athens opening a public website hosted behind ordinary HTTPS in Helsinki. The request path looks roughly like this:

1. the client downloads or already has a current consensus and relay descriptors
2. it chooses a guard, middle, and exit consistent with policy and diversity rules
3. it opens a TLS like Tor link to the guard
4. it extends the circuit hop by hop, performing ntor key agreement at each step
5. it opens a stream through the finished circuit toward the destination hostname and port
6. the exit resolves the hostname and connects to the destination
7. the client performs the HTTPS handshake through the circuit
8. encrypted application data begins to flow

Now look at what each participant can see.

The client sees the full plan. It knows the guard, middle, exit, and destination. That is unavoidable because it is the endpoint initiating the session.

The guard sees the client IP and knows it forwarded traffic into the Tor network toward the next relay. It does not see the final destination hostname in the ordinary case of stream setup carried inside the onion protected relay layer.

The middle relay mostly sees an incoming Tor link from the guard side and an outgoing Tor link toward the exit side. It forwards cells and manages circuit state, but it does not learn both ends.

The exit sees a Tor relay on one side and the public destination on the other. It can learn the target hostname or IP and the destination port. If the user is not using HTTPS, it can also read and alter the plaintext payload. If HTTPS is used, it sees connection metadata and the outer TLS handshake pattern but not the encrypted HTTP body.

The destination site sees the exit IP, not the client IP. Its server logs record a connection coming from the exit. If the site operator later inspects abuse logs, rate limits, or geolocation data, all of that is associated with the exit network presence rather than the user's original access network.

The local ISP or campus network sees the client connecting to the guard unless bridges or transports hide that fact. It does not see the final destination directly from the ordinary browsing flow because the Tor path and exit side DNS resolution sit in between.

That one example captures the whole Tor design philosophy. No single network observer on that path learns everything by default. The information is split across roles.

An Onion Service Request Has A Different Privacy Geometry

Now replace the public website with an onion service. The flow changes in a way that reveals why onion services are considered a separate protocol layer rather than "Tor websites" in a vague marketing sense.

Suppose the client wants to reach a service whose onion address corresponds to a server operated from a host somewhere in Europe. The sequence looks more like this:

1. the client derives where the service descriptor should live
2. it fetches the descriptor from the relevant hidden service directories
3. the descriptor reveals the service's introduction points
4. the client chooses a rendezvous relay and builds a circuit to it
5. the client also builds a circuit to one introduction point
6. through the introduction point it sends an introduction message containing rendezvous material
7. the service receives that introduction message and decides whether to accept
8. if it accepts, it builds its own circuit to the rendezvous relay
9. traffic now flows through the rendezvous point between two Tor side circuits

Notice what disappears from the picture: there is no public exit to the ordinary internet. That removes a whole class of exposure. No relay has to reveal the service by opening a public TCP connection to it. No public DNS lookup happens for the service name. No destination server log records the original client or even a public exit as the direct caller.

The client still knows the onion address and the rendezvous plan it initiated. The service still knows it is receiving a request for itself. But the network level knowledge remains divided. The introduction point knows it forwarded an introduction message. The rendezvous point knows it is connecting two Tor side circuits. Neither should know both real identities.

This geometry is why onion services are powerful for server location privacy. With a public website, the server IP must be reachable on the internet somewhere. With an onion service, the server identity is represented by key material and descriptor placement rather than by a globally exposed IP address that every client learns.

Relay Churn, Network Health, And Why Bootstrapping Must Keep Repeating

The Tor network is not static between one browser launch and the next. Relays appear, disappear, lose stability, change policy, upgrade software, and sometimes get flagged differently by the authority process. That means the client cannot treat its first downloaded consensus as permanent truth.

Over time several things happen:

• some relays go offline unexpectedly
• some relays recover after interruption
• bandwidth estimates change
• exit policies change
• software versions roll forward
• authorities produce fresh votes and a new consensus

The client therefore refreshes its view of the network periodically. If it did not, it would keep trying to build circuits through stale paths and would lose the ability to react to changing relay quality. This maintenance work is less glamorous than onion encryption, but it is what keeps the public network usable day after day.

Relay churn also affects anonymity in indirect ways. If the network were tiny or highly unstable, clients would have fewer plausible path choices and more repeated reuse of the same small set of relays. That would narrow the anonymity set. A healthier, broader, better distributed relay population supports both performance and privacy because it gives path selection more room.

This is one reason relay diversity matters beyond raw throughput. A network with 10 extremely fast relays under a narrow set of operators is not equivalent to a network with hundreds of reasonably fast relays spread across different administrative boundaries. Tor gains resilience from breadth, not only from peak capacity.

Tor Browser Exists Because The Network Alone Is Not The Product

It is easy to talk about Tor as if it were only a relay network. In practice most users encounter it through Tor Browser, and that is important because the browser is carrying a large part of the privacy burden.

If a user connected through the Tor network using a generic browser configured casually, many identifying signals would remain exposed:

• unusual window size
• extension fingerprints
• font availability
• canvas and graphics behaviour
• media codec support differences
• platform quirks in JavaScript observable APIs

Tor Browser tries to flatten those differences so users look more alike. That is not perfect, but it is one of the main reasons the network anonymity story remains credible for ordinary users. The browser tries to reduce variation in the layer where websites actually observe the client.

This is also why some user requests conflict with Tor's goals. People want custom extensions, persistent highly personalised settings, unusual viewport layouts, and complex desktop integration. Each of those can be convenient. Each of them can also make the browser more distinctive. Tor Browser therefore makes many conservative choices because privacy often requires refusing customisation that would be harmless in a normal consumer browser.

The result is that Tor is best understood as a stack:

• directory and consensus logic for network discovery
• onion routing for path level knowledge separation
• bridge and transport support for censorship resistance
• browser hardening for application level uniformity

If one layer is neglected, the rest can still work mechanically while the overall privacy outcome degrades.

Relay Operators Face Very Different Incentives Depending On Their Role

From the user's perspective, a relay is a relay. From the operator's perspective, guard, middle, bridge, and exit roles create very different practical burdens.

A middle relay is usually the easiest public contribution. It forwards encrypted Tor traffic but does not originate public internet connections to arbitrary destinations. That means abuse complaints are relatively limited and legal ambiguity is lower.

A guard relay has a different sensitivity. It sees client IP addresses at the edge of the network. That creates a stronger privacy burden for the operator and makes stability especially important because long lived guard behaviour depends on trusted persistence. A highly unstable guard is less useful than a stable one because clients want a small, reliable entry set.

An exit relay is the most operationally exposed role. It originates public traffic toward websites and services, so:

• complaint desks see the exit IP
• rate limits and blocks often land on the exit
• legal notices and abuse mail go to the operator
• destination services may blacklist or challenge the relay aggressively

This is why the Tor network can have strong middle capacity and still feel exit constrained. The bottleneck is not just technical. It is social, legal, and operational. Running exits requires a higher tolerance for friction and better preparation around policy, hosting, and abuse handling.

Bridges have their own incentive structure again. They are useful because they are not widely listed and can help users enter the network under censorship. But that same low visibility means bridge distribution and bridge secrecy become part of the design problem. Publicity helps volunteers find them, yet too much publicity makes them easier for censors to block.

Understanding these operator incentives helps explain why Tor cannot be analysed purely as protocol theory. The network that actually exists is shaped by the kinds of roles volunteers and organisations are realistically willing to sustain.

Tor's Security Depends On Independence, Not Just On Encryption

It is tempting to summarise Tor as "traffic is encrypted several times", but encryption alone is not the defining property. The system depends just as much on independence between the parties that observe different parts of the path.

Imagine a world where the guard, middle, and exit are all run by one operator inside one hosting provider using adjacent machines. Onion layers still exist, but the knowledge separation property degrades because one administrative domain can correlate observations across the circuit more easily.

Path diversity rules matter for that reason. Tor tries to avoid obviously related relays and relay families in the same circuit because anonymity comes from distributed trust assumptions. If every hop collapses into one organisation, the cryptographic layering still protects against outsiders but no longer creates the same internal separation.

The same logic appears at larger scales:

• concentration in one data centre ecosystem is not ideal
• concentration in one country is not ideal
• concentration in one operator family is not ideal

Tor does not eliminate these risks fully because the public relay ecosystem is limited by who volunteers and where they host. But the design keeps pushing toward independence because that is where anonymity value actually comes from.

This is also why discussion of "how many relays exist" can miss the real question. A network with 500 relays under narrow operational control is weaker than a network with fewer relays spread across more independent organisations and jurisdictions. The count matters. The independence pattern matters more.

Endpoint Timing And Behavioural Correlation Remain The Practical Edge Cases

Most people hear "global passive adversary" and imagine only state level surveillance. In practice, correlation pressure also appears in smaller but still serious ways:

• a website sees repeated return visits with similar behaviour timing
• a local observer sees when Tor sessions begin and end
• an application server records exactly when some action occurred
• leaked account activity elsewhere provides matching timestamps

Even if none of those observers individually sees the whole network path, analysts can sometimes line up events and shrink uncertainty. Experienced Tor usage advice often sounds behavioural rather than purely network focused for that reason. Delay patterns, account separation, document handling, and login discipline all exist because correlation risk is not confined to relay mathematics.

The network gives the user a stronger starting point. It does not absolve the rest of the operational picture. Tor remains strongest when route anonymity is paired with disciplined endpoint behaviour and with applications that do not immediately reattach real world identity at the first login screen.

What Tor Cannot Hide From The Destination By Design

Tor is strong at hiding the client IP, but the destination still learns many things unless other defences are added. A website contacted through Tor can still observe:

• login credentials and account identity if the user provides them
• cookies and persistent session state
• application level timing
• browser behaviour exposed through JavaScript and HTTP headers
• anything the user uploads directly, including metadata inside files

This is not a protocol flaw. It is a consequence of where Tor sits in the stack. Tor changes the network path. It does not automatically rewrite the semantics of the application protocol at the destination. If a user signs into a long lived personal account, the site no longer needs the IP address to recognise who it is dealing with.

The best Tor explanations always separate network anonymity from application identity for that reason. The network layer can be well protected while the destination still learns enough from the application session to reattach the activity to one person. Tor remains useful because IP level linkability is highly revealing, but it has to be paired with careful application behaviour to achieve stronger privacy outcomes.

Tor Remains Valuable Because IP Metadata Alone Is Often Enough To Identify Behaviour

It is easy to underestimate how much information ordinary network metadata reveals. If a user's ISP or employer can see which sites were contacted, when they were contacted, and how often the pattern repeats, that alone can reveal sensitive interests, relationships, and routines even when payload encryption is perfect.

Tor matters because it attacks exactly that category of exposure. It does not solve every privacy problem, but it removes one of the most routinely available sources of behavioural evidence: direct source to destination linkage at the network layer.

That alone is substantial.

The Right Mental Model

Tor works by dividing knowledge. The client learns the full circuit. Each relay learns only the neighbour information and the layer it must process. Guards reduce entry exposure. Exits let traffic reach the ordinary internet. Onion services replace exits with rendezvous logic. Directory authorities publish a signed shared map of the relay network so clients know what exists and what is usable.

That design achieves something valuable and concrete. It makes routine source destination linkage much harder. It raises the cost of surveillance. It protects users against many ordinary observers on local networks, access providers, and destination services that would otherwise directly see the client IP.

It does not erase all identity. Strong adversaries can still attempt correlation. Browser behaviour can still betray the user. Operational mistakes can still reveal the service. Tor is therefore best understood as a carefully engineered anonymity network with explicit assumptions, not an abstract promise of invisibility.

Once you see it that way, the protocol becomes much easier to reason about. Directory authorities solve bootstrapping. Guard nodes solve repeated entry exposure. Onion encryption solves knowledge separation per hop. Rendezvous circuits solve hidden destination exposure. Browser hardening solves application side leakage as far as practical.

That is the system. It is not simple, but it is coherent. And most of its important properties come not from one clever trick but from many narrow decisions that each remove one category of information from one part of the path.