[tor-bugs] #25870 [Core Tor/Tor]: Fix vanguard restrictions

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Apr 24 16:36:25 UTC 2018


#25870: Fix vanguard restrictions
--------------------------+------------------------------------
 Reporter:  mikeperry     |          Owner:  (none)
     Type:  defect        |         Status:  needs_review
 Priority:  Medium        |      Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:  #25546        |         Points:
 Reviewer:  asn           |        Sponsor:
--------------------------+------------------------------------

Comment (by mikeperry):

 Replying to [comment:4 asn]:
 > Hey Mike, can you explain how the branch prevents Tor from building `A -
 B - A` paths as it claims?
 >
 > IIUC, commit `4b61ba2a98` starts allowing `A - B - A` paths since it
 removes the guard-to-exit restriction.

 This commit by itself only allows A - B - C - A paths. Specifically, it
 allows C - G - L2 - L3 - G and C - G - L2 - L3 - M - G paths. Remember
 that vanguard paths are always at least 4 hops long, and sometimes 5. See
 route_len_for_purpose(). This is done to prevent the adversary from having
 influence over guard node choice (as you proposed on tor-dev).

 > Then commit `ac348ffbae` modifies `build_middle_exclude_list()` which
 should only exclude possibilities for the ''middle nodes'', hence blocking
 paths like `A - A - B` or `A - B - B`. Am I wrong?

 To see the whole picture, you have to go up to
 circuit_establish_circuit(). The steps are as follows:
 1. Call onion_pick_cpath_exit(), which picks the exit node. The exit node
 is either pre-specified (HSDIR, I, RP) or it is chosen randomly.
 2. Call onion_populate_cpath(), which then loops calling
 onion_extend_cpath() for each hop in the circuit.
 3. The first time through, onion_extend_cpath() calls choose_good_entry
 server(), which will now choose the entry guard without considering the
 exit already chosen.
 4. The second time through, it calls choose_good_middle_server(), which
 calls build_middle_exclude_list(). The exclude list will now contain only
 the entry guard and the exit (but not any other nodes from their families
 or /16). Then pick_vanguard_middle_node() uses the exclude list to pick an
 L2 that is not the guard or the exit.
 5. The third time through, choose_good_middle_server() is called again.
 Now the exclude list contains G, L2, and E. pick_vanguard_middle_node()
 then chooses an L3 that is not G, L2, or E.
 6. If the desired_path_len is 4 (from route_len_for_purpose()), we are
 done. Our path is G - L2 - L3 - E, where G can be E, but neither G or E
 can be L2 or L3, and L3 cannot be G, L2, or E.
 7. If desired_path_len is 5 (again from route_len_for_purpose()),
 onion_extend_cpath() is called once more. It again calls
 choose_good_middle_server(). The exclude list now contains G, L2, L3, E.
 But this time, middle_node_must_be_vanguard() returns false, and a
 completely random middle node is chose, but one that cannot be G, L2, L3,
 or E.

 So there can be no A - A - B, A - B - B, or A - B - A sub-paths, since
 build_middle_exclude_list() is building up the exclude list starting with
 the exit, and then after that, outwards from the guard, forbidding *any*
 duplicate node choices for all but the guard and exit positions.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25870#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list