[tor-bugs] #17604 [Tor]: Try to use only one canonical connection
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sat Nov 14 20:25:27 UTC 2015
#17604: Try to use only one canonical connection
---------------------------+-----------------------
Reporter: mikeperry | Owner: mikeperry
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Tor | Version:
Severity: Normal | Keywords:
Actual Points: | Parent ID: #16861
Points: | Sponsor:
---------------------------+-----------------------
For #16861, I would like to experiment with padding between relays, as
well as generally keep relay-to-relay orconns open much longer. This will
be beneficial against attacks like Torscan
(https://eprint.iacr.org/2012/432.pdf), as well as related netflow-based
attacks that attempt to determine the guard node of a connection by using
netflow data to accomplish the same thing as the Torscan attack.
Unfortunately, the logic for preferring orconns (is_canonical and
channel_is_better()) is a mind-bender, but it appears to be the case that
we may have situations where multiple orconns can be opened between relays
where each side disagrees over which connection is canonical. This can
happen because the source port won't match the orport in the descriptor of
the remote relay for incoming connections. It will also be the case for
nodes that make outgoing connections from different IP address than those
in their descriptor.
I asked on #tor-dev, and two relay operators reported cases of such
multiple connections to relays.
I think the following changes will improve the situation:
1. Mark all authenticated connections as canonical (everything with link
proto v3 and higher will authenticate, yes?)
2. Alter channel_is_better() to prefer older orconns in the case of
multiple canonical connections, and use the orconn with more circuits on
it in case of age ties.
I think age is more important than number of circuits because we want to
avoid giving an attacker the ability to switch an orconn between relays by
creating a new one and opening a bunch of circuits on it.
channel_is_better() is doing the opposite of this behavior right now, on
both fronts.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17604>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list