Sunday, May 21, 2017

协议auth_chain_a是啥

最近SSR弄了一个新协议auth_chain_a,很多人还不知道这个是什么鬼,这里我来简单介绍一下。

介绍分为两部分,给普通用户的介绍,及给开发者的介绍。多数人只要关注第一部分的介绍就好了。

首先,是给普通用户的介绍,因为这个协议和auth_aes128_md5(auth_aes128_sha1被代表了)有点像,我们就直接用这个协议做对比。不同点有:

1 统计客户端数量是实时的。这意味着如果服务端限制为只能1个客户端使用,那么你只要把A客户端关闭,B客户端就可以立即连上,而auth_aes128_md5协议需要等待3分钟。

2 UDP部分也带了长度混淆。避免了经常使用UDP查询DNS时,数据包大小高度集中的问题。但缺点是导致UDP转发效率降低。

3 协议自身就会在数据部分做RC4加密。不同用户不同的连接使用的加密密钥都不一样,所以可以安全地使用none不需要额外的加密。 而在auth_aes128_md5里面,使用单端口多用户时都是使用公共的加密方式,会导致如果有人要刻意捕捉数据,那么是可以用公共的密钥解密的(但之后还依然需要去猜测每个数据包里有效数据的起始位置,因为偏移量是用用户自己的KEY加密的,所以即使不加密很多人用auth_aes128_md5也是用得好好的)。而在auth_chain_a协议里,为什么叫做chain呢,因为后一块数据的处理是依赖它上一块的哈希信息,每块数据里的中间是加密过的有效数据,两边是混淆数据,其长度基于上一块数据的哈希信息的计算。于是尽管使用的加密算法是RC4,但安全性也比RC4本身要高(因为最终会依赖于破解AES-128以及MD5来确定有效数据的位置)。具体见第二部分。

其它优点:这个设计用于预防恶意客户端。例如如果在auth_aes128_md5协议下,如果有人刻意修改客户端实现,让混淆用的随机长度固定为一个常数,这样会导致很容易被统计分析,而部分不明真相的用户使用了修改过的客户端,这给这些用户带来了风险。而在auth_chain_a下,这个长度是协议算法决定的,没法修改。另外一点就是这个协议的实现为低延时设计,使用TCP时往往会得到比其它协议有稍低的延迟,基于TCP的游戏下表现理论上会稍好。但大流量下载时CPU占用可能会比其它协议稍高。

但这个协议的缺点也明显,主要是两点,第一是不能自己改加密方式,不过这点亦可算作优点吧,避免选择困难,乖乖用none就好了。第二是UDP效率问题,不过如果只是查询DNS那肯定没有问题的。要是打游戏或者P2P之类的,有可能会遇到速度瓶颈,遇到的话你就切换为auth_aes128_md5甚至origin玩吧(但要是说速度远远不及其它协议那是不可能的),因为这个协议主要在TCP上花了功夫,UDP的问题还没解决好,而且我也说过这个是实验性的协议。

面向普通用户的介绍就到这里。接下来是面向开发者的介绍,说明文档:
https://github.com/breakwa11/shadowsocks-rss/blob/master/doc/auth_chain_a.md

好了,面向开发者的介绍就说明到这里了(滑稽),有什么疑问就留言吧。

作者 twitter @breakwa11

Saturday, May 6, 2017

那些让人吐血的提问

1. SSR不能用了
(这让我不知道到底说客户端还是服务端,如果是客户端到底是windows/linux/mac/android哪个,如果是android那具体是哪个android版本,是哪个手机型号?是原版还是国内厂商的各种魔改?以及哪个版本客户端,是SSR原版还是其它修改版,版本号是什么?你的Log呢?你的配置呢?就算以上通通不算,那到底不能用是什么个意思?你客户端不小心自己删了所以不能用?还是你不小心删了节点或者关了节点或者你节点本身挂了不能用?还是客户端打开了闪退?还是说连不上?还是说连上了却打不开任何页面?连不上的话又是什么表现,是一直超时还是DNS解析失败还是一发数据就会断开还是指速度特别慢?所以你问问题要是没有把以上内容说清楚我懒得理你,我懒得这样追问你十几个问题去搞清楚你到底遇到了什么)

2. SSR运行不了
(难道和上一个有差别么。我建议你如果你的电脑出了问题,打电话找维修的时候,和他说“我的电脑不能用啦”“请问你的是台式机还是笔记本,是按了电源没反应还是开机进不了系统”“这个我不清楚,反正就是不能用啦,能不能修?”坚持只说不能用,其它信息什么都不要说,那不用几分钟,保证对面的维修人员就想顺着电话线过来揍你。而万一他真上门维修发现你的问题是电源线松了的话,为了弥补他的心灵上的创伤及时间的损失,他会说你的电源线有问题(具体什么问题关你啥事,都跟你学的),反正要更换一条好的,不然使用中可能随时突然没电了,然后推荐一条垃圾线,卖个50大洋。最后用户骂这人是奸商,而维修的骂用户是213)

3. SSR上不了网/SSR连不上
(难道和上一个有差别么,有,是其真子集)

4. SSR速度好慢
(很好,这个让我完全不懂怎么回答了,如果速度慢要非要由SSR背锅的话。你为什么不先想想你加了多少钱?)

5. SSR有后门
(那你直接不用就好了)

6. 360(或其它杀软)说有病毒
(挺好的,不要用就是了)

7. SSR开源了没有
(你猜)

8. 我的SSR被封了,上不了网
(和第3个有区别么?确实有区别,就是多了个自己的猜测。不过很可能他会坚信他的猜测的,而不会去查查是不是他的服务端改过密码或什么东西。这类猜测对患有被迫害妄想症的人有奇效)

9. SSR支持AEAD吗
(SSR正在走向加密方式设置为none的方向,所以你猜呢)

10. SSR在哪里下载
(右转Google,不过现在即使左转百度也能搜索到吧)

11. SSR不是很稳定,网络时快时慢,求改进
(我觉得说这句话的人也需要改进改进)

12. 粉色好难看
(摊手,你把自己变弯不就好了)

13. SSR比SS安全性更高吗
(SSR不关注安全性,而且离开具体配置来比较就是耍流氓)

14. 我用SSR访问Google运营商会不会知道我访问了Google
(我觉得直连更好,反正都知道了的话)

15. 我用SSR运营商会不会知道我的服务器的地址呢
(建议你拉私人海底光缆,这样运营商就不知道你的地址了)

16. 怎么安装SSR
(那你知道WIKI在哪里吗,知道Google吗)

(待,持续+1s)



Tuesday, April 11, 2017

无题

这里准备写一下最近的感想,不说技术方面的。

最近发生了一堆事情,尤其上星期我状态惯例很差。而就在这个时候,各位dalao发了两篇文章,都说到安全性。

反正我是很不懂为什么要安全性啦,好比面对同一个围棋局面,有的人认为要抢实地,有的人认为要厚势,有的人要摆大空模样,但这不重要,重要的是,无法说服对方同意自己的看法。而唯一说服对方可能性的办法,就是和他下,下多少把赢多少把,让对方输的怀疑人生。

而且,最大的问题是,他们的看法我认真看过几遍,都和我的看法很不一样,那这当然了,要是和我的看法一样,就可能直接和我合作了,怎么还写这种文章呢,而且丝毫看不到任何说服他们任何一个的可能性。当然,反过来看,他们也不存在说服我的可能性。

那这问题不就来了么,为什么都认为自己的是对的?而且为什么都不能说服对方?

举个例子,还是拿围棋。比如死活,这一片棋,说多不多,说少也不少,有4、5个,还没活,正遇到攻击,那怎么办?当然是做活搜刮对方的目数啊。当然,大部分情况下这样都是对的,但如果纵观全局,如果弃掉这4、5子却能在外面捞到比这更多的目数呢?理论上当然可以,但谁能看出来保证能捞到更多呢?你得有一个远超局部的眼光,才能看出弃子后的变化。

所以,真正的问题是什么?没错,正是看问题所在的局部。每个人所在的局部来看,结论都是对的,问题是,大家争论问题的时候,都没有讨论这个“局部”的范围到底是什么。而之所以他们的看法和我的很不一样,正是这个“局部”的区域并不相同。

但是,更好玩的是,如果真要讨论这个“局部”本身,那么结果会是相互否决对方的“局部”的合理性。

也就是说,除了他们的“局部”能重叠的地方,其它地方是不可能讨论下去的,讨论不过是浪费时间。

但是,这些问题偏偏是最不应该闭门造车,但事实上看来却不得不先闭门造车,为什么?因为你都没有把车造出来,拿什么来说服对方?码农最喜欢的一句话是"talk is cheap, show me the code"。这个是从我2015年8月底学会的,自此之后我再也不只发结论,只发相关的资料和代码,结论本身一点也不重要,更重要的是结论本身会影响很多人的利益,为了自身利益那些人怎么可能会让步?

最后结果是只能自己一个人研究,但自己研究很可能会出问题,除非自己就有足够的眼光。当然这是很困难的,但可以通过不停地研究不断进行修正,所以我自己并未停止研究,最近又新发现了几个从未曾想到的问题。

自己一个人研究非常的孤独,不理解你又不熟悉你的人会批判你,你熟悉的人却没有理解你的,而你不熟悉的人你没办法知道他理不理解你。这种情形有点像我小学的时候,没有女生找我玩,当然我更不会去找男生玩,不过我早已习惯。后来我也成了班里唯一一个升重点中学且为重点实验班的女生。当然,我也是因为去了那个班才知道牛人如此多,尤其是数学考试几乎总是比其它班平均分高出20+分,卷面分要是拿不到90%那就是在班里倒数几名的范围了。哪次要是平均分比第二名的班高出的分数小于20分可是得被班主任(数学老师)狠狠补课的,各种变态般的计算题证明题。到中考,依然是一堆人140+分(总分150),拿140+分简直像是必须的。压力这么大的环境我都不记得我是怎么活过来的。

所以,在实在压力大得不行的时候,怎么释放心理压力呢?我的方法太简单了,哭一会就好,但我是在4个月前第一次试过几乎哭了一天不停,最麻烦的是在别人面前还要装着没事,笑着聊天。挺有意思是事是这被很多人说“玻璃心”,那我反问一句,你们这些没有“玻璃心”的,是不是遇到点困难就放弃,所以从来不需要哭呢,那你们很"man"啊,你们努力过些什么了?那这些人当然会说:“上个网要努力什么?关我什么事?”,没错,因为这不需要成本,骂人,伤害别人,在网上除了花点时间打字,啥都不需要,所以盗版有理,破解王道,免流标配,只要不花钱,花点时间不算什么,尊重别人是什么鬼,我爱干什么就干什么,不是说言论自由吗?你管我说什么呢?<==持有以上观点的人,我都直接拉黑。

那回到文章一开始的问题,如果非要讨论安全性,那让我推荐一个加密方式的话,我推荐rc4-md5,哪个速度快用哪个(如果你机器上chacha20更快那就用这个,至于AEAD的没必要,因为这个虽然增加了安全性,但在另一个方面下降了(不是加解密时间),我不推荐,所以SSR里不会有AEAD),如果你用的是SSR的auth_aes128_*协议,那就大胆用none吧,至少目前看来不需要加密,不需要这种安全性。但千万不能直接用origin协议不加密,因为已经能准确多次重现打开特定网站会被立即封锁。那如果你非得要安全性怎么办?在PC上很简单的,只要开OpenVPN,开最高级别的加密和交换密钥方式(用ECC系列加上aes-256-gcm),以SSR做二级代理走TCP,问题就解决了。

有人把抗识别定义为以下两点:
1.观察一段数据流量,是否能判别这是一个代理协议的流量
2.对于一个仅暴露出 TCP 端口的黑箱,能否判断这个端口提供了代理服务
> 最后得出的结论一:最新的 shadowsocks 已经能满足抗识别的两个要求
这我当然是不同意的,不管1还是2均不满足,2还依赖于实际的服务端必须是ss-libev以及必须是AEAD加密。而且事实上,不会只使用1或2,而是组合使用,而且手段还不止这两种。
> 结论二:而使用 HTTPS,观察者无法判断这是一个 HTTPS 代理还是 HTTPS Web 服务器
这我同样是不同意的,可以识别,即使拿同一个端口,一会儿跑实际的https,一会儿跑https proxy,两者是不一样的,能知道什么时候是https proxy。甚至强如obfs4proxy,我都可以轻松地仅从流量记录看出来协议的一些关键信息,例如协议的RTT,有人看过文档和我说过RTT是3,但我一直想验证一下,又不想看代码,于是尝试看了一下记录,竟然比我想象中还要简单地看出来。
那为什么他认为满足而我认为不满足?其实就是所用的识别手段范围不一样,但其实很难因为自己的识别手段办不到而断定不能识别,好比某个猜想你证明不出来,你也找不到反例,于是你也无法推翻它,也无法肯定它一样。我都不会武断的认为SSR如今无法识别,但能肯定的是还有做得更好的空间。

那我怎么看“抗识别”呢?我的看法依然完全不一样,我并不这样定义,我把这个定义写成了一篇文章。而SSR达到了我的期望了吗?还没有,我头痛了几个月在研究,新的协议还没看诞生,还有好多难点。但大家造轮子好像造得很轻松的样子呢,那当然就是目标不同导致的,大家觉得很轻松,我觉得很困难,因为我还要解决几个数学问题。

看着blogger里囤着的好几篇一直在draft状态的文章,一声叹息,等吧,等我什么时候能解决这个问题再说,我继续折腾我自己的事去了。

Saturday, April 1, 2017

一些代理协议的简单统计分析(认真脸)

这个文章不是什么高深的技术帖子,只是个统计分析,也是为了大家都尽可能看懂而写

这里的分析也不是分析什么高大上的东西,只做一个很简单的事情,就是统计,然后画图。在这两年间居然没有人做这个工作,所以我想我还是简单做一做,给大家对这些代理协议来一个直观的感受。

那统计什么呢?通过抓包记录,把每个数据包的大小以图形的形式表示出来

以下为示例图(图1,请放大仔细看):


这个图,横坐标是包的大小,最左边是0,最右边是1447,最下方有个标尺,一小格就表示10,一大格就是100,纵坐标是这个包发送了的个数的比例,数量越多就越长,以最长的那个作为100%高度。同一根同时存在紫色和绿色,其中紫色的是上传,绿色的是下载,例如这个图里面,最左边第一个小格的中间位置(横坐标是6),绿色的高度是大约是紫色的高度的2/3左右,即大小为6的包,下载的数量是上传数量的2/3左右。

上面这个图可以看出,包的分布非常的稀疏,大多数位置都是0,而且大多数的包都集中在特定的位置上(贫富差距非常大),导致高的柱子高度特别的高,尤其是上传方向上。那么这些特别长的柱子可以作为特征吗?不,并不一定,并不是长的就有用,但特别短的就一定用不上。特别长的那些可能只是你访问不同的网站而产生的不同的特征,并不一定有代表性。

图2


以上这个是另一个例子,你发现特别长的那根的位置很明显的不一样了,嗯,没错,这个其实用的是另一个加密且访问不同的网站的结果。那么,应该怎么找特征呢?右边的包先不用看,看左边的,即尺寸较小的包,前一张图最小尺寸的包是6,而这一张的是18,这两数值有什么作用吗?首先,这两数的差是12,看第一张图的横坐标44的地方,有根较高的柱子,然后52的地方有根稍矮一点的,那这两个数分别加上12,得到56和64,对照看看第二张图这两个位置,正好也有两根很高的柱子,这种吻合说明的是这两个应该是跑的同一种协议,而第二个在第一个的基础上多了12字节的偏移。而事实上,这是个代理协议,代理的流量是访问twitter/youtube这类https(TLS)站产生的。而通过抓取实际的网站访问流量再画成图,我们可以发现(此图就不提供了),前面图1相对于实际流量有6字节的偏移,图2相对于实际流量有18字节的偏移,而这个偏移正好等于图上的最左边的包的大小,而实际的流量并不存在6或18这根柱子,因为不可能在0的地方有数据包。于是,这能得到两个结论:1,这里的6或18字节偏移应该是这个代理协议在每个数据包的附加数据(表示包的长度和数据效验等);2,这里的6或18字节的数据包一定是被代理的协议里面不存在的包,是一个有特殊功能的包,这个包将是这个协议的最明显的特征。

以上两图就简单分析到这里了,揭晓答案吧,第一个图是V2Ray使用 vmess协议 + aes-128-cfb加密的记录,第二个图是V2Ray使用 vmess协议 + aes-128-gcm加密的记录。根据协议文档,第一个是有2字节的数据包长度及4字节的校验,正好6字节的附加长度,第二个是2字节的数据包长度加上16字节的tag作为校验,正好18字节的附加长度。也就是说我们可以通过记录https站的数据包分布与其作对比,根据偏移的字节数知道这个连接使用的是什么加密,以及实际上在浏览什么网站。

我们再来看一个协议的统计图(图3)


这一个是firefly代理的统计图,但同样是访问https网站记录下的,在图上你能看到分布比前一个还要稀疏,但非常有趣的一点是TLS的特征在这里被抹掉了,但这个代理我没有找到具体的协议文档描述,我也没空去看代码分析这些包具体对应什么,这个就没法详细说了。但我们可以知道这个代理的协议是一个上下行不对称的协议。什么叫上下行不对称?你对比一下前两图,较高的柱子往往是两种颜色同时存在,说明同一类型的数据包,上传和下载是一样大的,可以猜测出使用了一样的数据结构。而这个图,神奇般地没有一根柱子同时存在两种颜色,也许是统计数据还不够多吧,但足够说明上传和下载的数据包格式应该是不一样的,不对称的。而非对称协议很可能表明它是个使用一个TCP连接承载多个TCP连接的协议。

接下来,我们来看看大名鼎鼎的Tor项目的混淆插件obfs4的统计图4(使用的是ptproxy项目的封装,作者gumblex)


一眼看过去,显著地和前面几个不一样,数据包分散地分布在不同大小的地方,可以想象obfs4连接的时候,就产生随机大小的包,以致于非常难通过分析知道这个连接可能在发什么样的数据,从抗分析上会明显强于之前和协议(但安装过程如此复杂麻烦实在不清真)。但是直觉告诉我这些高的柱子的位置很奇怪,于是我把客户端和服务端都关了重开,重新统计得到一张新的统计图,同时把两张图重叠一下得到如下图5:


重叠在下方那个是图4,上半是访问http站(不是https/TLS)产生的流量的统计图。你会发现居然还是在相同的地方出现了高高的柱子,尽管很分散,但位置竟然是固定的,且与你访问什么内容无关,而且是非常明显的上下行对称的协议(所有高的柱子都同时存在两种颜色),这让我非常的不解。从obfs4的文档上看,它确实有随机填充的字段,而且随机范围从0到8096,但是由于这里只统计了小于1448的数据包,大于的在这里做了一次过滤,没有在图上画出来。既然是随机,那居然只分布在如此少且相对集中的地方让我感到这很奇怪,因为这些固定的地方活生生成为了obfs4独有的特征。与此同时,我们能解释一个事实,就是obfs4为什么明显慢于其它的代理,因为它的随机填充的范围实在是太大,几百字节的包填充一下平均4千字节,导致会多出两三个数据包要发送,速度起码慢一半,而事实上确实如此。这里故意没画大的数据包,因为如果画上去了,前面这些柱子将会短得几乎看不见,目前貌似也只有obfs4会这样发包,超过90%的包都等于MSS大小(注:一个等于MSS大小的包会连同它后面的一个包(不管它是不是只有1字节)整体作为一个包统计)。如果以上内容核实,那么obfs4就是可以被识别的,但目前数据量不足,还需要多建立几个服务端测试(安装好烦啊)。我曾经和obfs4的作者Yawning Angel沟通过,他确认了obfs4确实存在问题,有新的混淆插件的计划。

最后,我们来看看SSR的auth_aes128_md5协议(不带混淆)的统计图6(使用C# 4.1.5版本客户端)


这明显得不能更明显地和前面的都不一样,可以清楚地看出来,这个的数据包分布均匀得多,也不存在哪个尺寸的包特别多,且不管上传还是下载都是如此(注,这个图是比例图,看上去似乎到处都很高,但是前面图1至图3最高点实际值达到几百,而此图最高的柱子高度是13,若把此图放在图1至图3使用相同的坐标系显示那么会显得很矮,矮得几乎看不见,高度仅1至2个像素,高度比例非常低,变成应该被忽视的部分)。这个特性有什么用呢?这个特性会导致无法通过特征分析知道你在浏览什么网站,也难以与发送随机数据包的协议区分开,更无法知道到底上下行对不对称,总之,这些数据包的分布导致大部分的统计分析失效,同时也会导致DPI或模式识别失效。由于分布均匀的特性,如果与其它具有明显特征的协议(如同时开一个http/https站)在同一个端口传输,那么外部特征将是那个有明显特征的协议,因为SSR的auth_aes128_md5协议本身的平均分布特性不会影响原来的特征分布,关注点就会被成功转移,将是以上几个协议里最难识别的协议实现(臭不要脸地)。

一个小插曲,有个网友做了个实验,使用auth_aes128_md5协议,不带混淆,不带加密,直接祼跑超过了80G流量,还是啥事都没发生。有没有人有兴趣用origin协议不带加密试试看?实验过的告诉我一声什么结果。

我一本正经地胡说八道完了,以上所有内容其实都是骗大家的,愚人节快乐。

Saturday, January 14, 2017

关于ShadowsocksR在2016年底的停更事件

事情已经过去了半个月,我想了想还是重新说说半个月前发生了什么吧(本文写于2017年1月14日)

早在2016年12月13日,在ss-libev刚刚push了obfs分支我就知道准备支持混淆了,我在那个时候,我是非常好奇的,好奇在这个混淆推出之后,那些一年前还在极力反对混淆的人会有什么样的反应,所以我也对我周围的人说,我非常期待这个混淆的推出,希望尽快合并到master主分支。

然后到了12月23日,转折点出现了,ss-libev又在obfs分支commit了一个新的混淆,一个名叫tls的混淆,我仔细看了代码,用的办法和SSR的一模一样,使用session ticket方式握手免除证书发送步骤。如果你说混淆早在N年前就有了,没错,几年前就有人弄过混淆,所以之前推出http混淆的时候,我是好奇的,是支持的。然而这个tls混淆所用的方式,是SSR首创的,半年前有其它项目(包括蓝灯)的作者问过我原理,同年9月Tor项目也有人和我交流过这个方案,并向Tor提案,但因为这种方式没有前向安全性而没有采用。也就是说,这个混淆只可能有唯一的参考来源,就是SSR。好吧,既然你用了这个做法,那到时候发布的时候,总应该说明点什么吧,我这样想着,并这样等待着。

等到12月27日,ss-libev把obfs分支以Squash方式合并到master分支(结果就是所有的commit合并成一个),同时obfs分支删除,于是具体的修改记录被抹掉了,这种神奇的合并分支方式让我惊呆了,为什么要选择不保留每个具体修改变化。当然,这天还不止发生这个事,还有某有名且特别贵的iOS APP作者高调宣布要支持这个obfs,而且非常迅速的在当晚10点就发布了支持http混淆的TF,原来当时声称极力反对混淆的人,如今是这样做的啊,速度之快让我佩服,你这么高调,看来某种导致涨价的阴影其实在你心中并不算什么了是吧,我真是服了。我顶着巨大的怒火,继续做我原本要做的事:组建ShadowsocksR organization,我原来的决定是通过圣诞节这一时机,重新开始公开发布,因为已经以不对外公开的方式保持了10个月了,就是为了躲开那些自以为是的喷子们,而这时越来越多开发者和我合作,所以打算重新使用github同步代码,顺便组建团队。

终于到了12月29日,发生了一件更严重的事情(不过这件事情只能保密了),这件事对于我来说,简直是致命性的打击,让我有停止维护的想法,再看看ss-libev那边的issue和文章,一直在刻意避免提及SSR,几个原因全部集合在一起,我感觉我要崩溃了,于是写下了这个公告,也是我第一次从写公告开始,一直哭到晚上睡觉(失眠)。

第二天起来即12月30日,这下不得了,遇到了好多dalao和我谈心,劝我不要停止开发,好几个有影响力的人出现了。而与此同时,知乎聚集了一帮troll,矛盾出现了,到底我应该怎么做好呢?如果要说继续,可我已经说了要停止了,那边还一直在那骂,答案还不断的更新,改了又改。我仔细观察了一些ID,有些ID我是认识的,从去年就一直黑到现在,到上知乎喷我。这时候,我想知道真实的支持比例,不想被这些喷子盖住真实的支持者,因为知乎上支持的答案大多都被举报删掉了,于是晚上开了个投票,并表示,只要有10%的反对票就停止开发,因为我确实觉得,如果反对的都有10%了,那价值就确实没多少了,我花费那么多时间在细节上的处理没有被认同的话。

到了12月31日,投票的比例让我吃惊,连5%都不到的反对票,比ss-android的1星2星的比例还要少,可以认为这个比例是完全正常的。喷子认为这个投票没有意义|做秀|用来给自己台阶|转嫁仇恨,我去,阴谋论学得真好,为什么不去写代码跑去学阴谋论和诡辩?明明一帮都是懂代码的,那我也阴谋一下吧,因为代码写不好所以去当喷子了。但我却在这次投票第一次知道了真实的支持比例,并没有我想像中那么差。同时也知道不少SS站站长表现了对我的支持,发布了支持SSR的公告,真心表示感谢。

然而,知乎的喷子并不止步于此,说什么2016不是说过停更吗(暂时停更四个字你一定要少看两个我能有什么办法),说什么SSR是个团队啦这样那样的,嗯,这句话同样在2015年8月某blog上出现过。 不过从2017年开始,确实就开始是个团队了,由开发者组成的团队,如果要继续黑有多少多少个运营什么的,将来打算怎么收割粉丝什么的,随便黑,我记得佛学里有一句话大概是这个意思,你的心是什么样的,那你看到的别人和世界就是怎么样的。

现在我继续开发,除了想继续把我还没完成的东西继续做下去以外,还想给这些自以为是的开发者通过事实狠狠的给他们一记耳光。还是那句话,请记得SSR是不存在的,SSR是垃圾,SSR的混淆是多余的(SS的混淆就很有用了),协议是无意义的。如不了解SSR,或存有任何疑心,请勿使用。

Sunday, January 8, 2017

ShadowsocksR单端口多用户配置方法

此文更新于2017-02-21,如你早于这个时间部署,可能要升级后端

如果你要尝试这个新功能,首先把服务端和客户端均更新到最新,客户端C#需要4.0.5版或以上,SSR-android需要3.3.3版本或以上。

第一部分:直接修改服务端配置文件大法,仅适用于使用单用户配置的情况
首先是服务端的配置
服务端把协议(protocol)配置为 auth_aes128_md5 或 auth_aes128_sha1,然后在协议参数(protocol_param)配置所有可用的用户id及其密码,示例如下:

        "protocol": "auth_aes128_sha1",
        "protocol_param": "64#12345:breakwa11,233:zhihuyaowan",

含义:
在#前面的表示每个用户的最大客户端数,照着写这个值或者不填都可以,但必须有#号。在#后,以英文逗号分隔所有的用户,而英文冒号的前面是用户的id,注意这个id必须是范围在 1~2147483647之间,后面的是用户的密码,密码不能有特殊符号,建议仅使用数字和大小写字母

然后是客户端的配置(此处配置同样适合下文的其它配置模式
客户端方面非常简单,需要使用用户id为12345的连接,那么在客户端的协议参数(protocol_param)里面填写 12345:breakwa11 就行了,如果使用id为233的同理,其它参数服务端怎么配置的就怎么写

那既然多用户可以单端口了,那能不能做得更像一个网站?完全可以的,如果是http的话,服务端安装一个nginx之类,把端口开在8080(监听127.0.0.1),然后SSR的端口开在80,同时在SSR的user-config.json里修改参数 "redirect" : "127.0.0.1:8080", 这时,直接用浏览器打开,就可以直接看到你开的网站了,而改成用SSR客户端连接就成了服务端了。不过注意的是这时候最好要开相应的混淆哦ヽ(´▽`)ノ

目前这个是刚出的功能,还在测试中,后端和面板还没有相应的支持,也没有流量控制等,建议几个人自己合玩的时候可以这样用,特别地在某些学校或公司这个功能非常好用的哦。

第二部分:使用mudbjson模式配置(适合单服务器多人合用或试用服务器)
2017-02-21更新:
现mudbjson模式多用户已支持,简要说明如下:
首先先创建对应的用户id,如果这个id大于65535,那么此用户仅用于多用户模式,小于等于65535时会同时监听这个端口。然后创建多用户端口,相应的protocol_param里就填写"#"就行了,以下是配置示例:

[
    {
        "d": 0,
        "enable": 1,
        "method": "aes-128-cfb",
        "obfs": "tls1.2_ticket_auth_compatible",
        "passwd": "vwHF%35j",
        "port": 12345,
        "protocol": "auth_aes128_sha1",
        "protocol_param": "#",
        "transfer_enable": 1125899906842624,
        "u": 0,
        "user": "12345"
    },
    {
        "d": 0,
        "enable": 1,
        "method": "aes-128-cfb",
        "obfs": "tls1.2_ticket_auth_compatible",
        "passwd": "E&iWmlxu",
        "port": 10001,
        "protocol": "auth_sha1_v4",
        "transfer_enable": 536870912,
        "u": 0,
        "user": "10001"
    },
    {
        "d": 0,
        "enable": 1,
        "method": "aes-128-cfb",
        "obfs": "tls1.2_ticket_auth_compatible",
        "passwd": "4~fGiKeY",
        "port": 100002,
        "protocol": "auth_sha1_v4",
        "transfer_enable": 10737418240,
        "u": 0,
        "user": "100002"
    }
]


在以上例子中,端口12345是多用户端口(可看成一个公共用户,但无法直接使用),有两个子用户,一个是10001,一个是100002,而10001用户,既可以使用10001端口,也能通过多用户方式使用12345端口。而100002用户只能使用端口12345。在使用端口12345时,实际的使用流量会统计到10001或100002上。注意的是用户10001在配置客户端使用多用户端口12345的话,配置密码为"vwHF%35j",即除了协议参数均填写此端口的配置,仅协议参数改为"10001:E&iWmlxu"即可。

其它:在使用mujson_mgr.py脚本添加协议参数时请使用-G且参数使用英文双引号包起来
如有不明白可留言问

第三部分:使用面板支持(适合站长多服务器下使用)
2017-01-24更新:
现在已经有支持此单端口多用户的面板及相应的后端,具体参见 https://github.com/esdeathlove/ss-panel-v3-mod

2017-02-21更新:
如果使用老面板,包括sspanel和WHMCS等,后端更新到最新后,那么可以在user-config.json内,修改或添加如下字段
"additional_ports" : {
    "6666": {
        "passwd": "pubpassword",
        "method": "aes-128-ctr",
        "protocol": "auth_aes128_md5",
        "protocol_param": "#",
        "obfs": "tls1.2_ticket_auth_compatible",
        "obfs_param": ""
    }
},
其中6666是那个端口(如果要设置多个,就additional_ports内再添加一个,注意逗号分隔),protocol必须为auth_aes128_md5或auth_aes128_sha1,protocol_param只需且必须写一个#。(直接复制以上内容时记得修改密码配置)

第四部分:高级端口转发
如果设置多个多用户端口,想设置不同端口不同的转发规则以最大化伪装为其它服务,例如开了80端口和443端口作为多用户端口(以additional_ports方式作为示例):
"additional_ports" : {
    "80": {
        "passwd": "pubpassword",
        "method": "aes-128-ctr",
        "protocol": "auth_aes128_md5",
        "protocol_param": "#",
        "obfs": "tls1.2_ticket_auth_compatible",
        "obfs_param": ""
    },
    "443": {
        "passwd": "pubpassword",
        "method": "aes-128-ctr",
        "protocol": "auth_aes128_md5",
        "protocol_param": "#",
        "obfs": "tls1.2_ticket_auth_compatible",
        "obfs_param": ""
    }
},
同时本地的nginx/apache开启端口1080和1443,那么在user-config.json里修改如下参数:
"redirect" : ["*:80#127.0.0.1:1080", "*:443#127.0.0.1:1443"],

配置好后,直接访问80或443端口,将是个正常的网站,用SSR去连接则为代理服务。
其它:nginx的rewrite规则默认会使用监听的端口,这时会导致rewrite有问题,需要指定一下端口号

Monday, January 2, 2017

知乎语录(防删用)

作者:梅石坚
链接:https://www.zhihu.com/question/54189771/answer/138642982
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

题记: 技术界晚香玉——breakwa11
好像破娃的粉丝很喜欢去淡化过去不开源的事实,并十分不情愿去看SS 作者clowwindy 的发言记录。
我不知道一个根基就是建立在以自我为中心上的,一个致力于玩小圈子文化大力发展核心粉丝的人,之后做这出这样的事情又有何奇怪呢?
我丝毫不意外破娃这次的举动。遥想当年,老美世界第一大国不承认中国地位,时任领导不就是时时对标美国,一直作为假想敌深入国民教育中么?
surge 的影响力很大,率先不支持SSR 引起了我们破娃的愤怒 。破娃一如之前的性格特色,你不支持我就要独立。但是她细想了下,即便自己联合多少免费软件开放者以福利为名的推广合作,也无法撼动surge 在业界的地位。
这时候又学到了很地道的一套,哭嘛。
前天我还在跟友人讲,我真的很想去给破娃的投票刷票,刷到距离放弃线百分之零点一,看破娃怎么给自己找台阶。很好玩的是,昨天公布结果的时候,破娃重点说了句,发现了刷票迹象。
我就纳闷了,有人真的去刷票会饶过你吗?(事实上我并没有刷票)
破娃给自己树立了很多假想敌,但是她真的会去出击么?不会。你看中国不时渲染的气氛,真的会派城管统一银河系么?
所以投票什么的,只是粉丝的初选罢了。
破娃的核心策略和surge 高度相似,先是圈定一部分粉丝,很散的粉丝群。然后通过一定的“大事”筛选粉丝群,将忠诚粉丝群体圈起来,最后就是收割粉丝。9.9美元让大家发现surge 好用,接着喝茶制造大事件,然后涨价圈定核心粉丝。等到火遍各大论坛的时候,盗版机制一出,收割剩余粉丝。破娃学习能力很棒,这不,圈定粉丝后开始收割了。



从与开发者合作推广开始,到现在的公开讲捐款。慢慢看吧,surge 那套,破娃会熟练起来的。(我不反对对于开发者的捐赠行为)
1.2更新:一如既往,我们的破娃开始渲染和 clowwindy 的关系了。SSR 因为SS 而来,现在破娃开始钦定clowwindy 的性别了。

大家有没有觉得这个套路很熟悉啊?
附赠,摘录一段推友的点评:
“希婆这么努力为我们好你们还要抓住她邮件门的把柄黑她”
“不遵守邮件保密规定只是一开始,以后会遵守的”
“希婆输就是因为她是一个女的”
“坚决拥护希婆,美国普通老百姓都是傻逼,灯塔国药丸 ”
然后你们看看这帮人和某些人的论调是不是很像
(已获授权,脑残粉自重请勿打扰原推主)