Why can't a modified guard node compromise the network?

Question

This is a newbie and probably a lame question but it popped up while I was reading the design doc: https://svn-archive.torproject.org/svn/projects/design-paper/tor-design.pdf

If theoretically someone runs a modified onion relay (OR) that does not really extend the circuit (section 4.2 - Constructing a circuit) but instead computes the next key and responds as it has extended the circuit as a real OR does. It seems that the user (Alice) does not make direct connections to the next nodes in the circuit but relies only on the entry node to extend it. Once she make a request through that OR, the OR will know details about her and the final endpoint and thus compromise TOR.

What does TOR to ensure that traffic is actually relayed through multiple nodes and not just passing through a single node that seemingly act as a normal node?

Answer 1

These types of attacks aren't possible in Tor because of Tor's ntor handshake and Tor's authenticated directory documents generated by the directory authorities.

Tor clients download a trusted (and signed) list of all relays generated by Tor's directory authorities. This list of relays is part of the network consensus document. Each relay in this list also has a server descriptor document referenced by this consensus. Clients generally download a flavour of these documents called the microdescriptor consensus and microdescriptors. Each microdescriptor contains the relay's "(ntor) onion key", a curve25519 public key known only by the relay.

When the client extends a circuit to a specific relay, it uses the ntor protocol and the relay's onion key from the relay's microdescriptor, which allows the client to ensure that it's communicating with the intended relay, even though the client is not connecting to that relay directly. Since no other relay knows the private key for the intended relay's onion key, the client can detect if a relay was attempting to pull off an attack like the one you described.

If you aren't familiar with these types of key exchange protocols, you may want to look into the Diffie–Hellman key exchange. This same idea is also used by HTTPS to ensure that your browser is communicating with the website it intends to visit.