Hacker Factor on Snowflake Pluggable Transports

I missed this from earlier when Dr. Neal Krawetz posted his entry titled “Tor 0day: Snowflake.” I will include the relevant part about detecting snowflake below. The other parts of his article cover the other issues with Tor covered in his previous blog posts as well as Nusenu’s discovery of an entity running hundreds of malicious Tor relays.

I also included a bit about Snowflake for those who are unaware.

What is Snowflake?

Per the Tor Project:

Snowflake is a pluggable transport that uses a combination of domain fronting and peer-to-peer WebRTC connections between clients and volunteers to circumvent Internet censorship. Snowflake, which is the spiritual successor to flashproxy, aims to lower the barrier for running anti-censorship proxies, resulting in a large pool of proxies for users to connect to. Instead of requiring a server with consistent up-time, Snowflake proxies run as an addon or extension in your browser. These proxies can move locations as users connect to different networks, providing a moving target that is more difficult to block. We currently have about 8 thousand available Snowflake proxies each day. When a user connects to Snowflake in order to circumvent censorship, they are matched with a currently available proxy. If this proxy “melts,” or disappears, the user will be seamlessly matched with a new proxy.

Complete documentation is available at Kerosene.net where much more information is available:

Snowflake is a new circumvention tool which provides access to the free and open internet. As a Pluggable Transport, it provides easy-to-use access to a censorship circumvention system such as Tor. It is inspired by and builds upon the previous work of Flashproxy. Snowflake is much like a hybrid of previous Pluggable Transports, and this document will serve as a guide for exploring this system.

To illustrate in the context of Tor, Snowflake allows anyone to leave a browser tab open to become an ephemeral Tor bridge. Much like the Flashproxy design, Snowflake involves a large network of highly ephemeral volunteer proxies, with the goal of outpacing the censor’s ability to block proxy IP addresses and providing a very easy to use, reliable, and hard-to-filter method of circumventing censorship. Previously, users faced difficulties in manually configuring port-forwarding, which limited adoption of older tools like Flashproxy. Snowflake addresses NAT traversal by making it automatic and not the user’s responsibility, among a number of new advantages.

Snowflake Issues

This is Hacker Factor

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.

i2p

In response to a comment on one of his previous posts about Tor, Dr. Krawetz wrote this:

I’m very familiar with i2p. I won’t go near it unless someone is paying me for exploits.

My short opinion: As many problems that Tor has, i2p is substantially worse.

It is worse BECAUSE every user is also a relay. I can sit at watch the connection, allowing me to map out each user’s address. If your server is up long enough, you should see everyone eventually.

Then there are the i2p servers (like Tor’s hidden services). It’s basically a Russian ghost town with a very strong anti-muslim vibe. (Seriously – it was like every site was “Drugs! No Arabs!” but written in Russian.)

And then there are the i2p exit nodes. Tor has a problem with hostile exit nodes. i2p has a problem because there are no exit nodes. (Well, there is ONE exit node, but it’s either down or so heavily congested by everyone else that it’s unusable.)

So if you’re using i2p, you’re not accessing the Internet (no exits). You’re likely only going to internal i2p sites that cater to illegal activity – making you a suspect just for being on i2p. And since every user is a relay, I can sit and collect the network addresses of every suspect user. Yeah, that’s worse than Tor.

All of the Hacker Factor posts about Tor make me concerned about the usefulness of Tor in the long term, even if the problems described in his posts are not ones that will immediately impact the users of drug markets (which, if I had to guess, make up the majority of my readership). As for i2p, I am not particularly concerned with the Russian ghost town part or the “anti-muslim vibe” part as neither of those impact the usefulness of i2p but it is irritating that there are so few eepsites that exist for purposes unrelated to drugs. Of course, being “a suspect just for being on i2p” is not evidence of crime in a court of law in many countries but it certainly could be an issue with ISPs and whatnot. Or make you a potential target for further scrutiny by LE.

The full Hacker Factor post is available here.