Redirect attack on Shadowsocks stream ciphers

[chenshaoju]

Shadowsocks is a secure split proxy loosely based on SOCKS5. It’s widely used in china.
However, we found a vulnerability in shadowsocks protocol which break the confdentiality of
shadowsocks stream cipher. An attacker can easliy decrypt all the encrypted shadowsocks
packet using our redirect attack. As the vulnerability is obvious and easy to exploit. I think the
government has already know it. So, using shadowsocks in steam cipher cannot hide yourself
from surveillance.

https://github.com/edwardz246003/shadowsocks

[riobard]

Interesting attack. Now we could finally get rid of stream ciphers (after deprecating them for years)!

To clarify: go-shadowsocks2 (not to be confused with the deprecated shadowsocks-go) supports AEAD ciphers from the very beginning, in addition to shadowsocks-libev, so the author's recommendation at the end is slightly incorrect.

[Mygod]

We have had active probing against stream ciphers since forever and that is already enough reason to not use stream ciphers already. (remember OTA?) I think stream ciphers are kept for improving performance if it is used along with plugins (shadowsocks/shadowsocks-libev#2581). Again this is a niche usage of stream cipher and personally I would prefer it gone.

[riobard]

Should we remove all stream ciphers from the officially supported implementations now? Can't wait to delete legacy code! 😄

Windows implementation will remove all (maybe except few oldest cipher for special case) non-AEAD cipher in next major release. We're rewriting encryption using BouncyCastle, as they are not safe, we needn't implement them now.

[riobard]

@studentmain What's the (rough) time frame for the next major release? And why still keep some old ciphers around? 😂

[riobard]

@madeye I'm removing all stream ciphers from go-ss2. Do you have any plan to deprecate them in ss-libev as well?

What's the (rough) time frame for the next major release?

When it down (or we give up).

And why still keep some old ciphers around?

plain/table/rc4/rc4-md5 for speed when user is hidden by plugin .If we finally decide keep them, user need edit config file in order to enable them, that make sure user know what they're doing.(Because of we dropped libsscrypto, they'll have a pure .NET implementation.)

[riobard]

@studentmain So maybe just leave plain (no encryption right?) is enough for plugin use? The most useful plugin is to wrap in TLS so there's no need to encrypt in SS at all.

I'd prefer plain(no encryption, stream cipher format with 0 bit IV) and rc4-md5, rc4-md5 is still wide supported, so user is more likely find a server has it. But it needn't be included in standard.

The reason I mentioned table and rc4 here is just I found their pure and simple C# implemenatation in git history and ported them into current codebase (of course, in personal branch).

[madeye]

The best practice is deprecating stream ciphers, not removing them: shadowsocks/shadowsocks-libev#2581

[riobard]

@studentmain I see, so it's more about removing some dependencies.

@madeye Fair enough. I'm removing them in go-ss2 to force the deprecation.

[Mygod]

@madeye @riobard In general, I think it's a good idea to remove stream cipher (except for plain so user will definitely know what they are doing?) from server-side but keep it on client side (for backwards compatibility) to prevent user outcry. Thoughts?

[riobard]

For go-ss2 I don't need to consider the client-side use case that much as I don't think many people use it as a client???

[Mygod]

I'm actually considering using a golang/rust implementation for shadowsocks-android because libev is too cumbersome to work with... 😆