Note: The full report is available at the bottom of the page
On approximately November 6, 2021, numerous users reported the blocking of their servers running Shadowsocks and VMess+TCP. Simultaneously, Outline lead developer Vinicius reported “a drop in the opt-in Outline usage metrics in China starting on November 8”. The start of this blocking coincides with the Sixth Plenary Session of the 19th CPC Central Committee (中国共产党第十九届中央委员会第六次全体会议), which was held from November 8, 2021 to November 11, 2021.
On November 14, 2021, the researchers confirmed that the Great Firewall (GFW) of China is now able to inspect and dynamically block any seemingly random traffic in real time. This capability potentially affects many censorship circumvention protocols that use encryption to appear random, including (but not limited to) VMess+TCP, Obfs4, and many variants of Shadowsocks. The censor strategically applies this censorship only against connections from China to certain popular VPS (Virtual Private Server) providers, possibly to mitigate over-blocking caused by false positives in traffic classification.
In the full report, the researchers demonstrate how the GFW identifies and blocks seemingly random traffic and shares code that led to their conclusions. It then discusses the implication of this blocking incident.
To maintain reproducibility and promote transparency, the research includes code in-line throughout the article to help other researchers reproduce the findings. Please note that this code is explicitly designed to trigger (or subvert) this new censorship system, so understand the risks before running any of the below examples yourself.
## Summary
* The GFW can now dynamically block any seemingly random data in real-time based on passive traffic analysis without relying on its well-known active probing infrastructure.
* The blocking only targets connections from China to a few popular VPS providers outside of China, including Vultr, AlibabaCloud (Hong Kong and Singapore), and Digital Ocean (San Francisco, New York City). Amazon Lightsail, EC2, and Oracle Cloud are reportedly not affected.
* In many cases, after the TCP handshake, a single data packet containing only 1 byte of payload from client to server is sufficient to trigger blocking.
* Only TCP traffic can trigger and is affected by the blocking. UDP traffic cannot trigger and is not affected by the blocking.
* Once triggered, the GFW drops all **TCP** packets from the client to the server having the same (client IP, server IP, server port) for 120 to 180 seconds. Packets from the server to the client are not dropped.
* The blocking can happen on any port from 1 to 65535.
* While the traffic classification appears to be deterministic, the blocking is probabilistic.
This blocking incident reveals many interesting details of the nature of the censor. Understanding this nature will help us
1) better understand the censor’s capabilities and limitations, and;
2) predict its possible future moves.
### The censor’s active probing may have been rendered ineffective
The rollout of this new censorship system may be an indication that the GFW’s active probing infrastructure has become less effective due to recent community efforts. The censor has been using a combination of passive traffic analysis, active probing, and potentially human decisions to block Shadowsocks. Such an approach cannot effectively identify Shadowsocks, thanks to suggestions by Frolov et al. and the patches by developers in the community.
### The censor still attempts to avoid over-blocking
A key insight shared by Tschantz et al., after summarizing a large number of real-world censorship incidents, is that “[c]ensors use exploits for which packet loss results in under-blocking instead of over-blocking” (see Table V and Recommendation 5 of their paper).
This conclusion still holds for the current blocking incident, where the censor limits its blocking only to a few popular VPS providers.
### The censor may still be testing this new system
Some of the results also suggest that the censor is not yet fully confident in the new system:
- The censor limits its blocking to connections from China to a few popular VPS providers. If the censor were confident that its traffic analysis has very few false positives, they could have applied it to *all* connections to the outside of China.
- The censor does only short-term dynamic port blocking, rather than long term IP blocking. When using this approach, the censor only blocks the port for 120 seconds or 180 seconds. If the censor were confident in having few false positives, it could have blocked the entire IP address of servers for weeks, like what it had done when using its active probing approach.
- The censor’s blocking rule includes the client IP. If the censor were confident that the server was really a circumvention server, it could have blocked the port or IP of the server for all client IP addresses.
### Censor may tolerate more false positives during politically sensitive times
The start of this less accurate blocking coincides with the Sixth Plenary Session of the 19th CPC Central Committee (中国共产党第十九届中央委员会第六次全体会议), which may show that censor is willing to tolerate more false positives during politically sensitive times.
## FAQ
### I am a user running a Shadowsocks server. What should I do?
At this time, our recommendation is to use other data centers to host the server. We have informed the circumvention tool developers on how to mitigate this blocking.
### If my Shadowsocks server is updated to protect from active probing, am I still at risk?
Although the GFW still sends active probes to suspected servers, it can now conduct dynamic and real-time blocking merely based on passive traffic analysis, without using any information from active probing. In other words, even if the server can defend against active probing attacks, it is still vulnerable to blocking. We want to emphasize that this does not mean that defenses against active probing are not necessary anymore.
If your shadowsocks server is updated and accepting connections successfully, you may be running with an IP address the GFW is not yet targeting.
## How can I help?
The current blocking only targets some famous VPS providers, including Vultr, AlibabaCloud, and Digital Ocean. But it possibly does not influence Amazon Lightsail, Oracle Cloud, and others.
Please feel free to contact the researchers and let them know of any other cloud vendor that does or does not work.
Full Report: Exposing the Great Firewall’s Dynamic Blocking of Fully Encrypted Traffic
Exposing the Great Firewall’s Dynamic Blocking of Fully Encrypted Traffic