shadowsocks-rust 服务端实现缺陷可能导致主动探测

[ghost]

shadowsocks-rust 服务端实现缺陷可能导致主动探测

注意：并非协议设计缺陷，仅影响 shadowsocks-rust，其他主要的 shadowsocks 实现都可以抵御此探测，此缺陷可以通过软件更新比较简单地修复，请勿恐慌

方法

在到 shadowsocks-rust 服务端的 TCP 连接上逐字节发送随机数。如服务端采用 AES-256-GCM 或 Chacha20-Poly1305，则连接会在服务端接收到第 50 字节时断开，对于其他 AEAD 加密，连接会在其他的固定位置断开。在使用此方法测试其他服务（HTTP，TLS，SOCKS 5，SSH，RDP，Minecraft，RTMP）时均未见在数十字节左右的固定值中断的现象。

分析

Shadowsocks AEAD 加密协议结构如下

[salt][chunk][chunk]...

其中 chunk 有以下结构

[encrypted_length][encrypted_length_tag][encrypted_data][encrypted_data_tag]

Shadowsocks （以及同类协议）对数据完整性的验证完全依靠 AEAD 解密过程保证——只有在第一次 AEAD 解密后，我们才能知道数据流是否伪造。如果一个服务端在发现解密失败后直接关闭连接，例如 shadowsocks-rust ，则可以使用 v2ray/v2ray-core#2523 中提到的逐字节发送数据包并观测连接何时关闭的手段测量验证过程至少需要多少字节。

对于 Shadowsocks AEAD，完成验证需要接收 salt ，第一个 chunk 的 encrypted_length 和 encrypted_length_tag 。其中 salt 和encrypted_length_tag 是与加密相关的常数， encrypted_length 长度为 2。则对现有 AEAD 加密，有下表，可见对于现有加密，有 34/42/50/82 这四种可能的验证所需长度，抛开不常用加密，实际上只有 50（和 34）。

加密	salt 长度	tag 长度	完成验证所需长度
XChacha20-Poly1305	32	16	32+16+2=50
Chacha20-Poly1305	32	16	32+16+2=50
AES-256-GCM	32	16	32+16+2=50
AES-192-GCM	24	16	24+16+2=42
AES-128-GCM	16	16	16+16+2=34
AES-256-PMAC-SIV	64	16	64+16+2=82
AES-128-PMAC-SIV	32	16	32+16+2=50

显然随机数不可能通过 AEAD 解密过程验证，服务端会在接收到完成验证所需长度的数据后关闭连接。因此若多次向某个开放的 TCP 端口逐字节输入随机数，连接始终在输入50字节后断开，则可怀疑此端口是 Shadowsocks 端口。

防御

按照 https://censorbib.nymity.ch/#Frolov2020a 的结论，最稳妥的防御是从不主动关闭异常的连接。我们不可能改变完成验证所需长度，但从不主动关闭连接应足以阻止此类依赖服务端响应的主动探测。

[Mygod]

Sounds fair. I think I proposed something similar for shadowsocks-libev or shadowsocks-org sometime back.

[zonyitoo]

按照 https://censorbib.nymity.ch/#Frolov2020a 的结论，最稳妥的防御是从不主动关闭异常的连接。我们不可能改变完成验证所需长度，但从不主动关闭连接应足以阻止此类依赖服务端响应的主动探测。

But if we don't close invalid connections actively, file descriptors will be exhaused.

[zonyitoo]

It seems that shadowsocks-libev closes socket only when recv() returns EOF:

https://github.com/shadowsocks/shadowsocks-libev/blob/a727596faaa91a4459daad4cc5a6618c20ce6475/src/server.c#L715-L749

It is quite tricky to avoid TcpStream to be closed by RAII...

[p4gefau1t]

@zonyitoo 也许可以 spawn 一个新的任务来接管这个 TcpStream

[zonyitoo]

@zonyitoo 也许可以 spawn 一个新的任务来接管这个 TcpStream

This is one of the ways I was thinking. But that will become very nasty: you have to "catch" this stream everywhere that would throwing Err.

[zonyitoo]

Made a simple solution for this issue, which will throw away data if server failed to decrypt the first handshake packet. Althrough it is not a perfect solution, but it should help.

I am going to make a release v1.8.17 for this.

[IceCodeNew]

throw away data if server failed to decrypt the first handshake packet.

Is this what you mean?
https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#4.2-http-request%20silent-drop

[zonyitoo]

throw away data if server failed to decrypt the first handshake packet.

Is this what you mean?
https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#4.2-http-request%20silent-drop

Sort of.