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 的性别了。

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

Tuesday, December 27, 2016

开撕奇文共赏

实在受不了如此虚伪还爱装13的人,决定还是写文章开撕好了,来共赏一下奇文共赏

以下先罗列事实
在2016年12月26日21:20分截图
然后,我更改主页内容,并小范围发了一个消息(于21:34)

主页更新:
因奇文共赏博文更新
原文中
因博主被DDoS于是关闭了评论
改为

因博主被DDoS,且因为删一些脑残粉的评论太烦(此为博主原文),所以曾经关闭了评论,所以你无法在那里看到16年12月24日以前任何支持SSR的评论
其实我博客Google Ad说估值20美元,老提示我让我放广告,但我不想放广告,但他那才0.24这么可怜,大家帮忙给他点击一下呗
https://t.du9l.com/2015/08/qi-wen-gong-shang


Monday, December 5, 2016

如何以最暴力的方式防止百度定位泄露真实位置

其实我很早就知道这玩意,并以以下的方式屏蔽,最近又有很多人关心,我就把我的方案公布一下

在系统的host加入如下的东西即可(即屏蔽掉这些域名)

1.0.0.1 api.map.baidu.com
1.0.0.1 ps.map.baidu.com
1.0.0.1 sv.map.baidu.com
1.0.0.1 offnavi.map.baidu.com
1.0.0.1 newvector.map.baidu.com
1.0.0.1 ulog.imap.baidu.com
1.0.0.1 newloc.map.n.shifen.com

::2 api.map.baidu.com
::2 ps.map.baidu.com
::2 sv.map.baidu.com
::2 offnavi.map.baidu.com
::2 newvector.map.baidu.com
::2 ulog.imap.baidu.com
::2 newloc.map.n.shifen.com

以上写法会让连接超时等待,如果你希望连接立即拒绝断开,那么把"1.0.0.1"改为"0.0.0.0",把"::2"改为"::"即可

如果你使用代理,那么在代理服务器及本地都最好设置一下

Friday, November 11, 2016

局域网下免设置路由全局透明代理

如果你不想光为了透明代理而单独买一个可刷OpenWRT固件的路由器, 同时你在局域网内有至少一台linux机器(可虚拟机),那以下内容可以帮助你在不需要设置路由的情况下实现透明代理(当然本质上就是把那台机器当成路由来用)。

首先你需要一台linux机器,ubuntu/debian/centos等均可,能编译ss-libev,使用iptables(于是不能centos7,我不会调教那个firewall)。你可以使用真实机器(如树莓派)或虚拟机。如果使用虚拟机,网络类型需要设置为桥接到物理网络,如果是VMware,不要对“复制物理网络连接状态”打钩。我建议使用虚拟机或性能不差的真实机器,这样网速不会受到性能上的限制。

接下来,安装操作系统、安装编译依赖包、git clone ss-libev、configure、make等这里就不说了,网上说明有很多(虽然大多数是过时了)。

编译好后,如果你clone的是ssr的libev版本,里面自带了一个ssrlink.py,可以通过此脚本快速生成一个客户端使用的配置文件,例如执行:

python ssrlink.py ssr://MTkyLjE2OC4xLjI6MTA4MDphdXRoX2FlczEyOF9tZDU6YWVzLTEyOC1jZmI6dGxzMS4yX3RpY2tldF9hdXRoOk1USXpORFUyLz9vYmZzcGFyYW09ZEdWemRDNWpiMjAmZ3JvdXA9ZEdWemRB > config.json
即可生成一个配置好了的config.json

东西都准备好了,现在开始配置。首先是开启ipv4转发,编辑/etc/sysctl.conf,解除net.ipv4.ip_forward = 1的注释,或直接添加这么一行,保存文件,并执行sysctl -p使修改立即生效。然后,设置IP为静态的,例如你的路由器地址为192.168.0.1,那么你可以设置为192.168.0.2,具体设置方法参考linux文档。设置好以后,在需要全局代理的机器上,把网关地址改为192.168.0.2,测试能不能正常上网(现在还没有通过代理),如果不能,那检查防火墙配置,或尝试重启它再测试。能正常上网后再进行后面的配置。

Monday, November 7, 2016

关于breakwa11的印象精选

在11月1日我发了一个调查,现已收到超过500条回应,以下总结一部分我自己觉得比较有代表性的印象(敏感信息已过滤,如发表人的联系方式)

"妹子做我女票"

"~~肌肉猛男一位~~"

"腐女一枚,学霸一位,吃货一个"

"女装大屌萌妹(>ω<)"

"逗比"

"技术宅,自我中心,成长环境好,有点娇生惯养,喜欢钻研自己入迷的东西,应该还比较漂亮,有点责任感,没有bf……其他想起来有机会再说吧。 另外就是感谢ssr的开发!"

"有 jj 吗"

"印象:还不错;评价:贡献很大;想说:感谢你所做的一切,如果历史是公平的,如果我们现在的普世价值观在后世任被认可,我相信你会受到后人的感谢与尊重的。"

"这个有大唧唧的女孩子为啥还没有被喝茶呢"

"印象还好吧,简单看过之前的争议事件,未了解前后情况,所以不好发表意见。不过能持续维护SSR,是很值得肯定的。
所以不用太在意别人的意见,做自己喜欢的就好,当然不含坏事。"


"之前完全没有听说过( •̀ ω •́ )y因为毕竟 SS 也都是网上随便搜一个脚本就安装了,但是速度实在太慢,后面实在受不了,才又找各种优化方法,才知道了 SSR ,折腾一下,感觉蛮好,速度也不错,以前速度永久了变慢换个机房 IP 就变好了,所以说加了混淆啥的还不错,但是具体的一些纠纷啥的也是后来才有看到,what?以前在 V2EX 居然木有看到,∑( 口 || ,so ,不管怎样,支持下了,继续努力把!!!PS:最新粉色版的 SSR 在我的 Android 手机上耗电量总是排在前几名,是有什么问题嘛??系统版本是 5.1.1 ,Flyme  PPS:听说开发者是一个妹子>.< "

"Breakwa11感觉很神秘,有点小脾气,不是很客观的一个人。但还是很感谢他(她)为我们带来这么好的软件,希望他(她)一直隐身下去直到民主那一天的到来。 THX!Breakwa11!"

"①辛苦写出SSR的天才少女 ②坚称SSR是私人用软件并采取各种方法减少SSR公开度的顽固开发者 ③不求报酬但求匿名的网络幽灵"

"没什么特别印象啦,就觉得很厉害,但是我现在用着原版ss感觉速度和稳定性比ssr强,另外就是希望ssr专心做好fq就好,免流这种千万别沾了,毕竟不被政府盯上是最好的,最后祝ssr越做越好,易用性真的比原版强太多"

"求照片"

"破娃你是D罩杯嘛?"

"上帝一般的存在!!!!非常的感谢破娃给我们带来了更安全更快速的上网方式,希望破娃可以将SSR做的越来越好,希望SSR万古长存!!!!!!我没有太多的编程基础,也没法贡献自己的力量,所以我只能说,发自内心的感谢!"

Thursday, November 3, 2016

ShadowsocksR协议的选择

其实这个要说的少得多,总之就一句话,能用auth_aes128_md5或auth_aes128_sha1的,就直接用这两个,最好不要开启兼容,其它的协议都不建议。但如果要解释的话,这个说来话长,需要一点点说明其它的协议的特性。以下简略说明一下各协议的问题。

首先我们来看原版协议(origin),原版协议有着最少的数据冗余,在没有限制的情况下,必然是原版协议速度最快,这是毫无疑问的。其它的协议的兼容,全是为了兼容原版协议。那既然原版理论上最快为什么不直接用?因为它没有数据完整性校验,无法确认数据是否被篡改,容易被攻击,它也没有做数据包的长度混淆,可以通过数据包长度统计分析检测出来(例如此专利中所说的方案)。当然如果你所在的地区直接使用没有感觉有什么问题,那直接使用就可以了,没有必要考虑后面的。

接着来看原版的OTA协议,这个协议增加了从客户端到服务端单向的完整性校验,于是服务端到客户端的方向还是存在同样的问题,且它也没有做数据包的长度混淆,一样可以通过数据包长度统计分析检测出来。另外此协议并非能抵抗CCA(Chosen ciphertext attack),依然可以通过CCA来确定这是不是OTA协议(通过服务端行为攻击,具体方法这里不说)。

Friday, October 28, 2016

ShadowsocksR混淆的选择

最初我设计这个混淆的时候并没有想到如今产生了如此多的黑科技用法,只是想着伪装为看起来像正常的流量,减少被注意到的可能性而已。

对于大多数人来说,混淆并不是必须使用的,不使用混淆其实都能正常使用,而且在这当中有近一半人所在的地区的网络,直接使用原版的SS能获得更好的速度。那么什么时候你应该使用混淆呢?第一类是遇到QoS情况的,使用混淆能提速的人,第二类是所在网络有严格限制,仅能使用80/443端口,不认识的协议根本不能用的(如学校、公司、政府办公网络),第三类是对自己的隐私有要求的,希望在运营商的连接记录里留下看起来正常的访问记录,第四类是试图绕过学校或运营商的计费系统的人,第五类其它黑科技用途保密。以上第四类并不在本文的讨论范围,这属于漏洞利用的非法用途。下文仅针对前三类进行展开。

Wednesday, September 21, 2016

Shadowsocks各分支的安全性

这里要说的安全性并不是指密码学上的那种,而是在防探测,防流量识别并阻断上的安全性(也许算隐匿性?),所以主要针对的就是服务端。现在服务端的版本主要有以下这几个分支:shadowsocks-libev,shadowsocksR-python,shadowsocks-python,shadowsocks-go,libQtShadowsocks。而其它的分支用的人太少,所以我也没有去研究代码。

在说这个问题之前,首先要提及一点:TCP是流协议,你需要假设它可能在任何地方被拆分开,后面内容过一会儿才收到。服务端在设计的时候应该遵守以上这点来设计协议或设计其行为。

目前主要在使用的协议,一个是原始协议,另一个是OTA协议,现在分别说说这两协议在各分支上的实现。以下内容为截止到20160921时的各分支的实现情况,若将来各分支修正了,那么以修正后的情况为准,下文仅以此作为示例说明。