Dishonest Tor relay math question - tor-talk is to lazy

grarpamp grarpamp at gmail.com
Sat Jan 15 22:14:19 PST 2022


https://www.hackerfactor.com/blog/index.php?/archives/944-Tor-0day-Snowflake.html
https://www.hackerfactor.com/blog/index.php?/categories/19-Tor

Tuesday, 21 December 2021
Back in 2020, I wrote nine blog entries about Tor that covered a wide
range of vulnerabilities. Many of them were well-known to the Tor
Project (some nearly a decade old!) but had never been addressed and
had no viable mitigation options or alternatives. Other issues were
brand new and first disclosed on my blog. (The last blog entry begins
with a summary of the vulnerabilities.)

Of all of the vulnerabilities and concerns that I raised in 2020, the
Tor Project didn't address any of them. Zero. Over the past year,
there were over a dozen updates for the Tor daemon (and that's not
counting the pre-releases). There were also over a dozen updates to
the Tor Browser (from version 10.0.8 to 11.0.3), but most of these
were basically incorporating updates from Firefox. The main
Tor-specific changes were the deprecation and removal of onion v2
support (replaced by v3 addresses) and the formal release of snowflake
as a pluggable transport.

Some of my "Tor 0day" blog entries mentioned a lack of good pluggable
transports for when someone blocks direct and indirect (bridge)
connections. Snowflake introduces another connection option, but it
has its own serious limitations and is far too detectable.

Still Viable Exploits
My "Tor 0day" blog series focused on one specific scenario: Can
someone watching the network traffic determine if you (specifically
you) were using Tor?

For example, many companies do not permit Tor within the corporate
network. This restriction prevents malware from downloading past the
corporate anti-virus scanners and deters someone from potentially
leaking company-confidential information. These companies don't mind
if you use Tor on your home network and home computer; just not on
anything that touches the company's network. For these companies, it
is one thing to have a rule about "no Tor", but it's another to
enforce the rule by detecting and immediately blocking anyone who
violates the rule.

This threat vector is also seen when countries block access to Tor.
Earlier this month, the Tor Project made an announcement that Russia
was blocking Tor. What they didn't mention was that these blocks were
made possible using the exact same methods disclosed in my blog series
a year earlier. Moreover, the Tor Project had known about these issues
for years. The Tor Project's alert about Russia was really just a
complaint that people were blocking their service through exploits
that the Tor Project hasn't felt like fixing.

The Open Observatory of Network Interference (OONI) is an organization
that tracks online censorship. About 10 days after the Tor Project's
announcement, OONI posted their report. According to OONI, it wasn't
all of Russia blocking Tor; it was 15 out of 65 subnets. Moreover,
each censorship instance used a different blocking method:

    In some cases though (such as on AS42437), OONI data suggests that
access to torproject.org is being interfered with by means of a TLS
man-in-the-middle attack, while in other cases (such as on AS51570),
we observe that the connection is reset once the TLS handshake has
been initiated, suggesting the use of Deep Packet Inspection (DPI)
technology.


If the censorship was government-sponsored, as the Tor Project
suggested, then I would expect it to be much more widespread and
consistent. This looks like individual blocking efforts. As OONI
noted, the blocks followed a "recent spike in the use of Tor bridges
(used for circumventing Tor blocking) in Russia."

To me, this looks like ISPs having a problem with Tor users. Tor is
often viewed a bad neighborhood since it is often associated with
other criminal activities, like human trafficking and drugs. By
blocking Tor access, these services reduce the number of bad actors on
their networks.

This censorship also means that these ISPs could easily detect Tor
bridges (as noted in my second Tor 0day blog entry.) If the Tor
Project actually provided anonymous or less detectable bridges, then
this filtering would never have happened.

Similarly, this year Tor researcher Nusenu found that one persistent
threat group (KAX17) had managed to create thousands of Tor nodes.
With that many nodes, they can easily decloak hidden services and
track individual users. This group has been around since at least 2017
and the Tor Project's efforts to remove them have been ineffective.
(See my 6th blog entry for more details.)

Pluggable Transports
Tor uses pluggable transports as alternative protocols for connecting
to the Tor network. My second blog entry shows how to detect and block
all production pluggable transports. Moreover, code had been deployed
and was working in real-time on high-volume networks. (As an aside: as
far as I know, my code is not being used for those Russian blocks.)

I had previously mentioned that the Tor Project had dropped support
for all pluggable transports except obfs4 and meek, and meek was being
shut down by various cloud providers. In effect, the Tor Project was
putting all of their eggs in one basket (obfs4) and hoping that ISPs
wouldn't block it -- even though it was trivial to detect and filter.

    Obfs4 acts as a trojan protocol. It sends encrypted communication
over a known port, like 22/tcp (normally used by Secure Shell) or
443/tcp (normally used by HTTPS). It's a trojan protocol because it
doesn't speak the right language when using a well-known port. Any
kind of stateful packet inspection at the session or application layer
will easily detect it.

    Meek depends on TLS tunneling. I currently have a couple of
methods for easily detecting Tor's use of meek.

The Tor Project's solution was to introduce a new pluggable transport:
snowflake. Snowflake had been a work-in-progress since 2016 and takes
a different tunneling approach. It pretends to be a WebRTC (video
chat) communication stream. WebRTC relies on a couple of protocols,
including STUN and ICE. (The name 'snowflake' is because it is related
to the ICE communication protocol. It is not intended as a derogatory
term.)

Detecting Snowflake
Of all of the pluggable transports that the Tor Project has released,
I think snowflake is the easiest to detect. I'm not saying that the
others were difficult to detect and filter. Rather, the other
protocols (fte, obfs3, obfs4, meek, etc.) only had a few ways that
they could be detected. Snowflake has literally dozens of trivial ways
to detect it.

For example, video chats rely on a protocol called STUN (Session
Traversal Utilities for NAT; network address translation). Basically,
STUN identifies your external network address. This is needed to
establish any kind of video chat when you use a firewall. Snowflake
uses a hard-coded list of available STUN servers. The current list is:

    stun.voip.blackberry.com:3478
    stun:stun.altar.com.pl:3478
    stun:stun.antisip.com:3478
    stun:stun.bluesip.net:3478
    stun:stun.dus.net:3478
    stun:stun.epygi.com:3478
    stun:stun.sonetel.com:3478
    stun:stun.sonetel.net:3478
    stun:stun.stunprotocol.org:3478
    stun:stun.uls.co.za:3478
    stun:stun.voipgate.com:3478
    stun:stun.voys.nl:3478

When the snowflake client first starts up, it queries DNS for a
randomly selected subset of these STUN servers. It looks for the
hostname resolution using both IPv4 and IPv6 (DNS 'A' and 'AAAA'
records). However, it doesn't just look up the hostnames; it checks if
the name is on the local network. Like most companies, my lab uses a
private network behind the firewall and runs an internal DNS server.
All computers on my private network use the domain name
"internal.lan". When I started snowflake, I immediately saw a set of
DNS queries for the STUN servers:

    client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.epygi.com'
    client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.voipgate.com'
    client -> dnsserver : DNS Query Type[1]=A Name='stun.epygi.com'
    client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.sonetel.net'
    client -> dnsserver : DNS Query Type[28]=AAAA
Name='stun.epygi.com.internal.lan'
    client -> dnsserver : DNS Query Type[28]=AAAA
Name='stun.voipgate.com.internal.lan'
    client -> dnsserver : DNS Query Type[28]=AAAA
Name='stun.epygi.com.internal.lan'
    client -> dnsserver : DNS Query Type[28]=AAAA
Name='stun.voipgate.com.internal.lan'

Each line is one packet, and all of this happened in one second. This
means that I have multiple ways to detect a Tor snowflake client
before it even tries to connect to the Tor snowflake server!

    A single WebRTC client typically connects to one STUN server. If
you see a single client immediately lookup multiple STUN servers and
all of the servers are in the snowflake hard-coded list, then you've
found a Tor snowflake client.

    Regular WebRTC clients do not do hostname lookups for remote STUN
servers on the local network. If you see any DNS lookups for
snowflake's STUN servers on the local network
(stun.epygi.com.internal.lan, stun.voipgate.com.internal.lan, etc.)
then you've found a Tor snowflake client.

About a second later -- after doing the DNS lookups -- there are
queries for the snowflake hard-coded domain fronting server:

    client -> dnsserver : DNS Query Type[1]=A Name='cdn.sstatic.net'
    client -> dnsserver : DNS Query Type[1]=AAAA Name='cdn.sstatic.net'

Again, if you see any IP address that first does a DNS lookup for a
snowflake STUN server and then does a lookup for the snowflake domain
fronting service, then you've found a Tor snowflake client.

These are just 3 ways for an administrator to watch DNS in order to
detect or block Tor snowflake users before they can connect to the Tor
network. There are another dozen ways to detect snowflake (zero false
positives, zero false negatives) if you start looking at how it uses
STUN and ICE. In addition, a snowflake client can be used to identify
the IP addresses of other Tor users because other Tor users provide
the snowflake proxies. (The entire snowflake protocol strikes me as a
project created by a group that put no consideration into how an
adversary might detect or block this pluggable transport.)

I want to emphasize the warning from my earlier blog entries: If you
are in a location where using Tor can result in an arrest, being
tracked by government agents, or losing your job, then do not rely on
snowflake for anonymity or to protect your privacy. The Tor Project
provides zero solutions if you are located in a repressive location.

Tor: State of the Onion
Earlier this year, I attended the Tor Project's online "State of the
Onion" presentation. During the presentation, different members spoke
about all of the great things that the Tor Project was doing to
advance online privacy, anonymity, and anti-censorship. They even
praised snowflake as a success.

If you didn't know the technical details, then you might get the
impression that this was very positive and incredible forward
movement. The amount of spin from the Tor Project was as good as any
nation-state or political announcement.

But behind the scenes? They haven't addressed any of their core
issues. If someone wants to track you through Tor, deanonymize your
network activity, or prevent you from accessing Tor, then they can do
it and you cannot stop them. And if you do something illegal over Tor
and you haven't been arrested, then it's only because there are bigger
villains than you; you're not a high priority -- yet.

Today, the Tor Project seems to be more focused on fund raising than
actual privacy, anonymity, or anti-censorship. I wonder if they will
ever start fixing these known issues.


More information about the cypherpunks mailing list