Why use Tor?
Transport Layer Security (TLS) already provides privacy by encrypting the data sent over a connection between a client and a server. An eavesdropper on the wire will not be able to read the data sent from your machine if the data is sent over a connection that uses TLS. Is this always enough?
Imagine you are trying to access a website that is banned in your country. You could potentially face time in prison for accessing these websites. It is not enough that the messages to the web server of the website are encrypted; you need to prevent any entity monitoring your network such as the Government or an ISP from seeing which servers your machine visits. What you desire is anonymity. Sometimes, you might want anonymity when privacy is not necessary. For example, a user might want to be anonymous from the web server of the site that they are visiting. In particular, they may want to prevent their search engine from creating a personalized profile of their search history which can be sold to advertisers. However, they might not care if the search requests themselves are private.
Would a Virtual Private Network (VPN) or a proxy server be enough to ensure anonymity? While these services do provide partial anonymity to their users from eavesdroppers and destination servers, the VPN or Proxy provider can still track the users’ traffic history. In other words, VPNs and Proxies provide limited anonymity against government entities since the VPN/Proxy provider can be subpoenaed into providing identities and IP addresses. Additionally, an attacker could compromise the VPN and leak its customer logs. Ultimately, Tor seeks to address these concerns by providing anonymity to its users without having to trust any centralized provider or authority.
What exactly is Tor?
Tor is an open source software project originally developed by the U.S. Navy to provide anonymous communication on the Internet. Tor is composed of an overlay network of volunteer relay nodes that implement the onion routing protocol, which uses multiple layers of encryption to conceal the origin of network requests. In this blog post, we will explain the mechanics of the onion routing network in detail, and discuss some attacks that have been performed to try and de-anonymize Tor users.
How does Tor work?
“Onions have layers. ̶O̶r̶g̶r̶e̶s̶ Tor packets have layers.” — Shrek
Suppose a user named Alice wants to communicate anonymously with her friend, Bob. To connect to this Tor network, Alice must download a Tor client, such as the Tor browser. Alice’s Tor client sends a request to a Tor Directory Server to get a unique circuit ID and the addresses of at least three Tor nodes. These Tor relay nodes will be used to form a circuit between the Tor client to the destination server. Before sending the packets, Alice’s Tor client has to encrypt the packets in a special way to protect her machine’s anonymity.
How does a Tor client encrypt the packets?
Using the Diffie-Hellman key exchange, Alice’s Tor client exchanges public encryption keys with each of the relay nodes in the circuit. After its name, “The Onion Router,” the Tor client will encrypt the data in successive layers like an onion starting with the innermost layer.
Starting at the innermost layer, Alice updates the packet’s header with the exit relay as the source address and Bob as the destination address, and then encrypts the packet. For the next layer, Alice sets the packet’s payload to the previous layer. Alice updates the packet’s header with the middle relay as the source and the exit relay as the destination, and then encrypts the entire packet with the blue key.
For the next two layers, Alice’s Tor client will continue this process in updating the packet header and payload. At each layer, Alice will encrypt the resulting packet with the destination relay node’s public encryption key. The resulting encrypted packet would be like Figure 2. It should be noted that each relay node can only decrypt its own layer, because Alice uses the particular node’s encryption key at that node’s layer.
How does the Tor client send packets?
After encrypting the packet in multiple layers, Alice’s Tor client sends the packet to the entry guard which is the first relay node in the circuit. The entry guard decrypts the outermost layer, because they have the red key. By reading the packet headers, the entry guard forwards the packet to the middle relay. For that circuit ID, the entry guard records that it receives packets from Alice and sends packets to the middle relay.
Similarly, the middle relay decrypts the next outermost layer with the green key and finds that the destination is the exit relay, to which it forwards the packet. Finally, the exit relay decrypts the next layer with the blue key and forwards the unencrypted (at the Tor protocol level) packet to the destination server.
How does the server send a packet response?
After the server receives a packet, it will likely need to send a response back. The server only knows that the packet came from the exit relay, so it sends the packet to the exit relay. When the exit relay receives the packet, it searches it’s local records for the circuit ID corresponding to the source of the request (Bob) and port number (multiple users may be communicating to Bob via that exit relay). The exit relay discovers that it should forward the packet to the middle relay based off the circuit ID. In the packet header, the exit relay sets the source IP address and TCP port to the exit relay and sets the destination to the middle relay. The exit relay sets the packet payload to its received packet and encrypts the payload with the Tor client’s public encryption key.
Both the middle relay and entry guard repeat this procedure of discovering who to forward the packet to, encrypting the payload, updating the packet header, and forwarding it. When Alice’s Tor client receives the packet, it’s encrypted with all three layers. Since Alice has the private decryption key corresponding to the public encryption key that the relay nodes used, she can unwrap all the packet layers to read Bob’s response.
How can Tor be used to create a hidden service?
For most of the Tor network, an eavesdropper would retrieve only encrypted packets. If an eavesdropper sniffs between the exit relay and the destination server, they would know that someone is trying to access that destination server using Tor. To mitigate this vulnerability, Tor introduced hidden services, which are destination servers existing entirely within the Tor network. Only Tor clients can access these hidden services, otherwise known as the “dark web”.
If an eavesdropper sniffs a packet going to a hidden service, they would not know the packet’s actual source and destination regardless of where they sniff the packet. These hidden services operate at the URLs ending with “.onion”. For example, Facebook’s public key, facebookcorewwwi, corresponds to https://facebookcorewwwi.onion/. Usually, these public keys are a nonsensical string of 16 random characters. Open source tools, like Shallot and Scallion, can generate keys starting with a certain prefix in a similar manner as Tor. Facebook used this approach to generate their vanity URL.
How do Tor clients find a hidden server?
Suppose Bob is a hidden server in the Tor network. Alice needs to be able to find Bob somehow, so Bob chooses three Tor nodes as introduction points. Bob establishes Tor circuits to each of these introduction points. Since these Tor circuits consist of three intermediary Tor nodes, eavesdroppers cannot determine that Bob is communicating with his introductory points.
For Alice to find Bob, she needs to find an introduction point. Bob stores the IP addresses of these introduction points along with his public key into a distributed database. Bob may advertise his public key online, and Alice would use Bob’s public key to retrieve his introduction points from the database.
How do Tor clients connect with the hidden server?
If everyone communicates with Bob over his introduction points, these introduction points would be overwhelmed with way too much traffic. Instead, Alice must establish a rendezvous point to meet with Bob. Alice randomly chooses a Tor node and asks it to act as a rendezvous point. In this request, Alice shares a one-time secret with the rendezvous point. To send this request, Alice forms a circuit to this rendezvous point with two intermediary Tor nodes, with the rendezvous point eventually forming the third intermediary Tor node.
Once this rendezvous point has been established, Alice asks the introduction point to introduce her to Bob. Alice forms an “introduce” message, which includes the rendezvous point and the shared secret. She then encrypts the message using Bob’s public key. She sends the message to the introduction point over a circuit, and the introduction point forwards the message to Bob over another circuit.
Only Bob can decrypt Alice’s message to discover where the rendezvous point is. Bob sends a message with the shared secret back to the rendezvous point. Since the rendezvous point received the same shared secret from Alice’s circuit and from Bob’s circuit, the rendezvous point establishes a connection between Alice’s circuit and Bob’s circuit. The connected circuit contains 6 intermediate Tor nodes: Two Tor nodes chosen by Alice; the rendezvous point; three Tor nodes chosen by Bob. This circuit between Alice and Bob’s hidden service is twice as long as a traditional Tor circuit. In exchange for this delay, Alice and Bob can communicate without anyone knowing where the packets originated from or are heading to.
Tor Security Vulnerabilities
Exit Node Sniffing
Tor users are only as anonymous as the application level protocols that they send data over. Some application protocols, such as POP3, SMTP, and basic HTTP, are not secure. If an eavesdropper sniffs packets between the exit node and the destination server, they won’t know the original source address of the packet, but they will be able to read the packet message. If the message is in plaintext, it may contain some identifying information, such as an email address or username.
The exit node itself might be untrustworthy. For example, researcher Dan Egerstad set up a Tor exit node and began to sniff all data going through his exit node. Soon, Egerstad began to pick up a lot of traffic coming from foreign embassies which had been using Tor to hide their sensitive diplomatic information from their host countries’ Internet networks. Unfortunately for these embassies, many employees were using unencrypted application protocols, allowing Egerstad to read their messages in plain text, giving him access to hundreds of diplomatic emails and passwords. This incident clearly highlights the fact that Tor’s encryption is only for anonymity, but does not guarantee that the data sent will be kept private.
Protocol/Side Channel Leaks
If users are not careful, not all traffic will go through the Tor proxy. For example, a browser might be incorrectly configured to only route HTTP traffic through a Tor proxy. In this case, when you visit a website, the browser will make a DNS request directly to a DNS server to get the website’s destination IP address. Afterwards, the browser will route all HTTP traffic between your machine and the web server through Tor’s darknet. This would leak which websites you’re visiting to the DNS provider, but not which requests you send/receive from that web server. A possible mitigation to such a leak is enabling your firewall to block port 53 which is used for making DNS requests, or using Tor only with the Tor Project’s official browser.
Suppose an eavesdropper can monitor the traffic between your Tor client and the guard node and between the exit node and the destination server. They may be able to match patterns in the incoming and outgoing traffic to determine that your client is communicating with the destination server. Certain patterns that the eavesdropper can observe include the timing of when packets are sent from your client and received by the server, and the volume of packets sent and received.
In 2013, a bomb threat email was sent anonymously using Guerrilla Mail to Harvard University, leading to a massive evacuation of the school. The threat turned out to be a hoax, and investigators began to look for the sender of the email. It turned out that the email request to Guerrilla Mail was sent from a Tor exit node. Using traffic analysis of Harvard’s monitored campus network, it was discovered that at the time the bomb hoax email was sent, the only user communicating with a Tor directory was Eldo Kim. When authorities went to Eldo, he confessed to being behind the hoax.
One way of mitigating such a traffic analysis attack would’ve been to use a busy public network, where the Tor user would have a short-lived IP address that would be harder to trace back to the user in real life. Another mitigation strategy would be to use a Tor bridge. Because Tor relays are publicly listed in the main Tor directory, an eavesdropper can see who within a network has been connecting to Tor. However, Tor bridges are special relays that are not publicly listed. Bridges must be requested from the Tor project and are only given out three at a time, preventing a malicious entity from finding out all the bridges available at a given time. Using a bridge helps obscure the fact that you are using Tor from eavesdroppers and can also circumvent Tor censorship by ISPs or governments.
Although Tor has been used to hide the activity of many questionable users such as drug traffickers and hackers, it must not be forgotten that Internet anonymity is essential in protecting our liberty. From journalists, to oppressed political dissidents, to just regular users who don’t want to be profiled by increasingly invasive Internet advertisers, anonymity is a must. We have seen how Tor provides this anonymity through a decentralized network of volunteer nodes which use Onion Routing. However, it should be noted that additional precautions should be taken by Tor users to avoid the several vulnerabilities that we mentioned above, especially if trying to remain anonymous against an extremely powerful eavesdropper such as a government entity.
In the end, we hope all those intending to use Tor remember: “With great ̶p̶o̶w̶e̶r̶ anonymity comes great responsibility.”
 “The Tor Project: Privacy & Freedom Online.” Tor Project | Anonymity Online, www.torproject.org/.
 “Tor Hidden Services — Computerphile”. YouTube, Uploaded by Computerphile, 9 June 2017. https://www.youtube.com/watch?v=lVcbq_a5N9I
 “How Tor Works (The Onion Router)”. YouTube, Uploaded by Hussein Nasser, 29 Nov 2017. https://www.youtube.com/watch?v=gIkzx7-s2RU
 “Tor: Onion Service Protocol”, 2019.www.torproject.org/docs/onion-services. http://2019.www.torproject.org/docs/onion-services
 Gray, Patrick. “Embassy Hacker’ Dan Egerstad and the Tor Network.” ComputerWeekly.com, ComputerWeekly.com, 3 Dec. 2007, www.computerweekly.com/news/2240022106/Embassy-hacker-Dan-Egerstad-and-the-Tor-network.
 Dingledine, Roger, et al. “Tor: The Second-Generation Onion Router.” Jan. 2004, doi:10.21236/ada465464.
 Thomson, Iain. “Dark Web Doesn’t Exist, Says Tor’s Dingledine. And Folks Use Network for Privacy, Not Crime.” • The Register, The Register, 11 Feb. 2018, www.theregister.co.uk/2017/07/29/tor_dark_web/.
 “Onion Routing — Computerphile”. YouTube, Uploaded by Computerphile, 31 May 2017. https://www.youtube.com/watch?v=QRYzre4bf7I
 “[Tor-Talk] Facebook Brute Forcing Hidden Services”. Lists.Torproject.Org, 2020, https://lists.torproject.org/pipermail/tor-talk/2014-October/035413.html.