Tor Proof of Work Defense: Protecting .onion Services from DDoS in 2026

Hidden services face a specific DDoS attack vector: introduction point flooding. When a hidden service publishes introduction points (the mechanism clients use to initiate connections), an attacker floods the introduction points with invalid connection requests. Each request causes the introduction point relay to do work; a flood overwhelms the introduction points and prevents legitimate users from establishing connections. This attack is particularly disruptive because the hidden service's IP address is not exposed (so IP-based filtering is impossible), and the attack targets the Tor protocol layer (not the application layer). Historical DDoS attacks against dark web forums, markets, and activist sites have caused days to weeks of downtime. The PoW defense addresses this at the Tor protocol level.

Tor's PoW system uses the EQUIX algorithm (a memory-hard, CPU-time-scalable puzzle). When a hidden service enables PoW defense, clients must solve a puzzle before their connection request is forwarded to the hidden service. The puzzle: EQUIX requires solving a combinatorial problem that cannot be parallelized efficiently (GPU farms provide limited speedup). The difficulty is dynamic: when the hidden service is under low load, no puzzle is required. As load increases (attack traffic), the difficulty increases, requiring more CPU time per connection attempt. Attacker impact: to maintain a high rate of introduction requests, the attacker must invest significant CPU per request. The attacker's flood rate is CPU-limited, while legitimate users experience a brief delay (0.5-5 seconds on a modern CPU at low difficulty levels).

PoW defense is enabled per hidden service in torrc. Key directives: HiddenServicePoWDefensesEnabled 1 (enables PoW for this hidden service), HiddenServicePoWQueueRate (how many requests per second to process), HiddenServicePoWQueueBurst (burst capacity for request processing). Minimum configuration: HiddenServicePoWDefensesEnabled 1 (other settings default to reasonable values). Additional tuning: HiddenServicePoWQueueRate 250 (250 connection setups per second, default), HiddenServicePoWQueueBurst 2500 (burst up to 2500). These values balance legitimate user throughput against attack traffic filtering. Higher queue rates allow more simultaneous users but also allow more attack traffic. Tor version requirement: PoW defense requires Tor 0.4.8+. Verify your Tor version before enabling.

Monitoring PoW during an attack: Tor's logs at notice level show introduction circuit establishment rates and PoW rejection counts. nyx (the Tor relay monitor) shows circuit establishment statistics. During an active attack with PoW enabled: reject counts increase (attackers fail the PoW), success counts stabilize at the legitimate user rate, and system load increases (solving PoW puzzles for legitimate users). Signs PoW is working: attack traffic is reduced at the introduction point level, the hidden service remains reachable for legitimate users despite high incoming traffic, and system CPU on the hidden service server remains manageable. Adjusting difficulty: if attack traffic overwhelms even PoW-filtered traffic, increase HiddenServicePoWQueueRate to reduce the effective rate cap. If legitimate users experience excessive delays (>10 seconds), the difficulty may be too high - reduce HiddenServicePoWQueueRate to allow more requests.

Tor PoW vs OnionBalance: OnionBalance distributes traffic across multiple backends, each with its own introduction points. An attacker must flood all backends' introduction points simultaneously to succeed. OnionBalance + PoW is the strongest combination: PoW filters per-introduction-point, OnionBalance distributes the remaining load. Tor PoW vs application-layer rate limiting: PoW filters at the Tor protocol layer (before the connection reaches the application server). Application rate limiting filters at the HTTP layer (after the connection is established). Both are needed: PoW reduces attack traffic before it reaches the server; application rate limiting handles any attack traffic that passes PoW and reaches the application. Tor PoW vs Tor circuit limits: Tor's MaxCircuitDirtiness and MaxCircuits settings limit per-relay circuit counts. These protect the relay infrastructure but do not protect the hidden service's introduction points directly.