Short answer: Onion routing encrypts data multiple times and sends it through several relays. Each relay removes only its layer and knows only the next hop. Tor implements this with guard, middle, and exit. It protects the path, not automatically the content to the website — HTTPS is still required.
Onion routing is a method that protects communications metadata through multi-stage forwarding and nested encryption. Terms in the glossary: Onion Routing, Guard Node, and Exit Node. Tor is the best-known publicly available implementation. Unlike a direct connection, Tor does not send data on the shortest path from client to destination. The client builds a circuit through several relays and uses cryptography so that each relay knows only the immediately necessary part of the path.
The goal is not to trust every computer involved. On the contrary: the design assumes that individual relays can be observed or malicious. Security comes from separating knowledge. The entry knows the user but not the destination. The exit knows the destination but not the user. The middle node joins the two segments without seeing either end identity.
From directory to circuit
A Tor client first needs a reliable view of the network. Special directory authorities jointly produce a signed consensus. It includes relay keys, reachable addresses, measured bandwidth, roles, and policies. No single ordinary web server decides which relays are available. The client ships with trusted keys and checks signatures before accepting the consensus.
From that network view the client chooses a path. Selection is weighted: relays with reliably measured capacity are used more often in proportion to their performance. Certain combinations are avoided, such as several relays from the same declared family or from nearby network ranges. That makes it harder for one operator group to occupy several positions on the same circuit.
A typical circuit to the open internet has three hops. More hops sound intuitively safer but do not automatically add proportional protection. They increase latency and network load, while the core goal is already met by separating entry and exit. Fewer hops would weaken that separation. Tor therefore chooses a pragmatic compromise of security, performance, and scalability.
Layered encryption
The client negotiates key material separately for each hop. The build is stepwise: first a secure connection to the guard. Through that existing channel the client extends the circuit to the middle relay and then to the exit. The previous relay forwards the negotiation but cannot derive the secret keys meant for later hops.
For an outgoing data unit the client applies cryptographic layers in reverse path order. Simplified: it encrypts first for the exit, then for the middle relay, and last for the guard. The guard removes the outer layer and sees the instruction to forward to the middle relay. That relay removes its layer and forwards to the exit. After the last Tor layer, the exit can serve the connection to the destination server.
The onion metaphor is useful but incomplete. Tor does not build a classic onion with entirely new keys for every IP packet. It carries data in structured cells and uses efficient symmetric cryptography inside a built circuit. Modern protocol variants also protect integrity and secure negotiation. The principle remains: each hop processes exactly one layer meant for it.
Reply data travels back on the same circuit. Each relay adds its cryptographic processing on the return path, and the client removes or processes the layers. Outsiders see encrypted connections between neighboring relays. Packet sizes, timing, and volumes do not disappear completely. Tor is a low-latency network and does not add strong, lasting delays or large amounts of cover traffic.
Guard, middle, and exit
Why guards are used for a long time
The guard is the only relay position that regularly sees the client’s connection IP. If the client chose a brand-new entry for every circuit, every malicious guard in the network would eventually get an observation chance. Tor therefore limits the set of possible entries per user and keeps guards for a long time. That concentrates a possible risk but reduces the chance of meeting a controlled entry at all.
The guard sees when the client uses Tor and roughly how much data is transferred. On a normal circuit it does not see which exit or internet destination is ultimately used. An observer directly on the connection has a similar timing view. Bridges can help hide that the entry is a publicly known Tor address; they do not solve the basic correlation problem of an observer who also watches other parts of the network.
The middle relay as distance
The middle relay separates guard and exit. It knows the guard’s address as predecessor and the exit’s as successor. The user’s connection IP and the final internet destination are missing. A malicious middle relay alone therefore cannot complete the linkage. It can disrupt connections, delay them, or observe data patterns, but that does not automatically yield plaintext.
Middle relays are the most straightforward form of support for volunteer operators. Because they do not send traffic directly onto the open internet, their IP addresses do not appear as the source of website requests. Their bandwidth increases the network’s diversity and capacity. The security effect depends not only on count but also on geographic, organizational, and topological independence.
The exit and the destination
The exit opens TCP connections to allowed destination ports. Its exit policy sets which destinations or ports it serves. It sees the destination address and can read application data if end-to-end encryption is missing. It does not see the connection IP; the predecessor appears as the middle relay.
HTTPS therefore remains indispensable. TLS is negotiated between browser and website and runs through the Tor circuit. An exit then carries encrypted application data. It still sees destination IP, port, time, and volume, but it cannot readily read page content, passwords, or form data. Certificate warnings must not be ignored; they can indicate an attack or a misconfiguration.
DNS resolution for the destination name is, in correctly used Tor applications, requested through the Tor network, typically at the exit. A local DNS query outside Tor would be an information leak. That is why Tor Browser is safer than an improvised proxy configuration of an arbitrary program: it aligns name resolution, browser isolation, and network paths.
Streams, circuits, and isolation
A circuit is the path through relays; a stream is a single application connection inside that path. Tor can briefly carry several streams over the same circuit to avoid expensive setup and extra latency. Circuits are replaced regularly, but not on every click. “New circuit for this site” changes the path for that website context, while “New identity” resets further browser state.
Switching too often by hand is not a universal security upgrade. It can put more relays in contact with the use and does not automatically destroy server-side accounts, text traits, or cookies already sent. Tor Browser isolates website data by first-party context so that different sites cannot easily combine their identifiers. That browser feature complements onion routing; it is not part of the relay cryptography.
Applications must use proxy rules correctly. Some protocols carry the local IP address in the content or open extra direct connections. BitTorrent is the best-known counterexample and also loads the network heavily. For web use, therefore use Tor Browser. Other applications need a documented configuration expressly suitable for Tor.
Onion services without an exit
With an onion service both ends stay in the Tor network. The service publishes encrypted descriptor information at distributed directory positions. A client that knows the onion address chooses a rendezvous point and contacts the service through introduction points. Client and service each build their own circuits to the rendezvous. That point joins the data streams but does not automatically learn both network addresses.
Because no exit is involved, there is no unencrypted last Tor hop. In addition the onion address authenticates the service’s public key. That does not replace all application security: a flawed website, a compromised server, or phishing remain possible. The long v3 address must come from an authentic source.
Onion services enable legitimate uses such as SecureDrop, protected admin interfaces, software repositories, and reachable services behind NAT. They should not be equated with random link lists. Technically .onion describes an addressing and authentication method, not a quality or legality rating of the content.
The threat model
Tor protects well against a local observer who sees only the connection at the access point, and against destination servers that see only the exit. It is robust against individual malicious relays as long as they cannot observe both relevant ends. It also protects against simple central logging by a single VPN provider, because no single Tor party mediates the entire standard connection.
Tor protects more weakly against a global passive adversary. Anyone who can observe the stream near the client and at the same time near the destination can statistically correlate timing, direction, and volume. Low latency is required for interactive browsing, but it prevents strong temporal mixing. Tor therefore does not claim to be a mixnet for every conceivable adversary.
Active attacks matter too. An adversary can delay traffic, mark it, drop connections, or try to steer users onto controlled infrastructure. Cryptographic integrity prevents simple content marking inside the circuit, but disruption patterns at the network layer are harder to rule out completely. The directory architecture, guard selection, and path rules reduce individual attack surfaces.
Endpoint compromise is outside the core protection. Malware on the client sees data before it enters Tor. A compromised destination server sees data after decryption. Browser security holes can bypass protections. Updates, operating-system hygiene, safe downloads, and — at high risk — an isolated environment are therefore as important as the network path.
The human is part of the model as well. A login identifies an account; a document can contain author names or GPS data; a writing style can be recognizable. If separated roles use the same username, the same email address, or distinctive time patterns, onion routing does not restore that separation. OPSEC means analyzing those information flows in advance.
Attacks and realistic limits
Sybil attacks try to bring many seemingly independent relays under one control into the network. The Tor community analyzes relay behavior, families, keys, and network traits to spot suspicious groups. Bandwidth weighting and guard requirements raise the cost but do not eliminate the danger. An open volunteer network needs ongoing measurement and response.
Website fingerprinting tries to infer visited pages from encrypted size and timing patterns. Research shows measurable signals under controlled conditions, but accuracy depends heavily on assumptions, training data, and observation position. Countermeasures conflict with speed and bandwidth. Users should neither ignore alarm reports wholesale nor treat lab results as automatic deanonymization of every real session.
Browser fingerprinting is a different layer. Websites combine visible traits such as window size, platform signals, and supported features. Tor Browser tries to make many users look the same. Individual extensions, maximized unusual window sizes, or unlocked APIs can shrink that anonymity set. “More hardening” through a personal special configuration is therefore not always better.
An exit can manipulate unencrypted HTTP traffic. HTTPS and onion services largely prevent that specific attack if certificates and addresses are checked. Downloaded programs should additionally be verified via signatures or published checksums. Trust in the transport does not replace checking the artifact.
Performance as a security trade-off
Tor optimizes for interactive communication. Three geographically distributed relays and extra cryptography make connections slower than the direct path. Current load, relay distance, and destination-server performance affect the result. A slow page load proves neither an attack nor a broken relay.
Strong cover-traffic systems could give observers less timing information but would produce far more bandwidth and delay. Tor deliberately chooses usable latency and broad accessibility. That design lets millions of people browse normally, but it sets a clear limit against adversaries with comprehensive simultaneous visibility.
Responsible use of shared bandwidth is part of the system. Large continuous downloads and filesharing harm other users. For software, projects often offer signed downloads over ordinary connections; not every file must travel through Tor if only authenticity, not retrieval metadata, needs protection.
Practical conclusions
For web use, the official Tor Browser should be used. It prevents typical DNS leaks, isolates website state, and ships sensible defaults. HTTPS must still be checked. Browser add-ons, external programs, and personal customizations should be used only when their effects are understood.
Before a sensitive session, a threat model is more helpful than flipping every option at random. Someone who only wants less ad tracking has different needs than a source whose device might be examined. At high risk, advice from a trusted digital-security organization and an agreed process are appropriate.
Onion routing provides a clear technical property: no single relay in a normal three-hop circuit is meant to receive both source and destination. That yields strong, practically usable privacy protection. It does not follow that all metadata vanishes, that endpoints are safe, or that human identifiers become meaningless. Distinguishing those claims is essential.
Conclusion
Tor is built on verified network information, stepwise key agreement, three specialized relay positions, and nested cryptography. Guard, middle, and exit share knowledge of a connection. Tor Browser adds application-layer protection to that path, while onion services allow connections entirely inside the Tor network.
The system is designed against local observation, destination tracking, and individual compromised relays. A global observer, traffic correlation, compromised endpoints, and poor OPSEC remain limits. Anyone who knows those limits can neither underestimate Tor nor overload it with unrealistic promises.
Sources
- Dingledine, Mathewson, Syverson: Tor: The Second-Generation Onion Router
- Tor Project: Tor Specifications
- Tor Project: The lifecycle of a new relay
- Tor Project Community: Onion Services overview
- Electronic Frontier Foundation: Tor and HTTPS