Streisand: Long-term Shadowsocks Plan: ShadowsocksR versus Shadowsocks2

[hybtoy]

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?

[hybtoy]

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

[hybtoy]

@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.

[hybtoy]

@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.

[hybtoy]

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?

[denoza]

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!

[hybtoy]

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)

[denoza]

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.

[hybtoy]

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.

[denoza]

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!

[hybtoy]

@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.

[hybtoy]

@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

[denoza]

@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.

[denoza]

@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?

[denoza]

@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 :)

[tiliarou]

If I have an existing streisand installed from last year, and I want to move to the latest version from git, how do I proceed to update shadowsocks now that the installation of streisand fails due to no ubuntu 16.04 repo for shadowsocks ? does the push from 2 days ago solves this issue and will udpate shadowsock with the libdev version ?

[nodje]

@tiliarou I had to do that a couple of weeks ago, and in order to proceed I first had to delete outdated sources in /etc/apt/sources.list.d/ and manually upgraded my server to 16.04.
I could then upgrade git repo and run ansible scripts again.
It went smoothly at the beginning but the install couldn't finish properly (see https://github.com/jlund/streisand/issues/578). I now have a half baked server but Shadowsocks is working.

[tiliarou]

Thanks @nodje. But in my case my VPS (Aruba Cloud) was already in 16.04 LTS.
I'm getting numerous error during apt-update (on the VPS) due to shadowsocks repo, and I got the same error last week from streisand install process after updating git repo on my local Ubuntu (16.10).
So the solution would be to delete outdated entries in sources.list.d on my VPS 16.04 LTS ? and then running streisand install again from my local Ubuntu 16.10.

[nodje]

Yes, there use to be a specific PPA for shadowsocks that isn't needed anymore.
Anyways, if you run the main playbook everything will be recreated so there's nothing to fear.
But you can always back them up ;)
I'm not familiar with the playbook implementation but apparently the services configuration is kept, and so you'll be able to connect as you used to. (You can also find a way to backup this if it's crucial enough for you)

[tiliarou]

Getting error:
fatal: [89.40.xxx.xxx]: FAILED! => {"changed": false, "failed": true, "msg": "failure 1 running systemctl show for 'shadowsocks-libev': Failed to get properties: No such interface ''\n"}

[cpu]

@tiliarou Please open a new issue since your troubles are unrelated to the topic of this one. Thanks!

[hybtoy]

Hey all.
@jlund @cpu
Recently ShadowsocksR updated and update gave to community new protocol - auth_chain_a
All shadowsocks-libev users at least have to try it. As I think, it is better analog of SS with AEAD.
auth_chain_a can be used without encryption method because it is already encrypted, just protocol + obfs (if you are under QOS).
If somebody want to try, there is an auto-install script - https://raw.githubusercontent.com/hybtoy/shadowsocks_install/master/shadowsocksR.sh
Credits goes to - @breakwa11 @teddysun @91yun

[cpu]

@hybtoy Thanks for sharing!

As I think, it is better analog of SS with AEAD.

Can you explain why its better than just using shadowsocks-libev with AEAD mode? I don't understand why this new auth_chain_a protocol is preferred. Do you know if there are plans to make this part of the official Shadowsocks spec? Do any clients/servers other than ShadowsocksR support it?

[hybtoy]

@cpu
Advantages of ShadowsocksR:

1. As I know, SS with/with out AEAD can be recognized by packet size statistics.
2. Triple layer of security (cipher + protocol + obfs). Obfs is used to bypass/cheat QOS. With auth_chain_a the most secure protocol of SSR for now, cipher can be set to "none", because protocol already encrypted.
3. Avoid replay attack.
4. If you want to turn on/off obfs in your app settings on the fly, there is a compatible option.
   For example: server is set up to tls1.2_ticket_auth obfs option, if I will add compatible option to it tls1.2_ticket_auth_compatible, I can turn off obfs option in app settings and use SSR without obfs (plain mode). When you want it back, simply turn it on again in your app setting.
   Config:
   "method": "none", "protocol": "auth_chain_a", "protocol_param": "", "obfs": "tls1.2_ticket_auth_compatible", "obfs_param": "",

Do you know if there are plans to make this part of the official Shadowsocks spec?

What you mean? ShadowsocksR is fork of Shadowsocks Python.

Do any clients/servers other than ShadowsocksR support it?

Clients:
Windows - https://github.com/shadowsocksr/shadowsocksr-csharp
MacOS - https://github.com/shadowsocksr/ShadowsocksX-NG/releases
Unix: supported by default with command line
Android - https://github.com/shadowsocksr/shadowsocksr-android/releases
iOS:
Potatso 2 - https://itunes.apple.com/us/app/potatso-2-ultimate-network-tool-for-power-users/id1162704202?mt=8
Shadowrocket - https://itunes.apple.com/us/app/shadowrocket/id932747118?mt=8
Cross - https://itunes.apple.com/us/app/cross-network-utility/id1194595243?mt=8
Windows Phone: As I know, not supported.

[cpu]

@hybtoy Forgive me, I'm new to Shadowsocks overall & not an active user. I'm still confused...

Triple layer of security (cipher + protocol + obfs). Obfs is used to bypass/cheat QOS. With auth_chain_a the most secure protocol of SSR for now, cipher can be set to "none", because protocol already encrypted.

Is "auth_chain_a" the protocol in this case? Not Shadowsocks? Why is it the "most secure protocol"? I can't find any specifications for it except for this Gist: https://github.com/breakwa11/shadowsocks-rss/blob/master/doc/auth_chain_a.md

Avoid replay attack.

It sounds like there is some contention about this, with a nonce scheme potentially providing protection against "short term replay attacks" (?)

If you want to turn on/off obfs in your app settings on the fly,

I'm confused again, now you've moved to obfuscation. How does this relate to auth_chain_a? shadowsocks-libev already provides for obfuscation with simple-obfs.

Windows - https://github.com/shadowsocksr/shadowsocksr-csharp
MacOS - https://github.com/shadowsocksr/ShadowsocksX-NG
Android - https://github.com/shadowsocksr/shadowsocksr-android

I did a search on all three repos for the string "auth_chain_a" and didn't find anything. How did you determine these client support this feature?

Overall this seems to be a unique & probably under-supported feature that (so far) only you have voiced interest in. To be honest, I could only recommend Shadowsocks in good conscious to folks that find it is their only option - I'm skeptical of the protocol design & the amount of analysis done by the larger cryptographic community. I'm reluctant to spend too much time evaluating niche parts of the community for Streisand's purposes and would prefer to support it only for those that absolutely need it, and only in a stable & well supported config.

Thanks!

[hybtoy]

Is "auth_chain_a" the protocol in this case? Not Shadowsocks?

Yes, additional protocol of ShadowsocksR.

Why is it the "most secure protocol"?

It is most secure protocol of ShadowsocksR for now. https://github.com/breakwa11/shadowsocks-rss/blob/master/ssr.md

shadowsocks-libev already provides for obfuscation with simple-obfs.

ShadowsocksR by default using obfs for cheating QOS. On ss-libev it is implemented as plugin mode.

How did you determine these client support this feature?

Because I use them. After new protocol release, developers need time to add it to the their clients.

Overall this seems to be a unique & probably under-supported feature that (so far) only you have voiced interest in. To be honest, I could only recommend Shadowsocks in good conscious to folks that find it is their only option - I'm skeptical of the protocol design & the amount of analysis done by the larger cryptographic community. I'm reluctant to spend too much time evaluating niche parts of the community for Streisand's purposes and would prefer to support it only for those that absolutely need it, and only in a stable & well supported config.

In my restrictive network, only ShadowsocksR helps me to avoid censorship. Maybe one day it will be interesting for you. A lot of people using SSR instead of SS but they don't visit github and don't know about streisand at all. Sometimes you need to show to people something that will be good for them and they don't know about it. IMHO.
Thanks.

[cpu]

In my restrictive network, only ShadowsocksR helps me to avoid censorship. Maybe one day it will be interesting for you. A lot of people using SSR instead of SS but they don't visit github and don't know about streisand at all. Sometimes you need to show to people something that will be good for them and they don't know about it. IMHO.

Agreed - thanks for sharing your perspective!

I'm going to close this issue for now. In terms of the original issue topic "ShadowsocksR versus Shadowsocks2" the answer I have is "neither". We're going to continue to use shadowsocks-libev for the short term and longer term will likely replace that with go-shadowsocks2. I think any further discussion should be on a fresh issue described as a feature request.

Thanks all!

[ortonomy]

@hybtoy -

Do you know if there are plans to make this part of the official Shadowsocks spec?

What you mean? ShadowsocksR is fork of Shadowsocks Python.

Because the official Shadowsocks protocol spec is here: https://shadowsocks.org/en/index.html

This doesn't specify an implementation language, python or any other. That's what he meant. Is Shadowsocks R development independent of implementation.

[bluepeter]

Shadowsocks is generally dead in past few months or so where I'm at. shadowsocks-libev is a fools errand and blocked within minutes; same for all other variants I've tried (not tried the go SS2, but will do so shortly... looks like not much dev going on there now, compared to robust daily dev in SSR world).

@hybtoy is right that ShadowsocksR with auth_chain_a (with support from clients such as Potatso and others) is best bet. Pity, @cpu, if you don't see the writing on the wall as evidenced by the growth of SSR.

[hybtoy]

@bluepeter Join our SSR Group https://t.me/ssr_en

[cpu]

Shadowsocks is generally dead in past few months or so where I'm at.

@bluepeter Where are you at? This isn't helpful information I can do anything with unless the location & network are specified.

Pity, @cpu, if you don't see the writing on the wall as evidenced by the growth of SSR.

I haven't seen evidence of the growth, just two commenters! I think it's a stretch to call this the writing on the wall :-)

Why did the SSR folks fork instead of working with shadowsocks-libev and the rest of the existing shadowsocks community? Why haven't the improvements been folded back into the main protocol design? It seems unusual that the core shadowsocks community would be ignoring all of improvements you folks think SSR has.

The larger issue here isn't about ShadowsocksR per-say: it's about the proposal of a change that would either completely replacing the existing Shadowsocks work that we just recently updated, or deploying a brand new role/service/firewall exception for ShadowsocksR next to Shadowsocks and accepting the docs/confusion burden of explaining it to users. Streisand has an extremely small base of active maintainers (2? 3?). Needless to say, this requires strong evidence & consensus and I don't see it here.

Overall I'm extremely adverse to adding new services until it's possible to pick/choose which are deployed. From my personal perspective a base Streisand instance is much too large as-is. Once there is support for modularity and if someone was willing to submit a PR for ShadowsocksR then this might be a discussion I'd be interested in picking up again. Until then I remain fairly unconvinced and I hope you can understand the rationale I've taken the time to explain here politely. Thanks!

[cpu]

It is most secure protocol of ShadowsocksR for now. https://github.com/breakwa11/shadowsocks-rss/blob/master/ssr.md

One note: looking at the chart you shared again it does not list the ciphersuite we're using with shadowsocks-libev, so it's not fair to use this as a justification for being more secure.

[bluepeter]

I haven't seen evidence of the growth, just two commenters! I think it's a stretch to call this the writing on the wall :-)

Take a look at the SSR repos, their stars, and the larger community outside GH supporting them. As @hybtoy noted, not everyone knows about GH, and that should certainly not be a proxy for overall interest in a project. The scratchings on the wall are evidence of a groundswell of focus on this fork.

Why did the SSR folks fork instead of working with shadowsocks-libev and the rest of the existing shadowsocks community? Why haven't the improvements been folded back into the main protocol design? It seems unusual that the core shadowsocks community would be ignoring all of improvements you folks think SSR has.

I don't know. Perhaps you're not aware of the history of SS and what happens to folks in some regions who develop? You need to give wide latitude for this community to develop in a manner that might not be regular for the West. Language, culture, politics, and access figure into this equation.

Please don't let your privilege stand in the way of important developments.

[nodje]

Speaking of evidence (and not implying anything really, just sharing facts):
I'm just back from China where I have users relying on SS for their daily internet access. (both Streisand and ad-hoc ss-libev instances).

All in all it's still working well, I was using it myself from phone, computer, and it was good and stable.

I had one instance of an existing server in Singapore that used to work fine for more than a year and suddenly stopped being accessible from broadband (was still ok from 4G). It turns out it's the server I just upgraded to latest Streisand, with difficulty. I think this was a coincidence though. Maybe because it was used from different places in China was enough trigger a flag in the GFW.
My simplest option was to get rid of the IP and create a new fresh Streisand server. Users had to reconfigure their client but that was ok. And so far so good, even from different locations in China.

specs:
Server location were UK & Singapore, cipher were both very simple aes-cbc-128 and latest chacha20 (the default one from Streisand, can't remember from the top of my head)
Very few users per server.

[bluepeter]

Request to reopen this issue.

[nodje]

@bluepeter I bet being political here won't lead you anywhere, this is a tech forum. My 2cts.
I think cpu's last comment was pretty clear: it's not an easy thing to do, it'll take time.

Meanwhile, why don't you simply fork Streisand and replace SS with SSR?

[cpu]

I'm not totally comfortable revealing that, but I live in a country with > 1 billion people.

That's fair, I don't want anyone to do anything they are uncomfortable with.

I don't know. Perhaps you're not aware of the history of SS and what happens to folks in some regions who develop?

You're correct that I don't have a deep understanding of the history of SS. I've said as much earlier in the thread. Can you elaborate? What region are the folks that develop ShadowsocksR in versus the region that the folks that develop shadowsocks-libev? How does one avoid the fate of the other (if I'm reading between the lines right here).

Please don't let your privilege stand in the way of important developments.

Please try and give me some credit :-) I'm here engaged in the discussion in my spare time instead of doing other things & try my best to carefully consider the input of folks "on the ground" connecting through contentious networks.

I've asked some other folks I know in China and abroad that use our shadowsocks-libev server to evaluate this thread and weigh it against their experiences. It sounds like @nodje also has some relevant experience they've added.

Request to reopen this issue.

Since the discussion seems to have picked up steam I'm willing to reopen the issue while we all discuss.

[cpu]

@nodje Thanks for weighing in with your experience!

My simplest option was to get rid of the IP and create a new fresh Streisand server. Users had to reconfigure their client but that was ok. And so far so good, even from different locations in China.

I have heard this before for both shadowsocks-libev and for some of our other services. We've been discussing ways we'd like to make it easier to take an existing Streisand server/config to a new IP but it will likely be an improvement that has to wait until down the road when we've done less exciting groundwork.

[bluepeter]

Meanwhile, why don't you simply fork Streisand and replace SS with SSR?

It troubles me when SSR is rejected in favor of "SS2"/SS-libev due to non-extant translations or (non-)weigh-ins from the "larger cryptographic community." The latter solutions simply no longer work, and it's head-in-the-sand to push forward on those despite a clear groundswell of support for SSR in non-Western forums.

[hybtoy]

I think that Streisand maintainers use SS because it has a bigger English speaking community and they can understand and act accordingly on what is going on with the libev port of Shadowsocks.

In my region, SS-libev with AEAD cipher is not working normally, DPI and FW easily resets connection.
I have spent a lot of time to find solution and found SSR. It works perfectly for me now. I had a problem with the specification understanding, because documentation is on Chinese.
I used translator to understand them, joined the their group, where 95% speaking Chinese only and contacted creator of SSR, understood how it is working and decided to use it instead of simple Shadowsocks and till now I didn't have any issues. :)

@bluepeter what that project is? :)

[denoza]

I would like to put my two cents in this discussion. I have been an SSR user for almost three months now and my experience with it is fantastic. Contrary to SS with AEAD, which I have been using in parallel, in my experience SSR provides more stability and robustness, in a sense that my IP doesn't get blocked frequently. I have spun up the present server around 2 months ago and I don't face packet dropouts or latency issues. Perhaps SSR provides more security to me because my provider might be under QOS. While, with the latest SS-libev I experience latency issues after continuous usage for a while.

I had started using SSR after reading this thread and since then I configure it on my server besides streisand. To sum up, in my personal experience SSR is a better choice for now. SS-libev works, however the experience is not as smooth. Frequent packet dropouts and latency issues force me to switch to SSR.

[hybtoy]

Maybe it will be better to create PR with ShadowsocksR and ask Streisand's Shadowsocks-libev users to test it and provide feedback?
I am not coder, so I am asking professionals to make a PR with SSR and test it.
I can donate vps for this reason.

[ortonomy]

@bluepeter Who do you think you are?

Why not use SSR?

It troubles me when SSR is rejected in favor of "SS2"/SS-libev due to non-extant translations or (non-)weigh-ins from the "larger cryptographic community." The latter solutions simply no longer work, and it's head-in-the-sand to push forward on those despite a clear groundswell of support for SSR in non-Western forums.

Why does it trouble you? @bluepeter - you've got 2-3 people working on Streisand? They don't speak Chinese.

Imagine this: You run a service that is meant to help people gain secure internet freedom. You have something already in place, that is written in your language. You very clearly understand what it's capable of. Somebody, you don't know, says 'Oi! Use this service instead of the current one'. From what you can discern, it uses an unknown protocol and / or security mechanism. You don't speak the language or the documentation, discussions, or development of the proposal. You don't accept the proposal because of this. You're not going to learn Chinese just to evaluate this proposal, because you know, you do this shit in your spare time.

Pretty simple, really? And really well explained by @cpu. When making a claim about something else, regardless of its level of support, the burden of proof is on the people making the claim. The very eminently sensible suggestion has already been made by @nodje :

Meanwhile, why don't you simply fork Streisand and replace SS with SSR?

Then you could prove it. As has already been (rightly) questioned, why hasn't effort been put in to put ShadowsocksR back into the main SS?

And this:

Please don't let your privilege stand in the way of important developments.

Is just plain rude, not to mention complete guff and irrelevance. Who do you think you're defending and / or promoting here? Hiding behind the story of Clowwindy as: _'Perhaps you're not aware of the history of SS and what happens to folks in some regions who develop? _' is not good enough. I'm sorry. Yes, it's tragic, but suggesting that people shouldn't continue to contribute to the mainstream because it is a bit disingenuous. Do you think it's cursed? ShadowsocksR is still here on GH, just like the original development was, and people are still developing on GH. The authorities are not so dumb as to think that just because you put an -R after the name that it's different or not related.

You need to give wide latitude for this community to develop in a manner that might not be regular for the West. Language, culture, politics, and access figure into this equation.

@bluepeter LOL, wut?

You continue to completely ignore the rational and reasoned replies as to why SSR is not being considered at this time, and instead try to make it about somehow oppressing a development community and not given them enough attention:

As @nodje rightly said:

@bluepeter I bet being political here won't lead you anywhere, this is a tech forum. My 2cts.
I think cpu's last comment was pretty clear: it's not an easy thing to do, it'll take time.

It's you who needs to understand what you're dealing with.

So let's begin with the real talk:

Shadowsocks and shadowsocks-libev in China

I live in China, in Shanghai. I'm not so hyperbolic as to not be clear about that. I have 2 Streisand servers up and running:

1. Uses old Shadowsocks (with OTA) - works fine on Mac and with Potatso 1 on iOS
2. Uses new Shadowsocks with AEAD - works fine on Mac (with latest Shadowsocks-NG) and Shadowrocket on iOS

I've not had a problem with either, and the 1) server on digital ocean has been up for 6 months without interuption to service.

So, there's my first-person, first-hand evidence @bluepeter. I'm not making claims about anyone else's experiences, saying that 'you'd better use SSR because SS doesn't work anymore'. Unless you can verifiably say prove it's affecting ALL users or a majority of users, what you're requesting doesn't have weight.

[hybtoy]

@ortonomy The main point of this issue is that we wanted to offer better security options to Streisand users.

Of-course we can fork Streisand repo and update SS to SSR but isn't it better to make it known to all Streisand users and all of them will benefit from it?

If there is no interest from repo collaborators (@cpu and @jlund) at least to try to understand and use SSR, we just wasting our times.

[ortonomy]

@hybtoy - and they've given perfectly good reasons why they don't want to wholesale jump into it. They've asked you (unanswered) questions about why it's better.

Try to understand that saying things like:

It is most secure protocol of ShadowsocksR for now.

Is not proof. It seems like an opinion. And without insight into the development of this (in a language they can understand) they're going to remain skeptical.

and by the looks of @cpu 's comments, he's not uninformed. They have reasonable doubts and THE BURDEN of PROOF is on you.

And reading your comments, I found them confusing too.

Is "auth_chain_a" the protocol in this case? Not Shadowsocks?
Yes, additional protocol of ShadowsocksR.

Shadowsocks IS the protocol. A protocol is just a set of rules for communicating. It seems like the comparison of 'auth_chain_a' in the table you provided is comparing encryption algos, not protocols.

So which is it? auth_chain_a is an replacement protocol instead of SS? or it's a new encryption algo?

@cpu said:

Is "auth_chain_a" the protocol in this case? Not Shadowsocks? Why is it the "most secure protocol"? I can't find any specifications for it except for this Gist: https://github.com/breakwa11/shadowsocks-rss/blob/master/doc/auth_chain_a.md

He couldn't find any specifications for it! HELP HIM UNDERSTAND IT, before saying how good it is.

If there is no interest from repo collaborators (@cpu and @jlund) at least to try to understand and use SSR, we just wasting our times.

This is the point. They probably would try to understand it, but you do a very poor job of explaining it!

e.g

ShadowsocksR by default using obfs for cheating QOS. On ss-libev it is implemented as... _(ed: implemented as what?)_

You didn't even finish what you were saying!

[hybtoy]

@ortonomy Tell me one thing please, did you try SSR?

You didn't even finish what you were saying!

Thanks. I have corrected the post.

[ortonomy]

@hybtoy - no, because I have no idea where to start:

There's the shadowsockR organization: https://github.com/shadowsocksr and the shadowsocksR in libev, C#, python. But which one is active development?

The one you linked to is under breakwa personal account: https://github.com/breakwa11/shadowsocks-rss and is called ShadowsocksRSS and is completely in Chinese.

I rely on Streisand to deploy and install SS, so not only would I have to learn Chinese, I'd also have to learn how to build and install ShadowsocksR server, open up the right firewall stuff, etc.

I'd love to try it though.

[ortonomy]

More on confusing explanations:

@hybtoy said:

Triple layer of security (cipher + protocol + obfs). Obfs is used to bypass/cheat QOS. With auth_chain_a the most secure protocol of SSR for now, cipher can be set to "none", because protocol already encrypted.

What does this even mean?

Triple layer of security (cipher + protocol + obfs).

OK

Obfs is used to bypass/cheat QOS

OK, but what is the obfs mechanism? Is it part of ShadowsocksR? Or is it a plugin? How does it compare to other obfs mechanisms avaiable? Why is it important in China? What does it combat? You said QOS - but its this applied universally behind GFW? By which mechanism is QOS applied, and so how does obfs combat it?

With auth_chain_a the most secure protocol of SSR for now

Opinion, unverified

cipher can be set to "none", because protocol already encrypted.

WHAT? How is the protocol already encrypted? What by? Where? No explanation.

I'm not capable of unwrapping any meaning in this.

[bluepeter]

I rely on Streisand to deploy and install SS, so not only would I have to learn Chinese, I'd also have to learn how to build and install ShadowsocksR server, open up the right firewall stuff, etc.

Takes about 15 mins to setup this one on an EC2 instance following the instructions here: https://github.com/shadowsocksr/shadowsocksr

[hybtoy]

@ortonomy Yes, it is complicated for the first time. I am also didn't know where to start but later found a way.

https://github.com/breakwa11/shadowsocks-rss - In active development. Have everything that you need to connect to your SSR server.

There is a repo with server auto-install scripts, I forked them and updated for personal use. Try it. If you know how to install Streisand, it will be easy for to install server from script.

https://raw.githubusercontent.com/hybtoy/shadowsocks_install/master/shadowsocksR.sh

ShadowsocksR config by default:

Cipher: AES-128/256-CBC or libsodium ciphers

ShadowsocksR Protocol: auth_sha1_v4, auth_aes128_md5/sha1 and auth_chain_a (the best)

Obfs: Can be turned off by using "plain" option or use as http_simple or tls1.2_ticket_auth and tls1.2_ticket_fastauth

Take a look to config first and if you will additional questions, ask me.

[hybtoy]

@ortonomy You are quoting your questions. I am not able to understand what you are asking.

[riobard]

I've been watching this issue for a while and the recent comments by several SSR users spreading misinformation really piss me off.

The claim that SSR with its latest auth_chain_a protocol provides better "security" is bogus. In fact, security has never been a design goal for SS/SSR from the beginning. The current recommendation for SSR deployment is to use plain auth_chain_a with builtin encryption by RC4, a known broken cipher.

For those really concerned about security, SS now uses industrial-standard AEAD ciphers from the TLS 1.3 suite. Notably the default AEAD_CHACHA20_POLY1305 cipher has been analyzed by the large crypto community and chosen for its excellent security and performance. If you are paranoid, you should trust the leading crypto experts.

The claim that SSR is better against QoS throttling does have some merit, mostly because SSR has obfuscation baked-in. But the funny thing about QoS is that it varies across different regions and providers, and there's no silver bullet to fight it once and for all.

SS follows a modular approach with isolated protocol/encryption/plugin layers. Specifically, features like obfuscation are implemented as plugins with well-defined interface borrowed from the Tor project. It's much easier to port existing and battle-tested Tor PT plugins than wasting time reinventing wheels.

[hybtoy]

@riobard

You began from this:

In fact, security has never been a design goal for SS/SSR from the beginning.

And continued with this:

For those really concerned about security, SS now uses industrial-standard AEAD ciphers from the TLS 1.3 suite. Notably the default AEAD_CHACHA20_POLY1305 cipher has been analyzed by the large crypto community and chosen for its excellent security and performance. If you are paranoid, you should trust the leading crypto experts.

So why SS using industrial-standard AEAD ciphers from the TLS 1.3 suite if it was not designed for security?

[ortonomy]

@ortonomy You are quoting your questions. I am not able to understand what you are asking.

Excuse me? I'm not quoting questions. I'm asking you to explain.

Just listing out options is not explaining!

Cipher: AES-128/256-CBC or libsodium ciphers

So this is the cipher built-in to SSR?

ShadowsocksR Protocol: auth_sha1_v4, auth_aes128_md5/sha1 and auth_chain_a (the best)

So SSR has options for the protocol itself? CONFUSED

Obfs: Can be turned off by using "plain" option or use as http_simple or tls1.2_ticket_auth and tls1.2_ticket_fastauth

I don't give a crap if it can be turned off, I want you to explain what the hell they do and how they combat QOS use by GFW!

You gotta explains WHY these things are better than vanilla SS!

[bluepeter]

I don't give a crap if it can be turned off, I want you to explain what the hell they do

Chill.

[ortonomy]

❄️🍦

[hybtoy]

So this is the cipher built-in to SSR?

Cipher is loaded from openssl or libsodium.

So SSR has options for the protocol itself?

What is difference between simple openvpn and ssl tunnelled openvpn? Do I need to explain it to you?

SSR has self designed protocols to protect and hide the traffic of the users. It is the aim of SSR, hide connection, so machine can not easily track, filter and analyze it.

Do you know what is the aim of obfs?

With tls1.2_ticket_auth obfs option in SSR, our traffice will look like simple SSL traffic and it will be harder to filer and analyze it. Do you UNDERSTAND what I am trying to explain you?

I don't give a crap if it can be turned off, I want you to explain what the hell they do and how they combat QOS use by GFW!

Who do you think you are? You have been warned.

I will not explain you anything else after that. Open repository and read it. If you can not understand it, use translator. :)

[riobard]

@hybtoy Go read SIP004

[hybtoy]

@riobard I was trying to use ss+aead cipher but FW resets connection, so FW can analyze that this is ss or suspicious traffic. And same before AEAD ciphers, even with OTA.

After that I tried SSR and didn't have any problems with connection.

2 everybody,

Sorry for my English, if it seems bad to you.

Thanks.

[riobard]

@hybtoy There's no envidence that GFW does traffic analysis to target SS. What you're experiencing is most likely your local router or ISP QoS random traffic because it thinks you're BitTorrenting. Simple obfuscation as TLS or even HTTP traffic will resolve most cases like this.

[hybtoy]

@riobard only ISP or Router? What about firewall and DPI?

[riobard]

Firewall and DPI are applications running on either routers or dedicated machines. There's nothing special.

[ortonomy]

@hybtoy - sigh.

I'm not getting into a fight with you. I don't want you to explain what the do. I said _in comparison to_...

I'll say it again. If you want someone to buy in to a proposal, show how it's better than what's already out there.

I'll make myself clearer and say again.

*Vanilla SS as I understand it:*
Point to point SOCKS 5 proxy with support for multiple encryption algorithms.

<host> <ss-local> <---_encryption_-----> <ss-remote> <target>

That's it.

There are additional things you can 'plug in'. As @riobard said:

SS follows a modular approach with isolated protocol/encryption/plugin layers. Specifically, features like obfuscation are implemented as plugins with well-defined interface borrowed from the Tor project. It's much easier to port existing and battle-tested Tor PT plugins than wasting time reinventing wheels.

ShadowsocksR as I understand it:

<host> <ss-local modified protocol><obfuscation> <---encrypted connection-----><obfuscation> <ss-remote> <target>

So, forgive me for wanting to be able to understand ShadowsocksR in terms of an apples to apples comparison:

1. Encryption:

So this is the cipher built-in to SSR?
Cipher is loaded from openssl or libsodium.

I know where the cipher suites are from. But lets look at Shadowsocks.org spec:

Vanilla SS:
AEAD ciphers: chacha20-ietf-poly1305, aes-256-gcm, aes-192-gcm, aes-128-gcm
Stream ciphers: aes-128-ctr, aes-192-ctr, aes-256-ctr, aes-128-cfb, aes-192-cfb, aes-256-cfb, camellia-128-cfb, camellia-192-cfb, camellia-256-cfb, chacha20-ietf
etc.

Now

ShadowsocksR:
@hybtoy says:

AES-128/256-CBC or libsodium ciphers

1. Protocol:

This is where I'm confused and there seems to be where you're making claims for, but not really giving information beyond, 'it's better'. I'm not trying to annoy you, I just want to help people here understand:

So SSR has options for the protocol itself?

SSR has self designed protocols to protect and hide the traffic of the users. It is the aim of SSR, hide connection, so machine can not easily track, filter and analyze it.

Then I have questions:

1. So SSR has radically changed that protocol of vanilla SS?
2. If so:

ShadowsocksR Protocol: auth_sha1_v4, auth_aes128_md5/sha1 and auth_chain_a (the best)

Why do the 'protocol' names look JUST LIKE CIPHER SUITE NAMES?!?!

1. What: a) do differently to the original SS protocol? b) Can you give evidence that they do it better?

1. Obfuscation:

Do you know what is the aim of obfs?

Well, um, yes... but

@riobard says:

There's no evidence that GFW does traffic analysis to target SS. What you're experiencing is most likely your local router or ISP QoS random traffic because it thinks you're BitTorrenting. Simple obfuscation as TLS or even HTTP traffic will resolve most cases like this.

But then @hybtoy says:

Can be turned off by using "plain" option

Why emphasise it can be turned off? If it's so important?

Choice of obfuscation:

1. simple HTTP
2. tls_ticket
3. tls_ticket_fast_auth
   Which of the three options is best?

So finally, again:

SS follows a modular approach with isolated protocol/encryption/plugin layers. Specifically, features like obfuscation are implemented as plugins with well-defined interface borrowed from the Tor project. It's much easier to port existing and battle-tested Tor PT plugins than wasting time reinventing wheels.

This is the explanation I'm looking for @hybtoy - why is better than SS as implemented in Streisand.

[cpu]

I think this thread has become rather heated & the discussion is rapidly becoming unproductive (and too much for me to follow!).

As I said earlier I consider support for modular Streisand services that can be enabled/disabled the primary blocker for beginning to consider ShadowsoksR support in Streisand. I would say the same about adding any new services, Shadowsocks based or not. The other blocker is the actual development of ShadowsocksR support. There are a lot of strong advocates in this thread for Streisand adopting ShadowsocksR but no pull requests :-)

For me this conversation has to be on hold until the two things above are resolved. If the discussion can be kept constructive I will keep following it, otherwise I'll have to lock the discussion.

Thanks everyone,

[cpu]

@nickolasclarke - What is your experience using a shadowsocks-libev server from a more restrictive network

[hybtoy]

@ortonomy

So SSR has radically changed that protocol of vanilla SS?

By the way, what is the protocol of SS?

Why do the 'protocol' names look JUST LIKE CIPHER SUITE NAMES?!?!

1. What: a) do differently to the original SS protocol? b) Can you give evidence that they do it better?

Maybe because name of protocol describes which technology used to make it?
a)By the way, what is the SS protocol?
b)I have one major evidence for myself, SSR is only way to wok in my restrictive network. SS is not stable for me.

Why emphasise it can be turned off? If it's so important?
This is an additional option that comes by default, it has to have to be turned on or off when you need it or not.

Choice of obfuscation:

simple HTTP
tls_ticket
tls_ticket_fast_auth
Which of the three options is best?

fastauth is new, I didn't test it yet. I am using tls1.2_ticket_auth and I think it the best. So your traffic seems like simple SSL/TLS traffic.

[hybtoy]

Specifically, features like obfuscation are implemented as plugins with well-defined interface borrowed from the Tor project. It's much easier to port existing and battle-tested Tor PT plugins than wasting time reinventing wheels.

reinventing wheels? Are you kidding? If obfs already included (not as plugin) and using it by default is "reinventing wheels"?

[denoza]

I will express my opinion as a user rather than a developer here. After following this discussion, I tried configuring the simple-obfs plugin with my existing shadowsocks-libev server, which I configured via streisand. To my surprise, it is even better than the SSR server which I used previously. I usually get a latency of around 204-206 milliseconds from my home to LA Vultr VPS.

1. With shadowsocks without simple-obfs, the latency increases to 290-300 ms while I browse the internet.

2. With shadowsocksR having obfs configured, the latency increases to 250-270 ms.

3. However, with SS simple obfs, I am writing this comment now and browsing for almost 30 minutes while my latency is back to 204-208 ms.

The results might vary between locations and ISPs. In my particular case obfs helps. Though I think configuring the simple-obfs with existing streisand instance is not difficult at all. It took me less than 5 minutes to do so. However, for users at client end, who might have difficulty in dealing with this, I will suggest the developers to install the simple-obfs tool by default while the Shadowsocks installation task is carried out. We could give an additional option to users in the documentation about adding the required information in the JSON files (on the server and client sides), if they wish to use simple-obfs option.

I haven't worked on Ansible, so I might have to pass a learning curve. But I am willing to work on this if it is considered a good idea. However, a downside is that it might complicate the generated instructions at users' end.

[nodje]

@denoza any pointer on documentation for enabling simple-obfs ? Sounds interesting, I'd like to try that.

[nickolasclarke]

@nodje https://github.com/shadowsocks/simple-obfs is where the project is found and there is some documentation on how to use it.

@cpu my experience matches those of many others here who have said that shadowsocks-libev is working for them just fine in China. Our installation has anywhere from 20-50 concurrent users at any given time during the day, and I get excellent performance. I often run everything through shadowsocks if I am not using domestic sites because I get significantly better performance for even for foreign sites that are not blocked. This emphasizes the very LARGE role that good routing and peering plays for your installation, both with your local ISP and the particular data center being used. In other parts of the country I've seen much much worse performance with an identical setup but using a different local ISP and/or remote datacenter.

I think that trying out simple-obfs and or implementing some of the other plugins like KCP now supported by shadowsocks may help address some of the performance concerns people have. I think that sticking with the much better documented and still quite obviously active shadowsocks project makes the most sense for now. perhaps we could reach out to @riobard or others privately or publicly to help us understand what is considered "best practice" for optimum performance of SS these days.

[hybtoy]

As I know, Shadowsocks for Windows doesn't support simple-obfs, does it?
I can't find any information about it.

[cpu]

@denoza That's really interesting! Thanks for adding this experience to the ticket. I've opened a separate issue to investigate using simple-obfs: https://github.com/jlund/streisand/issues/741 To me this seems like a better path forward in the short-term because it can build on all of the existing shadowsocks-libev infrastructure.

@nickolasclarke Thanks for adding your experience. Hearing your take makes me feel better about the path I think Streisand should be taking here with respect to waiting on modularity and focusing on the existing shadowsocks-libev infrastructure until there is an easier way to optionally add components to Streisand.

We can't make everyone happy all of the time but I hope the folks that are left unhappy in the short term understand that this is a decision stemming from practicality and not xenophobia or ignorance :-)

[denoza]

@denoza any pointer on documentation for enabling simple-obfs ? Sounds interesting, I'd like to try that.

As @nickolasclarke mentioned, https://github.com/shadowsocks/simple-obfs is the place to begin with. After following the instructions, the easiest way is to add the relevant flags in JSON files. After that just restarting the services will do. I am not sure about the client side support for this feature. But as per my experience, shadowsocks-libev shows it as an experimental feature up until version 3.0.6, android client also supports it as I recall.

As I know, Shadowsocks for Windows doesn't support simple-obfs, does it?

@hybtoy I am not sure about that, since I use shadowsocks-libev on both server and client sides.

I think that trying out simple-obfs and or implementing some of the other plugins like KCP now supported by shadowsocks may help address some of the performance concerns people have.

@nickolasclarke After having a glance at shadowsocks/kcptun repo here: https://github.com/shadowsocks/kcptun, I am a little confused with the level of encryption available with it, although it looks promising, with the performance benchmarks mentioned. Further look into the README mentions following ciphers:
aes, aes-128, aes-192, salsa20, blowfish, twofish, cast5, 3des, tea, xtea, xor, none (default: "aes"). Perhaps @riobard could give some direction as to how efficient/robust it is against the GFW circumvention.

@denoza That's really interesting! Thanks for adding this experience to the ticket. I've opened a separate issue to investigate using simple-obfs: #741 To me this seems like a better path forward in the short-term because it can build on all of the existing shadowsocks-libev infrastructure.

@cpu Yes, in comparison to replacing the whole component (SS with SSR), I think that this direction is simpler to pursue and easier to implement.

[riobard]

The primary goal of kcptun is not to circumvent GFW but to combat high packet loss for some ISP during peak hours (e.g. China Telecom at night). It breaks a TCP stream into UDP packets and applies its own congestion control to send those UDP packets.

TCP congestion control is implemented by the OS in kernel space. Users are discouraged to touch it for good reasons. Essentially kcptun moves congestion control from kernel space to user space (and switching from TCP packets to UDP packets), so that users can use a different congestion control algorithm than the one from the OS. Additionally, kcptun uses forward error correction to further combat packet loss (at the cost of reduced bandwidth).

The effectiveness of kcptun depends heavily on how aggressive your ISP throttles UDP traffic. Again, the idea of sending more UDP packets when the network is already highly congested seems to be at odds with ISP's traffic engineering practices. At best high volume of encrypted UDP packets looks a lot like BitTorrenting which is usually the primary traffic load to be removed by many network administrators (e.g. corporate network with limited bandwidth to the Internet).

[OneHappyForever]

Hi,

Just wanted to know what you guys think of the shadowsocks traffic detection apps made available by shadowsocks and shadowsocksR developers. Do you think they point to possible weak points and areas of imporovement?

Here are the links:
https://github.com/madeye/sssniff
https://github.com/breakwa11/shadowsocks-rss/issues/868

[cpu]

Hi @OneHappyForever,

I opened an issue for this discussion on the Streisand-Discussions repo: https://github.com/jlund/streisand-discussions/issues/25

In the future please avoid adding new topics of conversation to existing threads & favour the discussions repo for non-code related topics.

Thanks!

[OneHappyForever]

Hi @cpu

Sorry about that :)

[SquirrelCoder]

Guys, does anyone know why ShadowsocksR repo is not available anymore?

There is no info. I am freaking out ...

Sorry, but I didn't really know where to ask this question :( .

[OneHappyForever]

The creator of SSR deleted all repositories

[OneHappyForever]

She said it was because of the ss traffic detection tool and conflict with the ss development team. According to breakwa11, the développer of ssr, she received many complaints and even death threats.
Therefore, ssr is no more.

Edit: don't freak out completely, as there are backups. It just means it will no longer be maintained or updated. People may fork it and continue to work on it, kind of like what happened after cloudwindy deleted all ss repositories.

@madeye

[OneHappyForever]

[cpu]

@SquirrelCoder @OneHappyForever Hi :wave:

This isn't a great place for general discussion on ShadowsocksR (or the overall Shadowsocks ecosystem). This is a ticket specifically about adopting ShadowsocksR in place of shadowsocks-libev for use with Streisand. It would be helpful to the Streisand maintainers if you could move discussion that isn't about that specific topic to a new venue. It's taxing to keep up with the open issues/pull requests that pertain to Streisand and discussions on the general Shadowsocks ecosystem are not actionable for us.

Thanks for understanding. If this continues I'm going to have to lock the thread.

[cpu]

Since the ShadowsocksR repo is now deleted I'm going to close the thread. I was opposed to Streisand adopting ShadowsocksR before and now that it appears to be further fragmenting into more forks I have an even harder time imagining that it would be a good replacement for Shadowsocks-libev at present.

Thanks!

[OneHappyForever]

@cpu

I just thought that the info regarding shadowsocksR being deleted by developer is important to this issue regarding whether to choose shadowsocks or shadowsocksR.

Edit: this will be my last post on this thread.

[cpu]

@OneHappyForever I agree that was a relevant fact :-) Thank you for sharing. I'm hoping to curb too much follow-up discussion. I don't mean to be rude.

[OneHappyForever]

I understand, no worries! Keep up the good work. :)

Cheers