Re: [tor-dev] [RFC] On new guard algorithms and data structures

["l.m" <ter.one.leeboi@xxxxxxxx>]

> Thanks for the input!

Hey, no problem. Thank you for working on this too.

> Can you suggest a retry amount and time interval?

If the adversary is at the gateway and can do filtering, they pretty much want some rotation. Whatever that reason may be (choose a guard you've already chosen, or choose some other which may be adversarial). In the case you describe, I would minimize retry and maximize interval size. Sorry for being unspecific. The reason being if your client has selected and not connected, the adversary may become aware of this selection. They can then fingerprint your use when you change locations using the guards. It acts as a foothold to launch further attacks. It means even if the adversary doesn't initially succeed against you, then can always resume their efforts later.

A simplification might be to have the client explicitly state location changes. More than just detecting ip changes like tor. When you start TBB you make a choice, or in the torrc. Easier than network awareness for tor. You're at a trusted location or unknown. If the location is trusted then less skepticism is needed when forced to choose a new guard, or if you should retry connecting, and how often.

If the location is otherwise you expect some degree of third-party interference is likely. You expect that rotation is unlikely to be benign (you may already have a compromised guard). The guard which was just chosen should be treated with skepticism, network interruption and outage is likely suspicious, and any friendly guards can be used to identify you if you change location where this gateway is still used. Here you find the airport example. Are long-lived guards and the default path selection implementation as secure here. Some analysis is in order. Maybe short-lived (and not persistent) guards, and tuned path selection, is as good as long-lived guards at the trusted location? The whole question of whether the entry guards concept can work effectively in an untrusted location is being questioned here.

It might be better to just default-drop guards between untrusted location, while persisting guards at explicitly trusted locations.

Some symptoms of this adversary are: unable to bootstrap from dirauths, guards which were working have now become unlisted/down, client behaviors symptomatic of censorship which persist between locations unless guards dropped, traffic flows begin to favor a particular guard over time after multiple rotations, multiple guards become unreachable at the same time when another guard is chosen.


--leeroy
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev