A
Atindra Girish
Guest
In the third part of this series we covered the architecture of TOR, the onion routing, circuits and hidden services, and how TOR gave birth to the dark web. If you haven’t read the last part I would recommend starting there before diving into this one.
https://hackernoon.com/how-tor-hide...es-down-the-rabbit-hole-part-3?embedable=true
Now that we have a solid understanding of the architecture, it’s time to answer the critical question.
Does TOR provide 100% anonymity? Does it truly make you invisible?
In this part we look into the threat model of TOR, what it can and cannot protect you from, while walking through some real world case studies.
TOR is your best shot at anonymity and privacy, but it still won’t guarantee 100% anonymity or privacy. There are various reasons for this, but the most common reason people get unmasked while using TOR is not a flaw in the architecture, it’s human behaviour. In other words TOR cannot protect you against your own opsec mistakes. The other reasons are the inherent loopholes baked into the architecture itself.
TOR was built in the 1990s and the assumptions its threat model was built on look very different compared to how the modern internet works today. TOR is still improving but most of those early assumptions have become the very limitations that define what TOR can and cannot protect you against.
For example the TOR specification clearly states that it cannot protect you against global passive adversaries. In TOR’s early years this was a purely hypothetical threat. It’s still largely academic but most of the attacks a global passive adversary would theoretically perform are becoming increasingly feasible.
To understand this better let’s look at what TOR cannot protect you against, in other words TOR’s threat model.
Threat Model: What TOR Cannot Protect You Against
It’s clear from the architecture that TOR can effectively protect you against external adversaries doing passive monitoring. By passive I mean attacks where the adversary is not actively manipulating anything or hands on exploiting vulnerabilities, they are simply observing the network, doing things like traffic confirmation, traffic analysis, time correlation and so on. More on these shortly.
The multi layered onion encryption, the mixed traffic stream and the fact that there are hundreds of thousands of relays globally distributed, each handling multiple users simultaneously, makes it practically impossible for an external adversary to narrow down and unmask a specific user.
Remember how I said in the last part that you don’t have to worry too much about someone monitoring the entry node? This is exactly where that comes into play.
Internal Threats and External Threats
Before going further it’s important to note that while TOR has its own architectural strengths and weaknesses that contribute to its threat model, your own actions and surroundings also feed into it as external factors. So the threat model is not the same for every user, it shifts depending on who you are and what you are doing. This is not just about TOR’s threat model in isolation, it’s about the threat model of each individual user and how both pieces fit together.
Internal threats are the inherent loopholes in the design itself, the things users have little to no control over.
External threats are the behaviour, surroundings and environment of the user, things that differ from person to person and directly contribute to their personal threat model. Users have total control over this but TOR doesn’t.
With that distinction made, let’s look at where TOR actually falls short.
Internal Threats
An external attacker doing passive monitoring is not the real problem. The real problem is the threat that exists within the network itself. Remember every relay is run by a random volunteer whose true identity we will never know. They could be law enforcement, they could be a state sponsored attacker, or they could be people genuinely trying to keep TOR safe. The multi layer encryption and mixed traffic stream applies fully to external threats but only partially to the relays themselves, because the entry node can see who you are even if it can’t decrypt the data passing through the other nodes, the exit node knows where you want to go but has no idea who you are, and the middle node is effectively no man’s land, knowing nothing unless a leaky pipe topology is in play in which case it acts as the exit node.
It still seems hard to narrow down and unmask a user because each node is independent and globally distributed.
But in a hypothetical situation, what exactly would an attacker need to unmask you?
The entry node knows who you are. The middle node knows nothing. The exit node knows where you want to go.
Remove the middle node from the picture and you have the exact combination needed to unmask a user. In other words an entity that controls both the entry node and the exit node can use passive monitoring or active attacks like packet injection to correlate the two ends and unmask the user, because they know who you are on one end and where you are going on the other.
But there is still a limitation. The exit node doesn’t know the actual identity of the user so there is no straightforward way to confirm that the traffic the attacker is watching at the exit node belongs to the same user they are watching at the entry node. This is where traffic confirmation attacks come in.
Adversaries use passive techniques like traffic confirmation and time correlation to verify they are watching the right person. This involves monitoring the rhythm of the traffic. A simple example would be an attacker logging the exact time a request arrives at the entry node and comparing it with the time traffic exits from the exit node. If the timing matches, the attacker can confirm the target with a high degree of confidence. This works because TOR is built for low latency applications, meaning everything happens in near real time with very little delay between hops.
This reminds me of a perfect real world example. Let me take you back to December 2013.
Example 1: Time Correlation — Harvard bomb threat
A Harvard student sent a bomb threat to the university to try and postpone his exams. He used TOR and the temporary email service Guerrilla Mail to hide his identity. Using TOR was a smart choice in theory, but how he used it was a different story. From the email itself the feds and Harvard only had the TOR exit node to work with, which is effectively a dead end. But when they investigated Harvard’s internal network they found that only one person had been accessing TOR on the entire network at the time the email was sent, and the timestamps matched perfectly. That made him the prime suspect. After that all the feds needed was an interrogation and he was already confessing. This is not an isolated case, there are similar stories of students sending bomb threats through TOR only to be caught because of their own opsec mistakes.
It’s important to remember that time correlation and other passive attacks are not concrete evidence on their own. In the above case if the student hadn’t confessed it would have been a much harder road for the feds. These attacks narrow the field and give investigators somewhere to look, but they are not enough to jump to a conclusion on their own.
External Factors
There are external factors that feed into your specific threat model too, and some of them mirror the internal ones. Being unique is one of the biggest. If it’s unusual for anyone on your local network to be accessing TOR then you draw attention just by using it, like the Harvard student did. The anomaly itself becomes the lead.
**But how can someone even tell you are using TOR in the first place?
As I mentioned before, TOR relays are publicly listed. You can look up specific relays on the TOR Project website right now.
In the above search, the fields ‘country’ and ‘flag’ are used to filter relays based on the country and its type. eg Exit nodes from germany.
Try it yourself see how many relays you can find in your country: https://metrics.torproject.org/rs.html#.
You can alternatively use the keyword “tor node” to search specific nodes in duckduckgo
Try it yourself, once you have found a bunch of relays in your region pick one and search for it in duckduckgo: tor node <relay>
This public availability has given rise to detection engines and algorithms specifically built to identify TOR entry nodes. In some cases countries with heavy censorship use this knowledge to block TOR connections entirely, China being the most well known example, having pushed ISPs nationwide to detect and block connections to TOR.
This is a real and legitimate problem. You might think using a VPN to hide your initial connection to TOR solves it, but TOR itself doesn’t recommend that and as covered in the last part, it’s just bad opsec.
Instead TOR offers a workaround called Bridge. A bridge is an obfuscated server that acts as your proxy into TOR while looking like it has nothing to do with TOR from the outside. Bridges are not publicly listed like the relays, and they also help obscure the fact that you are using TOR from your entry node. There are two types of TOR bridges. Default bridges are somewhat publicly available and like the relays, they can be detected or blocked with a bit more effort. Private bridges can be specifically requested and are not publicly available at all.
Global Passive Adversary
Now back to the bigger picture.
For a long time the scenario of a single entity controlling both the entry and exit node of a circuit was considered nearly impossible. The relays are randomised, geographically diverse, globally distributed and the sheer volume of traffic made it seem implausible. But TOR does not verify its relays and cannot check whether the same entity is running more than one node. For an ordinary external attacker this remains effectively impossible, they simply don’t have the resources to monitor multiple relays in parallel at the scale required. But not every adversary is ordinary.
This brings us to what’s known as a global passive adversary. In simple terms this is the kind of adversary that has the resources to monitor a significant portion of the TOR network simultaneously on a global scale. It’s worth noting that this is a very simplified overview, the actual academic definition is far more specific and technically complex, which is part of why it remains a hypothetical threat rather than a confirmed one. The closest real world approximation of this in practice are the three letter agencies and their international alliances, and even they don’t fully meet the academic definition.
Which brings us to one of the most controversial examples in TOR’s history.
Example 2: CMU CERT — Unmasking Users via Active Monitoring
The CMU CERT research that involved monitoring TOR entry and exit nodes at scale to deanonymize hidden services and users. The reason it’s controversial is its suspected link to one of the largest dark web takedowns in history, Operation Onymous. This was a joint operation between the FBI and Europol, with involvement from Homeland Security, ICE and the DEA, that led to the shutdown of multiple markets including Silk Road 2.0 and the arrest of Blake Benthall, also known as Defcon, the mastermind behind Silk Road 2.0.
Setting the controversy aside, here is a quick technical overview of what TOR believes happened. The suspected attack was a combination of a Sybil attack and a traffic confirmation attack. A Sybil attack is when an adversary controls multiple relay nodes in the network. Traffic confirmation, as covered earlier, is when the adversary can monitor both ends of a circuit and compare traffic characteristics like volume and timing to confirm a user’s identity. What made this case different from a standard passive monitoring scenario is that this was an active attack. The CMU researchers deployed a large number of TOR relays acting as both entry and exit nodes. The attacking entry node injected a signal into packet headers, and the corresponding exit node read that signal to confirm the traffic. The same technique was applied to hidden service directories to de-anonymise hidden services. While this active approach exploited a specific vulnerability in the TOR protocol that has since been patched, the underlying threat of passive Sybil attacks and traffic confirmation remains. The key variable is simply the number of nodes deployed. The more high bandwidth relays an attacker controls, the higher the probability that a user builds a circuit through them. Law enforcement agencies are getting increasingly close to what was once only a theoretical global passive threat.
OpSec: The Human Variable
The other major reason TOR fails to protect people has nothing to do with the architecture at all. It’s simply human error.
Your safety within TOR depends entirely on how you use it. The external factors we talked about earlier, things like using a VPN, accessing TOR without a bridge, or connecting from a monitored network, all feed into your personal threat model. But the single biggest external factor is your own digital footprint, the trail you leave behind through your own behaviour that TOR has no control over.
Let’s say Alice joined a dark web forum and used the same username she uses on Facebook. In one move she linked her real world identity to her dark web presence, making it trivial for the feds or any motivated threat actor to connect the dots.
To put this in perspective let me walk you through some of the most well known cases of fatal opsec mistakes in dark web history.
Example 3: Silk Road — Ross Ulbricht
Silk Road was one of the oldest and most revolutionary dark web marketplaces, the one that essentially defined what the dark web could be. Ross Ulbricht, also known as DPR or Dread Pirate Robert, was its founder.
While the full story of his arrest is packed with betrayal, undercover operations and drama, there were a few opsec mistakes that sealed his fate long before any of that began. While the feds were busy trying to crack TOR, an IRS tax investigator quietly used simple OSINT and Google dorks to unmask DPR. He searched for the oldest mentions of Silk Road on the clearnet and found a post on a Bitcoin forum where someone was promoting Silk Road as an anonymous marketplace. Even though the post was written from the perspective of a customer, it read like it was written by the owner. The same username appeared again a few months later on a programming forum, this time asking for help building his marketplace, which confirmed this was the founder. But the real fatal mistake was in that same post where he included his personal email address, complete with his real name. That one slip handed the investigators everything they needed. From there it was just a matter of following the digital trail, which eventually led to multiple sting operations and his arrest.
Example 4: BreachForums — Pompompurin
Conor Brian Fitzpatrick, known online as Pompompurin, was the founder of BreachForums, one of the largest hacker forums on the dark web and the successor to RaidForums. It was actually the seizure of RaidForums that first exposed his opsec failures.
When the feds seized RaidForums they gained access to its internal private chats. One conversation stood out where Pompompurin was discussing a breach listed on the forum with the admin, arguing it was incomplete. To prove his point he shared what he claimed was a random email that just happened to resemble his, but it was in fact his own personal email. That was the first crack. On top of that it was found that he had repeatedly accessed BreachForums without TOR or a VPN, and from his personal iPhone, making it straightforward for the feds to track his clearnet activity and connect it back to the dark web. By the time he finally started using a VPN it was already too late. The logs told the rest of the story. One mistake after another and there was no coming back.
Example 5: AlphaBay — Alexandre Cazes
AlphaBay was often called the Amazon of the dark web. It had a polished user experience and an enormous catalogue. Its founder Alexandre Cazes, known asAlpha02 or simply as Moniker, built something genuinely impressive but buried a fatal mistake in it from the very beginning.
While the feds were working to infiltrate the market they received an anonymous tip containing a screenshot of an old AlphaBay welcome email sent to new users. The mistake was right there in the email header, Moniker had used his personal email address as the sender. That single detail unravelled his identity. What followed was a series of carefully executed moves by law enforcement that led to his arrest and the seizure of AlphaBay.
All three of these cases point to the same truth. The internet never forgets, whether that’s on the dark web or the clearnet. Your opsec mistakes will haunt you.
TOR cannot save you from your own digital footprint. Just like security in general, protecting your identity online is a multi layered effort and TOR is only one of those layers. Without proper opsec, the right access setup and disciplined behaviour, TOR alone is not enough. Privacy was never built into the internet, it was always an afterthought, and that makes it inherently leaky no matter how good the tools are.
So to answer the question we opened with: no, TOR does not provide 100% anonymity. But it is still the best shot you have.
What’s Next?
We covered the threat model, walked through how time correlation works in the real world, looked at why the global passive adversary threat is closer to reality than it once was, and went through some of the most well known opsec failures in dark web history.
In the next part I will show you how to access the dark web, and while I can’t hand you one single perfect path because that depends entirely on your goal and your own threat model, I can give you something better. Hang tight for part five.
Until next time, stay safe..