Tor Deep Dive Part 9: Other Ways Tor Can Fail You

The hijack in Part 1 is one way Tor fails: a hostile exit reading what it was never meant to read. There are others, and some are more important for ordinary users. This part covers the ones I could source or test. Where I only have reasoning, I say so.

Traffic correlation

Tor does not hide the fact that traffic goes in at one end and comes out at the other. An observer who can see both ends of a circuit, or who controls the guard and the exit, can compare timing and volume and match them up. Tor is a low-latency network, and traffic correlation is a known limitation of low-latency designs like it, so it is a risk you take by choosing Tor, not a bug waiting for a patch.

The real-world case I can point to is from September 2024. German broadcaster NDR (in its Panorama programme) and the Chaos Computer Club reported that German law enforcement had used timing analysis on Tor to identify a suspect on the Boystown platform. In the Tor Project’s response, from around 22 September 2024, it says that one user of the retired Ricochet messenger was de-anonymised through a guard discovery attack. The attacks it describes took place in 2019 to 2021. The project also notes that Ricochet-Refresh 3.0.12 (June 2022) added vanguards-lite protections against that class of attack.

I have not seen the court documents and I am not going to say more than the sources do. What the case shows is that the threat is real for people who are targets of a patient, well-resourced observer, and not much of a risk for someone checking a website on a normal evening.

Malicious relays that are not hijacked

The Part 1 relays were taken over. A different problem is relays that were set up to be hostile from the start.

The best-documented case is KAX17. Malwarebytes reported on it in December 2021, relying on research by the operator who goes by nusenu. At its peak the group ran more than 900 servers, on a network of roughly 9,000 to 10,000 relays a day. Nusenu’s estimates were that about 16% of users entered the network through a KAX17 guard, about 35% passed through a KAX17 middle relay, and up to 5% left through a KAX17 exit. The Tor Project removed several hundred of the relays on 8 November 2021.

Nobody attributed it to a particular actor, and as far as the public record shows, no deanonymisation was demonstrated. What the case shows is the scale at which one party can quietly run a lot of the network, and that the defence is people looking: the relays were found by a researcher analysing patterns, and removed by the directory authorities.

DNS leaks: measured on Debian 13

This one I could test directly. The question: when you point a tool at Tor’s SOCKS port, who does the DNS lookup? If the tool resolves the name locally and sends only the IP address through Tor, the lookup leaves your machine in the clear, and your resolver learns what you are visiting.

I ran tcpdump on the lab VM, filtered to DNS traffic that was not to the local loopback, while making three requests to the local Tor SOCKS port:

sudo tcpdump -ni any 'udp port 53 and not host 127.0.0.1'

Command	DNS queries seen leaving the VM
curl --socks5 127.0.0.1:9050 http://example.org	2 (A? and AAAA? example.org to the LAN resolver 192.168.11.1)
curl --socks5-hostname 127.0.0.1:9050 http://example.org	0
torsocks curl http://example.org	0

The difference is one word. --socks5 resolves locally, and --socks5-hostname hands the name to Tor to resolve at the exit. This is the same distinction as socks5 versus socks5h in other tools, and in Python PySocks it is rdns=True, which is why the scanner in Part 7 sets it. The lesson from the ssh-over-Tor setup in Part 4 applies here too: check what actually leaves the machine, do not assume.

Your application can identify you

Tor hides your IP address from the destination. It does not stop a browser from telling a site your fonts, screen size, language settings and installed plugins, and it does not stop you logging in to an account that already knows who you are. Tor Browser exists to make every user look alike; a general browser pointed at the SOCKS port does not do that. If anonymity is the point, use Tor Browser and not a proxy setting in another browser. I did not test fingerprinting. This is the Tor Project’s own guidance and I am relaying it.

Tor over a VPN, or a VPN over Tor

People ask which order is better. I did not test either, so this is reasoning and not measurement. A VPN in front of Tor means the VPN provider sees that you use Tor and your entry guard sees the provider, not you. It moves trust and does not remove it. A VPN behind Tor (traffic exits through Tor, then enters the VPN) is more awkward to set up and gives the VPN your real destination plus whatever account you use with it, which can undo the point. Part 10 compares these tools by who sees what.

Availability: Tor can simply not work

Not every failure is about secrecy. Sometimes the network is just hard to use.

In November 2024 the Tor Project described an attack in which someone spoofed SYN packets so that traffic appeared to come from Tor relays’ addresses. Hosting providers saw what looked like relay traffic attacking them and sent abuse complaints to relay operators. The post names OVH and Hetzner, and says some directory authorities were blocked as a result. It recommends running the OONI Probe circumvention test if you suspect blocking, and says the spoofing source was shut down on 7 November 2024. The post is dated 8 November 2024.

There is also a more recent and much weaker item. A forum post on 16 September 2026, “Traffic disbalance and overload” from a user called Kemp, points to the Tor Metrics graph “Bandwith spent serving directory requests” as evidence of unusual load. It is one operator’s hypothesis, and I found no corroboration I could read, so I record it as a single observation and not a finding.

One more I could not verify: a report that a BEGIN_DIR behaviour could be abused against relays. The mailing-list archive pages I tried to fetch looped on redirects, so I never read the report itself. I am not going to describe an attack I could not read about.

What I would actually do

The honest summary is that Tor is good at one thing, and the failures above are mostly outside that thing.

• Use an onion service for your own SSH, as in Part 4. It removes the exit, which is where the Part 1 attack lived.
• If you run a relay, run it as in Part 8, and check what the network publishes about it.
• Use socks5h, --socks5-hostname or torsocks and verify with tcpdump that nothing leaves in the clear, as set up in Part 3.
• Use Tor Browser for browsing, and do not log in to accounts that know you if anonymity is the aim.
• Do not treat Tor as protection against a patient observer watching both ends. If that is your threat model, you need more than a tool.

Part 10 finishes the series with the practical question for most readers: for getting at your own servers, is Tor even the right tool?