The Tor network in the research: how it works, proven attacks, and the limits of its anonymity

Tor is the most widely used anonymity network in the world, and also one of the most heavily studied security systems. Since its design paper came out in 2004, hundreds of academic papers have tried to break it, measure it, and improve it. The result is a fairly clear picture: Tor is very good against some threats, and was never designed to stop others.

This post summarizes what research has found about Tor: how it works, which attacks have actually been demonstrated, real incidents on the network, and what it means for developers who run services or just want to understand its limits. It complements OPSEC for developers: Tor is one tool, not a substitute for OPSEC discipline.

How it works: onion routing

Onion routing came out of the US Naval Research Laboratory in the mid-1990s (Goldschlag, Reed, and Syverson, Hiding Routing Information, 1996). Tor is its second generation, described by Dingledine, Mathewson, and Syverson in Tor: The Second-Generation Onion Router (USENIX Security 2004).

A Tor client builds a circuit through three relays chosen at random, weighted by bandwidth:

The client negotiates a separate key with each relay, then wraps the data in three layers of encryption. Each relay peels off exactly one layer, like an onion. Data travels in fixed-size cells (512 bytes) so message sizes aren't directly visible. The set of legitimate relays is decided by a small group of directory authorities that publish a joint consensus every hour.

The key point: no single relay knows both the user and the destination. But Tor's design states openly, from the start, that it does not protect against an observer who can see both ends of a circuit. Tor chose low latency so it could be used for the web; the consequence is that timing and volume patterns remain visible. Almost every attack below starts from that design boundary.

Traffic correlation attacks

If an attacker can watch traffic entering the guard and leaving the exit, they only need to match the timing and size patterns. No encryption needs to be broken.

• Murdoch and Danezis (Low-Cost Traffic Analysis of Tor, IEEE S&P 2005) showed that even an attacker running a single ordinary relay could estimate which relays a circuit used, by loading other relays and watching the latency change.
• Johnson et al. (Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries, ACM CCS 2013) simulated long-term Tor usage. Their conclusion: an attacker running relays with bandwidth comparable to a large volunteer could deanonymize about 80% of users within six months of regular use. An adversary at the level of an Autonomous System (AS) or Internet Exchange Point is even more dangerous, since its position on internet paths means it doesn't need to run relays at all.
• Sun et al. (RAPTOR: Routing Attacks on Privacy in Tor, USENIX Security 2015) showed that asymmetric internet routing raises the chance that an AS sees at least one direction of traffic at both ends, and that BGP hijacks can deliberately route guard traffic through the attacker.
• Nasr, Bahramali, and Houmansadr (DeepCorr, ACM CCS 2018) applied deep learning to flow correlation. With only about 900 packets per flow, they reached roughly 96% accuracy, against roughly 4% for the previous method in the same setting.

This is why Tor uses persistent guards. Øverlier and Syverson (Locating Hidden Servers, IEEE S&P 2006) showed that if the first relay is re-chosen for every circuit, the attacker will be picked sooner or later. With one guard used for months, that risk doesn't disappear, but it no longer grows every time a new circuit is built.

Website fingerprinting

Website fingerprinting is cheaper than correlation: the attacker only needs to see the user's side, such as an ISP or an office Wi-Fi network. Each site produces a distinctive pattern in the order, direction, and number of cells it loads, and that pattern can be recognized with machine learning.

• Panchenko et al. (WPES 2011) were among the first to show this attack is realistic against Tor.
• Juarez et al. (A Critical Evaluation of Website Fingerprinting Attacks, ACM CCS 2014) provided an important correction: many earlier results relied on assumptions that favored the attacker, such as users opening one tab at a time and visiting only sites from a small list. In a realistic open world, the base rate fallacy makes false alarms a serious problem.
• Sirinam et al. (Deep Fingerprinting, ACM CCS 2018) used a CNN and reached over 98% accuracy on undefended Tor traffic in a closed world. The WTF-PAD padding defense could still be beaten with over 90% accuracy, while Walkie-Talkie held top-1 accuracy to about 49.7%.

This research pushed Tor to add a circuit padding framework so defenses like these can be deployed without changing the core protocol. The problem isn't solved: padding costs bandwidth, and each new defense tends to be followed by a stronger attack model.

Malicious relays on the real network

Tor is run by volunteers, so anyone can add a relay. The research and incidents below show what happens when some of those volunteers turn out to be attackers.

• Spoiled Onions (2014). Winter et al. (Spoiled Onions: Exposing Malicious Tor Exit Relays, PETS 2014) built an exit scanner called exitmap and found 65 malicious or misconfigured exit relays, including some performing HTTPS man-in-the-middle and SSL stripping attacks. Most were subsequently given the BadExit flag.
• The "relay early" attack (2014). On July 30, 2014, the Tor Project announced that about 115 non-exit relays that had joined since January 30, 2014 were running a Sybil attack combined with traffic confirmation: they injected a hidden signal through sequences of RELAY and RELAY_EARLY commands. The attack appeared to target onion service users and operators. The relays were removed on July 4, 2014 and the flaw was fixed (CVE-2014-5117).
• SSL stripping exits (2020). Independent researcher nusenu reported a single actor who, at its May 2020 peak, controlled more than 23% of the network's entire exit capacity. Those exits downgraded HTTPS to HTTP on Bitcoin mixer sites and swapped the destination wallet addresses.
• KAX17 (2021). nusenu also found a group that had been running relays since around 2017, mostly guards and middles, peaking at more than 900 relays at once. Non-exit relays can't modify traffic, but their positions suit deanonymization. The Tor Project removed several hundred relays believed to belong to the group in November 2021. There is no public evidence that deanonymization was actually carried out, but the capability was there.

Two lessons. First, HTTPS is mandatory even inside Tor: the 2020 exit attack only worked on sites still reachable over HTTP. Second, finding malicious relays is ongoing work, and most of it is done by researchers and volunteers, not by automated mechanisms.

Onion services

Onion services (formerly hidden services) flip the direction of protection: the server is hidden too. Client and server each build a circuit to a meeting point (the rendezvous point), so neither learns the other's IP address.

Biryukov, Pustogarov, and Weinmann (Trawling for Tor Hidden Services, IEEE S&P 2013) showed that the old (v2) design leaked: by running relays that became HSDirs, an attacker could harvest nearly every onion address in about two days, measure their popularity, and even block specific services. Version 3 onion services, introduced in Tor 0.3.2 (late 2017), fixed this with ed25519 cryptography and key blinding: an HSDir can no longer learn the onion address from the descriptor it stores. Addresses also grew to 56 characters. Support for v2 ended in 2021.

A newer threat is denial of service against onion services. Since the server never sees client IP addresses, IP-based rate limits don't apply. Since Tor 0.4.8 (2023), operators can enable a proof-of-work defense: it stays dormant under normal conditions, but under attack clients must solve increasingly hard computational puzzles before connecting.

HiddenServiceDir /var/lib/tor/site/
HiddenServicePort 80 127.0.0.1:8080
HiddenServicePoWDefensesEnabled 1

Censorship and pluggable transports

For many users the main threat isn't deanonymization but blocking. The relay list is public, so a censor can block all of it easily. Tor's answer is bridges (unpublished relays) and pluggable transports that disguise Tor traffic.

• Winter and Lindskog (How the Great Firewall of China is Blocking Tor, FOCI 2012) found that the Great Firewall uses active probing: when it sees a suspicious connection, the censor connects to the server itself to check whether it's a Tor bridge, then blocks it.
• obfs4 makes traffic look like random bytes and doesn't respond to probes that lack the right secret.
• meek (Fifield et al., Blocking-resistant communication through domain fronting, PETS 2015) hides traffic behind large CDNs, so blocking it means blocking popular services. Many CDNs later shut down domain fronting.
• Snowflake (Bocovich et al., USENIX Security 2024) uses thousands of short-lived WebRTC proxies run by volunteers from their browsers. Because the proxy pool keeps changing, a censor struggles to enumerate and block them one by one.

Deanonymization that doesn't break Tor

The most publicized deanonymization cases rarely broke the Tor protocol. What got exploited was usually the layer above it:

• Browser bugs. In 2013, the FBI used a Firefox exploit (CVE-2013-1690) against visitors to sites hosted by Freedom Hosting. The payload sent the real IP address to a server outside Tor. The same approach was used in the Playpen case in 2015.
• Applications that leak IPs. Le Blond et al. (One Bad Apple Spoils the Bunch, LEET 2011) showed that BitTorrent over Tor leaks the real IP address inside its protocol, and that the leak can be used to link other streams from the same user.
• Operational mistakes. The operator of Silk Road was traced mainly through posts on public forums and an account using his real identity, not through a weakness in Tor.

Tor Browser exists precisely to close gaps like these: a uniform configuration so all its users look alike, first-party isolation, and security levels that can disable JavaScript. Running an ordinary application through a Tor proxy doesn't give the same protection.

What it means for developers

Don't block Tor without a clear reason

Tor is used by journalists, researchers, people in censored countries, and people who simply don't want to be tracked. Blocking every exit relay blocks them too. If there's abuse, limit the risky actions (mass sign-ups, repeated login attempts) with rate limits or a CAPTCHA, not all read access. The official exit list is available at https://check.torproject.org/torbulkexitlist if you need special handling.

Offer an onion address

An ordinary site can offer an onion address so Tor users never need to leave through an exit relay at all. That removes the malicious-exit risk and reduces load on the network. The Onion-Location header tells Tor Browser that an onion version exists:

Onion-Location: http://youronionaddress56characterslong.onion/

Don't make Tor your only layer

Traffic correlation research shows that an attacker who can see both ends will eventually win. Tor raises the cost of surveillance significantly, but highly sensitive data still needs end-to-end encryption, consistent OPSEC habits, and an honest threat model about who might be watching the network.

Conclusion

Two decades of research paint a consistent picture. Tor's cryptography is rarely the weak point. Its limits come from deliberate design decisions: low latency keeps traffic correlation and fingerprinting possible, a volunteer network leaves room for malicious relays, and the applications on top often leak more than the network itself. At the same time, that research produced real improvements: persistent guards, v3 onion services, circuit padding, proof-of-work defenses, and Snowflake. For developers the lessons are practical: require HTTPS, consider an onion address, don't block Tor indiscriminately, and remember that network anonymity is only one part of security.

References

• Goldschlag, D., Reed, M., & Syverson, P. (1996). Hiding Routing Information. Information Hiding Workshop.
• Dingledine, R., Mathewson, N., & Syverson, P. (2004). Tor: The Second-Generation Onion Router. USENIX Security Symposium.
• Murdoch, S. J., & Danezis, G. (2005). Low-Cost Traffic Analysis of Tor. IEEE Symposium on Security and Privacy.
• Øverlier, L., & Syverson, P. (2006). Locating Hidden Servers. IEEE Symposium on Security and Privacy.
• Le Blond, S., et al. (2011). One Bad Apple Spoils the Bunch: Exploiting P2P Applications to Trace and Profile Tor Users. USENIX LEET.
• Winter, P., & Lindskog, S. (2012). How the Great Firewall of China is Blocking Tor. USENIX FOCI.
• Biryukov, A., Pustogarov, I., & Weinmann, R.-P. (2013). Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization. IEEE Symposium on Security and Privacy.
• Johnson, A., Wacek, C., Jansen, R., Sherr, M., & Syverson, P. (2013). Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries. ACM CCS.
• Juarez, M., et al. (2014). A Critical Evaluation of Website Fingerprinting Attacks. ACM CCS.
• Winter, P., et al. (2014). Spoiled Onions: Exposing Malicious Tor Exit Relays. Privacy Enhancing Technologies Symposium.
• Tor Project (2014). Tor security advisory: "relay early" traffic confirmation attack.
• Fifield, D., et al. (2015). Blocking-resistant communication through domain fronting. Privacy Enhancing Technologies Symposium.
• Sun, Y., et al. (2015). RAPTOR: Routing Attacks on Privacy in Tor. USENIX Security Symposium.
• Nasr, M., Bahramali, A., & Houmansadr, A. (2018). DeepCorr: Strong Flow Correlation Attacks on Tor Using Deep Learning. ACM CCS.
• Sirinam, P., Imani, M., Juarez, M., & Wright, M. (2018). Deep Fingerprinting: Undermining Website Fingerprinting Defenses with Deep Learning. ACM CCS.
• Tor Project (2023). Introducing Proof-of-Work Defense for Onion Services.
• Bocovich, C., Breault, A., Fifield, D., Serene, & Wang, X. (2024). Snowflake, a censorship circumvention system using temporary WebRTC proxies. USENIX Security Symposium.