How Tor Onion Services Work: .onion Addresses and the Rendezvous Protocol

Tor onion services allow servers to be reachable without revealing their IP address — not to their clients, not to their ISP, and not to anyone observing the network. Previously called "hidden services," they provide a way to publish websites and services that can only be accessed through the Tor network. The server's physical location and IP address remain hidden, and the connection between client and server is end-to-end encrypted without relying on any certificate authority.

Unlike normal websites, which are identified by domain names resolved through DNS, onion services use .onion addresses — cryptographic identifiers derived directly from the service's public key. The address itself proves authenticity. There is no DNS lookup, no certificate authority, and no exit node. Traffic never leaves the Tor network.

What is a .onion Address?

A .onion address is not a traditional domain name. It is a self-authenticating identifier derived from the service's public key. When you see an address like facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion, you are looking at the service's cryptographic identity encoded as a string.

Modern Tor uses v3 onion addresses, which are exactly 56 characters long. The address is constructed from three components:

1. Public key (32 bytes) — The service generates an ed25519 keypair. The 32-byte public key forms the bulk of the address.
2. Checksum (2 bytes) — Computed as the first two bytes of SHA3-256(".onion checksum" || public_key || version). This detects typos in the address before any network request is made.
3. Version byte (1 byte) — Currently 0x03 for v3 addresses.

These 35 bytes (32 + 2 + 1) are concatenated and encoded using base32, producing exactly 56 characters. The complete derivation looks like this:

onion_address = base32(public_key || checksum || version)
checksum = SHA3-256(".onion checksum" || public_key || version)[:2]
version = 0x03

This design has a critical security property: the address IS the public key. If you know the .onion address, you can extract the public key and verify that the service you are connecting to holds the corresponding private key. No certificate authority is needed. No DNS registrar can be compromised to redirect the address. The address is cryptographically bound to the key, and the key is cryptographically bound to the service operator. This is the meaning of "self-authenticating."

The Rendezvous Protocol: How Connections Are Made

The most intricate part of onion services is how a client and server find each other and establish a connection without either side revealing their IP address to the other — or to any single relay in the network. This is accomplished through a multi-step rendezvous protocol involving introduction points, a distributed hash table, and a rendezvous point.

Here is each step in detail:

Step 1: The Service Sets Up Introduction Points

When an onion service starts, it generates an ed25519 keypair (if it does not already have one) and derives its .onion address from the public key. It then selects a small number of Tor relays (typically three) to serve as introduction points. The service builds a standard three-hop Tor circuit to each introduction point and sends an ESTABLISH_INTRO cell, asking the relay to accept introductions on its behalf.

The introduction point does not know the service's IP address. It only knows the circuit ID — it has no way to trace the circuit back through the three relays to the service's real location.

Step 2: The Service Publishes Its Descriptor

The service creates a descriptor — a signed document containing the list of introduction points and the cryptographic material needed to contact the service. This descriptor is signed with the service's private key and uploaded to HSDir (Hidden Service Directory) nodes in Tor's distributed hash table.

Which HSDir nodes store a given descriptor is determined by a formula involving the service's public key and the current time period. This means the descriptor's location in the DHT changes over time, preventing long-term surveillance of a single HSDir node to track who is looking up a particular service.

In v3 onion services, the descriptor is encrypted. Only someone who already knows the .onion address (and thus the public key) can decrypt it. This prevents HSDir nodes from learning the introduction points of services they store descriptors for — a significant improvement over v2.

Step 3: The Client Fetches the Descriptor

When a client wants to visit an onion service, it starts with the .onion address. From this address, it extracts the public key, computes the descriptor ID using the same formula the service used (based on the public key and current time period), and queries the appropriate HSDir nodes. It downloads the descriptor and decrypts it using the public key, revealing the introduction points.

Step 4: The Client Picks a Rendezvous Point

The client selects a random Tor relay to serve as the rendezvous point (RP). It builds a three-hop circuit to this relay and sends a CREATE_RENDEZVOUS cell containing a random rendezvous cookie — a one-time token that will be used to match up the two halves of the connection.

Step 5: The Client Introduces Itself

The client builds a separate three-hop circuit to one of the service's introduction points and sends an INTRODUCE1 cell. This cell contains, encrypted with the service's public key: the address of the rendezvous point, the rendezvous cookie, and a one-time key for establishing an end-to-end encrypted channel. The introduction point cannot read this data — it is encrypted for the service.

Step 6: The Introduction Point Forwards

The introduction point strips the outer layer and forwards the encrypted payload to the service through the pre-established circuit. The introduction point learns nothing about the client's identity (the client reached it through a three-hop circuit) and cannot read the encrypted content.

Step 7: The Service Connects to the Rendezvous Point

The service decrypts the introduction data, learns the rendezvous point's address and cookie, and builds a new three-hop circuit to the rendezvous point. It sends a RENDEZVOUS1 cell containing the cookie. The rendezvous point matches this cookie to the client's earlier CREATE_RENDEZVOUS cell.

Step 8: The Rendezvous Point Joins the Circuits

The rendezvous point now splices together the client's circuit and the service's circuit. From this moment, data flows between the client and the service through the rendezvous point. The client has a three-hop circuit to the RP, and the service has a three-hop circuit to the RP — six hops total. Neither the client nor the service knows the other's IP address. The rendezvous point knows neither — it only sees two circuit IDs to connect.

The end-to-end encryption between client and service is established using the key material exchanged during the introduction step. The rendezvous point, like all intermediate relays, sees only encrypted data passing through.

The Hidden Service Directory (HSDir) DHT

The HSDir is a distributed hash table (DHT) spread across Tor relays that have opted in to the HSDir role. It is how clients find the descriptors they need to contact onion services.

Each Tor relay that has the HSDir flag is positioned in the DHT ring based on its identity fingerprint. When a service uploads a descriptor, it computes the descriptor ID — a hash derived from the service's blinded public key and the current time period. The descriptor is uploaded to the HSDir nodes whose fingerprints are closest to this descriptor ID in the hash space, plus several replicas for redundancy.

The blinded key is a crucial v3 innovation. Rather than hashing the raw public key (as v2 did), the service derives a blinded key that changes each time period. This means the descriptor ID is different every period (roughly 24 hours), so even an adversary watching HSDir nodes cannot correlate lookups across time periods without already knowing the .onion address.

When a client wants to look up a service, it performs the same blinded key derivation and descriptor ID computation. Since both client and service use the same deterministic formula, the client arrives at the same HSDir nodes and retrieves the descriptor. The descriptor itself is encrypted with a key derived from the service's public key and the current time period — an HSDir node storing the descriptor cannot read its contents.

v2 vs. v3 Onion Addresses

Tor originally used v2 onion addresses, which were only 16 characters long and based on RSA-1024 keys. The v2 system was deprecated in October 2021 and is no longer supported. Understanding why the switch happened illuminates important cryptographic and privacy principles.

• Key strength — v2 addresses used RSA-1024, which is now considered cryptographically broken. RSA-1024 can be factored by well-resourced adversaries, meaning they could impersonate an onion service. v3 uses ed25519, which provides 128 bits of security with 32-byte keys — far stronger than RSA-1024 and more efficient.
• Address length — v2 addresses were 16 characters (80 bits of the RSA key hash, base32-encoded). This meant the address was a hash of the key, not the key itself — providing less than full key-strength authentication. v3 addresses are 56 characters and encode the entire public key, the checksum, and the version byte.
• Descriptor privacy — In v2, descriptors were stored unencrypted on HSDir nodes. Any HSDir node could see the introduction points of services whose descriptors it stored. In v3, descriptors are encrypted — only clients who already know the .onion address can decrypt them. This prevents enumeration attacks where an adversary running HSDir nodes catalogs onion services.
• Linkability — v2 descriptor IDs were derived from the public key in a way that did not change over time. An adversary monitoring HSDir lookups could link requests for the same service across different time periods. v3 uses blinded keys that change each time period, preventing this correlation.
• Improved cryptographic protocols — v3 uses a more modern and well-analyzed protocol for the introduction and rendezvous handshake, with better forward secrecy properties.

The upgrade from v2 to v3 was not optional. Tor clients stopped resolving v2 addresses entirely. Any service that had not migrated simply became unreachable.

Vanity .onion Addresses

Since .onion addresses are derived from cryptographic keys, they normally look like random strings. But some operators want a recognizable prefix — Facebook's facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion starts with "facebook" for a reason. This is achieved through brute-force key generation.

The process is straightforward but computationally expensive: generate an ed25519 keypair, derive the .onion address, check if it starts with the desired prefix, and if not, discard it and try again. Since each character in the base32 prefix represents 5 bits of entropy, finding a match requires on average:

• 1 character prefix — 2⁵ = 32 attempts (instant)
• 4 character prefix — 2²⁰ = ~1 million attempts (seconds)
• 8 character prefix — 2⁴⁰ = ~1 trillion attempts (days to weeks on powerful hardware)
• 12 character prefix — 2⁶⁰ = ~1 quintillion attempts (computationally infeasible for most)

The cost grows exponentially with each additional character. Tools like mkp224o perform this search efficiently by generating ed25519 keys at high speed and checking the resulting address against a target pattern. Facebook reportedly used significant computational resources to find their 8-character vanity prefix.

Vanity addresses serve a practical purpose beyond aesthetics: they make addresses easier for humans to verify. If you know Facebook's onion service starts with "facebook," you have a quick visual check (though you should still verify the full address through a trusted channel).

Security Properties

Onion services provide several security properties that are difficult or impossible to achieve with the conventional web:

Mutual anonymity. The client does not know the server's IP address or physical location. The server does not know the client's IP address. No single relay in the network knows both. The introduction point knows neither. The rendezvous point knows neither. Each sees only the previous and next hop in the circuit.

End-to-end encryption without certificate authorities. The TLS/HTTPS model relies on certificate authorities (CAs) — trusted third parties that vouch for a server's identity. CAs can be compromised, coerced, or make mistakes. Onion services bypass this entirely. The .onion address is the public key, so the client can verify the server's identity directly through the cryptographic handshake. No CA needed. No risk of a rogue CA issuing a fake certificate.

No exit node. In normal Tor usage (accessing regular websites through Tor), traffic eventually leaves the Tor network through an exit node, which can see the destination and, if the connection is not encrypted with HTTPS, the content. With onion services, traffic never exits the Tor network. The entire path from client to service is within Tor, encrypted at every hop.

Self-authenticating addresses. Because the address is derived from the public key, a man-in-the-middle attack is cryptographically impossible without the attacker possessing the service's private key. If someone gives you the correct .onion address through any channel, you can be certain you are connecting to the right service.

NAT and firewall traversal. Onion services do not require any inbound ports to be open. The service initiates all circuits itself (outbound connections through Tor). This means anyone can run an onion service behind a NAT, a firewall, or even a cellular connection — no port forwarding or public IP address needed.

.onion and the Domain Name System

The .onion top-level domain has a unique status. In 2015, the IETF formally recognized .onion as a special-use domain name in RFC 7686. This has several important implications:

• .onion is NOT in the ICANN root zone. No DNS resolver can resolve a .onion address. It is not a TLD in the traditional sense — it cannot be looked up through the DNS hierarchy. ICANN has agreed not to delegate .onion to anyone.
• DNS resolvers must not attempt to resolve .onion. RFC 7686 explicitly states that DNS resolvers should respond with NXDOMAIN for .onion queries and must not forward them upstream. This prevents .onion queries from leaking to DNS servers, which would reveal that a user is trying to access an onion service.
• Browsers detect .onion and route through Tor. The Tor Browser intercepts .onion URLs and handles them through the Tor SOCKS proxy rather than performing a DNS lookup. Some other browsers, like Brave, have also added native .onion handling.
• Certificate authorities can issue certificates for .onion. Since RFC 7686, CAs like DigiCert have issued EV (Extended Validation) certificates for .onion domains. Facebook's onion service, for example, has a valid HTTPS certificate. This is technically redundant — the .onion address already authenticates the service — but it provides a familiar visual indicator (the padlock icon) for users and enables HTTP features that require a valid certificate.

The relationship between .onion and DNS is one of deliberate separation. The entire point of onion addressing is to bypass the DNS system and the trust hierarchy it depends on, replacing it with direct cryptographic authentication.

Single Onion Services

Standard onion services use six hops in total — three from the client to the rendezvous point, and three from the service to the rendezvous point. This provides anonymity for both sides but adds significant latency. Each hop adds a round-trip time through the Tor network, making onion services noticeably slower than clearnet websites.

Single onion services are a variant for operators who do not need to hide their location. The service connects to its introduction points and rendezvous points directly (one hop) rather than through a three-hop circuit. The total path is reduced to three or four hops instead of six.

This makes sense for services like Facebook or ProtonMail that operate onion services not to hide their identity (everyone knows where Facebook's servers are) but to provide their users with the benefits of Tor: censorship circumvention, no exit node, and self-authenticating addresses. Single onion services offer better performance (lower latency, higher throughput) while preserving client anonymity.

To enable a single onion service, the operator sets the HiddenServiceSingleHopMode and HiddenServiceNonAnonymousMode options in their Tor configuration. This is a deliberate opt-in — the operator is explicitly giving up server-side anonymity.

OnionBalance: Scaling Onion Services

A standard onion service runs on a single machine. For high-traffic services, this is a bottleneck — all traffic must pass through a single Tor process and a single rendezvous circuit. OnionBalance solves this by distributing the load across multiple backend instances.

OnionBalance works by running multiple onion service instances, each with its own Tor process, and a management process that coordinates them. The management process collects the introduction points from all backend instances and publishes a unified descriptor containing introduction points from across the fleet. When a client connects, its INTRODUCE cell is routed to one of the backend instances, distributing the load.

From the client's perspective, there is a single .onion address. Behind the scenes, multiple servers handle the traffic. This is conceptually similar to DNS-based load balancing or anycast on the regular internet, but adapted for the onion service architecture. Large deployments like Facebook's onion service use OnionBalance (or similar internal tooling) to handle the volume of Tor users connecting to their platform.

Real-World Onion Services

Onion services are not just a theoretical construct. Several major organizations run them:

• Facebook — facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion. Launched in 2014, it was the first major website to offer an official onion service. Facebook uses it to provide access in countries where the site is censored.
• DuckDuckGo — duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion. The privacy-focused search engine has operated an onion service for years.
• ProtonMail — protonmailrmez3lotccipshtkleegetolb73fuirgj7r4o4vfu7ozyd.onion. Encrypted email accessible through Tor for users in restrictive environments.
• The New York Times — nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lnez7yd.onion. One of the first major news organizations to launch an onion service, helping readers in censored regions access journalism.
• SecureDrop — Used by dozens of news organizations (The Guardian, The Washington Post, The Intercept) to provide an anonymous whistleblowing platform. Sources can submit documents without revealing their identity, even to the news organization itself.
• Debian — The Debian project offers its entire package repository over an onion service, allowing users to update their systems without revealing which packages they are installing.

These examples demonstrate that onion services are not exclusively for anonymity — they serve as a censorship circumvention tool, a way to offer services that are resistant to network-level blocking, and a mechanism for providing strong authentication without the CA infrastructure.

Performance and Latency

The security of onion services comes at a cost. A standard onion service connection traverses six relays — three on the client side and three on the service side, with the rendezvous point in the middle. Each relay adds latency (typically 20-100ms per hop depending on relay location and load) and reduces throughput. The rendezvous protocol itself requires multiple round trips before data can flow.

A rough breakdown of the connection setup time:

• Tor circuit construction — Building a three-hop circuit requires three successive cryptographic handshakes, each requiring a round trip. Building two circuits (one for the rendezvous point, one for the introduction point) compounds this.
• Descriptor fetch — The client must query HSDir nodes to download the service descriptor, adding another round trip through Tor.
• Introduction handshake — The INTRODUCE and RENDEZVOUS exchange requires messages to travel through multiple circuits.
• Total — Initial connection to an onion service typically takes 2-10 seconds, compared to milliseconds for a regular website. Subsequent requests on the same circuit are faster but still slower than clearnet connections due to the six-hop path.

This is why single onion services exist — for operators who value the protocol's authentication and censorship-resistance properties but cannot afford the full latency penalty of a six-hop path.

Threat Model and Limitations

Onion services are not invulnerable. Understanding the threat model is important:

• Global passive adversary — An adversary who can observe all internet traffic simultaneously can potentially correlate the timing of traffic entering the Tor network from the client with traffic exiting toward the service. This is a theoretical weakness of all low-latency anonymity networks, not just Tor. In practice, such an adversary would need to monitor a significant fraction of all internet links — which is within the capability of nation-state intelligence agencies.
• Guard node attacks — If an adversary operates a Tor relay and a client or service selects it as their guard node (the first hop), the adversary can see their real IP address. Tor mitigates this by having clients use the same guard node for an extended period (months), reducing the probability of rotating onto a malicious guard.
• Application-layer leaks — Tor protects the network layer, but an application running over Tor can leak identity through browser fingerprinting, JavaScript side-channels, or protocol metadata. The Tor Browser is specifically hardened against these leaks, but other applications may not be.
• Sybil attacks on HSDir — An adversary could run many HSDir nodes and attempt to position them to store descriptors for targeted services, learning who is looking up those services. v3's encrypted descriptors mitigate this — even if the adversary stores the descriptor, they cannot read it without knowing the .onion address.

The key takeaway is that onion services provide strong anonymity against local adversaries (your ISP, your employer, the server's hosting provider) and moderate protection against well-resourced global adversaries. They are not a magic shield, but they are the strongest widely-deployed anonymity tool available.

Onion Services and the Network Layer

From a BGP and IP routing perspective, onion service traffic is indistinguishable from regular Tor traffic. Tor relays are normal servers with public IP addresses, announced through standard BGP routes, reachable through ordinary internet routing. The anonymity comes from the application layer — the layered encryption and multi-hop circuits — not from any special treatment at the network layer.

This means the prefixes hosting Tor relays are visible in the global routing table. You can look up the autonomous systems that host significant numbers of Tor relays. Many relays run in data centers operated by hosting providers, university networks, and nonprofit organizations. The diversity of networks hosting relays is important for Tor's security — if all relays were in a single AS, that AS's operator could surveil all Tor traffic.

See It in Action

Tor relays are regular servers with public IP addresses routed through BGP. You can explore the networks that host Tor infrastructure using the looking glass:

• AS24940 — Hetzner Online: hosts a significant number of Tor relays in Germany
• AS16276 — OVH: major European hosting provider popular with Tor relay operators
• AS47886 — Equinix: data center provider hosting Tor relays at internet exchange points
• AS13335 — Cloudflare: operates an onion service for its CDN infrastructure

Try looking up any IP address to see the AS path from the looking glass to its network. Tor relay operators choose their hosting providers based on network diversity, bandwidth, and peering — the same BGP routing fundamentals that govern all internet traffic.