"Nick Mathewson" wrote:
If the number of guards we have *tried* to connect to in the last PERIOD days is greater than CANDIDATE_THRESHOLD, do not attempt to connect to any other guards; only attempt the ones we have previously *tried* to connect to.
Torrc allows the use of multiple guards with numentryguards > 1. So if an adversary hasn't yet managed to compromise the guard this might lead to a DOS. The adversary may be interested in getting you to connect to *one* malicious guard at a time. It might be worth considering to perform a reach-ability test using a built circuit. I mention "built" because Tor wouldn't know if the connectable guard is adversary controlled. It might also be worth considering guards that successfully connect after a failure as suspect for a time. That is, they shouldn't be optimistically added to the list of guards unless absolutely needed.
We need to make this play nicely with mobility. When a user has three guards on port 9001 and they move to a firewall that only allows 80/443, we'd prefer that they not simply grind to a halt. If nodes are configured to stop when too many of their guards have gone away, this will confuse them.
If 80/443 are the least restricted types of connection maybe it would be a good idea to try n of those before stopping. If they work but other guards fail it might be a symptom of a fascist firewall to warn about.
If people need to turn FascistFirewall on and off, great. But if they just clear their state file as a workaround, that's not so good.
If FacistFirewall is 1 with some ports specified, and state isn't empty, don't consider the disjoint guards contributing to thresholds?
If we could tie guard choice to location, that would help a great deal, but we'd need to answer the question, "Where am I on the network", which is not so easy to do passively if you're behind a NAT.
If network location were the combination of physicaladdr+dnsname+subnet would it be so bad if you're behind a NAT and dnsname were unavailable?
--leeroy