Re: [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]

#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 nickm):

 Actually, there's a neat way to make walking onions "solve" this
 "problem", if we wanted to: clients could specify which rendezvous point
 they're using by including the SNIP that they want to use, or including
 the index that they want to use.  Onion services could verify that they
 were getting a valid and somewhat recent SNIP.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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]

#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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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]

#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:
+---
Changes (by asn):

 * status:  new => needs_information


Comment:

 The reason we dont require RPs to be part of the consensus, is that there
 is no global consensus, and clients and service can have a different one
 at any given time. This will cause desynch issues where the service will
 be rejecting rendezvous requests because they cant find the node on the
 consensus. In theory we could fix this by having the client pass a list of
 rendezvous to the service, but not sure if this is worth it given the
 limited improvements that this will bring to the overall attack (#24487).

 Even if we required that the RP is in the consensus, the attacker can just
 make a bunch of relays in those IPs, get them in the consensus and then
 perform the attack properly. Hence, I dont see the suggested defence being
 such a big improvement here.

 If I'm wrong please correct me.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs