gfw-report
commented
3 years ago Two attacks against Shadowsocks (and VMess) are proposed and being discussed recently.
https://github.com/shadowsocks/shadowsocks-org/issues/184 is a replay-based DoS attack against Shadowsocks server. If an in-path adversary sends a replay of the legitimate connection to Shadowsocks server before the legitimate packet reaches the server, the server with a replay filter will not respond to the client due to repeated salt. See the English summary of the description of the adversary, the proof of concept and our comments on this attack: https://github.com/shadowsocks/shadowsocks-org/issues/184#issuecomment-791117571
https://github.com/shadowsocks/shadowsocks-org/issues/183 is a replay attack against Shadowsocks client. In the attack, the adversary first records a legitimate connection sent either from client to server or from server to client. It then injects this recorded legitimate connection to the client, as a forged response from the server. Since the replay is unmodified and authenticated, the client decrypts it as normal and sends the decrypted traffic back to the original program.
This attack may be used to identify Shadowsocks protocol. Assuming the underlying traffic being proxied was TLS, a replay above will trigger TLS alert and certain traffic pattern may be observed (although the traffic is still encrypted).
The weakness cannot be fully mitigated by a persistent and time + nonce based replay filter for Shadowsocks clients. When multiple Shadowsocks clients communicated with the same server, each client is not aware of the salt sent by other clients, and thus cannot detect replays of connection between the server and other clients.
The Shadowsocks community is discussing an upgrade to the Shadowsocks protocol and they are welcoming discussions and feedback. Previous experiences show that it can be something tricky to do right, we thus make this post to draw more attentions from the research community.
Authors: Anonymous, Anonymous, Anonymous, David Fifield, Amir Houmansadr
Date: Tuesday, January 26, 2021
中文版: 防御GFW主动探测的实用指南
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.
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.
For users
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.
Advice on using Shadowsocks-libev
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.1or above. You can check the server version with the commandss-server -h.chacha20-ietf-poly1305(recommended),aes-256-gcm,aes-192-gcmoraes-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.
Advice on using OutlineVPN
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.For circumvention tool developers
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.
Proper authentication
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 authmode, 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.
Replay filtering based on both nonces and timing
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.
Being consistent in servers' reactions
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.
Enforce using strong passwords
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.
Probe your implementations
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.
Acknowledgement
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.
Contacts
We encourage you to share your comments publicly or privately. Our private contact information can be found at the footer of GFW Report.