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

[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!

[x0r2d2]

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?

[x0r2d2]

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

[x0r2d2]

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.

[x0r2d2]

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

[x0r2d2]

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

[aanwark]

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.

[x0r2d2]

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.

[x0r2d2]

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

[x0r2d2]

@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

[x0r2d2]

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

[x0r2d2]

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

[x0r2d2]

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

❄️🍦

[x0r2d2]

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

[x0r2d2]

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

[x0r2d2]

@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

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?

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