Noose woven with chain proxy--using stream encryption such as RC4-MD5 and chain proxy can paralyze the ss/r server

Some background (may include author's personal stuff)

• Although developers have repeatedly warned about the serious security risks of stream encryption, especially the stream encryption represented by rc4-md5, which is the favorite use of proxy providers (ie airports), and it is not as intuitive as "such 'simple' encryption methods can Save more resources and increase speed", on devices that support aes hardware acceleration, it does not perform as well as the more secure and more modern aes-gcm series encryption methods, and there is also chacha20-ietf-poly1305 on devices that do not support aes hardware acceleration. It is good to sound the alarm bell, or to explain patiently over and over again. In computer science, mathematics, and cryptography, it is good to use emotion and reason, but in exchange, it seems that you always don't understand, and there are evaluations such as "talking about yourself".
• The big news of last year's redirect attack decrypting shadowsocks stream ciphers is still fresh in my mind, but it only seems to prove that the "collective memory" of the users of most tools is far inferior to the Great Firewall and the technical team behind it, and the censors are changing with each passing day. A little too sentimental or even "carrying out".
• The vulnerability of this stream encryption originated from the vulnerability of the chain proxy and the RC4 encryption itself.

experiment

After the source code implementing the attack was made public, I tested the code with one of the developers of this project (also one of the developers of Qv2ray).

The process is not complicated either.

I initially planned to pull the source code to compile.

• Pull the source code (requires git installed)

 git clone https://github.com/Qv2ray/rc4md5cry

• Then it's a local build
• I found a big hole here. If I use the rust toolchain provided by rustup, the build can be successful, but the built binary file attack can not achieve the effect, whether I am on the vps of Debian9 or the local macOS.
• The rust toolchain installed using the pacman package manager can (I don't know how brew installed it), although the rustc and cargo versions of the two are obviously the same, I really don't understand rust.
• cd to the file rc4md5cry and run the cargo build command to generate an executable file under the target.
• give execute permission, run

 ./rc4md5cry --address shadowsocks server IP: server port\ --password shadowsocks password\ --rounds an integer value greater than 1024

• In short, because the binary file I compiled here went wrong, I finally used the binary file compiled by GitHub actions, and the attack can be successful whether it is on the mac side or the Linux side.
• successful attack performance
• The server will output "Too Many Open Files" followed by "Connection timed out". At this time, different from traditional denial of service attacks, the server CPU, memory, bandwidth and other resources are not necessarily consumed violently, but the ss/r service will be paralyzed.
• The effect is very shocking, try Bailing
• The following pictures are the logs of the attacked ss server using RC4-MD5 encryption

A brief explanation of principles that does not involve technical details, specific implementation, code and theory

Since the author is not a professional, the following principles are based on their own understanding, and may be inaccurate or even wrong. Welcome to point out and correct them, and thank the developers for their patience in explaining the principles.

• The principle of the attack probably involves: a weak and outdated stream cipher, a proxy chain and a loop created by the proxy chain.
• a weak stream cipher
• For example, RC4-MD5, the client and the server will use a key for communication, and due to the simplicity and vulnerability of RC4, it will be easier to calculate the key used for future communication according to the password of shadowsocks pre-shared by the server and client in a short period of time. , which is also a prerequisite for an attack.
• In fact, it is not limited to RC4-MD5. In theory, any non-negotiated algorithm (that is, the key is completely generated by the client, and the server does not intervene in the password generation) has the conditions to be attacked due to its own characteristics. It's just a matter of time and resources.
• One proxy chain, one loopback.
• This idea probably originated from the study of unencrypted web proxy (HTTP proxy). The normal proxy behavior is that the client informs the server (assuming A) to query the data of the target website, and the data flow is

 I (client) -> server (A) -> target website

• The normal chain proxy uses two or more proxy servers (A, B, C, etc.), and the data flow is

 I (client) -> server (A) -> server (B) -> target website

• So what can be done if this feature is exploited (abused) (used)?
• Paralyze the shadowsocks/r service at a very low cost without exhausting the server's cpu, memory or bandwidth resources
• All you have to do is make this proxy chain a ring. which is

 I (client) -> server (A) -> server (A) -> server (A) -> server (A) ->...—> server paralysis

• Each connection from A corresponds to an fd ( ie file descriptor ), and this fd is limited and can be obtained through ulimit -n. As long as the integer after rounds exceeds the upper limit, the proxy service will be paralyzed. And because the rounds of the attack can be increased infinitely, raising the upper limit will not solve the problem.
• What if it is forbidden to send data locally to the local loopback?
• In fact, this solution does not solve the actual problem, just add another server to the proxy chain

 I (client) -> server (A) -> server (B) -> server (A) -> server (B) ->...—> both servers are paralyzed

• A snowflake thus creates an avalanche along the cycle of agency chains.

What effect will this have?

• For individual users, I think most people don't have the luxury of streaking with the RC4-MD5.
• However, the airport does not know if it is because of unscientific delusions like "RC4-Md5 is more resource efficient as a weak encryption", although the developers have repeatedly clarified the fact (as above) that this type of encryption is commonly used and insisted.
• By the time the developers have unanimously decided to remove stream encryption from the software package, the lack of understanding escalates into an attack, although I really don't understand why developers who put in the time, effort, and intellectual effort to take a penny are so arrogant.
• Even if the airport has enough time to take the Great Firewall seriously, the cyberattacks of friends and businessmen cannot be ignored. Due to the emergence of this tool, it has never been so easy to paralyze the server at a very low cost, and there is no mitigation plan at present. What to say, embrace AEAD encryption, embrace SSL/TLS

Mitigation method (my own opinion, naturally contains a lot of private goods)

• Try to use a more advanced proxy protocol that uses SSL/TLS to camouflage and ensure transmission security. ss/r is indeed the sentiment of many over-the-wall enthusiasts. However, after all, the times are changing, and the high wall is growing. After all, only the ability to change with each passing day Grasp the amount of freedom.

• Many people love shadowsocks/R because of its simple and lightweight deployment. Compared with v2ray, trojan, etc., which need to build camouflage sites, apply for certificates, and modify relatively complex configuration files, it is much simpler. So it is not difficult to understand.
• Try to use a self-built proxy, but this puts forward higher requirements: "Linux, basic network knowledge and NGINX TLS configuration experience" and so on.

A little bit more thought!

• Because of the build issue that was going on for quite some time yesterday, it is recommended to use the binaries provided by GitHub Actions directly. (need to log in to GitHub account)

• To be able to come up with these attack methods, I really admire the creativity of the developers, and to realize them requires action and code level, admiration. (When will I get to this level?)
• I am also very happy and grateful that they have given me a lot of help and guidance. They are also beacons and inspirations for my self-improvement and self-change.
• Maybe I will write a tutorial on building an encrypted proxy in the future.