[tor-dev] [Proposal 241] Resisting guard-turnover attacks [DRAFT]

l.m ter.one.leeboi at hush.com
Mon Feb 2 20:02:28 UTC 2015

"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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150202/b850ddbf/attachment.html>

More information about the tor-dev mailing list