↓Skip to main content

Widespread Attacks Push Tor to Proof-of-Work

The Tor network is weathering the largest denial of service attack it has ever seen. Someone is sending trillions of packets across the network engineered to slow it down, likely in an attempt to identify or deny access to multiple Tor hidden services. Tor is one of the last places left on the internet which allows for truly anonymous communication when used properly. It hosts many sites which value freedom of speech within the bounds of an admin’s moderation rules, including the popular Reddit-like discussion forum Dread.

The admins of several prominent Tor hidden services confirmed privately to Darkdot that the scale of these recent DDoS attacks is unlike anything they have ever seen, and has driven them to run hundreds of Tor processes in an attempt to distribute the traffic across multiple servers using the popular tools Onionbalance and Endgame. This architecture is contrary to the Tor Project’s recommendations, and is a very real threat to user privacy depending on how prudent each admin was when configuring their Tor hidden services.

One of the biggest issues facing an anonymous network like Tor is how to handle malicious actors without introducing permission or identity into the network. These malicious actors usually seek to attack the network one of two ways: either via a “Sybil” attack, where the malicious actor spins up many Tor relays in order to attempt to de-anonymize or disrupt network traffic, or through a “Denial-of-Service” (DoS) attack that seeks to disrupt or completely shut down Onion services on the network.

While the Tor network has worked tirelessly to manage and prevent both attacks, DoS attacks have been a persistent issue, most recently causing outages and Onion service downtime since June 9th, an attack that is still ongoing as of this article being published.

Combining Tor’s existing tools for handling DoS attacks with a Proof-of-Work (PoW) algorithm like those leveraged by cryptocurrencies such as Bitcoin and Monero opens a unique avenue for mitigating DoS attacks without compromising privacy or severely hampering user experience.

What in the world is “Proof-of-Work”? #

While proof-of-work has become more well-known thanks to cryptocurrencies like Bitcoin that leverage it for security, it was actually invented as an anti-spam measure by Adam Back in 1997 for what would become “HashCash”. HashCash started as a method for leveraging PoW to limit or prevent spam emails by making each email require provably difficult work to be done before it would be forwarded by an email server or re-mailer.

Put very simply, proof-of-work as a DoS prevention mechanism allows a client (the user in the case of Tor) to perform a provably hard piece of work and submit it in such a way that the server can validate that they didn’t cheat. This process uses cryptography to ensure that the client actually performs the work they say they did, while making it immensely more difficult to generate the PoW (what the client, i.e. both good and malicious users have to do) than for the server (i.e. the Onion service) to validate the work.

This asymmetry in work required enables PoW to be a strong mechanism for DoS prevention, as a malicious actor has to perform drastically more work than the service they are trying to attack, limiting their ability to deny service and amplifying the costs and complexity of a DoS attack.

How can PoW be used by Tor mitigate these DoS attacks? #

Recently, a proposal that began in April 2020 to introduce Proof-of-Work to mitigate DoS attacks and benefit legitimate users has moved from theory to engineering and is seeing steady progress with many contributors on Gitlab. This proposal combines the original ideas of George Kadianakis from April 2020 and a novel PoW scheme designed by tevador (a lead architect and developer of Monero’s PoW algorithm, RandomX) called Equi-X in order to drastically limit the amount of resources that can be consumed by an attacker of an Onion service.

This proposal now leverages Equi-X when an Onion service is undergoing a DoS attack to force users to perform provably hard work in order to access the given resource, preventing any user from creating a rendezvous circuit (one of the most costly procedures in the network) unless they’ve done the appropriate amount of work. While the average user would only see a slight delay in visiting a site, an attacker would have to expend vast amounts of resources to be able to overwhelm the Onion service.

Another important aspect of this proposal is that legitimate users can “outbid” an attacker for access to a given Onion service or resource by performing more difficult work, allowing them to “skip the line” of network congestion and ensure access to a service even while it is being actively attacked. This bidding process would also continually increase the cost of an attack on a given service, further disincentivizing DoS attacks the more legitimate users want to access a service and increasing the cost of attacks on popular or important services in the network.

How does the PoW process work? #

Whenever an Onion service is undergoing a DoS attack (or when manually activated by the service administrator), the Tor daemon will start to require PoW from clients before creating rendezvous circuits. The process of using PoW to mitigate DoS attacks will go something like this:

  1. The Onion service sees a DoS attack and activates PoW (or an administrator can manually enable PoW for an Onion service)
  2. The Tor daemon automatically adjusts the required difficulty of work based on the scope of the attack and provides it to connecting clients
  3. The client performs provably difficult work at least as hard as specified by the Onion service and provides it in the introduction handshake with the service
  4. The Onion service validates the proof of work, ensures it has never been used before, and then continues normal operation if all verification passes

What will the user experience look like after this is included in Tor? #

While this can certainly have an impact on user experience, it importantly will not effect Onion services responsiveness or speed at all when those services are not undergoing attacks. Under normal load Onion services will not require PoW at all, ensuring the same user experience we’re all used to within the Tor network.

In the event of an attack on an Onion service, however, the Tor daemon would automatically enable PoW and start forcing users to perform provably hard work before they can access the service.During minor attacks this could be a very small amount of work, but during severe DoS attacks this could require much more computation. The exact timing requirements will depend on choices made in tuning the PoW approach being taken and the hardware in use, as more powerful laptops or desktops will be able to perform the computations proportionally faster.

The biggest improvement overall though is that even under active DoS attacks, Onion services will have a powerful tool to ensure that legitimate users can access the service, even if it requires provably hard work to be done by a users computer before they can access a service. The ability to ensure much higher uptime and resilience for Onion services with only a minor impact to user experience will be a big leap forward for the usefulness of the Tor network overall, and greatly simplify the difficulties of running an Onion service in an adversarial environment.

The initial proposal includes the Tor browser notifying users of why loading a service is initially slower when PoW is required while allowing users to tune how difficult of PoW they are willing to compute to reach a given service – the more you value the Onion service you’re trying to reach, the longer you will be willing to wait to compute the PoW and “outbid” any attackers during a DoS attack.

Where can I learn more about this proposal? #

As this concept has been around for quite a few years there is a lot of great information out there on the history, proposal, and current ongoing efforts on implementing PoW into Tor: