[tor-bugs] #33129 [Core Tor]: Tor node that is not part of the consensus should not be used as rendezvous point with the onion service
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Feb 4 21:32:13 UTC 2020
#33129: Tor node that is not part of the consensus should not be used as rendezvous
point with the onion service
----------------------------+-----------------------------------
Reporter: cypherpunks | Owner: (none)
Type: defect | Status: needs_information
Priority: Very High | Milestone:
Component: Core Tor | Version:
Severity: Critical | Resolution:
Keywords: onion services | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
----------------------------+-----------------------------------
Comment (by s7r):
I agree with you. It is actually bad for performance if we want to request
that the RP point should be part of the consensus (for the onion service
server view of the network). Onion service client and onion service server
can have (and will often have) different views over the network.
If we change this, it will be incompatible with Nick's walking onions
vision (which I really think is the way to go for the really really long
term).
Also, it gives us only downsides. Because it doesn't actually fix
anything. The attack is still possible exactly the same (not even with
slight additional effort from the attacker), because the RP is selected by
the onion service CLIENT (which we should always assume it's an attacker)
thus it's trivial to spin in some malicious middle relays (cheap to setup,
not even required to have the Guard flag), wait for the first consensus
and use them to carry on this attack just fine.
I indicated this back in 2016, and wrote a proposal attempt:
https://lists.torproject.org/pipermail/tor-dev/2016-January/010291.html
mikeperry considered it and implemented it as part of the vanguards
defense as `Rendguard`. If we change something, this should be a default
from my perspective, regardless to layer 2 and layer 3 guards for onion
service server. Because as opposite to layer 2 and layer 3 guards, the
rendguard subsystem doesn't face the load-balancing and fingerprinting
potential problems.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33129#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list