How does Tor protect against fake entry nodes / total redirection?

Question

There is much material on how to protect yourself from malicious exit nodes, especially by using SSL and minimizing the leakage of identifying information (user-agent, screen size, etc.).

However, I was wondering why an attacker could not just setup a bunch of fake Tor entry nodes, and redirect your outgoing connections to them (assuming you must route all data through their network). They could even virtualize or fake the whole Tor network with ease.

What measures does Tor have against such attacks, and what can a user do against it?

Are there e.g. a list of hardcoded entry servers with known public keys? If so, how do I know that those priviliged servers are not operated by the NSA or the Chinese or whoever? They could be a) compromized from day one, or b) someone could have manipulated torproject.org when I downloaded the software, and replaced the server list and checksums.

(I hope this doesn't sound too paranoid. I got this idea when I was working a large (US-)government-run facility, and noticed how pervasive their computer security measures were (probably with good reason). If I were a dissident or had something to hide, they could have easily 'rabbit-holed' my entire network. I guess this is a much more pressing problem in other countries.)

score 10 · Answer 1 · edited Oct 20 '18 at 07:06

[Is there] a list of hardcoded entry servers with known public keys

Every server is capable of acting as an entry as every packet is either a packet to be forwarded or an exiting packet. This is achieved by encrypting each packet to a specific node. Each node has a public key listed which is used to negotiate a session key with that node.

The principle behind this is called onion routing. The fine details are expansive, so reading the article is best. The summary is that the packet is encrypted for the last node, then that is encrypted for the 2nd to last node, and so on.

Without controlling every node in the chain, linking the original sender to the raw packet would require traffic analysis.

Since the public key of a Tor node is published, no node in the chain can redirect your traffic in a meaningful way. It must pass to a node that is capable of decrypting it. A symmetric key is derived using a signed Diffie-Hellman exchange, and thus will not be accepted from a node that doesn't possess the matching private key for the published public key. That key exchange and layered encryption is what protects you from malicious nodes removing downstream nodes from the chain.

I understand. But what prevents somebody from impersonating the directory node, and any nodes I directly connect to, and then emulating the tor network behind it (the complete cascade including exit nodes)? I would think that to prevent that, it would be neccessary to know public keys of certain nodes beforehand (at least the main directory and some exit nodes). I can't find any mention of something like that however. — jdm, Dec 04 '12 at 19:07
@jdm Further readings that help with these questions: https://www.torproject.org/docs/faq.html.en#KeyManagement https://www.torproject.org/docs/faq.html.en#EntryGuards. Initially trusting a key, however, is always one of the great weaknesses. — Jeff Ferland, Dec 04 '12 at 19:13

score 5 · Answer 2 · edited Mar 17 '17 at 13:21

Are there e.g. a list of hardcoded entry servers with known public keys?

You can browse Tor code, just download latest tar ball.

There are 10 authorities directory hardcoded into Tor, each element of char array contain public key, e.g. moria1: 9695 DFC3 5FFE B861 329B 9F1A B04C 4639 7020 CE31.

./src/or/config.c:

static void
add_default_trusted_dir_authorities(dirinfo_type_t type)
{
  int i;
  const char *authorities[] = {
    "moria1 orport=9101 no-v2 "
      "v3ident=D586D18309DED4CD6D57C18FDB97EFA96D330566 "
      "128.31.0.39:9131 9695 DFC3 5FFE B861 329B 9F1A B04C 4639 7020 CE31",
    "tor26 v1 orport=443 v3ident=14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 "
      "86.59.21.38:80 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D",
    "dizum orport=443 v3ident=E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58 "
      "194.109.206.212:80 7EA6 EAD6 FD83 083C 538F 4403 8BBF A077 587D D755",
    "Tonga orport=443 bridge no-v2 82.94.251.203:80 "
      "4A0C CD2D DC79 9508 3D73 F5D6 6710 0C8A 5831 F16D",
    "turtles orport=9090 no-v2 "
      "v3ident=27B6B5996C426270A5C95488AA5BCEB6BCC86956 "
      "76.73.17.194:9030 F397 038A DC51 3361 35E7 B80B D99C A384 4360 292B",
    "gabelmoo orport=443 no-v2 "
      "v3ident=ED03BB616EB2F60BEC80151114BB25CEF515B226 "
      "212.112.245.170:80 F204 4413 DAC2 E02E 3D6B CF47 35A1 9BCA 1DE9 7281",
    "dannenberg orport=443 no-v2 "
      "v3ident=585769C78764D58426B8B52B6651A5A71137189A "
      "193.23.244.244:80 7BE6 83E6 5D48 1413 21C5 ED92 F075 C553 64AC 7123",
    "urras orport=80 no-v2 v3ident=80550987E1D626E3EBA5E5E75A458DE0626D088C "
      "208.83.223.34:443 0AD3 FA88 4D18 F89E EA2D 89C0 1937 9E0E 7FD9 4417",
    "maatuska orport=80 no-v2 "
      "v3ident=49015F787433103580E3B66A1707A00E60F2D15B "
      "171.25.193.9:443 BD6A 8292 55CB 08E6 6FBE 7D37 4836 3586 E46B 3810",
    "Faravahar orport=443 no-v2 "
      "v3ident=EFCBE720AB3A82B99F9E953CD5BF50F7EEFC7B97 "
      "154.35.32.5:80 CF6D 0AAF B385 BE71 B8E1 11FC 5CFF 4B47 9237 33BC",
    NULL
  };

Attacker can't do anything with entry nodes, cause, e.g. HTTP-requests have 3 layers of encryption on entry to the Tor-network.

onion-encryption

Attacker better setup huge amount of exits, to sniff outgoing traffic.

Incoming traffic doesn't contain anything except crypto-text.

See my question: Attack on Tor with stolen private keys of main nodes

How does Tor protect against fake entry nodes / total redirection?

2 Answers2

Linked