[zmanian]

This attack is a general amplifier on denial of service attacks on Linux server.

If this attack was deployed against Tor, this would appear as a general DDOS attack against Tor and degrade most users experience.

It would not help an attacker direct circuits towards a malicious exit as described in the paper.

[russell_sears]

I still don't understand how you come to the conclusion that the attack won't work.

The bolded text in the blog post reads "the middle relay will pick a different exit relay", and should read "the client will pick a new circuit at random using the same bandwidth-proportional weights."

The security properties of the corrected description aren't very comforting: the attack is no longer guaranteed to work, just like there is no guarantee I will ever roll a one with a fair die.

[zmanian]

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.

[thegeomaster]

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.

[belorn]

> 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.

[thegeomaster]

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