Tor Guard Algorithm Enables Trapper Attacks

Our Guard Algorithm enables trapper attacks.

When combined with a covert channel between relays, this allows a malicious ISP or compromised WiFI router to perform full-scale de-anonymization of all local Tor client traffic, by running only two guards and one exit.

This property is a direct result of the following goals of the Tor Guard specification:

• Clients in censored regions or who are behind a fascist firewall who connect to the Tor network should not experience any significant disadvantage in terms of reachability or usability.
• Tor should make a best attempt at discovering the most appropriate behavior, with as little user input and configuration as possible.

These goals not only enable these attacks, they are redundant to our censorship circumvention components, which now also include auto-discovery of connectivity, independent of the Tor client.

We've known about this problem since the beginning, as per the penultimate goal on that guard spec, but we lacked a threat model that was capable of articulating the severity of these problems. There's no reason to make this issue private, just because we suddenly have one. The raccoon's been out of the bag for over a decade, here.

I also believe that the Tor Guard algorithm should be reworked to apply local GuardSets to help resist tracking users using netflow, but some form of rate limiting proposal that fails closed (and thus engages anticensorship features) much earlier than we do now, upon any connectivity issues to guards, would help stop the bleeding.

We also need to consider slow-roll attacks, where Guard connectivity is blocked one at a time.