> On Oct 20, 2026, at 7:56 AM, kullikovana via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx
_______________________________________________ tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx