mrb's blog

My Experience With the Great Firewall of China

By Marc Bevand

14 Jan 2016

Keywords: cryptography hack network security web

When I recently visited China for the first time, as an InfoSec professional I was very curious to finally be able to poke at the Great Firewall of China with my own hands to see how it works and how easy it is evade. In short I was surprised by:

  • Its high level of sophistication such as its ability to exploit side-channel leaks in TLS (I have evidence it can detect the "TLS within TLS" characteristic of secure web proxies)
  • How poorly simple Unix computer security tools fared to evade it
  • 2 of the top 3 commercial VPN providers in China, ExpressVPN and Astrill, use RSA keys so short (1024 bits!) that the Chinese government could factor them [Edit 2016-02-15: acting on my report, these 2 providers retired the short keys and now use 2048- or 4096-bit keys.]

Why evade the GFW?

Most westerners who visit China have a perfectly legitimate reason for evading the GFW: it blocks all Google services. That means no Gmail to access your airline e-ticket, no Hangouts to stay in touch with your family, no Maps to find your hotel, no Drive to access your itinerary document. This was my primary need for evading it.

Before visiting China I prepared myself a bit. On my phone I pinned documents in Drive to access them offline. In Maps I preloaded the locations I was going to visit by zooming in on them to load all the streets and points of interest nearby—the new offline Google Maps feature did not exist at the time. But Maps turned out to be almost unusable anyway: my GPS position was always offset by hundreds of meters from its true location due to the China GPS shift problem. (Google could fix it by using WGS-84 coordinates for their Chinese maps; why have they not done it already?)

Idea 1

So I arrived at my hotel in Beijing, tried to load google.com, and it errored out due to TCP RSTs sent by the GFW to block the connection. My first idea was to set up an SSH SOCKS tunnel (ssh -D) from my laptop to a server colocated in a datacenter in the USA, and I configured Chrome to use it: 

$ google-chrome --proxy-server=socks://127.0.0.1:1080
$ ssh -D 1080 my-server

This worked fine for a few minutes. Then severe packet loss, around 70-80%, started occuring. Restarting the tunnel fixed it for a few minutes. But the packet loss eventually returned, affecting all traffic to my server no matter what type: SSH connections, or simple pings. It is not clear why the GFW drops packets. Some say it is to intentionally disrupt VPNs without outright blocking them. Or perhaps the GFW selectively redirects some suspicious packets to a subsystem for deeper inspection and this subsystem is overloaded and unable to cope with all the traffic.

Whatever the reason is, this packet loss made the SOCKS tunnel too slow and unreliable to be usable.

Idea 2

I tried a slightly different approach: running a web proxy (polipo) on my server listening on 127.0.0.1:$port and using SSH port redirection (ssh -L) to access it: 

$ google-chrome --proxy-server=127.0.0.1:1234
$ ssh -L 1234:127.0.0.1:$port my-server

Again, this worked fine for a few minutes, but the packet loss returned. The GFW is clearly able to detect and interfere with SSH carrying bulk traffic.

Idea 3

Instead of SSH, why not access the proxy over a TLS connection? This should make it harder for the GFW to detect it since the traffic patterns of a user accessing a proxy over TLS are close to the traffic patterns of a user accessing an HTTPS site.

Making a web proxy available over TLS is what we call a secure web proxy, which is not common to the point that most browsers do not support it. So I used stunnel to wrap the proxy connection in TLS and to expose an unencrypted proxy endpoint to my laptop.

Of course I had to protect the setup with authentication. But I could not use standard proxy authentication because if the GFW actively connects to it, the "407 Proxy Authentication Required" error would expose it. And I did not want to use TLS client authentication because this might raise a small red flag that this might some sort of TLS-based VPN. Again I needed to make my secure web proxy endpoint look like and act like a regular HTTPS endpoint as much as possible.

So I wrote a small relay script in Python which listens on $port_a and forwards all connections to another endpoint $host_b:$port_b. The relay can run in 2 modes. In "client mode" (on my laptop) it inserts a 128-bit secret key as the first 16 bytes sent through the connection. In "server mode" (on my server) it verifies this key, and only forwards the connection if the key is valid, or else the data is discarded and dropped which makes it look like a non-responsive web server.

The setup looked like this on my laptop:

  • Browser configured to use proxy on 127.0.0.1:5000
  • Relay listens on 127.0.0.1:5000, inserts the key, and forwards to 127.0.0.1:5001
  • stunnel client listens on 127.0.0.1:5001, wraps the connection in TLS, and forwards to my-server:5002

And on the server:

  • stunnel server listens on my-server:5002, unwraps the connection, and forwards to 127.0.0.1:5003
  • Relay listens on 127.0.0.1:5003, verifies the key (removes it), and forwards to 127.0.0.1:5004
  • Web proxy listens on 127.0.0.1:5004

Result? This worked well! No packet loss, no problems whatsoever.

What does the GFW see on the wire when browsing an HTTP site through the proxy? A packet capture of "curl --head http://www.google.com" shows this on my system (size of TLS records shown in parentheses):

  1. C: TCP SYN to proxy
  2. S: TCP SYN+ACK reply from proxy
  3. C: TCP ACK
  4. C: ClientHello (86 bytes)
  5. S: ServerHello, Certificate, ServerHelloDone (67+858+9 bytes)
  6. C: ClientKeyExchange, ChangeCipherSpec, encrypted Finished (267+6+53 bytes)
  7. S: NewSessionTicket, ChangeCipherSpec, encrypted Finished (207+6+53 bytes)
  8. C: encrypted ApplicationData #1 (37+197 bytes)
  9. S: encrypted ApplicationData #2 (37+693 bytes)

(Side note: ApplicationData records are split in 2 records, the first one of 37 bytes, because of the 1/n-1 record splitting workaround for BEAST.)

There is a TCP handshake, a TLS handshake, an encrypted ApplicationData record sent by the client of about 200 bytes (the HTTP request), and an encrypted ApplicationData record sent by the server of about 700 bytes (the HTTP response). In fact this TLS exchange and traffic pattern is similar to a non-proxied HTTPS connection, which is why the GFW fails to detect it as an evasion technique.

Unfortunately, as soon as I started browsing HTTPS sites through my proxy, the GFW detected it and impacted it with a high packet loss... How can it be?

Idea 4

When browsing an HTTPS site through a secure proxy there are 2 layers of TLS: the outer TLS connection to the proxy and the inner TLS connection to the site. I theorized that the GFW is able to guess that the encrypted ApplicationData records hide a proxy CONNECT request and another TLS handshake. Here is what a packet capture looks like for "curl --head https://www.google.com" through the proxy:

  1. C: TCP SYN to proxy
  2. S: TCP SYN+ACK reply from proxy
  3. C: TCP ACK
  4. C: ClientHello (86 bytes)
  5. S: ServerHello, Certificate, ServerHelloDone (67+858+9 bytes)
  6. C: ClientKeyExchange, ChangeCipherSpec, encrypted Finished (267+6+53 bytes)
  7. S: NewSessionTicket, ChangeCipherSpec, encrypted Finished (207+6+53 bytes)
  8. C: encrypted ApplicationData #1 (37+197 bytes)
  9. S: encrypted ApplicationData #2 (37+69 bytes)
  10. C: encrypted ApplicationData #3 (37+325 bytes)
  11. S: encrypted ApplicationData #4 (37+3557 bytes)
  12. C: encrypted ApplicationData #5 (37+165 bytes)
  13. S: encrypted ApplicationData #6 (37+85 bytes)
  14. C: encrypted ApplicationData #7 (37+149 bytes)
  15. S: encrypted ApplicationData #8 (37+853 bytes)

To the GFW, these 8 ApplicationData records could look like 4 pairs of HTTP requests and responses in a keep-alive connection. However as research has shown [5] [6], side-channel leaks in TLS can be exploited, for example by looking at packet sizes. Doing so, we can see that they indeed match the expected sizes of the messages exchanged during a CONNECT request and a TLS handshake:

  1. C: encrypted ApplicationData #1 (37+197 bytes):
    "CONNECT www.google.com:443 HTTP/1.1\r\nHost:... \r\nUser-Agent:... \r\n\r\n" which is typically 200-300 bytes
  2. S: encrypted ApplicationData #2 (37+69 bytes):
    35-byte "HTTP/1.1 200 Tunnel established\r\n\r\n" proxy response. But with 1/n-1 record splitting, a 20-byte SHA-1 MAC per record (my stunnel was using the AES128-SHA cipher suite), padding to align with a 16-byte AES block, and 5 bytes of TLS record header, this translates exactly to a 37-byte and 69-byte record
  3. C: encrypted ApplicationData #3 (37+325 bytes):
    ClientHello which is typically 200-300 bytes if it advertises dozens of cipher suites (you may notice the ClientHello in the outer TLS connection is only 86 bytes but that is because my stunnel instances were configured to only allow 1 cipher suite)
  4. S: encrypted ApplicationData #4 (37+3557 bytes):
    ServerHello, Certificate, optional ServerKeyExchange, ServerHelloDone, which are typically 1000-4000 bytes combined (space mostly used by the certificate and optional certificate chains)
  5. C: encrypted ApplicationData #5 (37+165 bytes):
    ClientKeyExchange, ChangeCipherSpec, encrypted Finished, which are typically 200-300 bytes combined
  6. S: encrypted ApplicationData #6 (37+85 bytes):
    optional NewSessionTicket, ChangeCipherSpec, encrypted Finished, which are typically 100-300 bytes combined
  7. C: encrypted ApplicationData #7 (37+149 bytes):
    HTTP request
  8. S: encrypted ApplicationData #8 (37+853 bytes):
    HTTP response

Specifically, if ApplicationData #2 is very short (it is extremely rare to see an HTTP reply shorter than "HTTP/1.1 200 Tunnel established"), and if ApplicationData #4 is around 1-4kB (certificates + certificate chain), and if ApplicationData #6 is less than 300 bytes (HTTP responses this small are less rare but still uncommon), then the probability of that exchange hiding a CONNECT request and TLS handshake is high.

To verify my theory that the GFW exploits these side-channel leaks, I modified the relay script to pad each relayed data block smaller than 1500 bytes to a random length between 1000 and 1500 bytes: 

if len_pkt < 1000:
  len_pad = randint(1000 - len_pkt, 1500 - len_pkt)
else:
  len_pad = randint(0, 1500 - len_pkt)

Result? This worked very well! With random padding I was able to browse normally censored HTTP and HTTPS sites for multiple hours without slowdown, without packet loss caused by the GFW.

It was pretty fascinating to test how reliable enabling/disabling the random padding was. I would disable it and the packet loss would return in minutes. I would re-enable it and I could browse for hours. I would disable it again, and the loss would reappear instantly.

I learned through this experience that the GFW is unmistakably able to exploit side-channel leaks in TLS, such as packet sizes in order to detect the "TLS within TLS" characteristic of secure web proxies. This really surprised me. I had no idea the GFW had reached this level of sophistication.

The next day, the packet loss returned. But if I simply used a different port number for the proxy, everything would continue to work fine for another day or so. I think this time the GFW was not blocking me based on side-channel leaks, but based on network metrics. 100% of the network traffic to/from my server crossing the Chinese border was to my public IP in China, so the GFW probably learned my TCP endpoint was likely used as a private VPN, as opposed to being a public HTTPS site accessed by many client IPs.

GFW uses machine learning

None of the information above is new to those familiar with the GFW. It is only after I reached this point in my tests that I did some deeper reading and learned that the GFW uses machine learning algorithms to learn, discover, and block VPNs and proxies.

It all makes sense now: the GFW engineers do not even have to define explicit rules like I described above (if ApplicationData #2 is short, if ApplicationData #4 is around 1-4kB, etc). They train their models using various VPN and proxy setups, and the algorithms learns the characteristics of those connections to identify them automatically.

ExpressVPN

My proxy setup and custom relay script injecting random padding were running on my laptop which I could use at the hotel, and it worked very well. But I also needed a solution for my phone when out on the streets.

I used the commercial service ExpressVPN which seems to be 1 of the top 3 VPN service used to evade the GFW. It is simple and easy to configure: I installed their Android app and I was up and running in no time. ExpressVPN built their service on OpenVPN and have dozens of VPN servers located in many countries.

However I was not pleased when I saw that their OpenVPN root CA certificate RSA key size is only 1024 bits! Why, why, why? The Chinese government is one of the archetype "state-level adversaries" that crypto is supposed to protect us from. This ExpressVPN weakness has been reported and noted multiple times [1] [2].

It is believed that $10 million of specialized hardware can factor 1024-bit RSA keys [3] [4]. There is a high computing cost per key, but if I were China and could factor at least a few RSA keys, surely the root CA key of 1 of the top 3 VPN providers in the country would be one of my targets. Doing so would give them the ability to actively man-in-the-middle ExpressVPN connections and decrypt the traffic. It is possible that China is already doing so and spying on some (all?) ExpressVPN users.

Below is the current ExpressVPN root CA certificate with a 1024-bit RSA key, extracted from the OpenVPN configuration files they distribute to users. Its serial number is 14845239355711109861 (0xce04e28a62cf3ae5) and it is valid from Jul 19 09:36:31 2009 GMT to Jul 17 09:36:31 2019 GMT: 

-----BEGIN CERTIFICATE-----
MIIDeDCCAuGgAwIBAgIJAM4E4opizzrlMA0GCSqGSIb3DQEBBQUAMIGFMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCQ0ExFTATBgNVBAcTDFNhbkZyYW5jaXNjbzEVMBMG
A1UEChMMRm9ydC1GdW5zdG9uMRgwFgYDVQQDEw9Gb3J0LUZ1bnN0b24gQ0ExITAf
BgkqhkiG9w0BCQEWEm1lQG15aG9zdC5teWRvbWFpbjAeFw0wOTA3MTkwOTM2MzFa
Fw0xOTA3MTcwOTM2MzFaMIGFMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFTAT
BgNVBAcTDFNhbkZyYW5jaXNjbzEVMBMGA1UEChMMRm9ydC1GdW5zdG9uMRgwFgYD
VQQDEw9Gb3J0LUZ1bnN0b24gQ0ExITAfBgkqhkiG9w0BCQEWEm1lQG15aG9zdC5t
eWRvbWFpbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyN2QZ9DRRyGsM2/4
lrf/2/6MQ7RQkD34HeNm73/PiyCg8KM5pmZONfZvlKYPjn5GQVb7AdkgxGCkTtRa
KGflBwWlPVS716jD+G92McGXjrjVCNdqOADMZdGG69nryX15IAqOqsfeR4vouEra
UoW9zTibd0rKO6cGbKcfkjoICzkCAwEAAaOB7TCB6jAdBgNVHQ4EFgQU0I63Uy/Y
ejRdgNARuAef2r07VDEwgboGA1UdIwSBsjCBr4AU0I63Uy/YejRdgNARuAef2r07
VDGhgYukgYgwgYUxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEVMBMGA1UEBxMM
U2FuRnJhbmNpc2NvMRUwEwYDVQQKEwxGb3J0LUZ1bnN0b24xGDAWBgNVBAMTD0Zv
cnQtRnVuc3RvbiBDQTEhMB8GCSqGSIb3DQEJARYSbWVAbXlob3N0Lm15ZG9tYWlu
ggkAzgTiimLPOuUwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQBTRzCa
WuEimYpjcTSCp8NawUGWetPCeibdOfDinpcIGrmjorxC5RETSAVhQD0i4CaHP7Fu
vQmBYAIqgSByLAIz+oSj0Vw820pNwA3EGQB8aT/L6QCSuA5NqG6NZS0No8HlICzZ
KGa+SZvptdmGjhnD1czi+21knEg17ZtktvcQ0w==
-----END CERTIFICATE-----

Also, I am confused by the fact the Chinese government allows this well-known VPN provider (and others) to operate freely in the country. They could very easily deploy low-tech ways to block access to the ExpressVPN service, for example by filtering or redirecting the DNS records of their VPN hosts, which is something they do to block certain website hosts. But they do not do it to block ExpressVPN, why? One possible explanation could be that the Chinese government did factor the ExpressVPN root CA key and does spy on the network traffic of their users, but they prefer to not interfere with ExpressVPN in order to give their users a false sense of privacy. If China blocked the service, users would migrate to other more secure VPN services, and China would lose a SIGINT ability.

Many countries other than China have internet censorship capabilities that rival or surpass the capabilities of the GFW. I would be curious to poke at them too.

[Edit: I am well aware of some open source VPN tools that work quite well in China: ShadowVPN / ShadowSocks (whose developer was recently pressured by Chinese authorities to empty the GitHub repository), Obfsproxy (wiki), Softether, etc. My goal was to find out by trial and error the minimum amount of tricks needed to evade the GFW. And I found that a secure web proxy with packet size randomizaton (idea 4) worked perfectly well to evade it.]

[Edit 2016-01-22: I contacted ExpressVPN about their weak RSA key and they replied: "We agree that the issue you have raised is important, and you're correct in that it has been on our backlog to fix for some time. We've now decided to prioritize the upgrade for the next month". Also, I am told another VPN provider popular in China, Astrill, appears to use weak RSA keys.]

[Edit 2016-01-23: So Astrill is also using OpenVPN. They define 2 root CAs (CN=ASCA, and CN=ASCA2). The second one is 2048-bit, but the first one is 1024-bit. This means an active man-in-the-middle attack could intercept and decrypt all Astrill VPN traffic by impersonating malicious OpenVPN servers authentified by the CN=ASCA certificate. It has serial number 10853689667623641679 (0x96a00d3f5508e24f) and is valid from Oct 6 16:58:51 2010 GMT to Oct 3 16:58:51 2020 GMT: 

-----BEGIN CERTIFICATE-----
MIIDDTCCAnagAwIBAgIJAJagDT9VCOJPMA0GCSqGSIb3DQEBBQUAMGMxCzAJBgNV
BAYTAi4uMQswCQYDVQQIEwIuLjELMAkGA1UEBxMCLi4xCzAJBgNVBAoTAi4uMQsw
CQYDVQQLEwIuLjENMAsGA1UEAxMEQVNDQTERMA8GCSqGSIb3DQEJARYCLi4wHhcN
MTAxMDA2MTY1ODUxWhcNMjAxMDAzMTY1ODUxWjBjMQswCQYDVQQGEwIuLjELMAkG
A1UECBMCLi4xCzAJBgNVBAcTAi4uMQswCQYDVQQKEwIuLjELMAkGA1UECxMCLi4x
DTALBgNVBAMTBEFTQ0ExETAPBgkqhkiG9w0BCQEWAi4uMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDH+Q9xZyUp0eI8dFilbISDQtACxkoxtFk8xS8dmYafI8kj
vdcn6ow7Joey8n2G87dVgTOKhCGfVE8UNnJLze7TxifWk0ycEztzBjy0T7MsO8Du
Sz8NscQXIrSlXRNfCnhWECqFK0/ZhwJ1tZdDPedEXbqokbKnHCZVZa7lk0orbwID
AQABo4HIMIHFMB0GA1UdDgQWBBSCRD2bPGLS7EAqz+xZLyndXMa1nDCBlQYDVR0j
BIGNMIGKgBSCRD2bPGLS7EAqz+xZLyndXMa1nKFnpGUwYzELMAkGA1UEBhMCLi4x
CzAJBgNVBAgTAi4uMQswCQYDVQQHEwIuLjELMAkGA1UEChMCLi4xCzAJBgNVBAsT
Ai4uMQ0wCwYDVQQDEwRBU0NBMREwDwYJKoZIhvcNAQkBFgIuLoIJAJagDT9VCOJP
MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAhPkzNaNtiIK9EFfkfohi
RiF82MoXChzj5E0XRV6j+CJoFN36zRVTZuvWwphMo0C+Dnq4G01IJ8fdX71UlbhC
TmZQy3snIV4WbA82DueluQ0QQwFJ251tU/dXQaQm7ZDd3waBI8ot1eyKePiAye8E
8H72FQE3diFQWYPHrBq7unM=
-----END CERTIFICATE-----

I contacted Astrill support, we will see what they say.]

[Edit 2016-01-25: The Astrill Chief Security Officer personally emailed me, thanked me for the report and said "Effective today 1024bit cert (ASCA) has been removed from PKI and all clients are required now to use 2048bit cert". Woohoo!]

[Edit 2016-01-26: Official statements were posted by ExpressVPN and Astrill.]

[Edit 2016-02-15: ExpressVPN reported to me they finished upgrading their CA keys from 1024- to 4096-bit keys. Yay!]

Comments

Hannu wrote: I found this blog post very interesting. Is the code of your vpn solution available somewhere? I'm going to China this summer and would like to have a secure way to avoid GFW. Also did you managed to find a secure solution for mobile? 15 Jan 2016 18:08 UTC

donnie wrote: You must just use ipv6. 15 Jan 2016 18:52 UTC

Anonymous wrote: Did you try out Tor pluggable transports by any chance? They're supposed to obfuscate traffic patterns and packet sizes. 15 Jan 2016 20:11 UTC

mrb wrote: Hannu: I put it at http://pastebin.com/z3Ygc3jx

Use it like this on the client:
./tcprelay-secret-exp.py -p 5000 -P 5001 -m 1:$secret

And on the server:
./tcprelay-secret-exp.py -p 5003 -P 5004 -m 2:$secret

I did not look into other VPN providers. If you use Chrome, and browse HTTPS websites, and they don't use weak 1024-bit keys, and they have pinned certificates, and they use TLS 1.2, and you don't click through cert warnings in case of a MitM attack, the GFW cannot decrypt your traffic.

Anonymous: I did not try that. 15 Jan 2016 20:16 UTC

Jonny wrote: :) ; Nice to see you made it on HN; Glad to see you're enjoying your spoils, traveling round the world, and hacking along the way. Wish ya the best.

-Jonny 15 Jan 2016 20:46 UTC

Jonny wrote: "Also, I am confused by the fact the Chinese government allows this well-known VPN provider (and others) to operate freely in the country." -- most likely these VPN services are permitted to operate with the requirement (voluntarily or involuntarily) to share logs with misc. gov entities; it's a great tracking mechanism under the guise of freedom. 15 Jan 2016 20:50 UTC

mrb wrote: Hi Jonny! What a surprise... Wish you the best too :) 15 Jan 2016 21:17 UTC

est wrote: Poisoning Machine Learning is a new field. Use GFW against innocent sites even itself. lol 16 Jan 2016 06:09 UTC

Linus Lichtenberg wrote: If you're still in China and be able to access Google Play, please give this software a try:

https://play.google.com/store/apps/details?id=com.github.shadowsocks&hl=en

You can learn more about it here:

https://shadowsocks.org/en/index.html (This site is also blocked so you'll have to use Force)

It's a mature and reliable solution developed by a group of young people in China. 16 Jan 2016 06:10 UTC

pein0119 wrote: we use shadowsocks, and it works very well 16 Jan 2016 17:31 UTC

bossel wrote: Shadowsocks(-qt5) is actually still available via github:
https://github.com/shadowsocks/shadowsocks-qt5/wiki/installation

Installation on Kubuntu was a breeze.
The question is: How does it work? I haven't found much of an explanation yet.

Do I have to (or can I) use my own VPS as a server or where do I get server addresses? & how to get Firefox to then surf via Shadowsocks? 16 Jan 2016 22:02 UTC

Lupius wrote: Hey mrb, found your post on r/netsec. I'm in China right now and this time around I'm 100% relying on R7's VPN service (not sure if my activities are recorded). The GFW sure has gotten a lot more sophisticated since my last trip here. 17 Jan 2016 08:43 UTC

alex wrote: you can proxy the open internet used the shadowsocks over the VPS， open the YouTube video just seconds.... 18 Jan 2016 08:56 UTC

Patrick wrote: I'm a Chinese netizen. Sorry to see your grueling experience of crossing GFW in China. VPN, of many protocals, has been seriously banned in China since for years because the traffic feature becomes increasingly easy to be sniffed by the autohrities. Few months ago, in some regions of the country, such as in farwestern province of Xinjiang, using VPN will get phone service suspended by local police and VPN users there whose phone service was halted will be questioned by police. 18 Jan 2016 11:42 UTC

rat wrote: What you met in TLS over TLS is why we come for HTTP/2.
See more for nghttp in github. 18 Jan 2016 12:55 UTC

rat wrote: Professor Xingbin Fang or 'Father of GFW' as we call him has post a paper about how to measuring data inside an encrypted channel. 18 Jan 2016 13:11 UTC

Samuel wrote: You might want to try Lantern if you're still in China. Lantern is open-sourced, good to use in China for a while :)
https://getlantern.org/ 18 Jan 2016 18:53 UTC

Devon H. O'Dell wrote: Very neat information; I'm similarly surprised by the sophistication at which the GFW works. (I'm curious how much latency it adds; I wonder if that's discoverable somehow.)

I also wonder whether it would be possible to defeat the learning entirely using some AWS-like service. After some time period T, your proxy service would spin up a new AWS (or similar) instance. You'd start the service on this new instance, and then your proxy protocol would have some method for negotiating a "next proxy". You could then switch addresses and ports at random intervals. 18 Jan 2016 19:14 UTC

Anonymous wrote: As one chinese citizen I'm also developing software for evading GFW. The random padding works as no wonder, but it makes the connection not so efficient. Another idea that I've been working with is forwarding your data frames, maybe raw TCP/UDP frames randomly over several paths simultaneously. Such paths should appear using different protocols, and even over different servers. Shadowsocks, websockets, and even XMPP. I've demostrated this on my project , but nowadays not so actively. 18 Jan 2016 22:07 UTC

Anonymous wrote: Btw, I wonder if you can use Tor under ExpressVPN. The GFW system and other supercomputers may help the gov to decrypt your traffic. But it costs much more time than searching for patterns, so it may not be done on-the-fly. If the gov's just thinking it's no worry since we'll know what you are doing anyway a few days later, it's okay to use Tor over VPN. Not on-the-fly will mean they'll not block Tor connections right away, that's enough. 18 Jan 2016 22:17 UTC

Foreigners do not understand wrote: Great Firewall of China to use the machine and manual control, with the same anti-virus software. 19 Jan 2016 01:26 UTC

Anonymous wrote: In China it's better to use shadowsocks.Because though some VPN is secure the speed is too terrible in some city like Shanghai.Because the international connection in Shanghai is very terrible for personal user.So I suggest to use shadowsocks in those place.It works very well,we all love it. 19 Jan 2016 01:31 UTC

Will wrote: FUCK GFW. 19 Jan 2016 01:44 UTC

welcome to use GFW wrote: You need shadowsocks or pay for VPN to fuck GFW 19 Jan 2016 02:45 UTC

Jason wrote: So in China, we are all expert 19 Jan 2016 03:08 UTC

Jobs wrote: In some hotel,the Internet Connection would not block by GFW，bucause the ISP has some service that it can connect.... 19 Jan 2016 03:17 UTC

xiaoleng blog wrote: Shadowsocks is a awesome software(the shadowsocks-rss have instead of its place for the moment ).Swichyomega which one of the most popular chrome extensions in china, be called the shadowsocks mate. 19 Jan 2016 03:50 UTC

mrb wrote: Patrick: wow, this is very scary! I wish I knew more stories like this about what happens to Chinese citizens who get caught by the authorities when they evade the GFW. 19 Jan 2016 04:13 UTC

Hunter Chen wrote: to Mrb,

Nothing happens, Chinese government doesn't catch people for using VPNs. They'll just try to mess with your connection. 19 Jan 2016 04:46 UTC

Jason wrote: 有意思 19 Jan 2016 06:04 UTC

Nill wrote: U should use" shadowsocks", its a new proxy service, clever and smart. https://github.com/shadowsocks/shadowsocks/wiki 19 Jan 2016 06:31 UTC

Nill wrote: Beacuse the gov want to supervise the internet corps, if you dont want to be, they will block you. 19 Jan 2016 06:40 UTC

Jay wrote: Here's a step-by-step tutorial on how to install Shadowsocks on AWS EC2 to bypass the GFW:

https://www.vpndada.com/how-to-setup-shadowsocks-server-on-amazon-ec2/ 19 Jan 2016 16:04 UTC

ruigeek wrote: 那是你不知道用shadowsocks 19 Jan 2016 18:17 UTC

frank wrote: guys,as a chinese, i would tell you some experience:
1.do not use SSH and OpenVPN,nearly 100% block;they cracked the protocol
2.Some VPN could be use but depends on the server,eg,,Lindoe servers are blocked in this month.
3.Tor is also cracked and been interferenced. Even the GFW crew member has a thesis on it.
4.Most secure solution is to use shadowsocks and private SSL VPN ,especially Cisco Anyconnect VPN 20 Jan 2016 04:21 UTC

ccc wrote: the more you guys share a secure way to get rid of the wall on public internet, the faster gfw get to "fix" it, they may be watching these posts, too. 20 Jan 2016 07:48 UTC

Chuck Lorre wrote: 哈哈哈 21 Jan 2016 08:17 UTC

Fu Ren wrote: To Hunter Chen,

Not unless you are Uighur, Tibetan, or some other targeted sub-group such as working for an NGO etc. 21 Jan 2016 15:05 UTC

jiacheo wrote: Currently, Shadowsocks works fine, in China. 22 Jan 2016 02:05 UTC

John S wrote: This is why you only take your business plan a few visio docs a .ppt with you. You leave source code alone until you can get a proper party lawyer to say. "Yes, We will pay you, copper, silver, gold or platinum for working for Red.".

I don't want to tear down your expectations but let us make one thing clear the Chinese HATE everything that is non-Chinese. Including you.

Brilliant, Unique, Smart? Means nothing. Serve the people or serve no one if you are non-party.

My luck, I didn't care about the GFW because was taught by my folks from an Eastern Bloc country when to speak and when to STFU.

I really want to appreciate your post however you the context and quantitative data you have given us... "Derp, Machine Learningins". Indicate you were a dumb monkey poking a stick into a lock and sometimes it work and other times not based on the nibbles on your stick. 23 Jan 2016 04:11 UTC

MOFO Linux wrote: Lantern works great most of the time, but the GFW does interfere with it sometimes. Ditto for the very nice Psiphon application. Tor is effective. Can't say "Tor is cracked" because crypto keys always change; GFW tries to de-anonymize by timing, just as it does on one-hop VPNs.

It looks like there's an equilibrium between the GFW and circumvention tools since late 2015 - tools that work but only 80% to 90% of the time. This is a benefit of collateral freedom that circumvention tools are so effective against a rich and dedicated enemy. China's 25 Jan 2016 21:47 UTC

MOFO Linux wrote: China's 100% solution to the circumventionists will be a national disconnection from the internet. Maybe just disconnecting the people (disappearances and prison) would be enough. China is the new North Korea. 25 Jan 2016 21:51 UTC

Anonymous wrote: Use shadowsocks, it's simple and fast. Cisco Anyconnect also works. 29 Jan 2016 04:04 UTC

anonymous wrote: Shadowsocks has DNS leaks. It only works as a proxy on TCP, not
UDP. In some online games, it will leave your real IP to the game server, for example, Battlefield 4. 05 Feb 2016 12:39 UTC

Briarios wrote: I recently tried this, setting it up on a Raspberry Pi, it worked quite well. when doing something like that is to have polipo running on the pi and have your users connect to that, polipo will in turn connect to 5000 and the other polipo on the other end. this will speed up your connections etc. 23 Feb 2016 04:01 UTC

dl1mur4tdj wrote: welcome to china ~GFW

U SHIT 29 Feb 2016 14:14 UTC

dl1mur4tdj wrote: "I think "vpn service encryption using gpg (aes) better than other encryption 29 Feb 2016 14:18 UTC

Nosense wrote: Please comments on shawdowsocks if you are interested in this.

You can find this
https://github.com/shadowsocks

GFW is surely have white lists of VPN, most of them are the VPN for global enterprise use.(China Branch to other site out of China)
Traffic metric is one of the most important parameter to find the new VPN servers.(Most of them are built on VPS like Linode or Digital Ocean by individual users. They can find this course or one-click deployment solution on Linux host.) For example, if you built one shadowsock sever on Linode. You use Android phone to connect this server. You will be able to check facebook and twitter for hours, but only a few minutes for youtube.
I don't know the actual filter parameter of GFW.
Only to guess the pattern:
1. On white list or not, white list server can have unlimited traffic volume or very high traffic volume.
2. If you are not on white list, then you are on monitoring list, your traffic will be checked, at this stage, if your traffic matches OpenVPN or SSH, then GFW take action, randomly redirect your packet to server or other sites. You will find packet loss and very pool connection. If the protocol is something GFW can't recognize immediately, your traffic volume will be taken into consideration. If the volume exceed a certain level, you will be blocked. 16 Mar 2016 01:48 UTC

Pragmatic wrote: Publicly planning to break the laws of a foreign sovereign nation before you visit might be considered stupid at best. 21 Mar 2016 16:38 UTC

Paranoid wrote: How do we know you're not working on improving the GFW? 21 Mar 2016 16:40 UTC

Alex wrote: Last time, when I travel to China, I use this vendor. www.web-odyssey.com. It worked fine, although the links sometime drop, but not frequent. Overall, I can get around the GFW, check gmail, use facebook. Its a paid service, with three day free trial. If anyone interested, give it a trial. They have published the connection method on their website. 29 Mar 2016 15:46 UTC

Felismania wrote: I have been successfully breached GFW for several years. The most reliable solution is L2TP/IPSec VPN. And DO NOT use service from VPN company. Always deploy your own server in your VPS. I recommend using Japaneses VPN software SoftEther. It has a nice wizard which makes deployment easy. 30 Mar 2016 13:33 UTC

JR wrote: After 4 years of continuously circumventing GFW, I find VPN for PC + Shadowsocks for mobile is the best solution. Daily PC usage requires high bandwidth and global bypass, socks proxy is fast and efficient, perfect combination while also having the critical backup when either one is down.

For VPN, get an account from top providers who are relatively unknown to most Chinese users, log in through their proprietary clients or SoftEther, SoftEther Virtual Hub in particular works very well with VPN provider account, faster than providers' own clients and little chance to be blocked, unlike PPTP/L2TP where as soon as GFW found out the specific VPN server IPs they can easily block the specific server if they wanted to.

For Shadowsocks, you can either setting up VPS yourself or purchase an account, for a light user like me, a $8 annual account with 30GB/Month is more than enough, and it works flawlessly on Android 5.1 using NAT mode.

Hope above can help those planning for a long-term trip to China without knowing much about the issue, one last thing: Fuck the GFW. 02 Apr 2016 13:01 UTC

netmedia wrote: How can a political issue be solved by a technical solution ?

If you live in the area under the authorities jurisdiction, you are at their mercy, they can always pull the plug if they want to. some say you can setup your own satellite communication channels to completely bypass the censorship, the sad true is that police will walk in and take the satellite dish away. 05 Apr 2016 22:57 UTC

ChinaWorker wrote: This is great info. I've been in China for several years and dealt with the GFW enough to try putting together my own VPN on several servers (PPTP, SSH, L2TP/IPSec, OpenVPN, SoftEther). SoftEther seems to work the most reliably, though it's a bit slow. Currently I use a provider that can hide your OpenVPN traffic inside SSL or SSH. An interesting thing I think I've found about the GFW is that it appears to be set up regionally to some extent. Let me explain. If I set up a server (any protocol except for OpenVPN) and try to use it in my hometown here it often works great for several hours and then slows down. If I try the same slow server in another province it works great for a while and then slows. Interestingly enough I've discovered if I'm out of town for three weeks or more, my once slow servers work pretty well for a few hours.

Sorry, I know my explanation doesn't sound very technical. You're obviously miles ahead of me on this. 10 Apr 2016 13:42 UTC

willieaames wrote: Any ideas about what the best VPN choice is for China? Obviously an obfuscated VPN would be my first choice, but I don't know what the options are.
I know Tor is blocked by the Great Firewall often so I don't think that is an option.
Are these vpns listed at below link reliable enough in china?
http://www.bestvpnprovider.com/china-vpn 19 Jul 2016 11:21 UTC

mrb wrote: willieaames: I would recommend ExpressVPN or Astrill. They handled my security reports very responsibly, so they gained 1 trust point in my book. Also doublehop.me: they are a smaller company but they seem to know what they are doing. I don't know well enough the other VPN providers listed in your link. 20 Jul 2016 02:46 UTC

Anon wrote: Tor is dead definitely. Bridges are surely taken down. Tho there are still solutions on Tor, I will suggest Shadowsocks , they got solutions in Windows/Android/Mac/Linux/iOS , that will work for you. The only thing you need is a Shadowsocks Server running on foreign countries like USA. 01 Aug 2016 01:56 UTC

Sav wrote: Thanks Mate great info. Using ExpressVpn in China and mostly it works fine on PC and mobile. Bought a ASUS RT-N66U router and setup the openvpn client as per expressVPN instructions. The OpenVpn connects and I can confirm by checking my I.P. The problem is the blocked websites are still blocked but can access the unblocked websites. Could not get it solved with ExpressVPN support so I guess the router solution will not work. Any ideas? 03 Aug 2016 04:55 UTC

reader from China wrote: Thanks for your great post. I am living in China and the wall is really bringing me troubles to my daily work. I have to buy VPN to solve this problem. I tried to use some free tools(like goagent) to cross the fire wall but it is not quite stable. I may try ShadeSocks cause the VPN is getting unstable recently too... 08 Aug 2016 10:11 UTC

tony wrote: How many ways to evade the GFW ? 07 Sep 2016 14:39 UTC

Bill Bennett wrote: I've written a non-technical account of my experience last week with the GFC. Short version: the firewall seems fluid and ever changing.

http://billbennett.co.nz/2016/09/10/great-firewall-of-china 10 Sep 2016 02:15 UTC

Anonymous wrote: Hi, can you write some program that does this automatically, or publish the whole scripts used on your server?
I am very interested in tools and techniques of evading GFW and other firealls (corporate, state,..).
anonionman@openaliasbox.org 16 Sep 2016 10:16 UTC

tsinghuacampus wrote: I'm in China, connected to the internet through CERNET (the university network), and while a lot of websites are blocked through IPv4, I can access quite a few of them (google, facebook, youtube) through IPv6. Unfortunately, that is not very reliable. Often, I cannot reach those websites, but I can still ping them.

Do you have any explanation for this? 24 Sep 2016 16:03 UTC

mrb wrote: tsinghuacampus: sorry, I have no explanation. I did not test IPv6 while in China. 24 Sep 2016 22:57 UTC

Noone wrote: Very useful blog
I wish someone take same report from iran internet
Recently I got weird problem with api.twitter.com dns hostname not verify i do everything possible but failed failed 05 Oct 2016 23:00 UTC

blackantt wrote: www.smartrouter.trade will provide stable, fast, safe service in China to access Google, Gmail, Youtube, Facebook, Twitter, Netflix, Hulu plus, etc. 16 Oct 2016 10:18 UTC

BitLox wrote: I set up a VPN service for purely internal China use for a friend's company (remote access to his different offices in China from within China). OpenVPN weirdly enough did NOT work for access via SOME of the local ISPs, such as ChinaTelecom, but DID work when accessing via ChinaMobile. Very weird. Anyways, I changed the default port for OpenVPN to 21 (we are not using ftp anyways) and now it always works like a charm. 17 Nov 2016 12:45 UTC

BitLox wrote: Additionally, I'd like to mention that when originally using the 1194 default ports for purely internal Chinese OpenVPN connections, as soon as the server and client attempted to communicate I would get bogus connection attempts from the telecom's IP address space. This is what seemed to be making a standard 1194 connection impossible. 17 Nov 2016 12:49 UTC

Effl user wrote: Mebte çalışıyomı gnçlr :^) 28 Dec 2016 11:52 UTC

Roy wrote: Thanks Marc! Great article!
I had the same problem on my last visit to China, I found this free Shadowsocks service that worked for me http://shadow.tunnelz.online/ 03 Feb 2017 01:53 UTC

dariusz wrote: Very interesting. I am experimenting with this now. works beautifully. However python script uses a lot of cpu resources. Anybody thought to rewrite in C/C++ ? 06 Feb 2017 10:41 UTC

Max wrote: free Shadowsocks service is no longer work, not reliable. http://shadow.tunnelz.online/ 19 Apr 2017 05:29 UTC

Koll Kharsack wrote: Max, Shadow Tunnelz is working perfectly for me, their domain started using ssl now so it has "https" in site address: https://shadow.tunnelz.online/ 19 Apr 2017 14:18 UTC

dcamero2016 wrote: With Marc's permission, I have added the script for "Idea 4" to Github at https://github.com/dcamero2016/tcprelay-secret-exp 26 Aug 2017 07:04 UTC

Anonymous wrote: There are two prominent successors of Shadowsocks (short for SS), ShadowsocksR (short for SSR) and v2ray.

SSR is a non-official version of SS after the official development SS is taken down by GFW, it greatly improves the obfuscation of the original SS protocol and takes security measures that prevent Man-in-the-Middle attack at the expense of roughly 10-20% of the bandwidth. Unfortunately, it was removed from Github for unknown reason recently (you can still find itssource code from unofficial backup of SSR)

V2ray is a innovative tool (programmed in Golang) developed by a separate group inspired by SS. The core of v2ray is the optimized SS protocol (they called VMess), which provides better encryption, authorization, and obfuscation while maintaining a comparable bandwidth to that of SS (it's even faster since some SSs are experiencing GFW interference). It is also more versatile: supports TLS on TCP, mKCP (a modified TCP-like protocol on UDP) on UDP for those TCP got blocked, as well as websocket (which allows nginx to reverse-proxying packages to back-end V2ray servers). It also offers some high-end features like dynamic ports, protocol deception (simulate HTTP on TCP or videochat on UDP), and relays, and routing. The only drawback is the that V2ray is highly technical: you have to write your own config file, and it requires a lot more knowledge on networking than SS for deployment and use. 01 Oct 2017 16:42 UTC

Alex wrote: Try ShadowsocksR next time, I got very good results following the guide here: https://www.tipsforchina.com/how-to-setup-a-fast-shadowsocks-server-on-vultr-vps-the-easy-way.html 12 Oct 2017 08:10 UTC

Squid wrote: Thank you sir for your interesting and informative post! As a computer rookie I had no idea that the GFW even used machine learning. Not really good news, but certainly good to know. Also I heard that the GFW has gone through a big update recently, as many free and even paid, previously reliable VPN services failed. If you visited China again in the future, you may have some more fun poking at it :) Thanks again for the amazing post, and all the best for your future endeavours! 18 Dec 2017 06:04 UTC

anonymous wrote: I just spent a week at Hangzhou China in December 2017. I used regular SSH tunneling without any of the payload padding techniques mentioned in this article. I can definitively say that at least in Hangzhou, GFW was not able to heuristically detect my tunneling and slowdown/drop my connections. The tunneling was done on port 443 (but with SSH protocol). I typically run my SSH server on large number of ports, such as 22,53,80,179,443,8080, etc. 20 Dec 2017 18:27 UTC

Diego wrote: A simple, quite noobish (sorry) question:

What software do you use to check the percentage of lost packets? I can "feel" ssh suddenly goes slower, but it would be nice to be able to see how many of those packets are dropped, so I can perform similar tests.
Thanks!!! And, great article!!! 16 Jan 2018 11:51 UTC

Terary wrote: I am not sure if this blog is still active - but I have a concern about my trip to China.

I routinely use an OpenVPN via a server located in the US. My routine is, connect via SSH (alternate port), start the service, connect via OpenVPN client. From there I do all my work, which include Terminal Service, Gmail, etc.

Will my set-up work through GFW? 30 Jan 2018 18:54 UTC

mrb wrote: Diego: use ping

Terary: I can't answer as I don't know what changed in the last 2 years. 07 Feb 2018 20:46 UTC

Alan wrote: Hi Marc, this is a fascinating article! I am working in China for the year to come and I am using SSH Tunnel to visit Google. But just as you said, it gets interrupted every 10 minutes. Could you please share the relay Python script again? I would really appreciate it! My email is yuehalan@gmail.com 06 Apr 2018 15:04 UTC

Robert wrote: Hello Marc,

Can you update the script to make an automation to change port number both server and client? Or do you have any offer to overcome this. 27 May 2018 11:05 UTC

UN858146933CN wrote: UN858146933CN 09 Feb 2019 05:51 UTC

KK wrote: lmao my story was I made 2 trips to China. The first trip I underestimate the GFW and thinking bring a shadowsocks would help. Unfortunately during 2017~2018 the SS is semi-blocked (some cities it goes some cities no go), and during a "national day" all commercial VPN got blocked too.

The reason that commercial VPN can go through is, those large VPN companies use cloud services (IP addresses mixed with other legit company servers) and heavy obfs. So GFW find it hard to block without rising complaints. But in special days, they block it anyway.

The second trip I get smarter. I setup a v2ray websocket proxy behind a legit company web server I am managing. And it was smooth for few months. 18 May 2019 13:50 UTC

big brother watching wrote: soon all countries will have a GFW and be totally enslaved.

soon the dictatorship will begin. 23 Jun 2019 15:06 UTC

Westside wrote: Fantastic read and great detective work. Thanks for taking the time to type this all up! 28 Jul 2019 06:36 UTC

郭文贵 wrote: 郭文贵 30 Apr 2020 09:11 UTC

Cross-Hello wrote: Thank you. Recently the TLS over TLS detection causes a lot of problems.
Knowing how to detect is a gift.
Thank you. 05 Oct 2022 23:55 UTC

cantsay wrote: https://github.com/klzgrad/naiveproxy

NaïveProxy uses Chromium's network stack to camouflage traffic with strong censorship resistence and low detectablility 04 Nov 2022 19:31 UTC

anyone wrote: A simple and specific explanation of how tls over tls is detected 24 Nov 2022 13:28 UTC