How do you determine if a device is behind China's great firewall with the iOS SDK?

Question

Because of issues reaching our normal endpoints hosted outside of China reliably when the user is behind the great firewall, we're looking for a way to reliably determine if the user is currently behind the great firewall and use a different set of endpoint urls hosted within China.

What we would like to do is some kind of check that the client can make, like accessing a url that we know will always be blocked by the firewall forever (or is only accessible from within) or checking some property of the network configuration.

Things currently being considered:

1. Checking the device's IP against a list of netblocks assigned to China
   • Won't work if the device is behind a NAT firewall
2. Doing a traceroute from the device to a host known to be outside of china. If packets are being routed through hosts that are in China (see above) then the device must be in China.
   • Might work, but will introduce delays before the app can make calls while it.
3. Just ask the user
   • Worst case, this may be the best option.

Ailssa

I'd simply try to get data from any of the sites seen on the table of high ranking websites blocked in mainland China wiki page. – Rationale

The issue with that approach is, what happens if there is a change (which China has been known to make somewhat arbitrarily) and suddenly the sites that was previously blocked isn't anymore? – Ailssa

Try to Google "free tibet" and count the results – Herbart

About the second solution. Is the delay really a problem? You may run your trace route in background every x minutes, or when the app switches to foreground and reconfigure your app accordingly. – Lipid

Answer 1

IP address ranges or you can check a key few of the top blocked websites... maybe Facebook, Google, Wall Street Journal? Choose a variety.

Hardwick

Answer 2

I suspect that any method which attempts to check the great firewall directly will be unreliable, probably in the short term and definitely in the longer term. However since your goal is to select servers either within China or outside of the country, I suggest using the device time zone as a quick and dirty "where am I?" check. If the time zone name is Asia/Chungking, for example, use the Chinese server. If it's Europe/Amsterdam, for example, do not use the Chinese server. Check for every time zone in mainland China and you'll probably be fine.

You can get the time zone name as TimeZone.current.identifier.

Speechmaking

This is actually a pretty useful approach. However, I can use the chinese timezone in europe so that might block me out, right? – Endamage

You can change your time zone but most people don’t. I’d wager this will be more reliable than other checks are likely to be. – Speechmaking

I’m inclined to agree with the other two comments. At best this is a signal that the user might be in China, but isn’t 100% certain – Ailssa

One of those comments was mine. I don’t claim that this is 100% reliable but I expect it to fail less often than other methods, unless you can get direct help from the Chinese government to help you. – Speechmaking

Answer 3

A more technical approach may be to analyze the TCP RST packet begin sent by the firewall. This (page 5) white paper shows how researchers were able to differentiate a TCP RST from the firewall from their server by fixing the TTL value and noticing when it is different (61 vs 42 in the paper).

When a customer is possibly in China (determined by other info) you could force a RST on the first connection, save the TTL value and then notice when you get a RST of a different value.

Jaffe

Answer 4

My suggestion is based on a few assumptions and some prior experience validating traffic sources.

Assumptions

1. Any URL you continually check will eventually be noticed by GFWOC admins.

   a. this traffic pattern will result in a permanent block,

   b. and/or used to track devices attempting to hit this url (perhaps as a honeypot),

   c. and/or redirected to an internal state sponsored and monitored end point of some sort.

2. you have the ability to push updates to your iOS app through the firewall.

Options

1. Create an endpoint outside of China with a ppk authenticated login, and include the ppk file in your iOS application. The endpoint returns a message encrypted with the ppk such that only the calling instance of the iOS app can decrypt the response, which may simply be something like "ext_endpoint_reached" or some other known confirmation message.

   If this ever fails to properly decrypt or provide the expected message, fail over to the internally hosted endpoints. If it succeeds, proceed as normal.

2. If outbound encrypted traffic is not permitted, and inbound encrypted traffic is blocked, a two part handshake could take its place. In this scenario, call one registers an outbound connection on external endpoint A. The device then connects to endpoint B, which is just another face of the same service backend, to see if it has a message waiting that fits certain parameters known only to the iOS application instance.

   If the message it finds at B matches what is expected, and this could be a simple keyword based on the time or date or some other unique factor, you have succeeded in reaching the outside endpoint, whereas if you don't received the expected response or no response, you know you are being blocked or redirected.

Both of these options provide a fail over that confirms you are hitting the firewall, and both rely upon nothing terribly exotic to provide external, probably non-spoofable, confirmation that you are outside the firewall.

Sun