Infosec bod: I've found zero-day flaws in Tor's bridge relay defenses. Tor Project: Only the zero part is right

Warnings either not new or need more study, reckons open-source dev team

Neal Krawetz, a computer forensics expert, has published details on how to detect Tor bridge network traffic that he characterizes as "zero-day exploits"... which the Tor Project insists are nothing of the sort.

The project provides open-source software for communicating anonymously over the internet. It works by randomly routing your connections through a network of nodes spread across the world. Thus, when you use a website or some other service via Tor, your public IP address is concealed, meaning that website or service, and any eavesdroppers on the line, can't use the connection to trace you back to your home broadband, office, cafe, or from wherever you're using Tor, and your anonymity is preserved. The project also provides a Firefox-based browser for connecting to the public web and hidden services via this network.

Typically, users slide into the Tor network through a publicly listed entry relay, though they may choose to join via a bridge relay, or bridge for short, to avoid IP-based detection and censorship. Some countries, ISPs, and system administrators will put in place mechanisms that detect and stop traffic to entry relays as it's assumed you'll be up to no good. Bridges aren't publicly listed like entry relays; connecting to one may not set off any alarms as network administrators won't be aware of it, allowing you into Tor unhindered.

"Even if your ISP is filtering connections to all the known Tor relays, they probably won't be able to block all the bridges," the Tor documentation noted. "If you suspect your access to the Tor network is being blocked, you may want to use bridges."

Having said that, the bridge approach is not infallible. The Tor Project conceded censors have developed ways to detect and block Tor traffic even when people are using bridges, usually by inspecting packets in transit for telltale signs. The project has tried to address this through pluggable transports, which act as proxies and alter the characteristics of network traffic between the client and bridge so the ostensibly covert communication becomes more difficult to identify and block.

The Tor Browser currently implements four pluggable transports: obfs4, meek, ​Format-Transforming Encryption (FTE), and ScrambleSuit.

According to Krawetz, two of these – obfs4 and meek – can be detected, which undermines Tor's reason for being. If censors can spot Tor traffic, they can block it.

Krawetz, in a blog post, said he's spent years reporting security vulnerabilities to the Tor Project, only to have his advisories dismissed or ignored. "Since the public should know how vulnerable Tor makes them, I am making these vulnerabilities public," he wrote on Thursday.

Krawestz in June committed to publicly revealing Tor vulnerabilities because he is fed up with the project's handling of bug reports. Tor's developers, meanwhile, said the reported flaws are not new or poorly documented.

"We're happy to get bug reports in whatever way the reporter is willing to provide them," a Tor Project spokesperson said in an emailed statement to The Register. "The two reports from last week are not new, and the reports from today are worth investigating but are presented with little evidence that they work at scale."

So what's the issue?

The vulnerabilities amount to techniques for detecting obfs4 and meek traffic. And once detected, such traffic can be blocked. That's arguably not as severe as, say, unmasking a Tor user from their packets, though it's not ideal.

The Tor Project's spokesperson said that, despite Krawetz's assertion that he's unaware of previous public disclosure for detecting and blocking obfs4, academic papers published in 2015 and 2020 explore this very issue.

In his post, Krawetz described how to identify obfs4 using stateful packet inspection – applying filtering rules to follow network and transport packet fields to decide whether traffic is allowed, but not delving into the packet's application layer, which is the province of deep packet inspection. And he also discusses identifying meek by looking for characteristic traffic timing delays between the client and server.

The issue, as Krawetz describes it, is that Tor hasn't adequately responded to the censorship arms race. The Tor Project, he said, appears to have given up and settled on obfs4 as a means of avoiding network traffic detection.

"This is fine if nobody knows how to detect and block obfs4 traffic," he said. "However, China appears to have a complicated method for detecting and blocking obfs4 connections, and I have just shown that an easier stateful packet inspection system can detect obfs4 traffic."

The Tor Project's spokesperson said Krawestz's citation of a 2018 paper [PDF] to support his claim that the Great Firewall of China (GFW) can detect obfs4 appears to misunderstand the findings, which state, "We find that the two most popular pluggable transports (Meek and Obfs4) are still effective in evading GFW’s blocking of Tor."

The spokesperson also pointed to research showing that obfs4 bridges distributed over BridgeDB are blocked while private obfs4 bridges are not, indicating that the censors are intercepting bridge information from distributors rather than blocking the protocol itself.

"The blog post is correct in suggesting that a finely-calibrated decision tree can be highly effective in detecting obfs4; this is a weakness of obfs4," the Tor Project's spokesperson said.

"However, what works in someone's living room doesn't necessarily work at nation-scale: running a decision tree on many TCP flows is expensive (but not impossible) and it takes work to calibrate it.

"When considering the efficacy of this, one also has to take into account the base rate fallacy: the proportion between circumvention traffic and non-circumvention traffic is not 1:1, meaning that false positives/negative rate of 1 per cent (which seems low!) can still result in false positives significantly outweighing true positives. That said, obfs4 is certainly vulnerable to this class of attack." ®