I had a question about Tor and the anonymity status of a fully decrypted packet that leaves a Tor exit node. My high-level understanding is that prior to a packet traversing the Tor network, a Tor client chooses 3 Tor relay nodes for the packet to go through and encrypts a packet with the exit node's public key, then encrypts the encrypted packet with a middle node's public key, then does it again with the entry node's public key. And each node decrypts the packet as the packet arrives to it.

This is the part where I don't understand how this process achieves anonymity. After the Tor exit node fully decrypts a packet, that packet will be a normal packet so it should have a source address and a destination address. Therefore anyone who sniffs a packet after it leaves a Tor exit node will know what the source address and what the destination address is, right?

There must be something I don't understand about the The Onion Routing process and I was hoping somebody would help me with understanding how is the packet anonymous after it leaves the exit node. After all since it has been fully decrypted, its source and address fields can be sniffed just like any other packet?

  • 2
    Onion routing is set up such that the nodes aren't aware of which node the encapsulated packet is going to past the next hop., so the exit node will not know which node past the first one the response is supposed to go to. Client-server cryptography is needed to make sure content in the connection doesn't get sniffed by the exit node.
    – user
    Mar 13 '20 at 18:23
  • 1
    I've updated your title to be a bit more specific about to your question. If you don't like my change feel free to roll it back or change it more yourself. Also, welcome! Mar 13 '20 at 19:26

The trick is that it's the payload of the packet that's encapsulated, not the whole TCP packet. Therefore, when the packet leaves the tor exit node unencrypted, it is sent with the return address of the tor exit node. So a service will know that a packet came from a tor exit node and is being anonymized, but unless there's information in the packet payload itself to identify you (such as login information, session coookies, or some protocol that includes your IP in the payload), the endpoint/service doesn't know the originator's IP.

Furthermore, the tor exit node tracks the session, so it can return the packet to you, but it's only tracking the session from the tor middle node to the service/website being accessed. So an exit node will be able to see the service/website being accessed, but won't know the originator.

The middle node in turn is only tracking the session between the entry node and the exit node. So it knows neither the originator nor the destination.

The entry node knows the originator's IP address, but doesn't know the destination.

The reason there are three nodes instead of two is to defend against someone who's compromised either the entry or the exit node from being able to sniff traffic going into/out of the other node and make reasonable conjectures on which originator traffic correlates with which destination traffic based on packet size and timing. With three nodes, the entry node doesn't know which exit node is used and vice versa.


How Tor protects anonymity

The anonymity happens because while the Tor exit node knows the final packet and its destination, it doesn't know where the packet originated from. Similarly, the entry node knows where the packet originated from, but it doesn't know the packet contents or where it is destined for. As a result (theoretically), none of the nodes have the full details of the packet.

To further clarify, the exit node doesn't know where the packet originated from: only the location of the middle node. It receives the response from the destination server, encrypts it, and then returns it to the middle node. The middle node knows the location of the entry node and exit node but not any of the contents. Similarly, it encrypts the encrypted data it received from the exit node, encrypts it again, and passes it off to the entry node. The entry node encrypts it once more and then returns it to the original client, which decrypts all the layers.

As a result of this process none of the nodes have enough data to connect a request to any end client. However, if communicating with a server on the "regular" internet, the traffic does have to go from the exit node to the destination server via standard HTTP. Therefore, for instance, if you were to request a document via HTTP while using TOR as a proxy, a MitM between the exit node and your destination server would be able to sniff your request and the server's response - it just wouldn't be possible to connect that request to your machine.

But it's not perfect

Note that this is not a fool proof system and de-anonymization on the Tor network is possible. The "simplest" way to do this is simply by flooding the Tor network with malicious nodes. If you have enough nodes on the network that by chance nodes you control are selected as both the entry and exit nodes for a single request, then it is quite possible to connect the dots and figure out all data about the request, effectively de-anonymizing the Tor user. Attacks like this seem to have been used by law enforcement to catch criminals in real life. Note though that this is somewhat speculative, because apparently the FBI doesn't like to reveal the full details on how they have (occasionally) managed to de-anonymize Tor traffic.

  • 1
    Do you have a source for that last paragraph?
    – user
    Mar 13 '20 at 18:57
  • 1
    @user to be fair it is a bit speculative because law enforcement has no interest in explaining how they might de-anonymize traffic on Tor. Here is one of many articles that come to the same conclusion on de-anonymization without being able to state for certain what happened. forbes.com/sites/kashmirhill/2014/11/07/… Mar 13 '20 at 19:06
  • Well, hopefully the Tor update mentioned in the article managed to stop that attack then.
    – user
    Mar 13 '20 at 19:10
  • @user I'm not a Tor expert but I can't say for sure. To some extent it is the equivalent of a 50%+1 attack on a blockchain network, which is an inherent vulnerability in the protocol that cannot be easily fixed with software. If someone controls enough Tor nodes that they can control all nodes involved in a request, then there really isn't much a client can do to protect themselves. Obviously the network can try to mitigate this risk in various ways (add extra hops, kick suspicious nodes, require broad geographic distribution, etc...), but the risk itself will always be there. Mar 13 '20 at 19:14
  • 1
    In addition to attacking the Tor network, there's also side channel attacks such as browser fingerprinting. Being able to track your browser identity implies that your anonymity may compromised if you ever use the same browser without Tor. The Tor Browser attempts to resist such fingerprinting.
    – Fax
    Mar 14 '20 at 15:37

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