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

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

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