Long-term Shadowsocks Plan: ShadowsocksR versus Shadowsocks2

[x0r2d2]

Hey all, It will be better to use ShadowsocksR instead of Shadowsocks, because with SSR traffic is obfuscating and SSR uses more secure encryption protocols.
https://github.com/breakwa11/shadowsocks-rss https://github.com/breakwa11/shadowsocks-rss/wiki

[jlund]

This looks very promising from a cursory glance at the code and some machine translation. Are you aware of any English documentation?

[x0r2d2]

Are you aware of any English documentation?

@jlund Most of documentation is on Chinese. I am using Google translate to understand them.

[atulsian89]

@jlund I have shadowsocks R on a Openvz vs using this script. It works as a regular shadowsocks but when I tested the additional obfuscation features it didn't work.

https://shadowsocks.be/9.html

[x0r2d2]

@jlund

https://shadowsocks.be/9.html

This one is better https://www.91yun.org/archives/2079

@atulsian89

but when I tested the additional obfuscation features it didn't work.

What does this mean? Which obfs feature did you use?

[atulsian89]

@hybtoy sorry for not being clear. I have tested it long back. I remember testing this option tls1.2_ticket_auth when I tried it first time. Will spin a new server and will let you know how it goes.

[x0r2d2]

@atulsian89 what you have been testing actually? Do you know what is the purpose of the obfs in SSR? :)

[atulsian89]

The internet was not getting connected after I selected tls1.2_ticket_auth option. I couldn't figure it out why it was not working, hence, I rolled back to shadowsocks libev version.

[x0r2d2]

The internet was not getting connected after I selected tls1.2_ticket_auth option. I couldn't figure it out why it was not working, hence, I rolled back to shadowsocks libev version.

It could be because of DPI, I had the same issue. After that I switched to http_simple and it works fine. The main goal of the obfs in SSR is to bypass QOS of the wall in China, because the international bandwidth is limited. If your international bandwidth is not limited, you don't need to use obfs. Sometimes it is better to use it without obfs.

Translated from Chinese to English with Google Translate and corrected by me:

If you do not consider the original case, the recommended protocol only auth_sha1_v4 and auth_aes128_md5 and auth_aes128_sha1, the recommended obfs is only plain, http_simple, http_post, tls1.2_ticket_auth

Do not be surprised why one of the recommended obfuscation is plain, because the obfuscation is not always effective, depending on the strategy of the region, sometimes not obfuscated traffic looks better like random data than obfuscated

[atulsian89]

@hybtoy I think you are correct. I never tested it again though. As you said the obfs depends on the strategy of the region, not sure which one will jlund will prefer using in the script?

[aanwark]

Any easy to follow guide about how to setup SSR on server and client side? I am facing problems with SS OTA and would like to try it out. A quick glimpse on SSR-libev README shows that it is not difficult to setup, however I would like to see some detailed info about how to setup the server and client side configs.

Plus I wanted to ask: are there any differences with respect to performance and speed between these two protocols? Does SSR fare any better than SS?

[jlund]

I'm still trying to find good documentation too. I'm not at all opposed to bringing this to Streisand if it's the right choice, but I feel like I'm missing important context when reading things via Google Translate.

The upcoming Shadowsocks protocol fork (Shadowsocks2?) also looks promising. Developments there are easier for me to follow because most of the discussions have taken place in English.

Exciting times on the SS* front!

[x0r2d2]

Any easy to follow guide about how to setup SSR on server and client side?

For server side: use this script https://www.91yun.org/archives/2079 For client side: Windows, Mac or Linux?

Plus I wanted to ask: are there any differences with respect to performance and speed between these two protocols? Does SSR fare any better than SS?

SSR is more secure but SS is faster.

Try this setting of SSR: chacha20 (encryption) + auth_sha1_v4 (protocol) + plain (obfs)

[aanwark]

I was able to setup SSR successfully on the server and client side using the repo below: https://github.com/shadowsocksr/shadowsocksr (Python port of SSR)

I used the wiki of https://github.com/breakwa11/shadowsocks-rss to setup the server and client configurations.

For client side: Windows, Mac or Linux?

@hybtoy I use Linux. I was wondering if there is any GUI client for Ubuntu/Linux Mint. Do you know about it?

I am still confused about the role of obfs and protocol fields in the configs 'json'. I am not sure how to set them up. But I used the default parameters "http_simple_compatible" and "auth_aes128_md5" and they worked fine. However, I couldn't see much difference between speeds of SS OTA and SSR. Perhaps there is some issue with my ISP. I would love to know, whether it is affected in other parts and ISPs of China though.

Try this setting of SSR: chacha20 (encryption) + auth_sha1_v4 (protocol) + plain (obfs).

I set it up but couldn't see much difference. I will update my comment while I check it out for a longer amount of time.

[x0r2d2]

I use Linux. I was wondering if there is any GUI client for Ubuntu/Linux Mint. Do you know about it?

https://github.com/erguotou520/electron-ssr/releases But not all protocols supported

I am still confused about the role of obfs and protocol fields in the configs 'json'.

As I know, obfs is used to cheat/bypass QOS in China because international bandwidth is limited.

[aanwark]

Exciting times on the SS* front!

@jlund I support that. Streisand users in China heavily rely on SS therefore it would be good to have more reliability in this area. As to the subject of this discussion, I think using SS and SSR concurrently with streisand might be possible. There is no need to replace one with the other. And since setting both of them up is almost same, therefore I think that adding SSR support would require less effort. One thing I particularly liked with SSR is the definition of multiple ports: each having their specific encryption, obfs, protocols and passwords defined in a single config file on server. It gives the client independence of using alternate ports. I am not aware if this can currently be done with SS or not.

https://github.com/erguotou520/electron-ssr/releases But not all protocols supported

@hybtoy Thank you for sharing this.

[jlund]

I don't think that we want to run the forked and original Shadowsocks variants side-by-side. The level of duplicated functionality between the two is already high, and this is especially true with all of the recent protocol developments in the non-R variant.

Now that we're no longer in a bad place with a missing Shadowsocks repo, I want to take the next couple of weeks and observe what happens. Progress on Shadowsocks2 (the protocol revamp from the non-forked version) is flying along. The new updates appear directly inspired by the work that was done in ShadowsocksR, and tickets like this one and the other SIP enhancement issues give me the impression that Shadowsocks2 (or whatever it ends up being called) has the potential to become the best of all worlds with the widest range of client support.

For example, support for obfs transports in Shadowsocks is actively being worked on and there is already an Android client in the Play Store that supports it.

The new Go implementation for Shadowsocks2 is looking good too. My hope is that it will provide native Ubuntu 16.04 packages, but compiling Go programs is really simple. Or we can stick to the libev variant and build it from source a la the commit I pushed tonight. Or we can switch to ShadowsocksR.

These are all decent options, but I want to pick the best long-term path forward before devoting time to its implementation.

[riobard]

@jlund Thanks for the kind words! I'm the author of the new Go port of Shadowsocks, and I initiated SIP007 which is also adopted by the libev port. As it stands now, latest version of Shadowsocks with AEAD ciphers using per-session subkey offers much better security and performance is excellent on modern hardwares.

We at Shadowsocks.org are finalizing the protocol design and will start the difficult job of convincing client developers to adopt the new revision. It will take some time, but we're confident that it points us to a better way forward.

Please let me know if you have any issues or concerns, and we can help to eliminate the pain for you to integrate into your project.

Thanks!

[x0r2d2]

@riobard Thanks for the news regarding new SS ciphers.

As it stands now, latest version of Shadowsocks with AEAD ciphers using per-session subkey

As I understood, every new session will have it own key? It will be automatically generated or ...?

Thanks.

[riobard]

@hybtoy We have a detailed discussion about this in SIP007 https://github.com/shadowsocks/shadowsocks-org/issues/42

[jlund]

@riobard Excellent. I really appreciate the offer to help, and keep up the great work! I think the biggest thing that I can think of outside of an official 16.04 package would be implementing backwards compatibility on the server in order to allow a mix of old and new clients to connect seamlessly. That should make the transition really straightforward.

It looks like this layer already exists in your new Go implementation! The separation between shadowaead and shadowstream is exactly what I was hoping to see. I assume that it's possible to run both protocols simultaneously?

[riobard]

@jlund Interesting. There have been quite a few people asking for a single Shadowsocks server simultaneously support more than one cipher/password combo. I'm not aware of any implementation currently being able to do so. Let me discuss this with other implementers and see what they think. It might make management complicated, though.

On the other hand, it's always possible to run multiple instances of the server, each using different config parameters. Would you be fine with such setting?

[jlund]

@riobard Yeah, that's what I meant. Sorry about the confusion. Ideally we can avoid running multiple different daemons (e.g. needing different binaries/packages installed for legacy and new protocols), but separate invocations of the same package would work just fine. The configuration and documentation for each OS/client can be modified to point to different ports/settings as clients are updated to speak the new protocol.

[x0r2d2]

@jlund This script https://teddysun.com/486.html allow to run multiple shadowsocks instances on 1 server. Give it a try.

[ortonomy]

Sorry to ask about this again, but Shadosocks-NG dev just made latest release with OTA deprecated. Eager to know streisand can now use AEAD and if that will still be resiliant against GFW.

https://github.com/shadowsocks/ShadowsocksX-NG/releases/tag/v1.5-alpha

[aanwark]

@ortonomy I think it is pretty simple to change the config file of shadowsocks with current Streisand's installation. However, the biggest caveat is that AEAD is still not supported on the client side, I am talking about the GUI clients in specific. However, if you are comfortable with CLI then perhaps it won't be an issue. P.S. In case of changing config manually, your generated instructions will also become invalid.

[ortonomy]

@denoza - I agree. I've been keeping a pretty close eye on the Shadowsocks-NG implementation and it's developer is becoming more communicative.

He just posted this on one of the issues that I posted there:

https://github.com/shadowsocks/ShadowsocksX-NG/issues/260

Have embed latest ss-local in 1.5-beta

And that latest ss-local I think supports AEAD. I'm just not sure where to go next.

Does it make using Shadowsocks more secure and more resilient to GFW detection? And now that it's in the GUI client, will it be turned on by default in new Streisand setups?

[joopdo]

But any way, seems like most clients are dropping OTA already

[ortonomy]

@joopdorresteijn - that's what I mean. So I want to find a way to continue to use my Streisand server, and still update my client, rather than staying on an old version, if OTA is being dropped.

[aanwark]

@ortonomy I am using AEAD on my Streisand's Shadowsocks instance. Shadowsocks-libev supports the chacha20-ietf-ploy1305 cipher (on both client and server sides). However, I wasn't able to use aes-256-gcm. I didn't dig much into it since chacha20* seems to do the work just fine. I am not sure yet as to how does it improve confidentiality. The official site states that AEAD guarantees authenticity in addition to confidentiality though. I would also like to know how does it provide better GFW evasion?

[ortonomy]

@denoza - you say you're using AEAD - did you have to turn it on? Is there a flag? I thought chacha20 etc were encryption algos? Nothing about AEAD with them? By the way, I'm very ignorant when it comes to cryptography.

[ortonomy]

@denoza - also, are you using Shadowsocks-NG on a mac?

[aanwark]

@denoza - you say you're using AEAD - did you have to turn it on? Is there a flag? I thought chacha20 etc were encryption algos? Nothing about AEAD with them? By the way, I'm very ignorant when it comes to cryptography.

@ortonomy shadowsocks official site https://shadowsocks.org/en/spec/AEAD-Ciphers.html mentions a list of AEAD ciphers. I would suggest you to have a look on it. It mentions that chacha20_poly1305 and aes-256-gcm etc are AEAD ciphers. As far as I know, there is no flag to turn it on. I am sharing my config.json here for your guidance.

{ "server":"xxx", "server_port":xx, "local_port":1080, "password":"xxx", "timeout":600, "method":"chacha20-ietf-poly1305", "fast_open":true }

In addition to this, https://shadowsocks.org/en/spec/Stream-Ciphers.html mentions a list of stream ciphers. Simple chacha20 is mentioned as a stream cipher, along with others like aes-256-cfb etc. Interestingly, if I try OTA with AEAD ciphers, shadowsocks-libev spits out an error, which means that my config is right. I just have one issue, while trying aes-256-gcm I can't get it to work, perhaps chacha20-ietf-poly1305 comes with libsodium and therefore it works. Do I have to install some specific library to get gcm ciphers to work? I don't know!

@denoza - also, are you using Shadowsocks-NG on a mac?

I am using shadowsocks-libev on my Linux Mint 18.1

[OneHappyForever]

I'm a little new here. I know about shadowsocks and shadowsocksR, but what is this new shadowsocks 2 that you guys are talking about? Is it pipe socks? Do you have a link to their GitHub repo, or website?

[riobard]

@OneHappyForever https://github.com/shadowsocks/go-shadowsocks2

[cpu]

I've filed https://github.com/jlund/streisand/issues/586 and started working on a branch to update to the latest shadowsocks-libev release and the chacha20-ietf-poly1305 ciphersuite. I believe this will at least partially address this issue but I haven't started to look at the client-side for the gateway portions of the role.

@riobard go-shadowsocks2 looks like a really interesting alternative and I think it might end up being a better fit for this project long term. I'm interesting in packaging another Go tool in the future and would be in a better place to switch shadowsocks-libev for go-shadowsocks2 at that point. For now I'm going to punt and try to fix up the role Streisand has already.

[riobard]

@cpu Thanks for your hard work! :)

For now shadowsocks-libev is more feature-rich (e.g. TCP Fast Open and plugins) with better backward compatibility. It's currently the de facto reference implementation. See this page for a brief comparison between actively-maintained official implementations https://shadowsocks.org/en/spec/Implementations.html

The downside is that the libev port is difficult to compile due to its vast dependencies, and the plan to offer precompiled binaries for common platforms was rejected (see https://github.com/shadowsocks/shadowsocks-libev/issues/1355). Therefore we rely on distributors to offer up-to-date versions. Additionally, the libev has dropped support for Windows.

My initial goal of go-shadowsocks2 is to offer an alternative implementation aiming for easy of deployment. That means we'll offer prebuilt binaries for common platforms (Linux/macOS/Windows) and architectures (x64/x86/ARM). It should make the job easier for distributors as they don't need to worry too much about dependencies.

[riobard]

@cpu BTW I'm currently experimenting with pre-release builds on my fork here https://github.com/riobard/go-shadowsocks2/releases

[heri16]

Everyone should just take a look at https://github.com/fuckshadows already.

[cpu]

@riobard Thanks for the additional context! I found Issue #1355 about prebuilt packages while looking into this. I'm also keen to drop the compilation & dependencies of the libev project :-)

[riobard]

@cpu Great! In that case you might want to try my pre-built binaries and see if they work OK :)

[cpu]

@riobard It's on my list :-) Since there are folks already waiting for improved shadowsocks support and a large backlog of other things to look at I want to get the existing role updated first. One (modest) concern I have is about the lack of TCP Fast Open support in your project. I'm not a shadowsocks user myself, so I'd like to hear from existing users about how important that feature is to them before we drop it outright. Sound reasonable to you? You're of course also welcome to start a branch yourself and begin experimenting :microscope: :woman_scientist:

[cpu]

Everyone should just take a look at https://github.com/fuckshadows already.

@heri16 Without more context & rationale this isn't a very constructive comment. Can you elaborate? The mention of it being a "self-designed protocol" seems like an immediate disadvantage and a large departure from the existing service.

[riobard]

@cpu TCP Fast Open (TFO for short) is a highly desired feature as it will shorten the Time-To-First-Byte by reducing the time for TCP handshake. The effect should be more measurable if the client has a large latency to the server.

The lack of TFO in go-shadowsocks2 is primarily due to the lack of support in Go itself. There's alreay a proposal to add it in Go 1.9. Once Go 1.9 comes out, go-shadowsocks2 will support TFO automatically.

[cpu]

@riobard Thanks for the information! Once go-shadowsocks2 supports TFO by way of a Go 1.9 release I don't see any reason not to try switching. If any existing users of the current shadowsocks-libev service think there would be a downside hopefully they speak up soon :-)

[riobard]

@cpu Great! Go 1.9 release will come around later this year. By then go-shadowsocks should have become more mature and stable. Look forward to the future integration :D

[OneHappyForever]

My question is, does Windows, Mac OS, Android and iOS clients support TFO? If I understand correctly, only works between Linux or routers?

[cpu]

My question is, does Windows, Mac OS, Android and iOS clients support TFO?

@OneHappyForever - TFO is a server-side optimization. I don't think there are any client support questions to resolve for that particular feature. (I was wrong - see below)

[riobard]

Actually to get TFO to work, we need all of the following:

1. Server OS support.
2. Server application needs to explicitly enable TFO using setsockopt.
3. Client OS support.
4. Client application needs to use sendto instead of connect + send.

Linux has better support for TFO so far. I've asked a friend developing for iOS and Mac today, and he said iOS and Mac support for TFO seems to be unstable.

No sure about Windows, but Wikipedia says Microsoft Edge utilizes TFO on Windows 10.

[cpu]

I feel like I keep saying this but thanks again for the info @riobard :-) I stand corrected!

[riobard]

@cpu My pleasure to help :)