前一段时间关于Shadowsocks的事情闹得沸沸扬扬的，最近显然大批小白已经被吸引到所谓的「Shadowsocks增强版」（ShadowsocksR）那边去了。作为用C++/Qt实现Shadowsocks业余开发者，打算对这两个炸子鸡简单地发表一下自己的看法。
ShadowsocksR
我不知道背后的开发者是不是有后台、有团队的，但是我知道的是其作者确实曾经违反GPL协议对其二次开发的Shadowsocks C#客户端闭源。这里我们不谈什么别的因素，事实就是如此，GPL白纸黑字很清楚的，违反了就是违反了。但是作者随后开源了代码库，也算是一桩事件的尾声，也就没有必要再追究。
事情在clowwindy清空其shadowsocks的代码仓库之后有了些新的变化。以下仅罗列事实：
- ShadowsocksR作者曾表示要start from scratch写一个新的与shadowsocks无关的代理工具，并且不再更新ShadowsocksR
- 两三天后shadowsocks被勒令删除，
原shadowsocks项目基本消失 - ShadowsocksR作者表示原shadowsocks协议有缺陷（在下一节会进行讨论），重回焦点
- ShadowsocksR作者建立了Google+ Group，更新了ShadowsocksR相关代码
Shadowsocks的安全性
好了，下面开始描述一下ShadowsocksR作者声称的Shadowsocks的协议缺陷在于IV的长度大部分情况下为16字节。后面这一半是正确的，不少加密算法使用的IV都是16字节长（特别是流行的AES和RC4-MD5），so what? 这并不会引入所谓的「缺陷」，理由如下：
- 每个TCP连接在握手阶段的IV是随机生成的，而不是根据密码计算得出，所以IV是无法预测的。
- 在没有密钥的情况下，即便截取到了这部分IV，也是无法解密密文的。而且每个新的TCP连接都会使用随机生成的IV，也就是截取到的不同TCP连接的数据之间基本没有什么共同点。而解密密文需要同时正确的IV和密码，而任何连接都没有关于密码的任何特征。
- 大部分IV长度为16字节，也就是256的16次方种可能的组合，在IV都一样的情况下暴力破解都已经不可能，更别说再加上第二点。
按照ShadowsocksR的做法，在首连接前加入所谓的混淆头也是没用的，自身的特征就明显，而且根本没有改变后来的IV还是固定长度的本质。因为第四个字节就告诉大家随机填充数据的长度了，进行所谓「探测」的时候只要跳过前面这一堆，一样能够去截取IV。而前几点已经说过了，你得到了这个随机IV也没用。而如果是用来探测的话，固定的第一位版本标识就是赤裸裸的特征送过去识别的。- ShadowsocksR作者目前给出了一个主动探测的脚本，可以用来检测服务器是否在运行shadowsocks，根据目前网上的测试报告来看，成功率不算低（但也非100%）。而关于这一点，clowwindy已经在原版给出了auto ban的解决办法，自动把这些恶意IP屏蔽掉。
刚刚我在libQtShadowsocks里加了个补丁还有这个补丁屏蔽掉这种办法的探测，办法是按照随机概率返回随机长度的随机字串。
但是，这不代表shadowsocks的协议是完美无缺的，只是ShadowsocksR的「解决办法」是歪的，因为它的关注点本身就是歪的。我个人的想法是用公钥、私钥提高安全性，虽然对小白是不太友好了，但是安全性会得到提升，同时特征会减少（不用在握手阶段发送IV），shadowsocks协议需要向CCA安全方向发展。
05-Sep-2015 更新
给libQtShadowsocks服务端打上了autoban补丁，一旦发现header错误（无法解析）便将产生错误的IV和IP加入失败的IV和IP列表，如果失败的IV列表中已经存在该IV，或失败的IP列表中已经存在该IP，则将发送连接请求的IP加入黑名单，黑名单中的IP均直接拒绝连接。关于反侦测的最新详情请查看该issue，本文不再针对反侦测的应对办法进行更新。
06-Sep-2015 更新
本文只是想告诉大家不用过分担心Shadowsocks的安全性，现在的协议还没有出现重大漏洞，主要port的服务端也在更新来修复潜在威胁。和ShadowsocksR的作者也有在良好地沟通了，在白名单到来之前能撑一会儿是一会儿吧。
24-Sep-2015 更新
本文一直提的Shadowsocks安全性更多是指服务器的安全，目前的协议存在让服务器被暴力侦测而暴露进而被防火墙屏蔽（虽然探测的成本很高）的风险。传输内容的安全性是不用担心的，全都是工业级高强度加密算法（除了RC4和TABLE），破解传输的内容是几乎不可能的。
18-Nov-2015 更新
Shadowsocks通过加入一次验证提高了对抗CCA的安全性，各大ports已经陆续完成了支持。这里需要重申的是Shadowsocks的目标不是100% bug-free或100% bullet-proof，而是保证连接轻量快速的同时让主流攻击手段的成本高到一般无法实施。
There’s no such thing as security. 没有一个叫安全的东西。 （安全是相对的，如要100%安全，请断开电源）
55 responses to “关于ShadowsocksR和Shadowsocks的安全性”
请问做为服务器端，能不能通过探测手段，把大墙的IP都屏蔽掉，以避免大墙主动探测？
牆的IP據說是隨機的非真實地址
[…] https://www.librehat.com/about-shadowsocks-r-and-the-security-of-shadowsocks/ […]
[…] https://www.librehat.com/about-shadowsocks-r-and-the-security-of-shadowsocks/ […]
我支持SSR！确实好用！就像电灯做的不好还不准有LED了？太偏激！技术总有更新！你做不到的别人做到了！！！
问题在于，点灯并没有做的不好，反而做LED的，一边在喷电灯，一边又拿了电灯的源码开发而不开源（违反协议，虽然后面迫于压力低头了），这就不厚道了。目前来看，点灯和LED灯拥有同等安全性，稳定性点灯还更高一点（毕竟原版作者行事风格不会太情绪化，反观SSR作者虽知道接下来会不会心情不好突然停更或者又开始骂街搞些有的没的，这也无可厚非，她有这个权利），总之我还是推荐用原版SS。
[…] https://www.librehat.com/about-shadowsocks-r-and-the-security-of-shadowsocks/ […]
Good Article，点个赞
大大我想问一下shadowsocks qt5 go libev python等等这些版本的区别？
仅仅是写的语言不同吗？小白很是困扰…
都说libev省资源 py多端口…
这是服务端上的区别 客户端呢？ 是不是都有客户端…
SS和ssr都在更新,形式大好,ss的目录分为了两个
rm和master
rm里面是经审查过的readme.txt
master才是正文
只是默认调转到rm分支罢了
(P.S.求clow当年在喝茶前一天写的抨击break的文章链接)
已经找到了
https://github.com/shadowsocks/shadowsocks-windows/issues/293#issuecomment-132253168
哈哈 文章当年写得略偏激
[…] 網絡事件和安裝腳本 关于ShadowsocksR和Shadowsocks的安全性 ShadowSocks协议的弱点分析和改进 #38 […]
钓鱼
这个问题其实已经讨论的很清楚了，原版SS就是有协议缺陷会被侦测到，不知为何博主还不更正这个事实
ss说到底还是混淆啊，为什么没有考虑在ss client和ss server连接使用ssl双向认证呢，这样就能杜绝GFW抓特征了吧？
虽然我不是学计算机和密码学的，但是我是支持shadowsocksR的，因为切身体会，我们公司了，原版的shadowsocks已经连不上了，不管是买的公共服务器还是vps自己搭服务器，原版ss只能返回空白网页。而使用了shadowsocksR就能返回完整的页面。
这个事实证明了，原版SS协议是有特征的，能被特定的程序探测到并阻断链接，而shadowsocksR才能救我于水火啊！
我比较在意的是我和我身边的人、我在网上认识的人，使用原版SS完全没问题是怎么一回事。
其实事情发展到现在已经没人说 SSR 有安全问题了，该开源的都开源了，而且妹纸确实很热心，包括路由器这一块的集成给其他开发者提供了相当大的支持。后期的更新、维护和增强也一直在做，违背开源协议这事情虽然污点不可能洗掉，但能坚持下来并持续开发的作者始终值得钦佩的。技术上很多问题都是实现的方法不同而已。非要在这个问题上找对错本身就不对，但感谢博主的分析探讨。
开啥源了，啥也没开源
这么说SSR还一直在更新？ SS应该没更新了吧
ss一直在更新啊，你可以看Github上的仓库
你能连上不代表别人能连上。我都说明了是在我们公司里，原版ss不可用。我自己在家里，在路上用4G，原版协议也是能用的，唯独在公司里不可用。至于是什么原因不可用，我无能为力去追究，但是ssr确实能正常使用。
估计是被公司的网关拦截了
我的ss完全没问题
那个不是特征被抓取了，而是公司网络往往有L7的防火墙过滤，HTTP/TLS之类的会被放行，识别不出的会被屏蔽，这手段可以很的封杀P2P，在线游戏之类，ssr能用在于混淆，让他看起来像是个HTTP。目前ss也有混淆插件了。
正视现实吧，原版SS早就可以被检测了。
小白来膜拜大神来了 嘿嘿~
学习一个
公钥、私钥加密方式，明文部分相同的话密文部分也相同， 这样做和约定一个固定的IV又区别吗？
之前对这块没研究，纯粹乱讲的。
有一点说错了，IV是随机化的，每次连接时都不同，而且要求强随机，用库函数的rand()不可靠，系统熵太低就不可靠
正确实现的系统IV每次肯定是不一样的，绝对不会固定IV，正是因为IV是随机的所以明文相同密文也不会相同
额，那份公开协议文档是博主维护的吗？那份文档有点误导性的样子。我一开始理解成了服务器会使用和客户端相同的IV并且不再向客户端发送IV，后来发觉不是的，服务器连接会使用另外一个随机IV。。。
嗯，之前文档没有说清楚，现在把语句调整了一下。每个TCP连接的IV都是随机生成的。
不懂，纯学习下
看commit记录好像只有你的shadowsocks-qt5加入one-time auth了……linux上的其它版本有加吗？
libev有
文章里有typo，某处“16位”应该为“16字节”
另外请教个问题，如果基于websocket协议之上写一个简易代理，因为ws握手会不可避免增加地延迟，是不是可以利用这次ws握手加一个认证以抵抗主动探测呢，好像shadowsocks就是因为延迟的原因不愿意加入认证机制？
说到认证，我有一个疑问。
我有一个8位的账号和16位的密码，和我有24位密码无账号，对于“加密”有什么区别？
ss是一个加密传输方式，我觉得根本没必要做“认证”这种事。
就好像汽车发动机，并没有“钥匙孔”
可能是我的用词不对，这样想能抵抗重放攻击（https://github.com/shadowsocks/shadowsocks/issues/69）吗：ws握手的时候客户端和服务器都生成随机数，然后发真正要代理的数据时客户端对两个随机数做加法并附上，服务器拿到之后检查等式是否正确，如果不正确就可能是GFW在做重放攻击来主动探测，于是随机返回一些垃圾数据后关掉连接
上面的是我想多了，我再回去补补密码学基础……然后ws握手虽然不可避免但其实也能做到和ss一样的低延迟
一年之后在审视我造的小轮子的存在意义，于是又看到了这篇博文
回答一下你的问题，当时我密码学没入门大脑混乱，以为要做到免疫CCA需要像SSL那样有繁琐的握手步骤。事实上不用，正确的解决方法是加上MAC。
但说实话你的举例我真看不懂，加密后只有持有正确密钥的人才能解密不就是一种“认证”吗？我没说要加入用户名之类的东西……
欢迎参观我造的小轮子：https://github.com/krrr/wstan
谢谢，已改正。
消息验证和头验证均包含在最新的一次验证中，请查阅官网相关文档。
原来已经有了……文档里说的CCA是指翻转密文对应比特则解密后的明文的对应也会翻转吗？ （默认的CFB模式如果只考虑第一个分组的话可以这样做，CTR就更是如此）
文档是最近才加上的，可以看看英文Wikipedia的解释。细节方面我也不太懂。
ubuntu通过PPA装了你的QT5(看说明好像是包含了客户端和服务端),但是应该怎么输入命令来启动软件呢?
和你一样已经安装成功了，就是服务端软件不能自动启动啊
看了几个小时,小白我还是没弄明白服务端应该怎么装你的ss-qt5(或者说是libQtShadowsocks ?)啊,大侠能简单说一下吗.debian/ubuntu系统
我见有人用Tor加上ss的，我不是很理解，那样设置，还是用ss server去连Tor节点吧？那么SS client到SS server端的连接还是没变化啊，GFW不是判断网内客户端连接的特征来ban ss server的吗？那加个Tor没起作用啊
確實如此，不過要考慮到tor網絡在牆內也不容易連接，至少如果不用ss，在下也無法連入tor
洋葱主要意义在于其匿名性
自從 C# 閉源事件之後就沒再信任過這貨
ssr的作者有点深不可测：
“声称的Shadowsocks的协议缺陷在于IV的长度大部分情况下为16字节”
这种只有一半正确另一半的不正确的说法方法，很像是舆论导向员的言行举止。
感觉如果胡思乱想的话，有点恐怖。如果这是个专用的钓鱼工具……
她的意思可能是IV长度是固定的，然后可以对后面地址的那一位进行暴力攻击，然后探测出服务器是在运行shadowsocks，但是这并没有很大的问题，改进服务端程序ban掉错误头的请求来源即可。完全不用搞个什么新协议。
还是不要对别人妄加揣测吧。
世界真是小，竟然在这里看到你……