用链式代理织成的绞索--利用RC4-MD5等流加密以及链式代理可瘫痪ss/r服务端

2021 年 1 月 22 日

一些背景（可能包括作者的私货）

尽管开发者们一再告诫流加密，尤其是代理提供商（即机场）最喜欢使用的rc4-md5为代表的流加密存在的严重安全隐患，且并不如直觉“此类‘简单’的加密方法可以更节省资源提高速度“，在支持aes硬件加速的设备上，其表现并不如更安全更现代的aes-gcm系列加密方法，在不支持aes硬件加速的设备上也有chacha20-ietf-poly1305。敲响警钟也好，一遍一遍的耐心解释也好。计算机科学，数学，密码学的晓之以情动之以理也好，换来的似乎总是不理解，还有“自说自话自作主张”之类的评价。
去年重定向攻击解密shadowsocks流密码的大新闻历历在目，却似乎只能证明大多数工具的使用者“集体记忆”远不如防火长城和站在它背后的技术团队，审查者日新月异而这边似乎有点情怀过头甚至“抱残守缺”。
这次流加密的漏洞则起源于链式代理以及RC4加密本身的脆弱性。

在实现攻击的源代码公开后，我与这个项目的开发者之一（也是Qv2ray的开发者之一）对代码进行了测试。

流程也并不复杂。

我一开始打算拉取源代码进行编译。

git clone https://github.com/Qv2ray/rc4md5cry

然后就是本地构建
这里我发现很大一个坑，如果使用rustup提供的rust工具链，构建可以成功，但是构建出的二进制文件攻击并不能达到效果，我无论是在Debian9的vps上还是本地的macOS上都是如此。
而使用pacman包管理器安装的rust工具链却可以（不知道brew安装的怎么样），尽管两者的rustc和cargo版本明明一样，真是搞不懂rust。
cd 到文件 rc4md5cry 下运行 cargo build命令就会在target下生成可执行文件。
赋予执行权限，运行

./rc4md5cry --address shadowsocks服务端IP:服务端端口 
\ --password shadowsocks的密码 
\ --rounds 一个大于1024的整数值

总之最后因为我这里编译出的二进制文件出了状况，最后使用了GitHub actions编译的二进制文件，无论是mac端还是Linux端，攻击都能成功。
攻击成功的表现
服务端会输出 “ Too Many Open Files” ，然后是 “Connection timed out" 。此时不同于传统拒绝服务攻击，服务端cpu，内存，带宽等资源不一定被剧烈消耗，但ss/r服务会被瘫痪。
效果很是震撼，百试百灵
下面几张图是受到攻击的使用RC4-MD5加密方式的ss服务端日志

由于作者非专业人士，以下原理基于自己的理解，可能有不准确甚至错误，欢迎指出和改正，同时感谢开发者对原理的耐心讲解。

攻击的原理大概涉及：一个脆弱过时的流密码，一条代理链和代理链制造的一个回环。
一个脆弱的流密码
比如RC4-MD5，客户端和服务端会使用一个key进行通讯，而由于RC4的简单和脆弱，短时间内提前根据服务端客户端预先共享的shadowsocks的密码计算出未来通信使用的key会更加容易，这也是攻击的前提条件。
其实并非仅限于RC4-MD5，理论上任何非协商算法（即key完全由客户端产生，服务端不介入密码产生）由于其本身的特点都具备被攻击的条件，只是预先算出之后通信使用的key消耗的时间，资源的问题而已。
一条代理链，一个回环。
这个思路大概最先起源于对不加密的网页代理（ HTTP 代理）的研究正常的代理行为是客户端告知服务端（假设为 A ）查询目标网站的数据，则数据流向为

我（客户端）-> 服务端（A） ->目标网站

我（客户端）-> 服务端（A） -> 服务端（B） ->目标网站

我（客户端）-> 服务端（A） -> 服务端（A） -> 服务端端（A） -> 服务端（A） ->...—>服务端瘫痪

而A 向外的每一个连接对应一个 fd （即文件描述符），而这个fd是有限的，可以通过 ulimit -n 获得，只要rounds后整数超过该上限，代理服务就会瘫痪。而因为攻击的rounds可以无限提高，因此调高上限不能解决问题。
那如果禁止本地向本地回环发送数据呢？
实际上这个解决方式并不能解决实际问题，只需在代理链上增加另一个服务端

我（客户端）-> 服务端（A） -> 服务端（B） -> 服务端（A） -> 服务端端（B） ->...—>服务端双双瘫痪

对于个人用户而言，我想大多数人没有使用 RC4-MD5 裸奔的余裕吧。
然而机场不知道是不是因为“RC4-Md5 作为弱加密更节省资源”之类的非科学的错觉，尽管开发者一再澄清事实（如上文），普遍使用且坚持使用该类加密。
到了开发者们一致决定在软件包中移除流加密后，不理解更是上升到了攻击，尽管我真的不明白，为何要对付出时间精力智力劳动而不取分文的开发者这样高高在上。
就算机场有对防火长城视若等闲的余裕，友商的网络攻击大概不能不理会吧，而由于这个工具的出现，以极低的成本瘫痪服务端从未如此简单，且目前没有缓解方案，一定要说的话，那就是拥抱AEAD加密，拥抱SSL/TLS

尽量使用更加先进的以SSL/TLS来进行伪装和确保传输安全的代理协议，ss/r确实堪称很多翻墙爱好者的情怀所在，然而终归时代在变化，高墙在成长，终究只有日新月异才能把握自由的分量。

很多人钟情于 shadowsocks/R 也是因为其简单轻量化的部署，比起需要搭建伪装站点，申请证书和修改相对复杂的配置文件的v2ray，trojan等，确实简单易行的多。如此便不难理解了。
尽量使用自建代理，不过这就提出了更高的要求：“Linux、基础网络知识及 NGINX TLS 配置经验”等等。