[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25870 [Core Tor/Tor]: Fix vanguard restrictions
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs