[tor-bugs] #16824 [Tor]: coexistence of client and relay processing on same thread poses traffic confirmation risk
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Nov 9 00:16:52 UTC 2015
#16824: coexistence of client and relay processing on same thread poses traffic
confirmation risk
-----------------------------------------+---------------------------------
Reporter: starlight | Owner:
Type: defect | Status: new
Priority: High | Milestone: Tor:
Component: Tor | 0.2.8.x-final
Severity: Normal | Version: Tor: 0.2.6.10
Keywords: PostFreeze027, 027-backport | Resolution:
Parent ID: | Actual Points:
Sponsor: | Points:
-----------------------------------------+---------------------------------
Changes (by mikeperry):
* severity: => Normal
Comment:
Ok, so I've thought more about this, and if #16585 remains
unsolved/unmitigated, a potential workaround for technical users is to use
their relay as a bridge for a second tor client process that runs locally.
This will prevent the side channel from happening.
Unfortunately, to avoid exposing yourself to additional attacks, you
probably want to hack that second tor client to use 4 hops (so your local
relay-as-bridge, and 3 hops after that). You also want a second layer
guard to be used by your second Tor client after your relay-as-bridge, so
that Guard discovery attacks find that guard and not the relay that you
run.
Since this is two paragraphs of text, unless we create a torrc options to
do the above, we're still probably blocked here. But I do think this is at
least a way forward. Unfortunately, the Guard-after-bridge piece is a very
involved change because of how that code works right now. Simply changing
to 4 hops for that second Tor client is trivial, though.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16824#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list