[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #12466 [Tor]: Possible primary guard node skip when some guards are down
#12466: Possible primary guard node skip when some guards are down
----------------------------------+------------------------------------
Reporter: asn | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Tor: 0.2.6.x-final
Component: Tor | Version:
Keywords: tor-guard tor-client | Actual Points:
Parent ID: | Points:
----------------------------------+------------------------------------
This is another possible guard node skip (similar to #12450), that can
make Tor skip some of the higher priority guards and prefer guards in the
lower end of the list.
#12450 applies even for `NumEntryGuards=1`, but this one applies only when
`NumEntryGuards` is larger than 1.
So, this loop [0] in `choose_random_entry_impl()`:
https://gitweb.torproject.org/tor.git/blob/d064773595f1d0bf1b76dd6f7439bff653a3c8ce:/src/or/entrynodes.c#l1035
will try to add guards to `live_entry_guards` till it contains
`NumEntryGuards` entry guards, which is '''3''' currently.
Finally this code [1] will pick one of them:
https://gitweb.torproject.org/tor.git/blob/d064773595f1d0bf1b76dd6f7439bff653a3c8ce:/src/or/entrynodes.c#l1133
Let's assume that our state file contains many guards (50 or so), so we
have plenty of nodes to add to our `live_entry_guards`. It also so happens
that the third entry guard in our `entry_guards` list just went dead.
So, now we need to make a circuit. We go over loop [0], and add the first
three guards to `live_entry_guards`, then [1] picks the third entry node
to be used by the circuit. Unfortunately, since that node is down, the
circuit dies. And we go back to `choose_random_entry_impl()` to get a new
entry node.
So, now we go over the loop [0], and we add the first two entry guards and
the fourth one (since the 3rd entry guard is now marked as unreachable).
If [1] now picks the fourth entry guard, we have "skipped" our primary
guards and selected a lower priority one.
As a matter of fact, we can imagine this procedure happening a lot of
times, and if we are very unlucky, Tor will keep on adding new dead entry
guards to our `live_entry_guards` list and then it will keep on choosing
them. This will result in a `live_entry_guards` list always containing the
first two entry guards (let's call them the primary entry guards) and then
the 48th entry guard in our list. Then Tor will choose the 48th entry
guard and succeed on making a circuit, and there you have it, we just
picked a very low priority entry guard for our circuit.
This is theoretically possible, but not very likely to happen in practice.
But since we are trying to pay more attention to guard node security,
maybe it should be fixed.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12466>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs