Introducing Proof-of-Work Defense for Onion Services

by pavel | August 23, 2023

Today, we are officially introducing a proof-of-work (PoW) defense for onion services designed to prioritize verified network traffic as a deterrent against denial of service (DoS) attacks with the release of Tor 0.4.8.

Tor's PoW defense is a dynamic and reactive mechanism, remaining dormant under normal use conditions to ensure a seamless user experience, but when an onion service is under stress, the mechanism will prompt incoming client connections to perform a number of successively more complex operations. The onion service will then prioritize these connections based on the effort level demonstrated by the client. We believe that the introduction of a proof-of-work mechanism will disincentivize attackers by making large-scale attacks costly and impractical while giving priority to legitimate traffic. Onion Services are encouraged to update to version 0.4.8.

Why the need?

The inherent design of onion services, which prioritizes user privacy by obfuscating IP addresses, has made it vulnerable to DoS attacks and traditional IP-based rate limits have been imperfect protections in these scenarios. In need of alternative solutions, we devised a proof-of-work mechanism involving a client puzzle to thwart DoS attacks without compromising user privacy. 

How does it work?

Proof of work acts as a ticket system that is turned off by default, but adapts to network stress by creating a priority queue. Before accessing an onion service, a small puzzle must be solved, proving that some "work" has been done by the client. The harder the puzzle, the more work is being performed, proving a user is genuine and not a bot trying to flood the service. Ultimately the proof-of-work mechanism blocks attackers while giving real users a chance to reach their destination.

What does this mean for attackers and users?

If attackers attempt to flood an onion service with requests, the PoW defense will kick into action and increase the computational effort required to access a .onion site. This ticketing system aims to disadvantage attackers who make a huge number of connection attempts to an onion service. Sustaining these kinds of attacks will require a lot of computational effort on their part with diminishing returns, as the effort increases.

For everyday users, however, who tend to submit only a few requests at a time, the added computational effort of solving the puzzle is manageable for most devices, with initial times per solve ranging from 5 milliseconds for faster computers and up to 30 milliseconds for slower hardware. If the attack traffic increases, the effort of the work will increase, up to roughly 1 minute of work. While this process is invisible to the users and makes waiting on a proof-of-work solution comparable to waiting on a slow network connection, it has the distinct advantage of providing them with a chance to access the Tor network even when it is under stress by proving their humanity. 

Where do we go from here?

Over the past year, we have put a lot of work into mitigating attacks on our network and enhancing our defense for onion services. The introduction of Tor's PoW defense not only positions onion services among the few communication protocols with built-in DoS protections but also, when adopted by major sites, promises to reduce the negative impact of targeted attacks on network speeds. The dynamic nature of this system helps balance the load during sudden surges in traffic ensuring more consistent and reliable access to onion services.

This is a companion discussion topic for the original entry at

How will the puzzle look like?
Will it look like the regular Captcha puzzle?

It’s just additional load on CPU, user will notice only delay.

1 Like

Hmmm… another Captcha :neutral_face:

Think of it like the website takes a bit longer to load and not as a captcha you’ll have to solve

I understand the need of course and support the effort.

If I read the POW and Client Puzzle Protocol correctly, it will require the humanoid-carbon-unit to interact with a server somehow.
So: “A rose by any other name would smell as sweet” :neutral_face:

Yes, there are 1000s of children sitting here with me who press buttons for my Monero miner. :rofl: :joy:

More Info about POW in Tor:
Proof of work comes to Tor

“Client” in this context means computer program, which connects to “server” (also computer program).

I just re-read the first entry in this post again especially the “What does this mean for attackers and users?” section.

The magic term is: “the PoW defense will kick into action and increase the computational effort required to access a .onion site”

Now it makes more sense to this humanoid-carbon-unit.

Thus not a Captcha then.


How long it takes between new Tor release and possibility to update it from Index of / ?

If you want to use the POW features and don’t want to compile it yourself use: tor-nighly builds
tor-nightly-main-bullseye AFAIK POW is in since
Because I suffer more from exit DDoS I am particularly interested in reapply exit policy on reload :slight_smile:
Tanks @trinity-1686a for fast implementation :heart:

Yeah I was thinking about nightly builds but also I would like to avoid using alpha version of product in production.

Some useful links:

1 Like

I usually don’t either. Nightly builds + unattended updates of Tor (nightly) only run on my test server.
Because of ReevaluateExitPolicy 1, now also runs on the big exit.
In general, @toralf always runs the latest code. Self compiled on Gentoo. Family zwiebeltoralf
and Applied-privacy always has the nightly running.

tor_0.4.8.4-2_amd64.deb is already in the pool. and could already be fetched with curl or wget.

Yesterday it was in TorProject deb repository. So looks like it takes about 10 days from official release.

Yesterday I upgraded from stable to stable POW was already in

Changes in version - 2023-08-23
 Finally, this is the very first stable release of the 0.4.8.x series making
 Proof-of-Work (prop#327) and Conflux (prop#329) available to the entire

tor-announce [RELEASE] Tor stable mail reached me 30.08.23 19:42 and has since been in the pool..
The pointer to the stable archive was set approximately 4 days later.