I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3
Like many relays mine has been under attack for a while now. Recently it has however become worse. Because of the DirAuths.
After having restarted the relay a few time in order to upgrade the tor program in the vain hope there might be a fix for the attack, the attacker now only have to spend a few hours every few days on my relay. The rest of the time it is flagged as non-stable and gets hardly any traffic. Once the DirAuths figure the relay is stable the flags return, and so does the attack. And the DirAuths promptly removes the flags and we go another round around the loop.
If the torproject can't find a programmer to fix the actual issue can the DirAuths at least relax the requirements for the stable flag?
···
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Hi Nick,
A fix has been being tested since last week, hopefully it will be deployed soon, for more details please read the thread “Shutting down my ~40 guards”.
···
On Mon, 26 Oct 2026 at 15:46, Nick Weaver via tor-relays <tor-relays@lists.torproject.org> wrote:
On Oct 20, 2026, at 7:56 AM, kullikovana via tor-relays <tor-relays@lists.torproject.org> wrote:
flags june october
Running ~9 700 ~9 000
Stable ~8 800 ~7 300
Guard ~5 800 ~4 500
HSDir ~5 500 ~1 800
The problem is, truth be told, it appears the Tor project doesn’t actually care what is going on.
It isn’t the Tor network being attacked for the sake of being attacked, it is the Tor network is probably being attacked to target some set of hidden services to identify the visitors. This is almost certainly HSDir shaping.
The idea is either at 00:00 UTC (when the new shared random is published) or 12:00 (when the new shared random is used to restructure the hash ring for fetching) the attacker looks at the 6 relays which would serve for the targeted HSDirs and, if they don’t belong to the attacker, take them down and any following relays in the hash ring for the targeted .onions with DOS attacks until requests go to attacker-controlled HSDirs. Based on reporting it sounds like they are doing 12:00 as their start point.
These attacker HSDirs would then respond with signaling traffic and, if a target used one of the attacker’s guard nodes as well, identify the visitor. Which means if an attacker controls a fraction X of the network the odds of successfully identifying the visitor is X not X^2, vastly improving the effectiveness.
Concrete numbers: If the attacker has just 1% of the relays it now becomes 1 in 100 of identifying a visitor instead of 1 in 10000. For 5% it is 1 in 20 instead of 1 in 400.
The real fix would be to make the HSDir flag “sticky”, as the problem is not the DoS vector but, as seen by the attacker responding to single-router fixes with alternate DoS traffic, the DoS benefit.
When a relay would lose an HSDir flag it shouldn’t actually lose the flag until 12:00 the next day. Now an attacker can still DOS the hidden service by taking down the relays responsible but can’t deanonymize visitors to the hidden service, and the attacker could still DOS the targeted hidden service directly (proof of work doesn’t work against well resourced attackers which this attacker clearly is).
This fix only needs to take place on the directory authorities, not the relays themselves.
That Tor hasn’t deployed this fix, in the face of what is clearly obviously a major attack targeting some users that is destabilizing the entire network, is a pretty sad statement about the Tor project.
tor-relays mailing list – tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org