You'll get an exit with DDOS attack against it. Not an exit controlled by the attacker. The attacker will see the same fraction of Tor traffic with or without the attack. The Tor user base will notice a massively degraded experience.

You can't affect the proportion of Tor traffic that flows through a given exit with a DDOS attack.

I think the parent comment is saying that given an attack which can reliably abort connections between two arbitrary endpoints, one can reliably break other users' Tor circuits, which causes their Tor clients to renegotiate new ones. If a circuit is negotiated such that all nodes are owned by the attacker (in which case the attacker can unmask the affected user), the attacker can then choose not to disrupt that particular circuit. This, in turn, enables the attacker to penalize non-attacker-controlled circuits, and cause Tor clients to settle on compromised ones (which won't be penalized). This gives the attacker more power than simply waiting for an unlucky client to build a circuit with all nodes belonging to the attacker.

If this is indeed what the parent is saying, and if I'm understanding the attack and the Tor protocol correctly, I too don't see why such an attack isn't feasible. I'm perhaps in the wrong and missing something, but would very much appreciate if someone could clear this up for me.

> enables the attacker to penalize non-attacker-controlled circuits, and cause Tor clients to settle on compromised ones

That's the key question. Will clients "settle" on compromised ones, or just continue to try access the penalized (dead) circuits?

A few years ago, there were a bug which was used to rapidly force users to create new paths. The Tor Project fixed that bug, but they also added a extra precaution for future bugs by limiting how new paths were selected in regard to guard nodes. As to my understanding, when a client first connects, it initially generate a random (but consensus weighted) subset selection of all guard nodes. It then randomly picks one from that selection when creating new paths, which mean that only guard nodes in the selection can ever be picked by the client. A client that is attacked as described in the article will just cycle through its lists indefinitely and never choose a compromised node, unless it already picked a compromised node initially.

Ah, I see. Thanks for explaining that so clearly!