Opened 6 months ago

Last modified 6 months ago

#33129 needs_information defect

Tor node that is not part of the consensus should not be used as rendezvous point with the onion service

Reported by: cypherpunks Owned by:
Priority: Very High Milestone:
Component: Core Tor Version:
Severity: Critical Keywords: onion services
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

According to this article attacker is able to to chose a server that is running Tor but is not part of the Tor network as an rendezvous point with the onion service so that he can discover in to which family onion service`s guard node belongs and than use that information to ddos Tor nodes in that family so that onion service drops that guard node and instead chose his Tor node as a guard node.

https://www.hackerfactor.com/blog/index.php?/archives/868-Deanonymizing-Tor-Circuits.html

Child Tickets

Change History (3)

comment:1 Changed 6 months ago by asn

Status: newneeds_information

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.

comment:2 Changed 6 months ago 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.

comment:3 Changed 6 months ago 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.

Note: See TracTickets for help on using tickets.