Most people meet Tor as a way to browse anonymously: you run the Tor Browser, your traffic bounces through three volunteer relays, and an exit node fetches ordinary websites on your behalf so the destination sees the exit's IP instead of yours. We compare that mode against VPNs in Tor vs VPN. Onion services are the other half of Tor, and they work on a fundamentally different principle: location hiding for the server, not just the client.
When you visit a .onion address, your traffic never leaves the Tor network. There is no exit node, because there is no exit — both you and the service stay inside the encrypted overlay the entire time. That single fact eliminates a whole category of risk (malicious or surveilled exit nodes) and is why onion connections are end-to-end encrypted by the protocol itself.
The address is the key
A modern (v3) onion address is a 56-character string ending in .onion — and it is not arbitrary. It's a Base32 encoding of the service's Ed25519 public key, plus a checksum and version byte. That design has a powerful consequence: when you connect to an onion address, you can cryptographically verify you're talking to the holder of the matching private key, with no certificate authority in the loop at all.
On the regular web, a CA vouches that a public key belongs to a domain name (the problem the ACME protocol automates). An onion address skips that entirely: the name is the key. There's nothing for an attacker to forge and no third party to compromise — the trust is self-authenticating.
The trade-off is usability: those addresses are unmemorable strings of random-looking characters, which makes them vulnerable to a kind of typo-based impersonation where attackers publish a similar-looking address. Users must verify the full address from a trusted source, not eyeball it.
The rendezvous protocol, step by step
The genuinely clever part is how two parties who refuse to reveal their locations manage to find each other. Tor solves it with introduction points and a rendezvous point — a choreography of circuits designed so that no single relay learns both ends.
- The service picks introduction points. It builds anonymous Tor circuits to a few relays and asks each to act as an "introduction point" on its behalf — a public mailbox that forwards connection requests without knowing where the service actually is.
- It publishes a descriptor. The service signs a document listing its introduction points and its public key, then uploads it to a distributed hash table of relays (the "hashring"). For v3 onions, this descriptor is encrypted such that you need to already know the onion address to decrypt and use it — so the directory relays can't enumerate what services exist.
- The client fetches the descriptor. Knowing the onion address, your client derives where in the hashring the descriptor lives, downloads it, and decrypts it. Now it knows the introduction points.
- The client picks a rendezvous point. Your client chooses a random relay, builds a circuit to it, and tells it a one-time secret cookie — this relay will be the meeting place.
- The client sends an introduction. Through an introduction point, your client passes the service an encrypted message naming the rendezvous point and the cookie, along with the first half of a Diffie-Hellman handshake.
- The service meets you at the rendezvous. The service builds its own fresh circuit to the rendezvous point, presents the cookie, and completes the handshake. The rendezvous point now blindly relays cells between the two circuits.
The result: traffic flows over a circuit that is typically six hops long (three chosen by each side), and the rendezvous point — the one relay that touches both halves — knows neither your IP nor the service's. Every party in the chain sees only its immediate neighbors. We cover the underlying layered-encryption idea in mix networks; onion routing is a close cousin built for low latency.
Onion services vs. the regular web
| Property | Regular HTTPS site | Onion service |
|---|---|---|
| Server IP visible | Yes — published in DNS | No — never revealed |
| Naming | DNS (seizable) | Self-authenticating public key |
| Certificate authority | Required | Not needed |
| Exit node exposure | Traffic exits Tor | Stays inside Tor |
| Metadata to network observer | Domain often visible | Opaque |
Not just for hidden marketplaces
Onion services have a reputation shaped by sensational coverage of illicit markets, but the technology is general-purpose privacy infrastructure with serious mainstream adopters. The BBC, the New York Times, and ProPublica run onion mirrors so readers in censored regions can reach them. SecureDrop, used by dozens of newsrooms to receive material from sources, is built entirely on onion services. Major platforms have run them to resist traffic analysis and censorship.
Hiding the server's location isn't only about the operator evading identification. It's also about denying network adversaries the metadata of who is talking to which service — the kind of pattern that, on the open web, reveals associations even when content is encrypted.
The limits worth knowing
Onion services are not magic. Anonymity comes from the protocol, but it can be undone above it. A service that runs misconfigured software can leak its real IP through error messages or a server banner. A global adversary watching traffic volumes at many points can attempt traffic-analysis correlation. And onion sites are still websites — a vulnerable web application is just as exploitable whether it's reached over .onion or .com. Tor protects the network layer; it cannot fix application bugs.
Still, the core idea is one of the most elegant in privacy engineering: a name that is its own proof of identity, and a meeting protocol where neither party has to trust — or even locate — the other. That same instinct, pushing identity and trust down into cryptography rather than relying on a coercible middleman, is the one we build on at Haven. The mechanisms differ, but the goal is shared: connections whose security doesn't depend on a third party staying honest.