关于一些基本问题的讨论

[riobard]

这串讨论源起于 @hellowingy 在 Twitter 引用 @zhuhaow 的文章《某些网络工具的安全性》。考虑到最近 Shadowsocks 的一些改动引起了不少的争议，有一些基本问题需要理清楚，才好让大家（至少是相关项目的开发者）对这些问题有一个正确的认识。

[zhuhaow]

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

[riobard]

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

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

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

[zhuhaow]

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

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

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

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

[riobard]

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

[hellowingy]

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

[liaozibo]

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

[riobard]

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

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

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

A secure socks5 proxy.

[riobard]

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

[zhuhaow]

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

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

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

[liaozibo]

@zhuhaow 蛤蛤 赞同。

[riobard]

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

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

1. Confidentiality
2. Integrity
3. Authentication

[breakwa11]

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

[zhuhaow]

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

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

[zhuhaow]

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

[riobard]

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

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

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

[riobard]

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

[zhuhaow]

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

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

应该不会再回复了。

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

[hellowingy]

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

[Crystal-RainSlide]

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

[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 设置使用方面这么复杂，为啥人们还是用得很欢？我也不知道。

[hellofwy]

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

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

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

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

这里你可能需要解释下为什么你认为 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 notifications@github.com 写道：

你们这些大佬在这瞎讨论，其实我们用户就是想简单易用速度快，仅此而已。。。

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/shadowsocks/shadowsocks-org/issues/64#issuecomment-296919984, or mute the thread https://github.com/notifications/unsubscribe-auth/AF8zUXHzxVIIonU0AVl9sfdAk6LMtuduks5rzYr_gaJpZM4M36UQ.

[zzuzjl]

@ qinyuhang 哦哦，赶快删了！

[WordlessEcho]

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

[JollyTRjano]

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

[ptpt52]

我来凑凑热闹：

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

[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包，发到天黑都没人应答它