CODEWITHSUNDEEP
iosnetwork-programmingfirewallgreat-firewall-of-china
Mike Akers
Mike Akers

Reputation: 12247

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

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.

Upvotes: 5

Views: 2220

Answers (4)

Liam Kelly
Liam Kelly

Reputation: 3724

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.

Upvotes: 1

J E Carter II
J E Carter II

Reputation: 1506

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.

Upvotes: 0

Tom Harrington
Tom Harrington

Reputation: 70966

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.

Upvotes: 3

Jess
Jess

Reputation: 3146

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

Upvotes: 3

Related Questions