How Tor protects hidden services

Standard Tor circuits: the three-hop model

When you open Tor Browser and visit a normal website (say, Wikipedia), Tor builds a three-hop circuit between your machine and the destination. The circuit passes through three relays, each operated by a different volunteer:

Guard node. The first relay in the circuit. Your ISP can see that you connected to this relay, but all it sees is encrypted traffic going in. The guard knows your real IP address. It does not know what you are requesting or where the traffic ends up.

Middle relay. The second hop. The middle relay knows the guard's address and the exit's address. It knows nothing else. It cannot read the traffic because it is still wrapped in a layer of encryption meant for the exit.

Exit node. The last relay in the circuit. The exit strips the final layer of encryption and sends your request to the destination server in cleartext (or in TLS, if the destination uses HTTPS). The exit can read unencrypted traffic, but it has no idea who sent it because all it sees is the middle relay's address.

The word "onion" comes from this layered encryption. When your Tor client builds a circuit, it wraps the original request in three layers of encryption, one for each relay. Each relay peels one layer, reads the next hop address, and forwards the remaining layers. Nobody in the chain sees both ends: the guard knows who you are but not where you are going, and the exit knows where you are going but not who you are.

This is fine for visiting clearnet websites through Tor. But hidden services have a different problem. The server itself also needs to stay anonymous. An exit node would expose the server's IP address, which defeats the point. So hidden services do not use exit nodes at all.

Hidden service circuits: no exit node

A Tor hidden service (any .onion address) is reachable without traffic ever leaving the Tor network. Instead of routing through an exit to a clearnet IP, the client and the service each build a separate circuit to a shared meeting point inside the network. Tor calls this meeting point a rendezvous point.

The rendezvous point is just another Tor relay. It does not know what the client is requesting, what the service is returning, or who either party is. All it does is forward encrypted bytes between two circuits that happen to have agreed on the same rendezvous cookie (a short random identifier).

Because both sides build independent three-hop circuits to the rendezvous point, the total path from client to service is six hops. The client's ISP sees traffic to the client's guard. The service's ISP sees traffic to the service's guard. Neither ISP sees the other end.

Why this matters for .onion marketplace infrastructure

A darknet marketplace like DarkMatter runs its web server behind a Tor hidden service. The server's IP address is never transmitted across any network hop in cleartext. Law enforcement cannot find the server by intercepting traffic at an exit node because there is no exit node. They would need to compromise enough relays in the path to perform a traffic correlation attack, which is computationally expensive and requires significant network-level presence.

This is why .onion services are considered more private than visiting a clearnet site through Tor. The clearnet model hides the client but exposes the server to the exit relay. The hidden service model hides both.

Introduction points and descriptors

Before a client can reach a hidden service, the service has to advertise where to find it. But "where" in this context does not mean an IP address. It means a set of Tor relays willing to act as introduction points.

Here is how it works in sequence:

The hidden service picks a few Tor relays and establishes persistent circuits to each of them. These are its introduction points. The service then publishes an encrypted descriptor to a distributed hash table (DHT) inside the Tor directory system. The descriptor contains the introduction points' addresses and the cryptographic material a client needs to start a connection.

The descriptor is encrypted with a key derived from the service's onion address. This means you need to already know the .onion address to decrypt the descriptor. You cannot browse the DHT and discover hidden services by accident. This is by design.

When a client wants to reach the service, it fetches the descriptor from the DHT, decrypts it, and picks one of the listed introduction points. The client then builds a circuit to a rendezvous point (a random Tor relay the client chose) and sends a message through the introduction point asking the service to meet at that rendezvous.

The service receives the request through its introduction-point circuit, builds a new circuit to the specified rendezvous point, and the two circuits are joined. From this point on, all communication flows through the rendezvous point.

The introduction point never carries actual traffic. Its only job is to forward the initial "please meet me at this rendezvous" message. After that, it is no longer involved.

Why hidden services go offline: DDoS on the Tor layer

Between 2023 and early 2025, the Tor network experienced sustained denial-of-service attacks that targeted hidden services specifically. Multiple darknet markets, including those in DarkMatter's tier, were intermittently unreachable for days at a time. The attacks were not aimed at the server's IP address (which the attacker did not know). They targeted the Tor infrastructure around the service.

Flooding introduction points

The simplest attack is to flood the introduction points with connection requests. Each request triggers a descriptor lookup, a circuit build, and a rendezvous negotiation. These are not cheap operations on the Tor network. A few thousand requests per second can exhaust the introduction points' capacity and make the service unreachable to real clients.

The service can rotate to new introduction points, but the attacker can follow by fetching the updated descriptor. It becomes a game of whack-a-mole that the attacker usually wins because flooding is cheaper than circuit building.

Directory-level attacks

A more sophisticated variant targets the distributed hash table where descriptors are stored. By flooding the DHT nodes responsible for a particular onion address, the attacker can prevent clients from fetching the descriptor in the first place. No descriptor means no introduction points, which means the service might as well not exist.

Guard discovery

If an attacker can identify the hidden service's guard node, they can attack that specific relay. Guard nodes are chosen for long-term stability (Tor assigns them for weeks or months to resist certain correlation attacks), which means taking out one guard can break the service's connectivity for a while. The Tor Project has made guard selection more resistant to discovery over successive protocol versions, but the attack surface is not fully closed.

Proof-of-work rate limiting (Tor 0.4.8 and later)

The DDoS waves of 2023 forced the Tor Project to ship a defense mechanism that had been discussed for years: client-side proof of work for hidden service connections.

Starting with Tor version 0.4.8 (released June 2023), hidden services can require connecting clients to solve a computational puzzle before the introduction point will forward their request. The puzzle uses the EquiX algorithm, which is designed to be hard to parallelize on GPUs but runs quickly on a normal CPU.

The difficulty adjusts automatically. Under normal load, the puzzle takes a few milliseconds and the user does not notice. Under attack, the service increases the difficulty. A legitimate user solving one puzzle at high difficulty might wait a few seconds. An attacker trying to generate thousands of connection requests per second has to burn proportionally more CPU, which makes the attack expensive enough to discourage or at least throttle.

The system is not perfect. Attackers with access to large botnets can still generate enough puzzle solutions to maintain pressure. And the difficulty ramp-up can cause slowdowns for legitimate users during an attack. But the Tor network's DDoS resilience improved measurably after 0.4.8 rolled out, based on the decreased frequency and duration of hidden-service outages reported across the network in 2024.

What mirroring means for hidden services

When a marketplace like DarkMatter publishes multiple onion addresses (a primary address and two mirrors), each address is a separate hidden service with its own Ed25519 keypair and its own set of introduction points. All of them connect back to the same web server, but from the Tor network's perspective they are independent services.

The point of mirroring is redundancy against DDoS. If an attacker targets the primary address's introduction points, the mirrors may remain reachable because they use different introduction points. The attacker would need to flood all three services simultaneously, which triples the cost.

Mirroring also creates a verification problem. A user who finds a mirror address needs to confirm it was published by the same operator, not by a phishing attacker. The standard solution is PGP: the operator signs all canonical addresses with the same PGP key, and users verify each mirror against the operator's published fingerprint.

The verified-access section on our homepage publishes the three signed addresses for the DarkMatter onion URL in this format. The status page monitors reachability across all three.