totally not insane
idea of the day

Fun with The Great Firewall

11 July 2013

I was playing with the Tor Project and decided to understand how the Chinese block Tor servers.

Philipp Winter wrote an amazing paper on that subject. He noticed The Great Firewall of China is actively scanning services and if it detects a Tor bridge it blocks the ip:port tuple for a few hours.


When a port gets censored "ACK" packets are dropped by the GFW. Most importantly SYN+ACK and RST+ACK. Here's how it looks on the server side:

This can possibly be useful: a connection stuck in SYN_RECV state for too long may indicate a GFW blockade. I wonder if there's a counter for this in netstat -s.

Active probing

Chinese infrastructure seem to be changing right now. My results from last week are not consistent with what I see today.

Late June

The active scans sent by GFW in June were pretty consistent with what Philipp described in the paper. When triggered (for example by sending a byte sequence looking like a Tor handshake) one could see two scans: one from a random IP address and another from "".

Using my SSL patch to p0f the ClientHello frames from the scans can be printed as:


They are identifiable and look different than legit Tor traffic. Here's the raw payload if you can read SSL (underscores for readability):



With that data we can easily log these probes on the iptables layer. For example:

$ iptables -A INPUT -p tcp -m string --hex-string "|00001800390038003500160013000A00330032002F0007000500FF0100000400230000|" --algo kmp -j LOG --log-prefix "china_long "

$ iptables -A INPUT -p tcp -m string --hex-string "|00001400390038003500160013000A00330032002F0005020100|" --algo kmp -j LOG --log-prefix "china_short "

One could do -j REJECT to block these probes. I did that but I've noticed the port still got censored, I'm a bit confused about it and I'm not sure what really happened, maybe I missed something.

Early July

Recent GFW probes were different. First, for any outgoing connection from China there are two probes initiated sending data that looks randomly. The length of the payload is usually 1388 or 1448 bytes. Sometimes I was able to see 233 bytes or multiplies of these numbers (2776).

Tor server drops connection when it reads junk. I'm not sure what those probes are for, but they seem to be independent from the SSL probes Philipp noticed.

Sometimes when I initiated a legitimate Tor connection to a bridge I was able to record SSL scans that looked different than before:


Raw payload:


This scan comes from two random IP address, I've also seen it coming from "". It's worth noting that the hosts are able to speak SSL and do a full SSL handshake, not only send initial data. See this log:

Again, it is possible to easily log the initial SSL packet sent by GFW on the firewall:

$ iptables -A INPUT -p tcp -m string --hex-string "|00002800390038008800870035008400160013000a00330032009a009900450044002f00960041000500ff020100000400230000|" --algo kmp -j LOG --log-prefix "china_new "

This time blocking this traffic seem to work and the service seems not to get censored by GFW any more. At last that's what I recorded in early July 2013.


It's unclear what purpose the random probes serve. We can guess they could be used to reveal Obfsproxy or a VPN server.

I also publicised this work on the tor-talk mailing list.