请求加回不安全的弱加密方式

[TGSAN]

Is your feature request related to a problem? Please describe.
Shadowsocks 是非常好用的 代理软件 在，它并不一定是只能用来突破网络审查。
在一些情况中它可以作为轻量、部署简单且功能强大的内网代理。
而在这些环境下并不一定需要强加密，如 rc4-md5 加密方式性能损失非常低。

如在内网环境下可以通过 shadowsocks with rc4-md5 实现简易、高性能的跳板机连接。
这种情况下无需担心协议会被嗅探。

Describe the solution you'd like
希望加回不安全但非常高效的加密方式，或者默认隐藏这些加密方式，然后通过开关来控制这些选项是否显示（标注这些方式是不安全的、容易被嗅探的）

[kslr]

在大多数情况下 aes 比 rc5-md5 性能更好

[chenshaoju]

你仍然可以使用旧版本的客户端和服务端，这一点没有区别。#3041 (comment)

[ghost]

在我们的测试中RC4由于缺乏硬件加速表现相当难看，至于AES的各个操作模式，GCM在当代CPU上也有一套专门的硬件加速指令，甚至在某些测试中速度超过其他所有传统操作模式。

至于内网跳板，使用linux系统普遍内置的ssh服务器相当方便快捷。

[TGSAN]

在测试用的 arm32 架构轻服务器下 aes 的 CPU 占用比 rc4-md5 要更高，目前已回滚至 4.3.3 继续使用。

[ghost]

在测试用的x86-64架构计算机上，aes-gcm可以达到约130MB/s速度，rc4-md5约40MB/s

[zonyitoo]

所使用的arm32架构服务器，是否支持AES指令？使用的服务端实现是哪个？

[TGSAN]

所使用的arm32架构服务器，是否支持AES硬解？使用的服务端实现是哪个？

不支持 aes 硬件加速，服务端实现是 shadowsocks-libev

[ghost]

若不考虑安全等因素，使用SOCKS5优于使用Shadowsocks

• 支持SOCKS5代理的程序显然远多于支持Shadowsocks的
• SOCKS5原生支持多用户
• SOCKS5不加密，绝对比RC4快
• SOCKS5可以通过BIND指令要求服务端监听特定端口

[ghost]

相应的，若考虑安全因素，流加密的已知可被利用的问题已经能出一本论文集了。

[davendu]

至于内网跳板，使用linux系统普遍内置的ssh服务器相当方便快捷。

若不考虑安全等因素，使用SOCKS5优于使用Shadowsocks

从安全上网角度考虑，使用专用的跨国专线上网更加安全，且快捷（虽然并不方便，就像没有了rc4-md5的shadowsocks一样）。

而且从用户角度来看，是要考虑攻击者的成本的。完全有理由假定在内网环境中，攻击者可以访问/记录所有流量，但并不能解密流量，也没有动机对协议类型做嗅探。

[ghost]

攻击者可以访问/记录所有流量，但并不能解密流量，也没有动机对协议类型做嗅探。

Shadowsocks流加密协议已可被解密。

[DuckSoft]

本来不想提的: redirect attack on shadowsocks stream ciphers

[davendu]

Shadowsocks流加密协议已可被解密。

协议可以被解密 !== 攻击者能解密

攻击者也是有自己的困局的，比如流量超过了攻击者能处理的带宽，或者攻击者只（能）关注明文流量。请注意，我关注的是有局限的内网环境，而不是公网环境。

[ghost]

另外使用流加密的Shadowsocks协议因为难以校验数据包真实性，导致缺乏有效的主动探测防御措施。

[ghost]

Shadowsocks流加密协议已可被解密。

协议可以被解密 !== 攻击者能解密

攻击者也是有自己的困局的，比如流量超过了攻击者能处理的带宽，或者攻击者只（能）关注明文流量。请注意，我关注的是有局限的内网环境，而不是公网环境。

密码学小常识：如果可能，攻击者什么都会做

[DuckSoft]

不是很明白，现代计算机上，有aes指令集加持的aesgcm系列aead模式，无论是性能还是安全性都吊锤rc4md5，为啥还要为rc4md5招魂。

我个人支持shadowsocks生态全面扔掉流加密的决定。

[davendu]

密码学小常识：如果可能，攻击者什么都会做

@studentmain 如果是建立在“什么都可能”的基础上，那么这个问题没必要讨论了。

我觉得应该拿出比较开放的态度来对待shadowsocks。保留弱加密选项但移除显示，或者要求在带有特定参数的情况下才能使用弱加密选项，让用户明确的表达出“i know what the hell im doing”，应该是一种可接受的方案。

现代计算机上，有aes指令集加持的aesgcm系列aead模式，无论是性能还是安全性都吊锤rc4md5，为啥还要为rc4md5招魂

@DuckSoft 原帖说的很清楚了，就是因为没有AES指令集才希望使用rc4。

[ghost]

@davendu 用户显然有重新编译程序的自由

[DuckSoft]

如果没有 aes 指令集，那为什么不试试神奇的 chacha20-poly1305 呢

[kslr]

我建议有需要的人自行维护一个版本，而不是对其他人要求，没有人有义务为你的需求负责。

[database64128]

The short answer: It's not going to happen. Support for the legacy protocol with stream ciphers will not be added back. Use ChaCha20Poly1305 or AES-GCM instead.

We are also asking other implementations to do the same thing. V2Ray removed it in v2fly/v2ray-core#566. shadowsocks-rust is deprecating the support with a feature flag in shadowsocks/shadowsocks-rust#373.

[MoeGuoH]

可以理解为新年了，没啥好改的，删了其认为不安全其他人用不到的协议方式，以给小白负责，提供更少更优的选择，噢这不是有苹果那味道🤭。隔壁libev等没无聊到马上删除，估计是没这种小白群体把。
不过百思不得其解的是，明明就是个PPAP的产物(SOCKS5+openssl-lib)，就是为了一键开启连接不那么裸的SOCKS5，根据自己需求自己选择相应的配置方案。而不是全部都是那种高安全加密，抛开场景讲安全需求，这不就是耍流氓。流氓耍不过就说这个是我commit，我是contributors,我有权利说yes和no,建议你直接自己fork建议你自己创轮子。草太有苹果🍎内味。

[EpLiar]

“其认为不安全”
“流氓耍不过就说这个是我commit，我是contributors,我有权利说yes和no,建议你直接自己fork建议你自己创轮子”

Fine, 我们大可以过段时间来看看

[IceCodeNew]

可以理解为新年了，没啥好改的，删了其认为不安全其他人用不到的协议方式，以给小白负责，提供更少更优的选择，噢这不是有苹果那味道🤭。隔壁libev等没无聊到马上删除，估计是没这种小白群体把。

libev 已经被 ss-rust 替代了，留在那里只是为了兼容旧办法，自然不适合引入这样的 breaking change
你的发言只暴露出你对整个 ss 生态圈所知甚少，不知道哪来的底气让你在这里阴阳怪气

不过百思不得其解的是，明明就是个PPAP的产物(SOCKS5+openssl-lib)，就是为了一键开启连接不那么裸的SOCKS5，根据自己需求自己选择相应的配置方案。而不是全部都是那种高安全加密，抛开场景讲安全需求，这不就是耍流氓。流氓耍不过就说这个是我commit，我是contributors,我有权利说yes和no,建议你直接自己fork建议你自己创轮子。草太有苹果🍎内味。

你到底是求人办事还是当起了甲方啊？
求人办事被人拒绝是再常见不过的事，不知道你到底在崩溃什么

[chenshaoju]

就事论事吧，讨论不是坏事，扯其他的就没意思了。

Shadowsocks的流式加密的确已经可以被解密了，这有两年的时间了，并不安全，所以推荐使用基于AEAD的加密算法。

这里有安全人员写的论文和实现脚本，你可以研究：https://github.com/edwardz246003/shadowsocks ，这点上不应该存在争议。

[SekiBetu]

可以理解为新年了，没啥好改的，删了其认为不安全其他人用不到的协议方式，以给小白负责，提供更少更优的选择，噢这不是有苹果那味道🤭。隔壁libev等没无聊到马上删除，估计是没这种小白群体把。
不过百思不得其解的是，明明就是个PPAP的产物(SOCKS5+openssl-lib)，就是为了一键开启连接不那么裸的SOCKS5，根据自己需求自己选择相应的配置方案。而不是全部都是那种高安全加密，抛开场景讲安全需求，这不就是耍流氓。流氓耍不过就说这个是我commit，我是contributors,我有权利说yes和no,建议你直接自己fork建议你自己创轮子。草太有苹果🍎内味。

个人的激进观点：不论是常规用途还是什么用途，我认为传输安全性是很重要的，不然不会有那么多专家从ssl1.0研究到tls1.3，如果不考虑安全性的场景，那么明文传输更加高效简洁且节省CPU资源，(这么说来，谷歌未来从Chrome源代码里删除tls1.0和1.1的支持也是对所谓内网环境的一次打击？)

[MoeGuoH]

原来提issue人员给出的建议是

希望加回不安全但非常高效的加密方式，或者默认隐藏这些加密方式，然后通过开关来控制这些选项是否显示（标注这些方式是不安全的、容易被嗅探的）

并且该issue提出人员在提出，场景情况下

如在内网环境下可以通过 shadowsocks with rc4-md5 实现简易、高性能的跳板机连接。

因此我也是同意原来Issue提出者的看法，但是看某些contributors，和一些非contributors给出的看法是

贵生态圈的一些人的reply依旧杠精。

我建议有需要的人自行维护一个版本，而不是对其他人要求，没有人有义务为你的需求负责。

在大多数情况下 aes 比 rc5-md5 性能更好

@davendu 用户显然有重新编译程序的自由

那只能允许杠精杠，不允许我嘤嘤怪阴阳怪气嘛？而且我有说过rc4-md5安全嘛，下面这句话这些杠精都脑内忽略了嘛？直接高潮的麻烦看完再reply

根据自己需求自己选择相应的配置方案。而不是全部都是那种高安全加密，抛开场景讲安全需求，这不就是耍流氓。

就事论事吧，讨论不是坏事，扯其他的就没意思了.我认为这些选择应该就应该给用户选择，而不是直接Default In Code.希望你们能理解.

“i know what the hell im doing”

这句话.

顺带提一句，保留和不保留，会影响其他加密方式的安全嘛.真实摸不着头脑.怕不是迫害妄想症了.

[ghost]

“i know what the hell im doing”

DES使用了______网络来构造

[MoeGuoH]

DES使用了______网络来构造

保留和不保留 ______影响ss其他加密方式的安全.

[ghost]

@MoeGuoH 用户____选择不安全的加密

[EpLiar]

保留 rc4-md5 增加_____的维护工作

[MoeGuoH]

@MoeGuoH 用户____选择不安全的加密

该用户使用自己的_______保证自己的安全

[ghost]

@MoeGuoH 因此应当__能力独自靠此手段保证安全，不需要借助shadowsocks

[SekiBetu]

建议搞个美式选举，用户投票给开发者，开发者再投票要不要保留

[EpLiar]

replace("请求", "要求")

[MoeGuoH]

@MoeGuoH 因此应当__能力独自靠此手段保证安全，不需要借助shadowsocks

shadowsocks-window != shadowsocks

[ghost]

@MoeGuoH 原来你也记得这个啊

[MoeGuoH]

@MoeGuoH 原来你也记得这个啊

但你也忘记回答

保留和不保留 ______影响ss其他加密方式的安全.

[fakeboboliu]

嘛，上面一位都说出来“生态圈”了，那生态圈内做事应该统一啊，不把其他 impl 的 rc4 也删一下？

[davendu]

@studentmain

DES使用了______网络来构造

我认为你的这条回复典型代表了：不就事论事，阴阳怪气，以及对我和issue中其他讨论者的极度不尊重。

既然您对Fistel这么有研究，不如来向我们传授一下同样是使用了Fistel网络，为什么我们不能在保证密钥长度足够长的前提下应用DES算法。

---

@SekiBetu

谷歌未来从Chrome源代码里删除tls1.0和1.1的支持也是对所谓内网环境的一次打击

事实上的确有一部分企业的应用收到了影响。

---

@kslr

我建议有需要的人自行维护一个版本，而不是对其他人要求，没有人有义务为你的需求负责。

这是issue中的讨论，不是需求单。

---

我觉得这个讨论串真的很有意思，一直在用户明确认为可以接受不安全的情况下讨论这个做法是否安全，甚至连加入讨论都需要一个“熟悉这个圈子”的资格，中文互联网的圈子精神被发挥的淋漓尽致。

另外你们大可以明确的把“保留这些算法会增加我们的维护量所以我们决定不维护了”说出来，虽然我们都知道 #2757 本身也是工作量的一种体现。

---

@database64128 Since the decision has already made, I recommend we just lock this session and stop those nonsense talking & arguments. If someone have any other idea, they can "satisfy their own requirements" open a PR like @EpLiar and @kslr , and wait for some Jan Doe to approve it, if lucky enough :)

I will just have my own RC4 supported "unsafe" clone in my local Git repo, since the "community" does not seems happy for the patch.

[ghost]

@MoeGuoH 用户__选择不安全的加密，并声称自己知道自己在做什么，与此同时他并没有回答DES使用了______网络来构造

[MoeGuoH]

@MoeGuoH 用户__选择不安全的加密，并声称自己知道自己在做什么，与此同时他并没有回答DES使用了______网络来构造

您可以就行杠精，可以不尊重我的观点和看法，不如回复下之前被你无礼搪塞@davendu 他的留言

[zonyitoo]

Discussion here are kind of pointless. My friends, be rational!

[DuckSoft]

Just lock the thread. This is not discussion. @madeye

[SekiBetu]

#3059 (comment)

原issue认为性能会有损失，那么，想办法支持AES不就好了，既保证了安全也保证了性能，而不是把精力花在支持不安全的方法上

[davendu]

原issue认为性能会有损失，那么，想办法支持AES不就好了，既保证了安全也保证了性能，而不是把精力花在支持不安全的方法上

@SekiBetu 我觉得这也是一种方案……但那就要找SoC厂商流片了

[davendu]

@MoeGuoH 用户__选择不安全的加密，并声称自己知道自己在做什么，与此同时他并没有回答DES使用了______网络来构造

请试图在网页中搜索您的答案

[SekiBetu]

原issue认为性能会有损失，那么，想办法支持AES不就好了，既保证了安全也保证了性能，而不是把精力花在支持不安全的方法上

@SekiBetu 我觉得这也是一种方案……但那就要找SoC厂商流片了

那我只能是说，相信未来会有更多设备会支持AES了，这应该是个趋势吧