Tor is much slower latterly than it used to be

Thank you for your hard work!
Unfortunately, right now I don’t observe any improvements, but maybe some time is needed for these changes to take effect? Am I correct thinking that no any additional settings are needed from the users’ side?

I’m seeing the change to two guards instead of one taking effect on both Tor Browser Stable and Alpha. But the two guards my Alpha browser was assigned are both still using old versions of Tor, 0.4.5.6 and 0.4.6.10 (one of them has an uptime of 326 (!!) days). Therefore the circuits I am handed will not take full advantage of the congestion control in 0.4.7.7+, am I right?

I was wrong, sorry for the misleading, just didn’t have enough time for testing. I actually see huge improvements in both tor 0.4.7.8 and tor-browser 11.0.14. Can see that both use two entry nodes. I’ve been using TB for an hour now, and it feels pretty good.

1 Like

Actually, your guards don’t need to be running the latest versions, to make use of the new congestion control stuff. Only the endpoints matter – (A) your client, and (B) your exit relay (or the onion service you’re talking to, if it’s an onion service you’re reaching).

3 Likes

Thanks for the update. Could you please clarify what this means for us folks who use pluggable transports? Will this setting affect us if we have 2 bridge lines or more?

1 Like

Great point!

I believe the answer is yes, people who use bridges will now use two of them by default (if they have at least two configured).

Proposal 271 has all the gritty details of the new (as of Tor 0.3.0, in 2017) guard design:
https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-selection.txt

(The goal of the prop271 guard design was to somehow avoid the attack where an adversary who controls your local network blocks connections to every guard in the consensus except the one(s) they control. The way the design works is that you grab a pretty small set of possible guards (dozens), and then you only choose your guard out of that set, and if you run out, you fail closed. Bridges re-use the same design, not because it is a great idea for bridges, but because it’s what the code does.)

3 Likes

it seems the ddos stopped ? I’m seing less traffic on my relay on the past hours !

I can see a drastic improvement, videos no longer buffer and onion services are usable again (instead of taking 20 seconds or more just to start loading).

Is there a torrc line or something users can do to change back to guard-n-primary-guards-to-use=1, in cases where safety is more important than performance?

Yes.
Though its generally not advisable for obvious reason, if you find yourself needing to specify your first hop, use this.

EntryNode $fingerprint

Quoted from: circuit - How to change the entry node? - Tor Stack Exchange

Add this line to your torrc file, and restart tor. Verify in browser or tor logs that the circuit was built using the fingerprint provided and is in fact connecting to the entry node you want.

There are a few different ways to implement this idea/solution though, and you can specify multiple entry nodes and tor will pick from one on startup.

Look specifically at the ‘EntryNodes’ section on the man page, a quick hotkey for finding it is copy EntryNodes, control + f (command + F on Mac) and paste. Should be right next to strictnodes.

Or from terminal in linux, unix, Mac, or BSD, copy paste

man tor | grep --color=always -C 10 EntryNodes
2 Likes

Too slowly

Hi @Mar-vellONE, please see: Network DDoS | Tor Project status

1 Like

Have they managed to figure out where/who its coming from yet? Its hard to tell if this is being done by agencies or criminals, not that there is often much difference between the two

From what I’ve read it was a DDoS on Dread, a .onion forum.

More than that, my relay got DDoS’ed so frequently within a few days that it would freeze and the kernel would straight up panic and go unresponsive. Hard shutdown required.
I had to take it offline entirely and release my public IP to stop it.
Attempting to redeploy soon under BSD.
its isn’t just .onion that’s under attack.

I guess its likely to be someone with control over millions of machines which would make it more likely to be a criminal act done by botnet owners. I don’t see the purpose behind it though, its drawing lots of attention and hitting completely random people. I thought it could be law enforcement trying to push people away from Tor and to pseudo anonymous VPNs which they could perhaps have more chance of tracing, yet the act of performing a DDoS is illegal itself so I don’t know if it would even be allowed and if it were to be allowed then where would they get so much powerful traffic and for such a long period of time?

The only real explanation that makes sense (at least to me anyway) is this is a state actor, not likely the US (though I may be wrong about that who knows) my money is on China and the CCP. But I digress.

I noticed that between the DDoS attacks, they were concentrated around when my relay received the HSDir flag, and the stable flag.

The first time I was DDoSed was after my machine had been up and chugging away silently for around 4 or 5 days, V2Dir, fast, and Valid flags only. Within 4 hours of receiving the Stable and HSDir flag, I started getting DDoSed.

Im pretty confident someone has a script that’s scanning Tor metrics for certain flags. HSDir, Guard, and Stable relays seem like the target here, given the data I’ve been exposed to anyway, and that explanation starts to Gell when you consider that relays with these flags receive more traffic, and longer lived circuits.
It wouldn’t make sense from a logistics standpoint to attack nodes without the Stable or HSDir flags, as it wouldn’t significantly disrupt the network as a whole. Hitting 500 or 1000 relays with certain flags is a lot more doable than hitting every relay, and targeting relays that are marked as stable will reduce the total number of long lived circuit nodes, and targeting relays that have the HSDir flag will prevent a lot of tor users from finding onion services. Not all of them mind you, but enough to hurt either way.

If you can’t take them all down, rendering the network unusable or slow to a point of unusable is just as good as taking them all down.

Why not hit Guards or exits nearly as often? Why not the Authorities? Well, I’ve though about it for a while, and its a matter of threat profiling. The Authorities, Guard nodes, and exit nodes are more likely to be hardened and run by experienced operators, especially if they’ve been around for more than 6 months consistently. Newer relays, or relays that are more middle or onion service relays like my own might overall be less secure. They receive less traffic, and ill be willing to bet many of the stable middle relays and such are run by operators that aren’t nearly as experienced.

Without middle nodes and HSDir relays, the guard and exit nodes are largely irrelevant anyway. So why hit hardened targets?

If it is as you say, another theory is that the attacker is also running relays and the attack is meant to make traffic pass those relays more likely.
We can’t easily tell if all machines with the Stable/HSDir flag gets attacked.

Its a surprise that more isn’t being done to investigate the source, computer science universities and digital legal experts could perhaps find something massive if they looked. Does anyone know if MIT are looking into it? They have a history of tampering with Tor so its probably a pretty interesting event for them