Examining How the Great Firewall Discovers Hidden Circumvention Servers (2015) | Hacker News Reader

Examining How the Great Firewall Discovers Hidden Circumvention Servers (2015)

fermatslibrary.com

104 pointsgarrincha18 comments

Readable version without extraneous nonsense:

http://conferences.sigcomm.org/imc/2015/papers/p445.pdf

Thanks. That page has so much popup junk that I opened Inspect Element and deleted the popup nodes just to read the thing.

Thank you for that. I nearly lost the will to live and gave up around page two.

Tor stopped working (with bridge) when I was there last month. It worked for a day or two then stopped working. It didn't matter how many times I refreshed my bridges list, it just wouldn't work. Luckily I provisioned an Azure VM in Hong Kong which I could access via RDP to keep access to GMail, Facebook etc.

Did you provisioned an Azure VM while you were in Hong Kong or an Azure VM that was hosted in Hong Kong?

The VM was in Hong Kong. I was in Mainland China.

HK is not affected by the GFW, as far as I know.

I've never been anywhere near the GFW but I do find OpenVPN listening on 443/tcp and a few other ports (tcp and udp) on the outside quite handy for drilling through firewalls. It supports basic auth proxies but CNTLM is in the toolbox as well. Add in NAT and a few routing entries on other hosts.

It also provides a simple way to detect a transparent MitM proxy. If OVPN fails to connect but an "unprotected" https connection gets through then the alarm bells go off and the presented SSL cert gets a serious examination. I keep a couple of thumbprints of known certs handy for this - the discipline of proper checking rather than a cursory glance at an image that the GUI throws up.

I use readily available stuff but looking into the description of how the obfs protocols work in Tor I'm impressed and rather glad that my life or liberty doesn't depend on my efforts. When I get it wrong I simply lose access to BBC iPlayer or whatever. When someone who is having to take this rather more seriously gets it wrong, they might not get a chance to repeat their mistake.

This sort of thing used to work, but doesn't anymore. The GFW is now smart enough to detect VPNs based only on the traffic they generate, not port numbers or other easily changed things. It's currently an arms race between VPN providers trying to mask their traffic and the firewall trying to uncover it, and the firewall is winning so far.

Whelp, that's pretty much it for the internet. Won't be long before many more governments are licensing and using this technology. The question is how long before supposedly 'free' governments start.

It's easy to fix by mirroring their behavior: drop incoming connections from China until they drop their firewall.

If you're in China, you might want to use Shadowsocks. The server is easy to set up on any VPS (no need for TUN/TAP), and there are clients for Android (Shadowsocks), iOS9+ (Potatso), linux and routers.

I've found plain OpenVPN over TCP or UDP stopped working a few years ago (even using remote-random to shuffle ports). PPTP mostly still works.

I haven't used other VPN protocols for a long while, and don't use commercial VPN providers, but occasionally hear from friends that they have temporarily issues (for hours or days, but not weeks).

Thanks, I'll give that a shot next time. I think I tried PPTP when I was there last year without success, but I may be misremembering.

Here's a summary that's a bit easier to digest: https://blog.torproject.org/blog/learning-more-about-gfws-ac...

Here is the presentation from CCC 2015

https://www.youtube.com/watch?v=NgYdmRR7JtY

We have a client's system that seems to get probed for this sort of thing. We keep seeing URLs like the following being requested:

    htttps://www.example.com/http://www.baidu.com/cache/global/img/gs.gif

There are a number of variations including plain IP numbers and other URLs, like www.google.com being used.

I guess at some point somebody accessed the site from China.

EDIT: Just got another probe from 94.102.49.174 owned by Quasi Networks Ltd in the Seychelles.

Quasi (aka Ecatel) is basically a den of ddos for hire, ddos, malware, botnet C&C, abuse reports ignored. Servers are in NL.

Probably not China.

A good time to TLS fingerprint your connections and get an idea of which client is probing your server.

Probers might have their own unique TLS fingerprint.

https://blog.squarelemon.com/tls-fingerprinting/

(2015)

Reply on news.ycombinator.com