How to stop the onion denial (of service)

As you might have heard, some onion services have been experiencing issues with denial-of-service (DoS) attacks over the past few years.

The attacks exploit the inherent asymmetric nature of the onion service rendezvous protocol, and that makes it a hard problem to defend against. During the rendezvous protocol, an evil client can send a small message to the service while the service has to do lots of expensive work to react to it. This asymmetry opens the protocol to DoS attacks, and the anonymous nature of our network makes it extremely challenging to filter the good clients from the bad.

For the past two years, we've been providing more scaling options to onion service operators, supporting more agile circuit management and protecting the network and the service host from CPU exhaustion. While these don't fix the root problem, they provide a framework to onion service operators to build their own DoS detection and handling infrastructure.

Even though the toolbox of available defenses for onion service operators has grown, the threat of DoS attacks still looms large. And while there is still a bunch of smaller-scale improvements that could be done, we believe that this is not the kind of problem that a parameter tweak or small code change will make it disappear. The inherent nature of the problem makes us believe that we need to make fundamental changes to address it.

In this post, we would like to present you with two options that we believe can provide a long-term defense to the problem while maintaining the usability and security of onion services.

The intuition to keep in mind when considering these designs is that we need to be able to offer different notions of fairness. In today's onion services, each connection request is indistinguishable from all the other requests (it's an anonymity system after all), so the only available fairness strategy is to treat each request equally -- which means that somebody who makes more requests will inherently get more attention.

The alternatives we describe here use two principles to change the balance: (1) the client should have the option to include some new information in its request, which the onion service can use to more intelligently prioritize which requests it answers; and (2) rather than a static requirement in place at all times, we should let onion services scale the defenses based on current load, with the default being to answer everything.

👀 👉🏼 https://blog.torproject.org/stop-the-onion-denial

#tor #onion #DoS #attack
📡@cRyPtHoN_INFOSEC_DE
📡@cRyPtHoN_INFOSEC_EN
📡@BlackBox_Archiv
📡@NoGoolag

You are not anonymous on Tor - Last February, my Tor onion service came under a huge Tor-based distributed denial-of-service (DDoS) attack

I spent days analyzing the attack, developing mitigation options, and defending my server. (The Tor service that I run for the Internet Archive was down for a few hours, but I managed to keep it up and running through most of the attack.)

While trying to find creative ways to keep the service up, I consulted a group of friends who are very active in the network incident response field. Some of these are the people who warn the world about new network attacks. Others are very experienced at tracking down denial-of-service attacks and their associated command-and-control (C&C) servers. I asked them if they could help me find the source of the attack. "Sure," they replied. They just needed my IP address.

I read off the address: "152 dot" and they repeated back "152 dot". "19 dot" "19 dot" and then they told me the rest of the network address. (I was stunned.) Tor is supposed to be anonymous. You're not supposed to know the IP address of a hidden service. But they knew. They had been watching the Tor-based DDoS. They had a list of the hidden service addresses that were being targeted by the attack. They just didn't know that this specific address was mine.

As it turns out, this is an open secret among the internet service community: You are not anonymous on Tor !!

💡 Threat Modeling

There are plenty of documents that cover how Tor triple-encrypts packets, selects a route using a guard, relay, and exit, and randomizes paths to mix up the network traffic. However, few documents cover the threat model. Who can see your traffic?

👀 👉🏼 https://www.hackerfactor.com/blog/index.php?/archives/896-Tor-0day-Finding-IP-Addresses.html

#tor #onion #service #zeroday #DDoS #attacks #anonymous #poc #thinkabout
📡@cRyPtHoN_INFOSEC_DE
📡@cRyPtHoN_INFOSEC_EN
📡@BlackBox_Archiv
📡@NoGoolag

You are not anonymous on Tor

👀 👉🏼 https://t.me/BlackBox_Archiv/1252

#tor #onion #service #zeroday #DDoS #attacks #anonymous #poc #thinkabout
📡@cRyPtHoN_INFOSEC_DE
📡@cRyPtHoN_INFOSEC_EN
📡@BlackBox_Archiv
📡@NoGoolag