关于一些基本问题的讨论

[riobard]

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

[ptpt52]

怎样构造密码包呢？ 举个例子，发送syn包，带上tcp option timestamp timestamp 就是敲门密码

当然，如何更安全，如何加密避免被伪造，还是需要深入研究一下，这只是一个简单的例子。

[ccsexyz]

@ptpt52 我的意思是，在你已经发送了一个特定序列把门敲开的情况下，如何辨别哪一个才是合法的连接请求呢？timestamp是每个新建的连接都带还是只是敲门包带？如果是敲门包带，那玩出花也没用的。

[ptpt52]

@ccsexyz 敲门包syn当然是每个新建连接都带有呀。当然只有当前连接能够连入成功呀。

[ccsexyz]

@ptpt52 中间人完全可以直接重放你的syn

[ptpt52]

哈，这就是要继续深入研究的避免它重放了 @ccsexyz

这个时候 TOTP 之类的技术派上用场了

当然安全不是绝对的，大幅增加它扫描检测的难度，就足够了。

[ccsexyz]

@ptpt52 基于时间序列是完全不靠谱的。 这个方案我个人认为唯一的作用就是坑开发人员了,并不能带来任何收益，只是把验证信息从一个地方移动到另一个地方。把ts放在tcp option里面和直接放在在应用层又有什么区别呢？

[ptpt52]

@ccsexyz 你可能不理解区别 这种方案，常用的扫描识别工具，根本无法扫描和识别了，你可以扫描一下我的服务器 81.171.7.119 感受一下。 这将大幅度增加被扫描的难度。

但是如果端口和传统服务器一样，常态开放的，扫描和识别就很容易了。

[ccsexyz]

@ptpt52 这防的是瞎比扫描者,或者说脚本小子们,而不是中间人.

[ptpt52]

@ccsexyz 我好像一开始就是说的这个目的呀。

中间人攻击才不需要关心你端口是否开放呢，直接在已经建立的TCP流 注入

[ccsexyz]

@ptpt52 额，这个issue讨论的是防止墙的探测吧。

[ptpt52]

主动扫描探测 也是探测的一种^_^

[ptpt52]

其实墙早就识别出ss流量了，人家只是不屏蔽你而已

某某说得很对，如果现在能用，没必要假象敌人出什么招数；

等到对方出招了，咱再接招。

[henrypijames]

从理念和原则上完全不能接受“我知道对方能出招，但是只要他没出我就当他不出；如果他真出了，我先挨几百上千招再去想怎么应对”。

[henrypijames]

关于“理论不安全”不等于“实际不安全”的说法：这一说法根本就不适用于（泛）安全领域的应用。（什么叫泛安全领域？你整天和别人争一个东西会怎样被“探测”“封堵”“伪造”，还好意思说这个东西不属于泛安全领域？“影梭本来就不是安全应用”纯属文字游戏。）在（泛）安全领域中，理论不安全就是可能不安全，可能不安全就是实际不安全。再换一种表述方式：“很可能安全”就是不安全，只有“没有理由相信不安全”才算安全。

在王小云那个传奇的演示之前，绝大多数人都认为MD5是“理论不安全但实际暂时安全”，结果一夜之间天翻地覆，MD5从此成为防君子（无意混淆）不防小人（有意伪造）的算法。此前的“伪苟延残喘安全感”，在遭到如此无情的踩踏之后，居然至今仍有市场？所谓“理论不安全”，翻译成白话就是“随时可能出现一个王小云把它干掉”。（顺便说一下，王小云近年来消声觅迹，是江郎才尽，还是脱离江湖成为大内供奉了？阴谋论者请自行想象。）至于有人（见上）认为“随时有可能被干掉，但目前视野范围内尚未被干掉”的东西仍然可以称之为安全，对此我只能问：你买了一辆车，开了一段时间没事，某天突然在新闻里看到该款车被检测出安全隐患，厂家召回了，那么你是把车退回去修，还是说“安全隐患只有万分之一的概率，这车我先接着开，等真出了车祸再说”？

至于说“墙没必要这样大动干戈对付影梭用户”，就更是掩耳盗铃了。我们完全有理由相信，影梭用户中有一部分已经是或可能成为“国家敌人”级别的人（至少原作者本人众所周知已经是了）。在某些特定场景下，完全可以想象墙有针对性地动用国家级别的资源来对付这样的用户。TOR一开始就定位于保护“国家敌人”级别的用户（更不用说PGP不但做出如此定位，而且作者为了保护未知的潜在的不特定的“国家敌人”用户，不惜自己成为国家敌人），那么作为应用场景十分类似（类似到很多普通用户无法区别的地步）的影梭，没有理由不作相同的安全定位。

[ptpt52]

呃，我想表达的应该是，无论对方如何出招，我都能见招拆招

某某说得很对，如果现在能用，没必要假象敌人出什么招数；

何况，我的要求没那么高，能够访问被墙的目标网站就足够了，就达到目的了。

安全性，应该是应用层自己保证的，比如 起码一定程度上讲，用https访问谷歌（无论是否经过代理），安全系数相对很高，相反你用普通http经过SS代理访问百度，不见得安全。

ss不应该考虑这些安全性，只需要做到TCP一样，做简单“搬运工”就足够了。 ss的定位，最初的想法，就是类似TCP级别的搬运工角色

要不然我也可以讲，你用TCP协议传输数据本身就不安全，TCP可以轻易被中间人攻击（注入和篡改）

何况，我上面讨论的是 一种可能的 用来防止服务器被主动扫描和识别的 手段。这些手段都是初步的想法，不保证就100%安全可靠，有兴趣可以提出新的想法改进。

[henrypijames]

@ptpt52 你真能见招拆招吗？你的程序有人工智能，会自动进化出应对措施是吗？你所谓的见招拆招不就是我说的“先挨几百上千招再去想怎么应对”。

[ptpt52]

是的

[chu8129]

@ptpt52 赞同； 个人观点:各司其职,各尽其责;ss只需要做到不被识别就好； 就跟在ss后加上kcp一样，每个工具做好自己的工作就好了；

[skywang00]

现在国外主流网站都普及https了，安全性就不用ss管了 ss做好伪装就好了

[leonshaw]

@henrypijames 我觉得没什么太好的办法。 安全对于ss来说，第一位的是可用性，然后才是保密、完整性等等。可用性不是密码学要解决的问题。 上面之所以一直在讨论加密，因为好的加密能够增加检测难度所以更加不容易被封。但是我比较怀疑这一点，因为防火墙清楚地知道你在传输加密流量。至于要不要进一步检测是不是ss，要不要封，封什么范围完全是它权衡false positive/negative成本的策略。 我们真正需要的是隐写术而不是加密，当然有的话更好。理想的情况是能伪装或者嵌入合法流量，但是防火墙如何判断什么流量是“合法”的，我们只能试验和猜测。而且跟密码学不一样，很难证明某种方法是安全的，非常依赖方法的保密，又很容易暴露特征。防火墙也一直在更新，今天的方法可能明天就不能用了。 所以我持悲观的态度，个人觉得苟且偷生、见招拆招，跟墙共同进步可能是最好的办法了。

[zcyzcy88]

1. 「密码学意义的安全」并没有多大用处，因为密码学基于柯克霍夫原则：敌人知道系统，但不知道密钥 而SS的目标与密码学无关：不让敌人知道系统（不让GFW知道SS的存在）

2. 加密本身就是一种混淆：由良好的加密算法产生的密文，密文应该看上去像随机数 就算不需要「密码学意义的安全」，为了使流量看上去像随机数，加密是最方便的手段

3. 综上所述，我支持SS提供简单的加密，但不要专注于加密 如果需要专注于加密的代理，就不该使用SS，使用OpenVPN

[arthurkiller]

并不是，加密跟混淆目的就不同，加密是防止被破解，混淆是降低特征

Best regards ✉️✉️✉️✉️✉️✉️✉️✉️✉️✉️✉️✉️✉️✉️ Arthur lee Sent from my iPhone

On 14 Oct 2017, at 9:04 AM, zcyzcy88 notifications@github.com wrote:

加密本身就是一种混淆：由良好的加密算法产生的密文，应该看上去像随机数 就算不需要「密码学意义的安全」，为了使流量看上去像随机数，加密是最方便的手段

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[zcyzcy88]

目的不同，但看上去相同

[arthurkiller]

但是，在ml看来，也许有很大的不同。因为不是专注于同一个目的

Best regards ✉️✉️✉️✉️✉️✉️✉️✉️✉️✉️✉️✉️✉️✉️ Arthur lee Sent from my iPhone

On 14 Oct 2017, at 11:00 AM, zcyzcy88 notifications@github.com wrote:

目的不同，但看上去相同

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.