近日，VLESS协议和Xray的作者rprx发现Shadowsocks AEAD 加密方式设计存在严重漏洞，无法保证通信内容的可靠性。具体来说，便是Shadowsocks AEAD防重放设计有缺陷，中间人可以随意对客户端接收的数据进行移花接木或重放，比如对调两条 TCP 连接所返回的数据，达到隐蔽式拒绝服务攻击的目的。
更多详情请参考：
1. 利用防重放机制自动对 Shadowsocks、VMess 等未知流量代理进行“隐蔽式拒绝服务攻击”
2. Shadowsocks AEAD 加密方式设计存在严重漏洞，无法保证通信内容的可靠性
一下是相关issue的转载：
这个问题是昨天发现的，本来我只是想先给 Xray-core 的 Shadowsocks 明文结构加个时间戳以彻底解决对服务端的重放问题。
顺便研究了一下 SS AEAD 的安全性，我脑洞比较大，考虑得比较多，比如是否可以造成 对客户端的攻击，简述如下：
- 对于 TCP，Shadowsocks AEAD 往返是完全一样的加密结构，HKDF 的
info也相同，且响应的加密完全独立于请求 - 对于 UDP，同样存在上面的问题（甚至可以与 TCP 杂交），更糟糕的是，UDP 往返连明文结构都是完全一样的
以上“特性”的利用方式太多了，真的很难排列组合完，还是主要说对客户端的攻击：
在不需要密码的情况下，可以随意对客户端接收的数据进行移花接木或重放等操作，使得被代理程序收到的数据没有任何可靠性。
比如将 A、B 两条 TCP 连接返回的数据对调，Shadowsocks AEAD 客户端是无法发现异常的，只会成功解密并传给被代理程序。
一些 SS 实现是全局共用 IV 过滤器，只能在单一客户端且不重启（which is impossible）的前提下防御重放，防不了移花接木。
Shadowsocks 流加密也存在此问题，有兴趣的可以研究一下 SSR 的 auth_chain_* 系列是否也存在此问题。
建议先用 VMess AEAD（实际上它有其它问题，但不是这种严重漏洞），最后感谢某个开发者群成员参与讨论与验证。
需要说明，这里主要是描述存在的漏洞，而对漏洞的利用有很多方式，比如 移花接木、重放、自交、杂交 等，欢迎补充测试结果。
由于 #183 ，我在研究“对服务端与客户端的逐字节重放”，并且取得了一些成果，此时又开了一下脑洞：
如果布隆过滤器被人恶意打满呢？不过可操作性不强，还有太多未知变量。
接着就想到了如题：众所周知，某中间人一直在对未知流量进行重放，导致现在大多数实现都有防重放机制。
而利用服务端的防重放，中间人不需要破坏连接，只需提前发送未知流量的前 32 个字节（或更多），即可使这些代理实质性失效。
不需要封锁任何 IP 或端口，精准阻断未知流量类代理。 某种程度上还是无解的，允许重放又会存在问题。
这个机制简单可行，好消息是，它尚未被部署，坏消息是，一旦部署会很棘手。
其实只会阻断这类协议：未知流量、0-RTT、有重放过滤器，听起来是不是很熟悉？而且并没有封你，是你自己封了自己。