SS is the original, SSR is a third-party version derived from the original, compatible with the original protocol, and has some more camouflage functions (protocol and confusion) than the original.
There is also a lot of discussion about SSR on the Internet, both for and against, but for ordinary users. Whether it is SS or SSR, it can help you climb over the wall normally at present.
As for which version of the client you download, it all depends on whether SS or SSR is installed on the server of the SS account you purchased. The most original SS function can be used no matter which client is downloaded, but if you want to use SSR's functions (protocol and confusion), you must download the SSR client.
But don't worry, all the nodes we provide support SS and SSR compatibility. It is recommended to use SSR. Faster to prevent being harmonized!
There was a lot of noise about Shadowsocks some time ago, and recently it is clear that a large number of novices have been attracted to the so-called "Shadowsocks Enhanced" (ShadowsocksR). As an amateur developer of implementing Shadowsocks in C++/Qt, I would like to briefly express my opinion on these two fried chickens.
ShadowsocksR
I don't know if the developer behind it has a background or a team, but what I do know is that its author did close source the Shadowsocks C# client for its secondary development in violation of the GPL. We won't talk about other factors here, the fact is that the GPL is very clear in black and white, violating is violating. But the author then open-sourced the codebase, which can be regarded as the end of an incident, and there is no need to pursue it further.
Things changed after Clowwindy emptied its Shadowsocks codestore. The following are just a list of facts:
The ShadowsocksR author has said that he wants to start from scratch to write a new proxy tool that is not related to shadowsocks, and will no longer update ShadowsocksR
Two or three days later, ShadowSocks was ordered to be deleted, and the original Shadowsocks project basically disappeared
The author of ShadowsocksR said that the original shadowsocks protocol was flawed (discussed in the next section) and returned to focus
The ShadowsocksR author has established a Google+ Group and updated the ShadowsocksR related code
Shadowsocks security
Now, let's start with the description of the ShadowsocksR author's claim that the Shadowsocks protocol flaw is that the length of the IV is 16 bytes in most cases. The latter half is correct, many encryption algorithms use IVs that are 16 bytes long (especially the popular AES and RC4-MD5), so what? This does not introduce so-called "defects" for the following reasons:
The IV of each TCP connection at the handshake stage is randomly generated, not calculated from the password, so the IV is unpredictable.
Without the key, even if this part of the IV is intercepted, the ciphertext cannot be decrypted. And each new TCP connection uses a randomly generated IV, that is, the data intercepted from different TCP connections has little in common. Decrypting ciphertext requires both the correct IV and the cipher, and any connection has no characteristics about the cipher.
Most IVs are 16 bytes long, which is a possible combination of 256 to the power of 16, and it is impossible to brute force crack when all IVs are the same, let alone add a second point.
According to ShadowsocksR's approach, it is useless to add the so-called obfuscation header before the first connection, its own characteristics are obvious, and it does not change the essence of the later IV or fixed length at all. Because the fourth byte tells you the length of the randomly filled data, as long as you skip the previous pile when performing the so-called "probing", you can still intercept IV. And as I said a few points ago, it's useless if you get this random IV. If it is used for detection, the fixed first version of the logo is the naked feature sent for identification.
The author of ShadowsocksR currently provides an active detection script that can be used to detect whether the server is running shadowsocks, and according to the current online test reports, the success rate is not low (but not 100%). In this regard, Clowwindy has already given an auto ban solution in the original version, automatically blocking these malicious IPs. I just added a patch to libQtShadowsocks and this patch blocks the detection of this method, which returns random strings of random length according to random probability.
However, this does not mean that the Shadowsocks protocol is perfect, but that ShadowsocksR's "solution" is crooked because its focus is crooked. My personal idea is to use public keys and private keys to improve security, although it is not very friendly to novices, but the security will be improved, and the characteristics will be reduced (no need to send IVs at the handshake stage), and the shadowsocks protocol needs to develop in the direction of CCA security.
Updated 05-Sep-2015
Once the header error (cannot be resolved) is found, the wrong IV and IP will be added to the failed IV and IP list, if the IV already exists in the failed IV list, or the IP already exists in the failed IP list, the IP that sent the connection request will be added to the blacklist, and the IP in the blacklist will directly reject the connection. For the latest details on anti-detection, please refer to this issue, and this article will not update the countermeasures for anti-detection.
Updated 06-Sep-2015
This article just wants to tell you not to worry too much about the security of Shadowsocks, the current protocol has not yet had major vulnerabilities, and the servers of the main ports are also being updated to fix potential threats. I have also communicated well with the author of ShadowsocksR, and it will be a while before the whitelist arrives.
Updated 24-Sep-2015
The Shadowsocks security mentioned in this article refers more to the security of the server, and the current protocol has the risk of exposing the server to brute force detection and then being blocked by firewalls (although the cost of detection is very high). The security of the transmitted content is not to be worried, all of which are industrial-grade high-strength encryption algorithms (except RC4 and TABLE), and it is almost impossible to crack the transmitted content.
Updated 18-Nov-2015
Shadowsocks has improved its security against CCA by adding a single verification, and major ports have already completed their support. It is important to reiterate that the goal of Shadowsocks is not to be 100% bug-free or 100% bullet-proof, but to ensure that the connection is lightweight and fast while making mainstream attack methods too expensive to implement.
|
Posted on 11/10/2017 12:41:35 PM
|
|
|
