Rendezvous: How a Client and Onion Service Meet Without Knowing Each Other

First: The Four Essential Participants

The Tor client is the software that wants to reach the service. The onion service is the software that accepts the connection without directly publishing its IP address.

A circuit is a logical path through multiple Tor relays. In the basic model, we use three positions, or hops, on each side. A hop is a position in the path; it is not necessarily a relay distinct from every other position in the diagram.

The service already maintains circuits to several introduction points. An introduction point is a relay that can deliver an initial request to it. The client obtained their coordinates from the onion descriptor, the temporary document described in the previous article.

The rendezvous point, abbreviated RP, has a different job: it receives two circuits, associates them, and forwards cells between them. It is not an exit to the Internet.

The Client Prepares the Meeting Place First

The client chooses a suitable relay as the rendezvous point and builds a dedicated circuit to it. Construction proceeds from the first relay to the RP; the client does not open a direct connection to the central relay.

It then generates a rendezvous cookie, an ephemeral random 20-byte value, and sends it to the RP with ESTABLISH_RENDEZVOUS.

The RP associates that cookie with the waiting circuit and replies with RENDEZVOUS_ESTABLISHED.

The cookie is a tag used to match two circuits. It is not the session’s final cryptographic key and does not by itself prove the service’s identity.

The Client Opens a Second Circuit

At this point, the client already has a circuit to the RP. It builds another, separate circuit to one of the introduction points listed in the descriptor.

Over this second circuit it sends INTRODUCE1. The message carries, in a form protected for the service:

• the rendezvous cookie;
• the information needed to reach the RP;
• the client’s contribution to the subsequent cryptographic handshake.

A handshake is an exchange through which two participants verify cryptographic material and derive shared keys. Here, the client prepares its half before a complete logical link to the service exists.

The introduction point checks that the request corresponds to an active introduction circuit. It then forwards the same contents to the service as INTRODUCE2 and replies to the client with INTRODUCE_ACK.

The acknowledgement says only that the request was forwarded or that an error occurred. It does not mean that the service has already reached the RP.

The Introduction Point Does Not Open the Client’s Message

The fields needed to manage the introduction session are visible as defined by the protocol. The payload intended for the service, however, remains opaque to the introduction point.

The service receives INTRODUCE2 and verifies that the message is intact, addressed to the correct keys, and not a reuse of a previous request. This replay check prevents an old recorded and resent introduction from automatically being treated as new.

Only the service can decrypt the payload and obtain the cookie, RP coordinates, and handshake material. It can accept or reject the request. Receiving INTRODUCE2 does not require it to build a circuit.

The Service Reaches the Relay Chosen by the Client

If it accepts, the service builds its own circuit to the rendezvous point specified by the client. This half also crosses intermediate relays: the service does not connect directly to the RP.

When the circuit is ready, the service sends RENDEZVOUS1. The message contains the cookie and its part of the handshake.

The RP looks for a waiting client circuit with the same cookie. If it finds one, it associates the two circuits and forwards the service’s information to the client through RENDEZVOUS2.

The RP has matched two tags. It has not authenticated the service, nor has it obtained the end-to-end keys.

The Client Verifies That the Correct Service Is on the Other Side

The client verifies that RENDEZVOUS2 completes hs-ntor, the handshake used by onion services and begun with INTRODUCE1. It uses its ephemeral key and the service keys obtained from the authenticated descriptor. The link to the onion address runs through that descriptor and the subcredential, a periodic value derived from the service identity and blinded key: the identity key does not directly sign RENDEZVOUS2.

If the handshake is valid, the client and service derive shared keys and digests. These keys create an additional virtual hop between the two endpoints.

It is virtual because it does not correspond to a sixth server. It is an end-to-end cryptographic layer added over the two existing Tor circuits.

The per-hop protections of both circuits remain. The virtual hop does not replace them; it additionally protects the complete logical segment between client and service, including passage through the RP.

After the Join, the Relevant Path Changes

The circuit the client used for INTRODUCE1 does not carry rendezvous application data. After a positive INTRODUCE_ACK, the client should close it and not reuse it for other purposes.

The service can keep its introduction circuit to receive requests from other clients. But that circuit does not belong to the newly created stream.

Data instead travels along the client-to-RP circuit, crosses the rendezvous point, and continues over the RP-to-service circuit. The RP forwards relay cells without removing the virtual-hop protection.

There is no public exit on this path.

A Note on the Diagram

In the teaching model with three hops per side, the rendezvous point occupies the last position in both circuits. The diagram therefore shows six positions but five distinct relays, because the RP is shared. Neither side uses an exit.

The count only helps us read the diagram. The important property is different: client and service build separate paths to the same RP. The number is not universal. Vanguards-Lite, for example, adds a middle relay to the service-side rendezvous circuit; other overlays or layers can change the topology without changing this logic.

The Rendezvous Point Does Not Know the Content, but It Observes Traffic

The virtual hop prevents the RP from terminating the end-to-end protection between client and service. The relay does not directly receive their original IP addresses through the two circuits.

The RP still knows an important local fact: it has associated two circuits. It can observe when cells arrive, which direction they travel, and how much traffic passes.

Encrypting content does not eliminate timing and volume.

The rendezvous therefore solves a very specific problem. It lets two endpoints converge on a relay without opening a direct connection and without entrusting the communication keys to that relay. It does not make every traffic property invisible, and it does not protect an already compromised device.

We now have every component of a Tor path, both toward the Internet and toward an onion service. We can finally ask precisely what each participant knows and which combination of observations can break the separation.

Technical Sources

Introduction and meeting. Tor Specifications, The introduction protocol , opening, “Sending an INTRODUCE1 message,” and “Processing an INTRODUCE2 message”; The rendezvous protocol , “Establishing a rendezvous point,” “Joining to a rendezvous point,” and “Key expansion.”

Virtual hop and variants. Tor Specifications, Encrypting data between client and host , shared keys and virtual hop; Vanguards-Lite and Full Vanguards , design sections; Proposal 333 — Vanguards-Lite , implemented topology.

Online specifications consulted August 14, 2026. Legacy sections and the Single Onion Service case do not belong to the anonymous version 3 model followed in this article.