Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #12466

Closed (moved)
Open
Opened Jun 25, 2014 by George Kadianakis@asn

Possible primary guard node skip when some guards are down

This is another possible guard node skip (similar to #12450 (moved)), that can make Tor skip some of the higher priority guards and prefer guards in the lower end of the list.

#12450 (moved) 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.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#12466