Instead of messing with your path selection a better strategy would be just run your own guard nodes that you trust (a guard node is the first node that you connect to in a Tor circuit) and to stick with them. Remember, de-anonymization attacks require the attacker to control both the guard node and the exit node at the same time.
If you want your guard node to be helpful in anonymizing your traffic, you should really make sure it's public and used by some % of the global user base (so that your traffic blends in the noise).
Once you do that though, you will always have to trust that node a little less than you could if it was walled-off so it would only serve you, just because it is another machine serving connections on the internet that will likely be targeted by adversaries who would benefit from turning many of the guard nodes into part of their Tor de-anonymization service.
If I had endless resources and was truly paranoid, what I'd do is build my set of public guard nodes, make sure they're serving Tor traffic, etc.
But then, I'd "borrow" those IPs occasionally for trusted nodes which will only accept connections from me (ideally both sets of machines will be live and routing traffic simultaneously).
In theory, you could apply the same tricks with similar success to exit nodes of course (though as usual, running an exit node is generally a slightly riskier / harder thing to do)
Which relays are guard relays is public knowledge (by necessity, it's how clients know which hops to select). If you operate a middle relay, and you see traffic coming from a relay not known to be a guard, you know it's from a non-standard Tor config, since you should only see circuits being built through guards (ignoring onion service traffic, which is small enough that we can do so in the limit). If you mean "get your relay listed as a guard, but don't accept traffic from anyone else", 1. you're going to lose your guard flag pretty quickly trying that, and 2. you ultimately have the same problem, since the adversarial middle will see that this guard is relaying suspiciously little traffic (relays only get flagged by auths as guards if they can handle above a certain amount of traffic, since they are designed to change infrequently, so a bad one will give you a bad Tor experience for a long time).
> That only works if the attacker doesn't know the guard node is you.
That's not how Tor nodes work. Once you setup a guard node (and it got enough reputation) you won't be the only person using the guard node. Also de-anonymization attacks require you to know the traffic coming to the guard node (and if you run a trustworthy one yourself and you're not dealing with a global passive adversary then there's no way the attacker will be able to see the incoming traffic to the guard node).
Running your own node and "sticking with it" is not a great idea especially if you're the only one using it. You will be spotted and identified pretty much instantly
I guess this approach works fine for an individual, but if everyone has to run their own guard node to be safe, why would anyone connect to your guard node (given it would be risky from their perspective since they aren’t running it themselves).
In other words, if you accept you can’t trust anyone else, why would anyone else trust your node too?
(Edit: Sorry I’m wording it poorly but I hope you get the idea)
Most people don't need to. Most people use Tor when it's a) completely unnecessary, b) not interesting to the sort of well-funded attacker that could run this many nodes, or c) only needed to avoid identifying them to the service they're requesting from.
>I guess this approach works fine for an individual, but if everyone has to run their own guard node to be safe, why would anyone connect to your guard node
By the time a few percent or tor users are running a guard node, KAX17 would be too diluted to be a real threat.
Does an attacker only need to control the guard and exit nodes, or the middle relay node(s) as well?
If the latter, can you configure Tor to use more than one middle relay node, depending on your threat model?
Could Tor do something like overlay a fixed-throughput circuit-switched network on top of the packet-switched network to prevent correlation attacks? Obviously at the expensive of efficiency.
Also: If KAX17 is running nodes on 50+ AS's "including non-cheap cloud hosters like Microsoft" shouldn't it just take one insider at one of those hosts to leak the identity of one or more of these node operators? Come on, guys...
> Does an attacker only need to control the guard and exit nodes, or the middle relay node(s) as well?
No, only controlling the guard and exit nodes is necessary.
> If the latter, can you configure Tor to use more than one middle relay node, depending on your threat model?
Tor makes dozens of circuits in a typical use. You never stick to a single circuit. In the Tor Browser you have first party stream isolation so you get a different circuit (and hence different middle and exit nodes) for each first party domain that you visit.
