关于一些基本问题的讨论

[riobard]

关于一些基本问题的讨论

[zhuhaow]

ss 的 integrity 的意义就和我用UDP实现一个 reliable, ordered, and error-checked protocol一样无谓，这个gfw完全没有关系。
我已经说过了，篡改不会发生，因为没有意义，一件不会发生的事情为什么要未雨绸缪。

你看，我就从来没有设想过有钱了以后如何生活……

[shinku721]

两天没看，多出了一个这么有趣的问题。
这讨论试图把原本偏向严谨化的协议设计讨论重新搅混，让人很想爆粗。但是作为一只有素质的真红我不能爆粗。

首先声明，我不懂密码学。我不知道 confidentiality, integrity, authenticity 到底是什么意思和它们的意义是什么，所以对此我表示没有什么可探讨的。这也不是 ss 的实现目标。

我就想谈谈， ss 从 table 发展到 AEAD ，在漫长的拉锯讨论中决定要（尽量）达到 IND-CPA, IND-CCA2 究竟是为什么。
以我个人愚见，很简单，因为我们不知道 GFW 是什么。

GFW 是旁路设备，是 IP 过滤器，是关键字检测器，还会主动探测可能的翻墙服务……不对，这些都是表象，是假想敌，是并非真实存在的东西。因为政府并没有跳出来，说，我们造了个 GFW ……没有人承认这个。所以我们也不知道那些旁路设备是哪些，在哪些路由器上部署了，说到底它是什么，这些都是黑盒子。这一切都是我们的想象，我们甚至没有办法证明这只是我们的网络链路不好。
所以，我们对敌人会采取什么样的攻击一无所知。一开始是 table ，因为我们觉得 GFW 只是关键字检测；后来我们要 IND-CPA ，因为我们觉得 GFW 会进行 DPI ，会检测流量内容的统计特征；又后来，有人提出了 GFW 可能采取了主动探测的行动并且出现了多组证据，因此我们要求 IND-CCA2 ；再之后，我们猜测 GFW 可能进行了重放攻击，因此才有了一些防重放手段的提出……
现在有人否定，说 GFW 不会进行这些攻击，加这些没意义的安全性是 ss 协议的失败。这个说法，可能对一些人是成立的，但是怎么论证它对所有人成立呢？有的人遇到了，有的人没遇到的攻击，到底存在还是不存在？谁能给这个答案？
那么，我们能做的，就是如同假定 GFW 是存在的一般，假定这个攻击是存在的，对此做长期的数据收集观察以期可信证据，并作出针对性预防措施。说到底它的根源，是我们的敌人是未知。

当然 ss 自己造轮子这一点我是不喜欢的。为什么不用 TLS 呢？原因我大概可以想到不那么坚定的两点。一是一开始 clowwindy 设定的目标就是要 0-RTT Data ，这一点其实在 TLSv1.3 中已经将要实现了，所以不久后这一条理由可以废掉了。二是 TLS 那套证书的机制麻烦，不过 TLS 本来就有 PSK 的办法的，所以这个理由也不是很强。其它的，大概是感觉上 TLS 就设计得太复杂了吧？可是明明 TLS 设置使用方面这么复杂，为啥人们还是用得很欢？我也不知道。

[zhuhaow]

业界在安全上的选择本身就是非常保守的（倾向于最快的更换到最安全的算法）。

1. 算法的普及需要时间，所以越早开始越好
2. 业界有一些东西是有高价值的，当年google退出**据说就和证书有关，至今cn的证书都是独立的。如果等十年能够拿到google的根证，那也是值得的。算我的流量？花一秒钟都不值。
3. 大家主观上喜欢这种安全的感觉 《-主要原因

ss 这种东西真的需要那种安全？一个跑着windows，安了一堆不知什么软件都搞不清楚的电脑，手机一android，主要权限管理靠那些不知什么软件的情况下，在ss上追求这种安全？

我只是不喜欢这种危言耸听而已。明明自己开一公园，非说飞进苍蝇都是安全隐患。

[zhuhaow]

@breakwa11 TYPE 3 的问题其实我也想到了，不过这个完全依赖具体实现几乎无法作为规则使用，尤其是实现如果结合非法请求延迟断开就不可能进行检测，我实现一个肯定就查不出来（就算给你重放的机会）。更何况何必要这么检测，ss 的流量特征本身就足够明显，ssr的那些混淆还好，而且AEAD本身的特征不是更明显了，就算ss再加上简单的混淆，还不是大量莫名的随机字节，一样一眼就看穿了。

额外字节什么的完全无影响，新协议那么多字节都加了还差这inet_ntoa多出来的那几个么。

SSR那些更多理论上的安全性部分，一个本来就安全的东西理论上的安全性的增强对用户又有什么意义呢。

我并不否认这些东西在理论上更安全了（不过比安全更安全也还是安全而已），只是单纯普及一点讨论的基础罢了。如果大家很喜欢理论安全性就去追，我也没啥意见，我也喜欢理论上的安全性，但是别总是要来讲的原来的东西有多"不安全"。

一讨论起来总有人来就是ss的原版安全性有问题，能不能不要用忽悠的方式，大大方方的告诉大家到底那里不安全（比如TYPE 1 4的bug的提出的就很好啊，直接说，这个bug也丝毫没有影响过ss的传输安全性本身，但是后来也还是被广泛误解了），什么级别的计算机才可能进行破解？别的不说，至今为止有一人能把ss+RC4-MD5的流量解密出来么，准备用什么计算资源？更不要说其他了。

比如楼上上的帖子，sorry，不是挂人，你正好发了我就举个例子，第二条真的从来都不是问题，AEAD也没有任何帮助

就是这种话太多了，太多人以为旧协议一刻也用不得了，所以我才写这篇文章。

[liaozibo]

ss基于实际而诞生的，他的设计也是基于实际用途（穿墙而已）。设计之初我想人家也并未想要达到“密码学”意义上的”安全“。
个人认为：ss已经足够安全，且并不需要“理论”上的安全。
发烧友在”理论“上的安全建议完全可用插件或其它方式实现。ss保持简单的设计哲学就可以了。
ss对于“穿墙”这个需求来说已经完全足够。不需要搞得太臃肿。that's all。
老拿ss是否理论上的安全来说事，命题之处就和设计理念相偏离，没有意义继续讨论。
再这么说下去。吃瓜群众到时候真会分不清 用 “火电”翻墙效率高 ，还是“水电”翻墙效率高。😂。蛤蛤蛤

[riobard]

@hellowingy 前面已经说过了呀，那就不要提「是不是安全」这个事情，直接讲能不能用就好了。这么多年了大家也用的很好不是。

对大部分人来说 TLS 1.3 deprecate 那么多 ciphersuite 也是没有必要的，为啥还要大力教育开发者这些安全的理念呢？名字里面有个 secure 字眼，总是要对招牌上的东西负责吧。

你们打开 shadowsocks.org 首页看看标题里面写的什么。

A secure socks5 proxy.

[bigboyq]

我觉得ss的目的就是翻墙，这个是第一要务
如何更好的翻墙？
1.ss协议去特征化
2.ss内容在特征明显的时候可以降低访问对象的特征
其他的所谓
1.加密性问题，应该交由app层的协议去保障，例如tls
2.完整性问题，其实aead已经解决

我觉得现在的关键是如何在3.0的基础上降低特征即可

1. 8位随机IV 加数据流的格式
   2.检验失败不返回断开

个人建议，在验证失败时返回随机结果，由客户端进行结果检验后判断后续处理就可以了

至于由此引发的慢速攻击，cc攻击等，交由防火墙，策略等按常规处理

[zhuhaow]

为什么这么说呢？integrity的目的是什么，是为了确保中间通路的各个节点不能够修改数据。
如果application有这项需求，那么它自己就应当实现这一点，因为application是不可能会设想传输是通过一个安全代理完成的。如果它没有，它自然就不在意这个问题。
最常见的确保integrity的方法就是SSL/TLS，很显然，在意integrity的（理论上应该是所有网站，现实么），应当自行使用SSL/TLS来完成数据传输，在这时，ss并不会提供任何而外的价值。
对普通数据，设想即便ss提供了integrity的保障，数据依然要明文由ss服务器通过若干中间节点的传输，中间依然可以发生篡改，既然application不在意，ss提供的保障其实也没有起到意义。

[zhuhaow]

这些年大家都喜欢靠偷换“安全”这个词的概念来提升影响。

明明大多数人没有最基本的安全意识和密码学常识，对安全的理解就是不安全的东西就和没有一样。

偏偏就是要在不加说明的情况下和他们说“不安全”。

[riobard]

@yjqiang 底子要打好嘛，不然以后再改成本就更高了。

我理解 obfs-simple 主要是为新的插件机制做个 demo，并没有打算提供非常完善的混淆支持。有兴趣的开发者应该利用这个项目的模版开发新的或者移植已有的 Tor 的 PT 插件。

[breakwa11]

除非有涉及到：
我设计的方法依然可以进行CCA

算了，我实在忍不住了，我就说一句， @zhuhaow 你文章中不使用 TYPE 1 和 4，只使用TYPE 3以及验证域名合法性的方法，我还真有主动探测方法，不过会依赖于具体实现。不只你，还有其它人提到过这个方法，但我意识到这个问题所以我懒得去改动原协议了（用TYPE3还浪费更多的字节），做个协议包装来得更彻底
至于SSR有没有意义，时间可以去证明的，不过现在还没做到最好，还有更好的，可能你认为这不过是over doing

[Crystal-RainSlide]

那个……这样下去可能会把SS搞成非民用软件：太高级别的东西，无论是加密混淆还是什么，设置使用方面都会跟着复杂很多。

[ptpt52]

我来凑凑热闹：

1. ss作为一个代理，根本不需要安全，安全由应用层自己保证就行，做得跟TCP一个级别就够了。
2. ss作为一个防止被审查或屏蔽的代理，重点应该是防止被特征识别和封锁。比如使用混淆等方法。

[atYuguo]

就个人的经验来看，我使用 SS 主要关心两个层次：

1. 攻击者不应识别出我在使用 SS；
2. 攻击者不应识别出 SS 中正在通过的流量是什么。

首先两者都是必要的：极端情况下，如果只关心第一条，那么只要把 SS 实现为一个“空协议”，即不干任何事直接通讯（或者最多 redirect 一下端口），那么自然不存在识别出 SS 的可能。但第二条就完全失效，也无法绕过审查。如果只关心第二条，那么已经存在的 VPN 比如 Openvpn 就是例子。

理想情况下，两者都能实现，那对我的用途来说，也是充分的。不过实际情况下， SS 总是两个层次间妥协的产物。

关于最近加入的 AEAD，虽然起因是为了修补第一条中的漏洞，但长远来看，AEAD 对于第二条意义更大，毕竟由 @breakwa11 提出的攻击没有理由不能对信道内的特殊协议起作用。换而言之，对第二条好的加密是必须的，所以我支持最近安全性方面的更改，与其修修补补，不如直接上 AEAD 这样成熟的工具，既不伤害第一条（实际上还避免了由 @breakwa11 提出的问题），又为第二条打下了坚实的基础。实际上要我来的话就直接推出个新版本，然后只剩下 AEAD，免得麻烦：）

[zhuhaow]

@breakwa11 加密的目的是很明确的：
不能在可接受的运算资源内让中间人知道传输内容
其他的手段听起来也是加密啊

[zhuhaow]

原作者没有考虑要理论的安全，我做一个我也不一定会考虑，越简单的协议特征越少，在现实意义上越“安全”。

希望大家以后能够在推动算法安全的同时做到基本知识的普及就更好了。

应该不会再回复了。

很高兴和大家讨论，晚安。

[zhuhaow]

@shinku721 本来真的是不想回复了，但是你又想要爆粗，理性讨论，何必呢。你说的恰恰就是我要写这篇文章的根本原因。

ss 最早的IND-CPA当然有问题。IND-CCA2也有问题，但是我已经指出了这只是实现的问题而已，算法本身没有什么问题。

不过我想有几个问题要先达成共识才好：

1. 在正常人理解的范围内，没有人能够“破解”RC4-MD5之后的任何加密数据（我所知的RC4的目前最大漏洞就是那个重复明文2^30多次才会泄露点信息的那个），所以使用原协议不会泄露任何数据
2. GFW的重放或者探测都不会对用户的数据安全造成任何影响

那么回过头来，我们担忧的是什么呢？是GFW会检测到ss服务器的地址，如此而已。
我无法，也没有在其他任何地方，看到理性讨论提出有任何其他的担忧，如果你有其他的任何合理的担忧可以明确指出。

好，既然怕的是GFW的服务器的检测，那就回答我一个简单的问题，AEAD的流量特征是比原版强还是弱？不仅仅是强，而且不知强了多少倍。我看到你在之前的讨论里面也提到了特征的检测，但是你还想这是要基于CCA，其实根本就不用，这样子的流量还能有什么其他应用？一分析就确定了。

原因？加密算法本来就不在乎Obfuscation。既然唯一怕的是检测，那么最重要的自然也就是Obfuscation。而我最烦的就是这个，天天就是喊AEAD，surge实现了AEAD，然后呢？我也不知他实现了simple-obfs了没有，反正文档里是没说支持，我也不知怎么设置。大家就纷纷表示真安全，也是不知道他们这个时候怎么就不怕服务器被检测了。

一堆人追着问NEKit什么时候实现AEAD啊，也没有一个人问说什么时候实现simple-obfs。

没有人喊simple-obfs，倒是一边喊着防检测一边用上了特征更加明显的AEAD，真真的一出荒谬剧。

@riobard TLS的问题是很多的，因为完全没有考虑过Obfuscation。我听说过ssl proxy很快被封的例子，因为ssl in ssl的包长度特征也是比较明显，当然我之前用的一个很久都没有被封，所以也是难说。反观ss因为是全随机流量所以反而隐藏在诸多无法分析的普通不常见协议流量中可能还好混一点，不过非要分析都是一样的明显。所以ssr里面的很多混淆我觉得都是有价值的。

[riobard]

我理解 @shinku721 想说的意思是没有办法证明什么攻击一定不会发生。在敌暗我明的情况下先把可能发生的问题都解决了显然是个更稳妥的方案。

AEAD的流量特征是比原版强还是弱？不仅仅是强，而且不知强了多少倍。

@zhuhaow 这里你可能需要解释下为什么你认为 AEAD 的特征更明显了。在我看来是和之前没有区别。

另外 Surge beta 支持了 simple-obs。我现在正在用。

用 TLS 和 simple-obfs 恰恰是为了提供一个强特征给某些局域网内（比如公司内网）的防火墙，让它觉得这是一个普通的 web 请求，否则这些防火墙会对未知类型的链接进行限速或者阻断。我现在就处在这样一个防火墙后面。

[zhuhaow]

有点事所以回的比较慢。

Confidentiality 这个问题其实是一个大家过于关注的问题了。事实上，也并没有什么实质的理论指出64 bits的nouce真正的不安全。

通常在加密这个领域大家说到可能weak，甚至是weak的时候，往往指的是，如果CIA／FBI／Mossad／whatever 在想的情况下，在可预见的未来，似乎有可能运用几年／月的运算时间破解出数据的内容。对于普通人而言，其实就是没有任何安全问题可言。

[riobard]

说回integrity的问题，无所谓定义如何，我来定义我们想讨论的就是，是否有必要能够验证数据是由一个知道pre-shared key的用户发来的，且未经篡改。

这里稍微有点问题，已经是 integrity + authenticity 两个要求了。Integrity 指的是作为密文的接受方能确保密文未被不知道 PSK 的第三方篡改过。而密文的接收方能确保密文是由知道 PSK 的人发过来的则是属于 Authenticity 的范畴。Authenticity 暂时不是重点，待会再说。

Integrity 的问题最初是由 @breakwa11 提出可以通过篡改密文中 type 对应的那个字节然后观察服务器的反应，根据反应结果有极高的可信度判定是否为 ss 协议，并且提供了可用的测试工具。这个便是因为 Integrity 的缺失导致的行为侧漏 😂，因为服务器端在 3/255 的概率上不知道密文被篡改了。

很多人认为这个问题根本不需要解决，攻击者有那个空闲来探测不如直接封掉 IP 算了。在目前的情况下的确是可以这样认为……不过毕竟泄露行为不是什么好事吧，于是有了 OTA 这个补丁出现。然后就是如 @wongsyrone 所言这属于自己造的轮子不圆，不如用现成的、理论基础更完备的 AEAD，所以有了 SIP004 (#30)。

[riobard]

总体来说， AEAD 给 ss 带来的好处是大大提高了安全性，并且采用成熟的第三方库实现，避免了自己造轮子可能带来的潜在问题，同时又提供了极佳的性能和兼容性（只需要支持已经成为行业标准的 AEAD_CHACHA20_POLY1305）。我们应该鼓励客户端和服务端的开发者尽可能支持 AEAD 的加密方式。

至于其他的如混淆、伪装等问题，则应该通过 SIP003 (#28) 的插件机制实现，在保留核心功能不变的情况下提供更加灵活多变的组合以应对用户所处的不同的网络环境。

[zhuhaow]

AEAD无关痛痒（不论是性能损耗还是安全性加强），我只是想指出意义太有限而已。

所有所谓的安全性增强都只是幻象，因为原本的安全性就没有任何的问题，好比100米的墙已经够高了，非要加高到800米，我只能说未尝不可，但是太没有意义了。

在某种意义上ssr做的事情确实更有实际意义（但很多只是比没意义好一点点的有意义，所以很多我也懒得支持）。

除非有涉及到：

1. 我设计的方法依然可以进行CCA
2. 篡改数据对中间人是有意义的或者中间人能够进行对用户有损害的篡改（相较于直接封服务器而言）
3. 在 confidentiality 上有漏洞
   不然我不再回复了。

写文章本就只是想澄清一些大家的误解，并没有想说新算法没有更“安全”。
大家想要追求不同程度的“安全”，所以只能求同存异了。但是至少基本事实是不能搞错的。

希望通过更多的讨论能让大家理清一些事实，毕竟真正的讨论太少，玄学太多了。

[riobard]

@zhuhaow 原版 ss （密码学意义的）不安全是客观事实，没有必要强行洗白，这是我觉得你文章有问题的核心。你让 @clowwindy 出来说他也不会认为当初的设计目标和安全有半毛钱的关系。

撇开 @breakwa11 的探测方式不说，nonce re-use 的情况下 XOR 一下两个密文就可以了，根本不需要多大的计算资源（不过需要一些存储）。

[zhuhaow]

我写文章就是要告诉大家，不会怎么样。

我只是希望以后大家都能先告诉大家，不会怎么样，但是我们还是可以更安全。

[breakwa11]

我想问两个问题
1 在SS里面的加密要解决什么问题？
2 如果有其它手段能代替加密的效果那我们还需要加密吗？

[zhuhaow]

而且如果要“防止服务器行为检测“，那ssr真的做的好的不知哪里去了（虽然我觉得没有意义），就算有AEAD也没有起到任何obfuscation的作用啊。

[zhuhaow]

以上两条评论是针对一些被删除了的回复的……

[hellowingy]

”我不管，反正它很好“ 哈哈哈...

[riobard]

@yjqiang 然而并非所有网站都是 TLS 连接。对于很多人而言，安不安全并不要紧。如果其他条件保持不变的话，安全总比不安全要好吧？在更好的基础上去解决混淆和伪装的问题，总强过在不牢靠的基础上修修补补。两者并不矛盾。

[riobard]

你看，所以我说讨论的时候不能太发散。本来就是为了讨论密码学意义的安全，上面已经说得很明白了，原版 ss 就是不安全的（因为设计目标就没考虑安全）。这是客观事实。但是这种不安全的后果怎样呢？其实也不会怎样 😂

[zhuhaow]

Confidentiality 在现实意义上从来都没有任何问题啊……在密码学上都不会说这些算法是“不安全”的……只是一种情况下会发生什么而已……

安全是一个完完全全的相对概念，必须要先告诉用户后果才有安全不安全的判断可言。

[hellofwy]

@shinku721
TLS 协议的证书是明文传输的，是个明显特征。如果要使用 TLS，使用对应的 HTTP 代理就好了。

ss 在开始开发的时候， TLS 还没有现在成熟。

由于 ss 是开源项目，有需要的人，完全可以按照自己的想法实现自己的项目。如果效果得到了当前 ss 维护者的肯定，也可以选择最后整合到 ss 项目中。

[JollyTRjano]

@zhuhaow TCP checksum没有取消或者不用，只是交给网卡处理了，有个硬件TCP校验和选项的。当然如果中间人改完你包肯定会重新checksum，integrity的确没法依赖这个

[riobard]

先提一个最基本的问题：Shadowsocks （后文简称 ss）有没有（以及要不要）提供密码学意义的安全？

密码学意义的安全具体指保密性 (confidentiality)、完整性 (integrity)、真实性 (authenticity)。

[zhuhaow]

首先我不觉得integrity和authenticity有什么实质上的区别。
其次它们的必要性在ss中是值得怀疑的。

[riobard]

在《某些网络工具的安全性》中，@zhuhaow 认为

(ss 的) Confidentiality 从来都没有出过问题， Integrity 可以说在设计之初就并没有列入考量（这并没有问题，我懒得展开了，但是篡改数据没有任何意义）， Authentication 其实是通过 TYPE 来实现的，也是出问题的地方所在

这里我认为是不对的。事实上 ss 在设计之初并没有考虑密码学意义的安全，因此使用 table 方式做了简单的替换，目的仅仅是为了绕过内容过滤审查。后来换用流加密（stream cipher）也没有考虑保密性的问题，因而保密性是有缺陷的，这个问题在 #36 里有讨论。

[riobard]

我不觉得integrity和authenticity有什么实质上的区别。

这确实是个比较 tricky 的问题。可以参考 PGP 的解释 http://www.ac.uk.pgp.net/pgpnet/secemail/q4/node4.html

其次它们的必要性在ss中是值得怀疑的。

这个就是要不要的问题。

[zhuhaow]

当然table不安全，很难说这是加密了，但是自RC4-MD5之后的方法，没有任何理由说它们在实际的使用中会不安全，当然我坚决支持在性能可接受的情况下使用最新的加密方法。事实上，我不想为兼容性妥协任何安全性。

[zhuhaow]

说回integrity的问题，无所谓定义如何，我来定义我们想讨论的就是，是否有必要能够验证数据是由一个知道pre-shared key的用户发来的，且未经篡改。

[zhuhaow]

在谈integrity的必要性之前，我先说攻击者是否有兴趣篡改，或者伪造数据。
在我文章里提出的解决方案下，CCA是不可行的（至少我设计不出方案来）。那么攻击者伪造数据没有任何意义，他只可能想要篡改数据。

[zhuhaow]

那么对于攻击者而言，首先他要决定的是如此大量的数据面前，他要篡改什么数据。
显然不能随机选，那就必然已知这是ss的流量了。
在这种情况下，如果攻击者不希望用户正常使用，显然封服务器是最简单好用的策略，看不出任何篡改的意义。

[zhuhaow]

接下来我们再看，ss协议本身，是否有integrity的需求。
ss是做什么的呢，是用来传输数据流的，那只是一个代理的协议。我们可以看到，http代理也好，socks4/4a/5代理也好，均没有任何关于integrity的验证，尤其是socks4/4a/5这个数据流代理也没有。这是为什么呢？因为数据流的integrity是应当由application在需要的时候完成检查的。

[riobard]

事实上，也并没有什么实质的理论指出64 bits的nouce真正的不安全。

这个陈述过于模糊了。64-bit nonce 安不安全取决于 nonce 是如何生成的，以及相关的 key 是如何使用的。初版 ss 使用 PSK 配合随机 64-bit nonce 的方式确实是（密码学意义）不安全的。这个有客观的方式可以度量。这个在 #40 里面有讨论。

通常在加密这个领域大家说到可能weak，甚至是weak的时候，往往指的是，如果CIA／FBI／Mossad／whatever 在想的情况下，在可预见的未来，似乎有可能在几年／月内破解出数据的内容。对于普通人而言，其实就是没有任何安全问题可言。

我认同这个大前提。但是因为这里讨论的是密码学意义的安全，我觉得还是有必要遵循主流的定义。至于说「不安全也影响不到某个个体，所以对这个个体是安全的」这种说法比较容易搅乱定义，不利于展开讨论，我倾向于反对这种说法。我们可以说「的确不安全，但影响不大」。

[zhuhaow]

这个陈述过于模糊了。64-bit nonce 安不安全取决于 nonce 是如何生成的，以及相关的 key 是如何使用的。初版 ss 使用 PSK 配合随机 64-bit nonce 的方式确实是（密码学意义）不安全的。这个有客观的方式可以度量。这个在 #40 里面有讨论。

设想我有一任意快的计算机，那么所有加密技术都是没有区别的。加密的目的就是在于使得破解所需要的资源在当前和可预见的未来是不足够的。而当前的很多deprecated的加密算法其实也还是满足这一点的。

不过我依然建议使用更强的加密算法。只不过这个问题对普通用户完全不构成问题而已。

[zhuhaow]

其实，ss这些代理协议，完全可以看作是TCP流的代理版，从来没有听说有人想要检查TCP包的integrity（checksum都被取消了），因为本身这就不是TCP需要关注的问题。

[riobard]

@zhuhaow 我先把加密的问题理一下哈，等下再说 integrity 的问题。

当然我坚决支持在性能可接受的情况下使用最新的加密方法

其实目前的两种 AEAD 的性能挺好的。在搭载 AES 硬件加速的机器上 AEAD_AES_128_GCM 的性能显著高于 AES-128-CTR/CFB。没有 AES 硬件加速的机器上 AEAD_CHACHA20_POLY1305 如果利用了较新的 CPU 指令集也能做到非常高的效率。

[bigboyq]

至于obfs
我觉得 ss over tls就可以了，甚至iv都可以基于tls本身特定串hash生成
不要试图在一个翻墙工具里面解决所有问题

[zhuhaow]

这里稍微有点问题，已经是 integrity + authenticity 两个要求了。Integrity 指的是作为密文的接受方能确保密文未被不知道 PSK 的第三方篡改过。而密文的接收方能确保密文是由知道 PSK 的人发过来的则是属于 Authenticity 的范畴。Authenticity 暂时不是重点，待会再说。

你仔细想想这两件事是一件事，就是数据是由有key的人生成加密并发过来的。

[riobard]

@zhuhaow 不是呀，篡改数据不需要有 key。

[riobard]

我说一下我对「ss 有没有提供密码学意义的安全？」的理解吧：

1. 初版 ss 没有提供保密性、完整性、真实性，因为安全根本不是设计目标。
2. ss 采用 SIP007 (#42) 后提供了保密性和完整性。真实性则取决于是否给多个用户共享同一个密码。至少在设计理念上 ss 是不鼓励多个用户共享密码的。

[riobard]

从来没有听说有人想要检查TCP包的integrity（checksum都被取消了），因为本身这就不是TCP需要关注的问题

其实是有必要的……比如 TCP RST 攻击就是因为 integrity 缺失导致的 😢 SIP005 (#32) 试图解决这个问题，但在应用层面并不可行只好作罢。

[yjqiang]

个人以为加密方式只是作为一种混淆方法存在，保密性自然的有上层的tls保障。甚至像 @breakwa11做的那样，认为混淆性已经足够好，加密还使用none。（https://breakwa11.blogspot.sg/2017/04/proxy-protocol-analyze.html ”一个小插曲，有个网友做了个实验，使用auth_aes128_md5协议，不带混淆，不带加密，直接祼跑超过了80G流量，还是啥事都没发生。“)

从这个方面来讲，我认为加密甚至可以不存在，混淆的意义远远大于保密。

[yjqiang]

同意，两者不矛盾，而且也同意本项目的混淆设计思路，去把混淆与安全区别开。
但是最近的obfs-simple更新中并没有多少混淆方面的加入，利用已经造好的tor的混淆思路是好的，但似乎还远远没完成，而且在各平台的客户端也都明显基本都没有跟上。
个人的意见只是从最近项目发展来看，似乎过于强调了安全。希望今后可以把大部分精力投入到混淆的方面。

[riobard]

大家想要追求不同程度的“安全”，所以只能求同存异了。但是至少基本事实是不能搞错的。

是的，也是这串讨论的本意。

有个小异议就是 3. confidentiality 事实上是有漏洞的，不过就目前的情况看来对个人而言影响不大。

[zhuhaow]

@ccsexyz 在重放的情况下如果实现的不好还是可以的，成功率不高，而且还要求是重放就是了。

[ccsexyz]

@zhuhaow 重放可以用 iv cache 来解决啊

[zhuhaow]

@ccsexyz 他们对安全的要求比较高（是理论级的）。

假设对你很有兴趣并且愿意花很长的时间反复尝试呢？cache总是要满的。

[zhuhaow]

我说了啊，到底那里不安全你说出来啊，不要东拉西扯的……

没有那个实现会有nonce re-use吧。

[zhuhaow]

重放时候用的就是合法时候的IV啊，关键在于理论上早晚有一天cache会满的。
老实说通过cache来防止replay我也是很不喜欢的。

[riobard]

没有那个实现会有nonce re-use吧。

你肯定没看之前的讨论。建议先阅读 #36 (comment)

我相信一个靠谱的实现不会主动 re-use nonce，所以才使用随机生成对不对？假设我们用最完美的随机数生成器，只有 64-bit nonce 的 chacha20 会在 2^32 内出现 nonce re-use。更何况实际上很多人在低端路由器上跑 ss，硬件本身提供的随机数生成器就质量可疑，在 entropy 不足的情况到底多久会 nonce re-use 其实根本没有理论值那么乐观。

[zhuhaow]

嗯，终于步入正题了。

2^32次是和IPv4的地址一样多的，这是很多的。
随机数发生器是这样的……
首先呢，路由器这种等级应该是不够格配硬件随机发生器的。
再次，最重要的，随机数发生器（软件）的质量低往往不是指他们会重复，事实上恰恰相反，随机数发生器的算法往往是在它的一个cycle内不会重复的！这也恰恰是随机发生器质量不高的一个重要例证……不过这恰好是我们要的……因祸得福

最后，我们就假设有一个中间人这么闲吧，他也不知道你的数据是什么，但是他兴致勃勃的把他们全部记录下来，至少也要几百万条甚至更多，然后找出开头一样的，XOR，BINGO，他得到了某两条明文的XOR，然后……然后又怎么样了，这数据有多重要以至于有人会能够分析这两个XOR的结果得到原文然后得出有价值的信息影响用户的安全么。理论上也有可能。

理论上都没错，但是如果我，我就会写完上面一段再告诉大家，这个算法在业界是被一些人认为weak的。

[riobard]

还有一点要说明的是，ss 使用 chacha20 的方式不安全并不等于 chacha20 本身不安全；反过来，chacha20 安全并不等于 ss 使用 chacha20 的方式安全（chacha20 可以换成任何加密方式）。这才是很多人跟风起哄、玄学四起的本因。

而作为开发者，我们要避免给用户过多的选择导致各种玄学。给出一个基础扎实的默认构造让大家用就好了，用户没有必要选来选去。AEAD 就是要解决这个问题：性能不错、足够安全。

[riobard]

@zhuhaow 那你不能在文章里面说原始的构造是安全的呀，这样很容易产生误解的 😂

[zhuhaow]

原始的构造依然是安全的啊，到底是哪点不安全了？

[zhuhaow]

理论上的东西没有实际的可能性啊

[zhuhaow]

我会在文章里加上理论方面的讨论。

[riobard]

原始的构造依然是安全的啊，到底是哪点不安全了？

诶……如果你坚持认为一个 security margin 在理论上都只有 2^32 的构造是安全的，那只能说明我们对什么是密码学意义的安全的理解完全不一样 😂

就好像说虽然 SHA1 碰撞已经可以实现了，但实际上并不会有人会拿这个来搞你，那为啥业界还是要坚持换用 SHA2 呢？对吧。

[riobard]

所以说「是不是安全」和「要不要安全」是两个截然不同的问题。你文章的硬伤在于把前者弄错了。后者是个人主观选择的问题，就不讨论了。并不是所有人都不在乎。

[hellowingy]

「是不是安全」or「要不要安全」，如此阐述概念很容易极端化，尤其是对于不明原理的大众。安全是个程度问题，永远没有绝对的安全。换个角度论证是否更好？ --->《对于大部分人来说是否足够安全》

[riobard]

@liaozibo 设计之初本来就没有考虑安全，所以不存在「足够安全」这种说法。要不要是个人的选择。

[liaozibo]

@zhuhaow 蛤蛤 赞同。

[riobard]

@zhuhaow 我也很好奇谁在偷换「安全」的概念 🤔。反正你文章是这么写的

通常的 Cryptography 有很多方面，而我们关心的工具我想应该只关注以下方面：

1. Confidentiality
2. Integrity
3. Authentication

[riobard]

Confidentiality 在现实意义上从来都没有任何问题啊……在密码学上都不会说这些算法是“不安全”的

照这个逻辑 SHA1 也是安全的咯，反正又不会被你撞见 😂

本来原作者就没有考虑要安全，并且在理论上和实操上都被证明有漏洞，你要坚持说反正不会发生在我身上，那也只能求同存异啦 😄

[riobard]

Anyway，感谢参加讨论的各位！特别感谢 @breakwa11 @zhuhaow @hellowingy 几位对 ss 项目的贡献，没有你们的努力，很多人还是不能愉快的上网。谢谢大家，晚安！

[hellowingy]

实际生产中，如果探测SS的方法是不可规模化的，也就没了探测的必要了。
规避这类方法的优化，没什么意义。

[riobard]

我觉得 @shinku721 指出了问题的核心所在：对潜在威胁的认知不一致导致对项目的走向和重心的看法产生分歧。 #62 是试图定义潜在威胁的一个初步尝试，欢迎有兴趣的人参与讨论。

[riobard]

关于为何 ss 不使用 TLS 的问题我认同 @hellofwy 的观点，也部分解释了为什么 ss 没有伪装成 TLS 的 obfs 插件：如果需要伪装成 TLS，不如直接用现成的 HTTPS proxy 更好（只要不暴露代理身份即可）。

@shinku721 提到的 TLS 的复杂性的问题也是一个影响因素，毕竟 ss 还是以设计简单为核心目标。AEAD 并没有增加多少复杂度，而且由于可用的 AEAD cipher 数量就两个，其实是减少了用户使用配置时候的困惑。If in doubt, use AEAD_CHACHA20_POLY1305.

[hellowingy]

不妨讨论下这些所谓的”潜在威胁“是否有发生的可能性

“潜在威胁”这个词和“不安全”一样容易误导，几乎不可能的事件也可称为“潜在”。建议说清楚这些潜在威胁具体是如何在翻墙这个场景下发生的（不是理论可能，而是实际生产中的可能性）

很多人私信我希望增加对AEAD的支持，言语间透露着不安全感。个人不支持也不反对AEAD，但建议在推广自我意志的时候避免“不安全”、“潜在风险”等极具误导和煽动的词汇。
由于不想陷入到争议中，@zhuhaow 犹豫过是否要发这篇文章。由于我感受到了太多人没必要的不安全感，才建议他发布了这篇文章。在此表示抱歉和感谢！

[zhuhaow]

这里你可能需要解释下为什么你认为 AEAD 的特征更明显了。在我看来是和之前没有区别。

我发现确实是我二了……向 @shinku721 和你道歉……应该是没有区别的

用 TLS 和 simple-obfs 恰恰是为了提供一个强特征给某些局域网内（比如公司内网）的防火墙，让它觉得这是一个普通的 web 请求，否则这些防火墙会对未知类型的链接进行限速或者阻断。我现在就处在这样一个防火墙后面。

这是我觉得有意义的。本来就是要掩盖ss的特征。

[riobard]

没关系，就事论事，把问题讨论清楚就好了 😊

前面也提过了，AEAD 和混淆、去特征的需求并不矛盾，而是想要解决原版 ss 设计之初并没有考虑的安全性问题。虽然这种安全性短期而言还不至于对很多人造成影响，但作为项目的开发者需要对未来可能发生的问题有一个预判，并提供相应的解决方案。

换句话说，AEAD 相比原版 ss 协议来说基本没有什么负面影响，又提供了额外的安全性且提高了性能。作为 NEKit 及其衍生产品的用户，我希望你也能提供支持。

不知道这样有没有把目前的问题表述清楚。谢谢！

[zhuhaow]

NEKit是不会支持的了，我已经懒得改了，我本来就已经准备在libnekit里提供全部的ss和ssr支持了，彻底免除大家问来问去的烦恼。不过最近NS刚刚到手……c写起来又格外的恶心……

我还是觉得你们还是过度强调安全和不安全了，造成了一种无谓的恐慌情绪。我对未来的预判大概是人类走出太阳系也发生在RC4被彻底破解之前，所以那时候有没有wall还是个问题。

Anyway，很高兴讨论中纠正了我之前理解的一个错误，虽然我也不理解为何之前会这么想……
谢谢大家的讨论。

[riobard]

不过最近NS刚刚到手……c写起来又格外的恶心……

明白 😂，期待 libnekit 早日面世！

[shinku721]

@hellofwy 证书是，PSK……好吧也许也算一个。这么说我能够理解。

@hellowingy "潜在威胁"也许不能精确描述，不过你可以认为是，过去曾发生的攻击是在某个模型下针对某一点的攻击，与其避免掉这一点的攻击而依然面临其它点受同样模型威胁的问题，不如直接用成熟的方法避免这个模型的攻击。不安全感的问题并非 ss 协议设计时的意图，然而 ss 并没有什么刻意宣传吧。您能详细讲一下是什么样的不安全感吗？毕竟总的来说 GFW 针对的是协议整体而非使用者个人，我不认为个人使用者应当为此抱有什么负担……

@zhuhaow 嗯，我只是对于那篇博文强烈否定从 naive ss 到目前为止的一切发展而感到不适。能理解最终走向现有成熟的 AEAD 的原因真是太好了。

GFW的重放或者探测都不会对用户的数据安全造成任何影响

GFW 的重放可能产生影响，不过对于重放的问题需要更多的证据。
关于 Obfs 的问题，其实是你想让 ss 流量和什么协议的流量不可区分的问题。ss 的流量数据是和随机内容不可区分，如果想混淆成某种数据（比如HTTP）那么就应该在插件中进行一次重编码，把原数据编码到目标协议可能的数据空间上去。
当然这只是在流量数据特征不可区分了，连接特征是一个更复杂的问题，这方面还没有看到什么好的方法。

[qinyuhang]

@gufeng Guo 我认为你这样是对整个项目的不尊重，什么叫做 `瞎讨论`？请你解释一下。

…

在 2017年4月25日，13:56，GuFeng Guo ***@***.***> 写道： 你们这些大佬在这瞎讨论，其实我们用户就是想简单易用速度快，仅此而已。。。 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#64 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF8zUXHzxVIIonU0AVl9sfdAk6LMtuduks5rzYr_gaJpZM4M36UQ>.

[zzuzjl]

@ qinyuhang 哦哦，赶快删了！

[WordlessEcho]

Shadowsocks 在设计之初应该是一个轻快的代理。
也就是说，从开始，我们的目的只有一个：翻墙。
这要求我们更加深入地研究墙是如何工作的，因为翻墙特征，就不能翻墙，所以 Shadowsocks 在努力地伪装自己的流量；等等等等……这些都是在围绕着翻墙这一目的。
如同 @shinku721 所说，根本问题还是要研究墙是如何工作的；墙到底是要识别、阻断还是攻击？

[ptpt52]

关于服务器如何避免被扫描和识别，我有个（也许）很好的方法，我预计会在未来1个月内实现这个方法，避免服务器被扫描

提前透露一点：如果端口都关闭了，它还扫描个鸟啊！

[ptpt52]

原来有人这样搞了
https://blog.benjojo.co.uk/post/ssh-port-fluxing-with-totp

[ccsexyz]

你没有卖关子的必要啊，你直接说出来说不定还能节省下大把时间

[ptpt52]

@ccsexyz 已经说了呀

利用 TOTP 服务端和客户端同时变换端口，看看上面连接给的例子：ssh-port-fluxing-with-totp

[ccsexyz]

@ptpt52 这个工具用来防探测肯定不行，它对抗的是瞎比扫描者,而墙是知道你在什么端口上新建了连接的,而且每隔30s断开已经建立的连接。这明显不适合 ss.

[ptpt52]

你理解错了，已经建立的连接不会断开
客户端在此刻用随机端口建立了连接，30秒后，服务器的端口已经不存在啦
但是连接仍然保持
后续客户端如果要建立新连接
就用后面那个时刻的随机端口啦

总之服务端 的端口一直在变，客户端自己才知道每个时刻的端口是什么
中间人是不知道的啦

[ccsexyz]

@ptpt52

even if the code expires established connections stay connected

关键问题不在这里，关键问题是你只要新建了连接中间人就知道什么端口是开放的了,而且这个合法的端口还会开放相当长一段时间

[ptpt52]

@ccsexyz 只是知道那30秒内开放
这个是个折中的方案，考虑到很多客户端无法修改底层，才用这个30秒变换开放端口的方法

更狠的方案，是使用knock敲门技术了

[JollyTRjano]

@ptpt52 你似乎理解错了中间人的概念。In computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. 中间人并不需要基于扫描你的端口来获知信息。

[ptpt52]

@JollyTRjano
MITM 当然不需要知道开放端口，可以TCP注入，我理解没错的。
你可能误解我的意图

服务端为何要变换端口，或者说隐藏端口，目的就是避免被扫描和识别出服务器类型，比如扫描8388端口，通过一定手段，识别出服务器属于SS服务器，然后block

我的意图是避免被主动扫描和识别，不是避免MITM

1. 折中的方案是用TOTP变换端口，避免某个端口持续开放，被持续扫描和检测
2. 更好的方案就是用敲门技术，服务器在收到一定密码序列的包后，才accept连接，建立成功。这能够很好地隐藏服务器。
3. 当然，道高一尺魔高一丈，你也可以说这种服务器特征反而是可识别的特征。那我无话可说了。

[ccsexyz]

@ptpt52 这样吧，假定中间人在某个端口连接建立成功之后1s内立刻探测这个端口,该怎么办呢

[ptpt52]

@ccsexyz
用敲门技术吧，这样就不存在任何时刻 开放端口了

[ccsexyz]

@ptpt52 问题是，你能连接凭什么中间人不能连接?

[ptpt52]

@ccsexyz
我有密钥，根据密钥发送序列密码包后，连接才能建立成功
中间人 建立连接，发syn包，发到天黑都没人应答它