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 shadowsocks/shadowsocks-org#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

[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

2. 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?!?!
3. What: a) do differently to the original SS protocol? b) Can you give evidence that they do it better?

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

[x0r2d2]

@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?!?!
3. 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.

[x0r2d2]

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

[aanwark]

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.

[x0r2d2]

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

[aanwark]

@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: StreisandEffect/discussions#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 👋

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