Authors: Anonymous, Anonymous
Date: Saturday, October 15, 2022
中文版：分享一个修改版的Shadowsocks，兼谈我们对猫鼠游戏的一点想法

In this post, we release and open source a modified version of Shadowsocks that can bypass the current GFW's detection and blocking. We first introduce the reason why this modified Shadowsocks can bypass the detection and blocking. We then share a simple tutorial on how to setup the client and server. We will also cover two other ways that help Shadowsocks and VMess bypass the current GFW's blocking. At the end of the article, we share some of our thoughts on the cat-and-mouse game of censorship. In particular, we start with answering why censor always starts the massive blocking a few days or weeks before politically sensitive period of time in China; we then argue that, comparing to the anti-censorship community, a fundamental weakness of censor is its inflexibility. We further discuss how to exploit censor's weaknesses to achieve better anti-censorship effect with limited resources.

Motivations

We release this modified Shadowsocks tool today for three reasons:

1. First, we want to provide Chinese netizens with a (temporarily) viable solution to bypass censorship, mitigating the GFW's massive blocking of multiple censorship circumvention tools since October 3rd, 2022.

2. Second, we would like to take this opportunity to start a discussion among anti-censorship researchers and developers. Our empirical research shows that the current GFW can already accurately identify Shadowsocks, VMess, and Obfs4 and many other full-encrypted protocols. We estimate that the GFW's current traffic detection algorithm has 0.6% false positives, while the false negatives are almost negligible. This finding urgently requires us to brainstorm and discuss how to improve the current protocols collectively.

3. Finally, we would like to use this release as an experiment to observe both the censor and the anti-censorship community on how fast each side can react to a new (anti-)censorship event.

Why can this modified Shadowsocks circumvent the GFW's current detection and blocking?

We worked with other researchers to discover that the current GFW utilizes a number of different rules to identify fully encrypted protocols like Shadowsocks, VMesss, and Obfs4. One of these rules takes advantage of the fact that the ratio of 0 bit to 1 bit in these encrypted flows is close to 1:1. Therefore, if we add more 0s or 1s to the encrypted traffic and then rearrange the bit sequence, we can achieve the goal of changing the original ratio feature to bypass detection and blocking.

How do I use this modified Shadowsocks?

This modified version of Shadowsocks is based on Shadowsocks-rust, and we also make use of Shadowsocks-android to compile the apk files for Android users. All client and server side software can be found at this branch and this release.

Installing the server

The installation process is the same as installing any other Shadowsocks-rust server.

1. First you login to your remote server, and then get the server binary with:

wget https://github.com/gfw-report/shadowsocks-rust/releases/download/v0.0.1-beta/shadowsocks-v1.15.0-alpha.9.x86_64-unknown-linux-gnu.tar.xz
tar xvf shadowsocks-v1.15.0-alpha.9.x86_64-unknown-linux-gnu.tar.xz

2. Then you create a configuration file:

sudo nano server_config.json

Copy and past the following settings to the file. Note that you need to replace the password ExamplePassword with a much stronger one. A handy way to do this from your terminal is: openssl rand -base64 16. You may also want to change the server_port.

{
  "server": "0.0.0.0",
  "server_port": 8388,
  "password": "ExamplePassword",
  "method": "aes-256-gcm"
}

After finishing editing, you type Ctrl + x to exit. The text editor will ask "Save modified buffer?", and you can type y and then hit Enter.

3. Now you can start running the binary with the configuration file, but to make it work even after you ended your SSH session, you may want to create a tmux session by:

tmux

You then do:

./ssserver -c ./server_config.json

Finally, type Ctrl + b and then type d to detach from the tmux session.

Firewall configuration

We use ufw to open ports for the Shadowsocks server.

To install ufw on a Debian-based server:

sudo apt update && sudo apt install -y ufw

Then open ports for ssh and Shadowsocks-rust. Note that if you set the server_port to a value different than 8388 in server_config.json, you need to change the value 8388 below accordingly:

sudo ufw allow ssh
sudo ufw allow 8388

Now enable ufw:

sudo ufw enable

If it prompts Command may disrupt existing ssh connections. Proceed with operation (y|n)?, type y and hit Enter.

Finally, run sudo ufw status, and the output should look like this:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
8388                       ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
8388 (v6)                  ALLOW       Anywhere (v6)

Client side configuration

Below is a configuration file for Client. Remember to change the server value from ExampleServerIP to your remote server's public IP address. If you used andorid and installed from the apk file we provided, the usage should be the same as usual.

{
    "server": "ExampleServerIP",
    "server_port": 8388,
    "password": "ExamplePassword",
    "method": "aes-256-gcm",
    "local_address": "127.0.0.1",
    "local_port": 1080
}

Limitation of the current implementation

• Since we made changes to the Shadowsocks protocol, it is not compatible with other Shadowsocks clients and servers for now. Users need to download the client and server we prepared.
• Currently, the clients only support Windows, Linux, macOS, Android phone, and Android TV. It doesn't not support iOS. We welcome iOS developers who have the ability to implement this modified protocol. We also encourage iOS developers to contact us and we will share other ways to bypass the censorship with you.
• In terms of encryption method, the modified version does not yet support Shadowsocks-2022. This is not because we intend not to support it, rather, it's just that we do not have enough time to do it yet. Our current recommended encryption method choices are: chacha20-ietf-poly1305 or aes-256-gcm.
• In terms of implementation, we have made changes directly on the core code. It's not because we want to start maintaining a separate folk of the Shadowsocks protocol, rather, we just have got enough time to make the modified algorithm a user-selectable option yet. We will actively communicate with the Shadowsocks developers and hope to eventually merge the new protocol into Shadowsocks as a user-selectable option.

Are you aware of any other ways to circumvent the current blocking?

We know of two other currently viable options, all of which utilize a different traffic detection rule by the GFW.

If you are a V2Ray user, you can turn on the ExperimentReducedIvHeadEntropy option to avoid the GFW's detection and blocking. The advantage of this option is that you do not need to make any changes to your servers.

@database64128 also implemented another way to bypass the censorship. Because the protocol is changed, it requires updating both client and server to use it.

Our thoughts on this cat-and-mouse game

We'd like to take this opportunity to share some of our thoughts on the cat-and-mouse game of censorship. Our views are based on our observations and reflections on both the censor and the anti-censorship community; we have also been deeply influenced by klzgrad, David Fifield, and many other anti-censorship developers and researchers.

Censor's timing choice of new blocking techniques

As many long-time Internet censorship observers have noticed, Chinese censors always start using their new censorship weapons on a large scale a few days or weeks before a politically sensitive event. In fact, such timing choices are no coincident. So what are the specific reasons? We suspect there are at least three reasons, and we encourage everyone to share their thoughts on them.

1. First, it is an important political task for censors to ensure that they have sufficient control over public opinion and information flow, at least during politically sensitive time periods. This task is often described in official parlance as "protecting the cybersecurity during such-and-such event".

2. Second, censors are willing to tolerate more collateral damage caused by false positives in detection during sensitive times. This nature provides new censorship weapons a more permissive trial-and-error environment when they are first put into use. Tschantz et al. analyze and summarize a large number of censorship incidents and find that "real censors tend to use vulnerabilities that produce underblocking but not overblocking" (see recommendation 5). And this tendency shifts slightly during politically sensitive times: censors become more tolerant of the collateral damage caused by false positives in detection in trade of a tighter social control. By deploying a new censorship weapon during such period of time, the censor's mistake will be more tolerated even if the tool caused any overblocking accident due to bugs that were not tested out in the prior phases. klzgrad shares a similar view in this comment.

3. Finally, and most importantly, a often overlooked reason is the fact that the GFW is actually trying to compensate for and cover up its fundamental weakness of inflexibility. In this cat-and-mouse game, the censors know that they are simply no match for the anti-censorship community in terms of responsiveness and flexibility. If they started deploying their new secret weapon long before the sensitive period begins, the anti-censorship community will have more time to study it and find new ways to bypass censorship. At that point, if they can't be flexible and fast enough to improve their censorship weapons, then their attempts to tighten their controls over the Internet during politically sensitive times will fall flat. David Fifield shared a similar point of view in this comment.

Censors have weaknesses

The censor's lack of flexibility is dictated by the nature of itself and the problems it faces. Specifically, it is itself part of a large bureaucracy, which inevitably leads to inefficient internal operations and rigid behaviors. And yet the problem it faces is as complex as monitoring and censoring network traffic on a national scale. It is not hard to imagine that a new censorship weapon always has to go through the procedures of early-phase research, grants application, more formal scientific research, product development, debugging, surveying on real-world traffic, experimental deployment, and then the final nationwide large-scale deployment and use. The length of the process can take quite a long time.

One may be wondering if it indeed takes such a long time for the censor to deploy a censorship weapon. Let's take this release as another experiment to observe how fast the censor and anti-censorship community can react. In particular, let's see how long it takes the censors to block our released tool that has many weaknesses.

How to exploit censor weaknesses?

Exploiting the censor's weakness, we came up with a few principles in hope they can make the anti-censorship efforts more effective.

1. Be more tolerant of imperfect circumvention solutions and do not give up on an imperfect circumvention solution too soon. As mentioned in the previous section, the fact that the GFW is less flexible than the anti-censorship community is often overlooked. And because of that, many circumvention solutions have been dismissed and killed prematurely simply because they "have weaknesses". This is often because when anti-censorship developers and researchers envisioning themselves as censors, they tend to focus on the first step for censor -- "pre-research" -- and thinking that a circumvention solution would be easily blocked; however, they actually underestimated the long process of funding applications, formal scientific research, product development, debugging, surveying real-world traffic, experimental deployments, and finally, nationwide deployment, that the real censors have to face. In fact, if an anti-censorship developer spends an afternoon rolling out a new anti-censorship tool, but it takes the censor a large amount of time, energy, human, material and financial resources to block it in six months, we have to say this "imperfect" tool served as a great leverage.

2. Increase the diversity of censorship circumvention solutions by letting a thousand flowers bloom. In many people's imagination, the GFW is a perfect censor because of its national-level resources; however, in reality, there are limited number of teams with the skills, ability, and resources to walk through all the procedures to make a censorship weapon from an idea to a real weapon deployed national-wide. Therefore, the more anti-censorship solutions the community can create, the less likely these limited resource censor teams will be able to block all tools in one go. And as long as there is one working circumvention solution left in one of these massive blocking event, the information is not disrupted completely.

3. Actively report new censorship events, promptly measure and understand new censorship techniques, and share the viable circumvention strategies with the community. Achieving this will require communication, effort, and cooperation between Chinese netizens, researchers, and developers. Encouragingly, we are now seeing more and more people joining this collaboration and working together as a collective.

4. Develop backup circumvention tools in advance. We have seen that the GFW makes up for its lack of flexibility by starting using its new secret weapons in large scale a few days before politically sensitive events. So can we use a similar strategy where we develop more backup plans in normal times, and then send them out just before sensitive times, like this release? This way, even if the technical staffs working for the GFW immediately spot any flaws in the new tool, and knew how to block the tool, it would still take them a long research and development cycle before actually being able to block it in real world.

Acknowledgment

We thank David Fifield for commenting on an earlier draft of this article.

Contact

We encourage you to share your thoughts, comments, user experiences publicly or privately. Our private contact information can be found at the footer of GFW Report.