5

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.
Mike Akers
  • 12,039
  • 14
  • 58
  • 71
  • I'd simply try to get data from any of the sites seen on the [table of high ranking websites blocked in mainland China](https://en.wikipedia.org/wiki/Websites_blocked_in_mainland_China) wiki page. – Michael Dautermann Mar 08 '18 at 23:47
  • 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? – Mike Akers Mar 08 '18 at 23:54
  • 3
    Try to Google "free tibet" and count the results – CodeBender Mar 09 '18 at 00:06
  • 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. – Moose Mar 18 '18 at 12:18

4 Answers4

3

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

Jess
  • 3,097
  • 2
  • 16
  • 42
3

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.

Tom Harrington
  • 69,312
  • 10
  • 146
  • 170
  • This is actually a pretty useful approach. However, I can use the chinese timezone in europe so that might block me out, right? – Akaino Mar 16 '18 at 10:15
  • 1
    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. – Tom Harrington Mar 16 '18 at 14:02
  • 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 – Mike Akers Mar 18 '18 at 13:37
  • 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. – Tom Harrington Mar 18 '18 at 15:56
1

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.

Liam Kelly
  • 3,524
  • 1
  • 17
  • 41
0

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.

J E Carter II
  • 1,436
  • 1
  • 22
  • 39