How onion services work: introduction points, rendezvous relays and the six-circuit handshake
When you open a .onion address, no exit relay ever ferries your traffic to a public server. Instead, two strangers each build their own anonymous path into the Tor network and agree to meet at a randomly chosen relay in the middle.
Neither side learns the other's IP address, yet both end up with an encrypted connection they can trust. The trick behind that apparent contradiction is a carefully choreographed handshake involving descriptors, introduction points and a single rendezvous relay.A name that is also a key
Start with the address itself. A modern v3 onion address is nothing more than the service's Ed25519 public key, encoded in base32 with a checksum and version byte, which produces exactly 56 characters ending in ".onion". There is no DNS entry and no registrar. Because the address is derived directly from the key pair, it is self-authenticating. If you have typed the address correctly, you are talking to whoever holds the corresponding private key, and nobody else can impersonate the site. That property anchors everything that follows, as the rendezvous specification notes in its section on naming hidden services (rend-spec-v3).Publishing the descriptor
To become reachable, an onion service first picks a handful of Tor relays and builds a separate three-hop circuit to each. These are its introduction points: standing relays that will hold messages on the service's behalf, without ever learning where the service actually runs. The service then writes a signed document called a hidden service descriptor. It lists the chosen introduction points, their cryptographic keys and instructions for contacting the service, and it is uploaded anonymously to a distributed set of directory relays known as HSDirs. Descriptors expire after about three hours, so the service keeps republishing them while keeping its introduction circuits alive.The client sets the table
Now imagine you request that onion address. Your Tor client first fetches a current descriptor from the appropriate HSDir, verifying the signature against the public key embedded in the address itself. A valid descriptor means the address is genuine and the listed introduction points are live. Next comes a step most people never hear about: your client picks a random relay and asks it to act as a rendezvous point, handing over a fresh 20-byte cookie. From that moment, this relay is under orders to join any circuit that shows up quoting the same cookie. Crucially, the rendezvous point has no idea who chose it or who will eventually arrive.Six circuits, one meeting
Only then does the actual introduction happen. Your client builds another anonymous circuit to one of the introduction points and sends an INTRODUCE1 message, encrypted so only the service can read it. Inside is the rendezvous point's address, the cookie, and the first half of a cryptographic handshake. The introduction point forwards the sealed note along its standing circuit. The service decides whether to accept, then builds its own three-hop circuit out to your rendezvous point and presents the matching cookie. The relay splices the two circuits together, completes the key exchange, and traffic begins to flow.If you count the hops, the picture becomes clear: three relays on the client side plus three on the service side, joined at a shared midpoint. That is why people describe onion connections as running over a six-circuit path.Every participant sees only a fragment of the whole. As the Tor Project documents the protocol, the rendezvous relay knows neither party, the introduction points know neither party, and the two ends never touch the public internet at all.