"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
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
