Complete Anatomy of Tor: From the First Map to the Rendezvous

1. Where does the first map come from?

A newly installed client does not yet know the current network. However, it already knows the cryptographic identities of the directory authorities expected and some initial points from which it can download documents.

The authorities combine their views into a consensus signed document. The client verifies the signatures and validity, then recovers the missing information on the relays.

The distinction we will need for the rest is already here: the server contacted provides a copy of the map; the signatures establish whether that copy is acceptable. The directory produces the candidates. It does not assign the user’s personal path.

The first article reconstructs this bootstrap and distinguishes authorities, fallback, cache, descriptor, flag, and consensus.

2. Why is the exit chosen first and reached last?

For a three-hop web circuit, the client selects the exit first, then the guard, and finally the middle. The destination imposes a constraint on the last relay: the exit must accept the connection request.

The construction proceeds in the opposite order. The client reaches the guard directly, then extends the circuit to the middle, and finally to the exit. Each extension traverses the already constructed circuit and establishes new cryptographic material with the relay added.

The second article separates these two sequences: choose exit → guard → middle; construct guard → middle → exit.

3. What is actually wrapped in layers?

Opening example.com creates an application stream. The stream uses a circuit. Its bytes are divided into relay messages transported inside cells. The cells traverse channels between adjacent participants.

Layered encryption applies to these units along an already constructed circuit. The third article starts with a single web loading and uses that action to distinguish channel, circuit, cell, stream, CircID, and StreamID.

4. Where do Tor, DNS, and HTTPS end?

To reach a normal site, the client sends the name and port to the stream. The exit resolves the name when necessary and opens the external TCP connection.

Tor protects the path until the exit. HTTPS, when present and authenticated correctly, protects the application content between the browser and the site. The two protections have different endpoints and tasks.

The third article follows this boundary. Then the series changes course: an onion service does not require a final connection from the exit to the public IP of the service.

5. How is a service found that does not publish its IP?

A v3 onion address cryptographically identifies the service, not the location where it is hosted. The service instead publishes a temporary descriptor that indicates some introduction points.

If the name must remain stable, why does Tor not always publish that descriptor under the same identifier? The fourth article answers by introducing blinded keys, periods, shared random values, and relay HSDir. At the end, the client knows where to knock, but it still does not know the service’s IP.

6. How do two endpoints meet that do not connect directly?

The client chooses a rendezvous point and leaves a random cookie there. It communicates that choice to the service through an introduction point. The service constructs a second circuit towards the same relay and presents the cookie.

The rendezvous point associates the two circuits, while the client and service complete a handshake that the relay does not finish. The fifth article follows each message, distinguishes introduction and data transport, and shows why the rendezvous is an encounter between two circuits, not a hidden exit.

7. What happens when the entry is blocked?

The public consensus allows a censor to enumerate ordinary relays. The sixth article follows a small escalation: public relay, IP block, bridge, traffic recognition, pluggable transport. These tools change the way to reach the first hop; after the entry, Tor continues to function as Tor.

8. What information remains visible?

The guard receives the client’s connection directly. The exit knows the destination. The middle sees the neighbors. HSDir, introduction points, and rendezvous points still observe different fragments.

This separation is the thesis of the series, but it is not enough to say that “no node knows everything.” Collusion, correlation, application identity, fingerprinting, and endpoint compromise change the adversary. The last article constructs the threat model property by property.

The security of Tor does not arise from the absence of total information. It arises from the cost and conditions necessary to connect information that the protocol delivers separately.

The onion was not wrong. It just started too late.

Technical References

This map synthesizes the seven deep dives. Each article links its claims to the relevant sections of the specific. The primary orientation sources are:

• Tor Specifications, Directory protocol — Outline , sections “Outline” and “Voting timeline”.
• Tor Specifications, Path selection and constraints , introduction and section “Choosing an exit”.
• Tor Specifications, Creating circuits , steps CREATE2 and EXTEND2.
• Tor Specifications, Protocol overview of onion service , sections “View from 10,000 feet” and “Distributing hidden service descriptors”.

Online specifications consulted on August 14, 2026.