5

According to robertheaton.com:

When a Tor client constructs a circuit, it negotiates TLS sessions with each of the nodes it has chosen for its circuit using the nodes’ TLS certificates and public keys. The outcome of each TLS session negotiation is a symmetric encryption key, known only to the client and the node.

SSL/TLS alone (without a PKI) cannot protect against active MITM attacks, and thus (it seems like) someone able to intercept the client's outgoing traffic could gain the symmetric key for each Tor relay node.

How does Tor prevent this from happening? Is there some certificate authority in charge of verifying and signing relay nodes' certificates?

  • 2
    Hi ATLief, welcome to the site! I think your question is being misunderstood: you say "SSL/TLS alone provides no protection against MITM attacks" and I was about to comment on that (because "of course it does", I thought) but then read further and realized what you meant: without the CA system, it doesn't prevent MITM. No key exchange method can solve the key distribution problem, everything needs out of band exchange of key material. You might want to edit your question to be more clear on that. – Luc Aug 13 at 13:08
2

The Tor Project hosts some bootstrapping servers called directory servers. They contain a list (a directory) with information about all Tor relays currently online. This info about each relay includes the public key. The directory is signed with one of the directory keys[1]. Those keys are distributed along with your copy of the Tor client[2].

Therefore, the answer to your question is: by having a trusted third party (similar to a certificate authority). Tor relays (called onion routers in the paper) upload their info to the directory periodically[3]. When a client connects to their guard node, they check that the connection is encrypted with the right key, as listed in the directory. Then, when proxying traffic to the middle node (between the guard and exit node), they setup an encrypted connection to that node, proxying through the guard, and checking again that the right key is used (instead of a MITM key) using the directory. Same goes for the final (exit) node.

Source: https://www.onion-router.net/Publications/tor-design.pdf

[1] "Each onion router maintains a long-term identity key and a short-term onion key. The identity key is used to sign TLS certificates, to sign the OR’s router descriptor (a summary of its keys, address, bandwidth, exit policy, and so on), and (by directory servers) to sign directories."

[2] "Client software is pre-loaded with a list of the directory servers and their keys, to bootstrap each client’s view of the network."

[3] "Tor uses a small group of redundant, well-known onion routers to track changes in network topology and node state,including keys and exit policies. Each such directory server acts as an HTTP server, so clients can fetch current network state and router lists, and so other ORs can upload state information."

2

In general, SSL/TLS does offer MITM protection. It encrypts data before it leaves your computer that only the endpoint can decrypt and vice versa. A MITM attack is ineffective against encrypted TLS connections because even if you intercept the public keys that the endpoints exchange, it still does not know their private keys.

As for a Tor, it is not encrypting your data at the Node level. The data is encrypted by a handshake between your endpoints so it can't be altered in transit. What Tor is encrypting with those TLS connections is routing instructions. The computer sending data establishes a packet of delivery instructions that is protected by layers of encryption. Basically Node A decrypted the 1st layer, which tells it who Node B is, but everything else is still encrypted. Node B runs another layer of decryption to find who Node C is and repeats the process until the endpoint is reached.

So, the only data any Node has access to is the next Node in the chain. Everything else remains unreadable. Since there is no unencrypted data to manipulate, a CA is pretty irrelevant. (That said, Luc's answer shows that Tor maintains its own CA just to be sure.)

  • When the client requests the node's public key over a compromised network, the attacker can substitute it with their own public key (for which they know the private key), and then decrypt and modify any communication before relaying it to the node. – ATLief Aug 12 at 19:53
  • If the attacker does this for each node, then they can decrypt and track communication between the client and the end server. – ATLief Aug 12 at 19:57
  • That is a common misconception, but it does not work like that. Since both machines contribute a private key to encryption method, a MITM can't actually intercept enough info to know how to decrypt it. See: security.stackexchange.com/questions/45963/… for an easy to understand explaination. – Nosajimiki Aug 12 at 20:24
  • 1
    I feel like there's a misunderstanding here. When I say MITM I'm talking about someone who can not only see sent data but also modify or completely block it. However the key exchange works (I'm somewhat familiar with D-H key exchange but that's irrelevant), the attacker can impersonate the node and perform it with the client and with the node separately, unless the client has some way to verify the identity of the server it's communicating with. – ATLief Aug 12 at 21:57
  • Yes, a node can see the traffic, and even redirect it, but a node can not decrypt it. If you can't decrypt it, you can't put any data of your own into the data stream without completely corrupting the output (this can cause a 500 error, but not take control of anything). If you try to send the Tor user back your own handshake request, then the Tor user will check your request against the CA of the domain he tried to visit and their browser will see that your handshake is forged, because you may be a MITM between the website and user, but not between the user and the website's CA. – Nosajimiki Aug 13 at 14:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.