Fun with The Great Firewall
I was playing with the Tor Project and decided to understand how the Chinese block Tor servers.
When a port gets censored "ACK" packets are dropped by the GFW. Most
RST+ACK. Here's how it looks on the server
This can possibly be useful: a connection stuck in
for too long may indicate a GFW blockade. I wonder if there's a
counter for this in
Chinese infrastructure seem to be changing right now. My results from last week are not consistent with what I see today.
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 "126.96.36.199".
Using my SSL patch to p0f the ClientHello frames from the scans can be printed as:
- First probe, from random IP:
- Second probe, always from "188.8.131.52":
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.
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:
This scan comes from two random IP address, I've also seen it coming from "184.108.40.206". 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: https://gist.github.com/majek/b59d4b4a6516240e47d2
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.