Shadowsocks AEAD加密方式设计存在严重漏洞，无法保证通信内容的可靠性

近日，VLESS协议和Xray的作者rprx发现Shadowsocks AEAD 加密方式设计存在严重漏洞，无法保证通信内容的可靠性。具体来说，便是Shadowsocks AEAD防重放设计有缺陷，中间人可以随意对客户端接收的数据进行移花接木或重放，比如对调两条 TCP 连接所返回的数据，达到隐蔽式拒绝服务攻击的目的。

更多详情请参考：

1. 利用防重放机制自动对 Shadowsocks、VMess 等未知流量代理进行“隐蔽式拒绝服务攻击”

2. Shadowsocks AEAD 加密方式设计存在严重漏洞，无法保证通信内容的可靠性

一下是相关issue的转载：

这个问题是昨天发现的，本来我只是想先给 Xray-core 的 Shadowsocks 明文结构加个时间戳以彻底解决对服务端的重放问题。

顺便研究了一下 SS AEAD 的安全性，我脑洞比较大，考虑得比较多，比如是否可以造成 对客户端的攻击，简述如下：

1. 对于 TCP，Shadowsocks AEAD 往返是完全一样的加密结构，HKDF 的 info 也相同，且响应的加密完全独立于请求
2. 对于 UDP，同样存在上面的问题（甚至可以与 TCP 杂交），更糟糕的是，UDP 往返连明文结构都是完全一样的

以上“特性”的利用方式太多了，真的很难排列组合完，还是主要说对客户端的攻击：

在不需要密码的情况下，可以随意对客户端接收的数据进行移花接木或重放等操作，使得被代理程序收到的数据没有任何可靠性。

比如将 A、B 两条 TCP 连接返回的数据对调，Shadowsocks AEAD 客户端是无法发现异常的，只会成功解密并传给被代理程序。

一些 SS 实现是全局共用 IV 过滤器，只能在单一客户端且不重启（which is impossible）的前提下防御重放，防不了移花接木。
Shadowsocks 流加密也存在此问题，有兴趣的可以研究一下 SSR 的 auth_chain_* 系列是否也存在此问题。

建议先用 VMess AEAD（实际上它有其它问题，但不是这种严重漏洞），最后感谢某个开发者群成员参与讨论与验证。

需要说明，这里主要是描述存在的漏洞，而对漏洞的利用有很多方式，比如 移花接木、重放、自交、杂交 等，欢迎补充测试结果。

由于 #183 ，我在研究“对服务端与客户端的逐字节重放”，并且取得了一些成果，此时又开了一下脑洞：

如果布隆过滤器被人恶意打满呢？不过可操作性不强，还有太多未知变量。

接着就想到了如题：众所周知，某中间人一直在对未知流量进行重放，导致现在大多数实现都有防重放机制。

而利用服务端的防重放，中间人不需要破坏连接，只需提前发送未知流量的前 32 个字节（或更多），即可使这些代理实质性失效。

不需要封锁任何 IP 或端口，精准阻断未知流量类代理。 某种程度上还是无解的，允许重放又会存在问题。

这个机制简单可行，好消息是，它尚未被部署，坏消息是，一旦部署会很棘手。

其实只会阻断这类协议：未知流量、0-RTT、有重放过滤器。听起来是不是很熟悉？而且并没有封你，是你自己封了自己。 

from https://v2xtls.org/%e9%a2%84%e8%ad%a6shadowsocks-aead-%e5%8a%a0%e5%af%86%e6%96%b9%e5%bc%8f%e8%ae%be%e8%ae%a1%e5%ad%98%e5%9c%a8%e4%b8%a5%e9%87%8d%e6%bc%8f%e6%b4%9e%ef%bc%8c%e6%97%a0%e6%b3%95%e4%bf%9d%e8%af%81%e9%80%9a/