SSR 还能用，为什么仍然不安全？

偶尔还能遇到这样的旧节点：地址没变，密码没变，客户端里选着 aes-256-cfb、auth_chain_a 和 tls1.2_ticket_auth，点一下，居然还能连上。

于是问题来了：

既然能用，为什么总有人说 SSR 已经不安全？

这里的“不安全”并不是说每一条 SSR 连接都会立刻变成明文，也不是说 AES 这个算法突然被破解了。更准确的意思是：面对今天的攻击者、流量分析能力和软件供应链，SSR 很难稳定提供现代传输协议应当具备的那组保证。

这些保证至少包括：

• 加密内容不能被读取；
• 数据被改动时能够被发现；
• 旧数据不能被重复利用；
• 长期密码以后泄露时，过去的会话仍尽量安全；
• 未授权探测不会轻易暴露服务；
• 实现持续维护，有统一规范和可追踪的安全修复。

SSR 在其中一些方面做过补救，但它们散落在不同的 method、protocol、obfs 和客户端实现里。一个叫“SSR”的节点，究竟提供了哪些保证，仅看这三个字母根本答不出来。

先说清楚：SSR 不是今天的 Shadowsocks

ShadowsocksR，也就是 SSR，是早期 Shadowsocks 的一个分支。它在原有加密代理外面增加了两类可选模块：

• protocol：尝试增加认证、抗重放或用户区分；
• obfs：尝试把流量伪装成 HTTP、TLS 等常见协议。

这不代表 SSR 是 Shadowsocks 的“官方高级版”。两者后来走上了不同路线。

今天的 Shadowsocks 有公开的 SIP 规范、AEAD 构造以及 AEAD-2022 版本。AEAD-2022 明确要求固定长度的高熵预共享密钥、消息类型、时间戳和完整重放保护，也明确写出它仍然不提供前向保密。

SSR 则延续成了多个社区仓库和客户端分支。不能说它们全部停止更新：例如 ShadowsocksR-Native 仍有社区维护，并加入了 GCM、Poly1305 等 AEAD 算法。问题在于，常见 SSR 客户端、服务端和订阅节点可能分别来自不同年代，支持矩阵也不一致；有的仍以 CFB、CTR、RC4 和旧认证插件为主，有的加入了新算法，却没有形成一个所有实现共同遵守的现代协议版本。

所以本文批评的不是某一位社区维护者，也不是声称“所有 SSR 分支都同样脆弱”。我们讨论的是 SSR 作为一个碎片化协议生态，已经难以给普通用户提供清楚、可验证的安全承诺。

问题一：明明写着 AES-256，为什么还不够？

因为安全从来不只取决于算法名字。

AES-256-CFB 里的 AES-256 是强大的分组密码，但 CFB 是一种只提供机密性的工作模式。它可以让内容不可读，却不会自动证明密文没有被修改。

NIST 对 CFB、CTR、CBC、OFB 的说明很直接：这些模式具有可篡改性，攻击者可以改变密文，并让解密后的明文发生可预测变化。解决这类问题通常需要额外的消息认证码，或者直接采用 AEAD。

Shadowsocks 当前文档也已经把旧式流密码标记为弃用，理由是它们不提供完整性或真实性。

概念图：攻击者不必先读懂明文，也可能修改密文并影响解密结果。具体能否形成可利用攻击，还取决于上层数据结构和 SSR 插件的额外校验。

那么 auth_chain_*、auth_aes128_* 不是会认证吗？

它们确实是 SSR 为旧协议增加认证、时间信息、随机填充或抗重放能力的尝试。不能因为名字里出现 auth，就说它完全没有校验。

但这里有三个问题：

1. 它们不是“给任意旧流密码一键升级成标准 AEAD”的通用开关；
2. 安全性依赖具体插件版本、客户端与服务端是否完全兼容，以及错误处理方式；
3. 多套插件与多套加密方法自由组合，扩大了审计和测试空间，也容易产生“配置能连上，但安全语义并不清楚”的情况。

现代 AEAD 的思路更简单：加密与认证属于同一个经过明确定义的构造。任何密文、标签或关联数据被改动，解密都应失败。

这也是为什么“算法名称看起来很长”不是安全证明。

问题二：tls1.2_ticket_auth 是不是等于 TLS 1.2？

不是。

这是 SSR 里最容易误导人的名字之一。它属于混淆器，目标是让若干字节和交互形状看起来像某类 TLS 流量。它并不自动等于一个完整的 TLS 1.2 实现，也不因此获得：

• 公开 CA 证书链校验；
• 标准 TLS 密钥协商；
• 浏览器级服务端身份验证；
• TLS 协议的全部状态机与错误行为；
• 经标准化分析的密码套件协商。

说得直白一点，穿上白大褂不等于拥有行医资质。

SSR 的 obfs 解决的是“外观看起来像什么”，不是“密文是否不可篡改”，也不是“客户端是否可靠确认了服务器身份”。

模仿协议还有一个天然困难：外观不只是开头几个固定字节。真实 TLS 有 ClientHello 指纹、扩展顺序、ALPN、证书、会话恢复、记录长度、错误码和时序行为。只模仿其中一部分，反而可能形成一种稳定的“假 TLS 指纹”。

问题三：只要密码足够长，就万事大吉了吗？

长随机密码当然比 123456 好得多，但它仍解决不了前向保密。

经典 SSR 与 Shadowsocks 一样，主要建立在预共享秘密上，并没有像 TLS 1.3 的临时 Diffie–Hellman 那样，为每次连接协商一个即使长期密码以后泄露也难以恢复的会话秘密。

这意味着：

• 如果使用的是人类可记忆的弱密码，攻击者可能尝试字典猜测；
• 如果长期密码、订阅链接或服务端配置以后泄露，事先保存的旧流量也可能面临解密风险；
• 同一秘密使用时间越长、用户越多，泄露后的影响面越大。

具体能恢复多少历史内容，取决于加密方法、密钥派生、插件和是否还有内层 HTTPS。比如用户访问的是 HTTPS 网站，浏览器到网站的 TLS 仍是另一层保护；泄露 SSR 密码不等于自动破解网站的 TLS 1.3。

但从隧道本身看，SSR 没有给你“长期密钥泄露后仍保护旧会话”的承诺。

值得注意的是，连较新的 Shadowsocks 2022 规范也明确承认没有前向保密。区别在于，它至少把这个边界写进了规范，并对密钥格式、认证加密和重放保护做了更严格的定义。

问题四：重放攻击和主动探测为什么麻烦？

攻击者不一定要解密数据。他可以把捕获的数据原样或稍作修改后重新发送，再观察服务器如何反应。

如果合法数据、随机垃圾、截断数据和重复数据触发了不同的响应、连接时长或资源消耗，探测者就能逐步判断端口后面运行的是什么。

SSR 的若干 auth_* 协议尝试通过时间戳、连接标识、HMAC 和缓存抵抗重放，这比完全没有防护好。但不同实现如何保存状态、如何处理错误、是否覆盖 TCP 与 UDP、缓存重启后会发生什么，并没有一个像 Shadowsocks 2022 那样统一、强制的规范保证。

这会出现一个现实问题：

客户端界面里的配置项相同，不代表不同内核在边界输入下会做出完全相同的安全响应。

对于主动探测来说，这些边界行为恰恰很重要。

问题五：随机密文不是看起来什么都不像吗？

“看起来像随机数”曾经是一种优势。今天，它也可能成为分类条件。

2020 年的 IMC 论文《How China Detects and Blocks Shadowsocks》通过测量展示了两阶段流程：先根据首包长度、熵和连接行为筛选疑似流量，再向疑似服务器发送多种主动探测。

2023 年 USENIX Security 的研究进一步说明，完全加密、缺少常见协议特征的流量也可以被被动启发式规则筛选。研究涉及 Shadowsocks、VMess、Obfs4 等多种“从第一个字节就像随机数”的协议。

这些研究并不能证明“任何 SSR 配置都会被百分之百识别”，也不能拿 Shadowsocks 的某个实验结果直接替代所有 SSR 插件的测试。它们证明的是另一件事：

加密内容不可读，与流量不可分类，是两个不同问题。

http_simple 或 tls1.2_ticket_auth 之类混淆可能改变某些特征，但固定模板、响应差异和不完整的协议模仿也可能产生新特征。抗识别不是加一个看起来像 TLS 的插件名称就结束了，它是一场不断变化的实现对实现问题。

问题六：社区还有分支更新，为什么仍说维护有风险？

因为“GitHub 上还有提交”和“我手里的整套 SSR 链路处于可审计、可升级状态”不是一回事。

截至本文核对资料时，可以同时看到这些情况：

• 某些广泛流传的 Windows 客户端已经多年没有代码更新；
• 一些 libev 与 Python 服务端仓库保留着旧依赖、旧发行版说明和旧加密默认值；
• 另一些社区分支仍在更新，也加入了 AEAD 或 TLS 外层；
• 机场面板、客户端壳、路由器插件和服务端内核经常来自不同维护者；
• 用户拿到的常常是无法验证来源与构建过程的二进制文件。

这叫碎片化，不等于所有人都停止工作。

碎片化的安全代价是：

• 漏洞修复无法自动覆盖整个生态；
• 同名配置可能在不同实现里行为不同；
• 老教程继续传播旧默认值；
• 很难判断一个订阅节点到底使用了哪个内核和补丁；
• 客户端本身的更新、签名和供应链风险可能比协议更先出问题。

成熟协议并不只需要一份“还能编译”的源码，还需要规范、测试向量、版本策略、漏洞响应和可信发布链。

问题七：SSR 服务器本身能看到什么？

即便把加密方法换成可靠的 AEAD，SSR 也不是匿名网络。

服务器运营者通常能看到：

• 客户端来源 IP；
• 连接时间与持续时长；
• 访问的目标 IP、域名或端口；
• 上下行流量规模；
• 多个连接之间的行为关联。

如果目标网站使用 HTTPS，浏览器到网站之间还有端到端 TLS，SSR 服务器通常不能直接读取 HTTPS 正文。如果目标使用 HTTP，或者 DNS、应用本身发送明文，那么代理服务器以及服务器到目标之间的链路可能看到内容。

SSR 解决的是一段转发链路，不负责隐藏所有元数据，也不负责让不可信服务器变得可信。

把结论放进一张表

表里的“典型旧式 SSR”很重要。如果某个现代社区分支使用了正确的 AEAD，它可以改善机密性与完整性两项，但不会因此自动获得前向保密、匿名性、统一抗探测行为和整个生态的可维护性。

所以，SSR 是不是一点价值都没有？

也不必走到这个极端。

在一个你完全控制、风险很低、准备很快迁移的环境里，旧 SSR 可能仍然是一条能工作的临时通道。它轻量，老设备支持多，排障经验也多。“能工作”是真实优点。

但下面这些场景，不应继续把它当成首选：

• 需要长期保护敏感业务；
• 客户端或服务端来源无法确认；
• 多人长期共用一个密码；
• 依赖它隐藏身份，而不仅是转发流量；
• 网络中存在主动探测或强流量分析；
• 无法确认实际加密方法、插件版本和内核；
• 团队需要可审计的合规与漏洞响应流程。

如果暂时迁不走，至少做什么？

这些措施只能降低风险，不能把 SSR 变成现代协议：

1. 盘点真实的客户端、服务端内核、method、protocol 和 obfs，不要只看订阅名称；
2. 停止使用 RC4、CFB、CTR 等仅提供机密性的旧方法；
3. 如果双方实现确实兼容，优先使用经过定义的 AEAD，并验证失败数据会被直接拒绝；
4. 使用足够长的随机秘密，不要多人多年共享同一个人类密码；
5. 所有网站和管理面板继续使用 HTTPS，不把代理加密当成端到端加密；
6. 保护订阅分发、限制服务器访问、及时更新系统和依赖、减少不必要日志；
7. 制定迁移日期，而不是把“暂时能连”变成无限期维护策略。

迁移目标不应该只看哪个协议最流行，而要看用途：

• 普通加密代理可考虑有当前规范和维护实现的 Shadowsocks AEAD/AEAD-2022；
• 私有网络互联可选择有清晰现代安全模型的隧道协议；
• 需要抗审查外观时，应选择仍在针对当前探测能力维护的传输；
• 需要匿名性时，应使用为匿名威胁模型设计的系统，而不是普通单跳代理。

没有一个名字能同时解决所有问题。

最后，回答最开始的问题

SSR 还能连接，是因为服务器、客户端和旧协议依然能交换彼此理解的数据。

SSR 不再适合作为现代安全首选，是因为：

• 大量真实部署仍使用没有内建完整性保证的旧式加密；
• 认证与抗重放散落在多个插件和实现中；
• 混淆不等于标准 TLS，也不保证抗流量分类；
• 预共享秘密模型没有前向保密；
• 单跳代理无法提供匿名性；
• 生态分裂使升级、审计和漏洞响应变得困难。

“还能跑”描述的是兼容性，“是否安全”描述的是面对攻击时能承诺什么。两者从来不是同一个问题。

请仅在你有权管理的设备、服务器和网络中使用相关技术，并遵守所在地法律、网络服务条款与组织安全政策。

参考资料

• Shadowsocks：配置与加密方法说明
• Shadowsocks：AEAD 密码规范
• Shadowsocks SIP022：AEAD-2022
• Shadowsocks 协议规范仓库
• ShadowsocksR-Native：支持的加密、协议与混淆器
• shadowsocksrr/shadowsocksr-csharp
• shadowsocksrr/shadowsocksr-libev
• NIST：关于 CFB、CTR、CBC、OFB 可篡改性的说明
• IMC 2020：How China Detects and Blocks Shadowsocks
• USENIX Security 2023：How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic