Authors: Anonymous, Anonymous, Anonymous, David Fifield, Amir Houmansadr
In our recent IMC'20 work (paper, talk) we provided insight into the combination of traffic analysis and active probing techniques that the Great Firewall uses to detect and block Shadowsocks servers.
In this short post, we provide practical suggestions for non-technical users and circumvention tool developers to prevent their circumvention servers from being detected and blocked. We also introduce the mitigation to partitioning oracle attacks newly demonstrated by Len et al.. If your Shadowsocks servers still get blocked, even when you follow the instructions below, please report the block to GFW Report and/or the corresponding developers.
According to our own testing, and reports from developers, with proper configurations, there are at least two Shadowsocks implementations whose latest releases are resistant to the GFW’s active probes: Shadowsocks-libev and OutlineVPN.
If you decide to use Shadowsocks-libev, we strongly encourage you to follow this tutorial on how to install, configure and maintain a Shadowsocks-libev server. We commit to make that tutorial up-to-date and provide latest best practices to defend against emerging attacks against Shadowsocks.
If you already have a Shadowsocks-libev server installed, check the rules below to see if your servers have been properly configured.
As of January 2021, to prevent your Shadowsocks-libev server from being blocked, you have to:
v3.3.1 or above. You can check the server version with the command ss-server -h.chacha20-ietf-poly1305 (recommended), aes-256-gcm, aes-192-gcm or aes-128-gcm.To mitigate the partitioning oracle attacks against Shadowsocks servers, you need to:
openssl rand -base64 16;Note: there is no special requirement for the client. Any client compatible with the server is okay.
To prevent your OutlineVPN server from being blocked, you have to:
Note that:
chacha20-ietf-poly1305 (an AEAD cipher) as the encryption method, so you don’t have to select encryption methods manually.Below, we introduce our findings on the latest capabilities of the GFW; along with our suggestions for making circumvention tools more resistant to censorship. These suggestions are useful not only for Shadowsocks, but for other circumvention tools. We encourage you to participate in this discussion and we welcome any thoughts, comments, questions or concerns.
First of all, we strongly encourage circumvention tool developers to completely deprecate unauthenticated cryptographic constructions. Confidentiality alone is not enough.
Our seemingly bold suggestion comes for a good reason. As introduced in our paper, certain types of the GFW’s probes exploit the ciphertext malleability of Shadowsocks’s stream ciphers. This is not the first vulnerability caused by unauthenticated cryptographic constructions. In fact, the lack of proper authentication has been the root cause of many vulnerabilities in Shadowsocks and other circumvention tools.
In August 2015, BreakWa11 discovered an active probing vulnerability in Shadowsocks stream ciphers, resulting from their lack of integrity protection (see English summary). In 2020, similar vulnerabilities has also been discovered in other circumvention tools like V2Ray (see the summary). Shadowsocks developers mitigated the vulnerability by having the server not immediately terminate a connection when a target specification contains an unknown address type.
Shadowsocks developers attempted to further mitigate the problem by introducing a one time auth mode, in which each chunk of data would carry its own authenticator.
But a lack of integrity protection in chunk length prefixes led to another active probing vulnerability (see English summary).
In February 2020, Zhejiang Peng disclosed a devastating vulnerability in Shadowsocks stream ciphers (see English summary). Using the Shadowsocks server as a decryption oracle, an attacker, without knowledge of the shared master password, can get full decryption of recorded Shadowsocks connections.
As early as February 2017, AEAD ciphers had became part of the Shadowsocks protocol specification. While the authentication problem should have been fixed by that time, many servers are still using the vulnerable and deprecated unauthenticated stream ciphers in 2021. This phenomenon indicates that, in practice, many users cannot properly choose the right ciphers to use, possibly misguided by out-dated tutorials. We therefore encourage developers to help users make the right choice by completely removing stream ciphers from Shadowsocks.
We suggest that circumvention tool developers deploy a replay filter that takes into account both nonces and timing. Since a timing-based replay filter may require a fundamental changes to existing protocols, developers should at least deploy a nonce-based replay filter and:
These suggestions are based on the following research findings and rationale. As introduced in section 3.5 of the paper, the GFW can replay a legitimate connection immediately; or it may remember a legitimate connection but not replay it until three weeks later. Therefore, a realistic adversary model of active probing should permit the censor to perform replay attacks after an arbitrarily long delay.
Such a model reveals an asymmetry between attack and defense for purely nonce-based replay defense mechanisms. While it does not cost much in terms of resources for the GFW to record a few legitimate payloads and replay them after a fairly long delay, it is costly and complicated for Shadowsocks servers to remember the nonces of all authenticated connections forever, or until the master password is changed. The Shadowsocks server must remember those nonces even after being restarted; otherwise, the replay filter will be ineffective against replays that span a restart.
Fortunately, this unfair game can be inverted by the addition of a timing-based defense mechanism: the server only responds to authenticated connections that are not replays and whose timestamp is within an expiration time, similar to what VMess servers do. This way, the server does not need to remember nonces forever, but only for a limited time.
We also want to emphasize that a replay filter is required even in circumvention tools that use a random emphermeral open port per session. This is because the GFW may send a replay immediately after seeing the first data packet of a legitimate connection, before the session and the port are closed.
We suggest that developers make sure their circumvention tools react consistently not only in normal operation, but also when an error occurs. Ideally, as suggested by Frolov et al., a server should “read forever” on error. The reason for these suggestions is that censors may intentionally trigger protocol edge cases in an attempt to fingerprint servers.
In addition to the inconsistencies we found in Shadowsocks-libev and OutlineVPN, Frolov et al. demonstrated that various proxy servers, including Shadowsocks-python and OutlineVPN, can be identified using TCP flags and timing metadata after the servers close a connection. studentmain reported that, as of December 2020, various Shadowsocks implementations still have similar problems.
Frolov et al. suggest that proxy servers should read forever when errors occur, rather than terminating the connection. Doing so not only avoids revealing a specific timeout value, but also lets the server close the connection with consistent TCP flags in the non-error case.
Furthermore, reading forever will not make fingerprints of your circumvention tools more unique, as Frolov et al. found that a large number of endpoints exhibits such “infinite timeout” behavior. As surveyed by David Fifield, various popular circumvention tools have employed the “read forever” strategies, including OSSH, obfs4, Outline and Lampshade.
In 2020, Len et al. demonstrated partitioning oracle attacks against Shadowsocks servers. Exploiting the non-committing AEAD schemes used in Shadowsocks, an attacker can recover the password of Shadowsocks servers in a more efficient manner. We thus encourage the developers to enforce users to use strong passwords, possibly by setting entropy requirements for users’ passwords.
If you are a developer or contributor of a Shadowsocks implementation other than Shadowsocks-libev or Outline, we encourage you to check if similar vulnerabilities exist in your implementation of Shadowsocks. We have open-sourced the prober simulator we used in Section 5.1 of the paper.
We want to thank Vinicius Fortuna at Jigsaw, Robert Mitchell and Dan Fidler at APNIC, as well as DuckSoft and Student Main at Qv2ray for offering feedback to a draft of this post.
This report appeared first on GFW Report. We also maintain an up-to-date copy of the report on APNIC blog, net4people and ntc.party.
We encourage you to share your comments publicly or privately. Our private contact information can be found at the footer of GFW Report.