TLS版本10协议检测

2018年夏天，版本协我帮一个客户排查支付接口的议检间歇性超时问题。抓包结果里有一行让我愣了几秒——ClientHello 里带的版本协版本号是 0x0301。TLS 1.0。议检2018 年了，版本协一个日交易额七位数的议检系统，还在用 1999 年定稿的版本协协议版本。

这事比想象中普遍。议检TLS 1.0 发布于 1999 年（RFC 2246），版本协本质上是议检 SSL 3.0 的改良版。它修了 SSL 3.0 的版本协一些明显漏洞，但留下了大量设计上的议检历史包袱。最典型的版本协就是 CBC 模式加密套件里的 IV 处理方式——TLS 1.0 沿用 SSL 3.0 的做法，让上一轮的议检密文块直接充当下一轮的初始化向量。这个设计后来被 BEAST 攻击（2011 年）打得千疮百孔。版本协浏览器厂商不得不搞出 1/n-1 record splitting 这种补丁来绕过。

另一个让人头疼的地方是 TLS 1.0 的 MAC-then-Encrypt 结构。先算消息认证码，再加密，看起来合理，实际上给了 POODLE、Lucky13 这类 padding oracle 攻击可乘之机。TLS 1.2 后来改成 AEAD 优先，才从架构上规避了这类问题。

那为什么还有系统在跑 TLS 1.0？我见过的原因无非几种。一是老旧的 Java 应用，JDK 6 或早期 JDK 7 默认只支持到 TLS 1.0，升级 JDK 意味着要动整个运行时环境，牵一发动全身。二是嵌入式设备或工控系统，固件写死就是 TLS 1.0，厂商早就不维护了。三是纯粹没人管——服务器配置是五年前某个人搭的，那人已经离职了。

检测 TLS 1.0 其实不复杂。用 openssl 一行命令就能确认：

openssl s_client -connect example.com:443 -tls1

如果握手成功，返回证书链和会话信息，说明服务端接受 TLS 1.0 连接。把 -tls1 换成 -tls1_1、-tls1_2 可以逐版本测试。更省事的办法是用 nmap 的 ssl-enum-ciphers 脚本，一次性列出所有支持的协议版本和加密套件：

nmap --script ssl-enum-ciphers -p 443 example.com

输出里会明确标注 TLSv1.0 是否启用，以及每个版本下支持的 cipher suite 列表。我习惯重点关注 CBC 套件和 RC4——如果 TLS 1.0 开着，同时还支持 RC4，那基本等于裸奔。

2020 年之后，主流浏览器和支付卡行业（PCI DSS）都明确要求停用 TLS 1.0。Chrome 从 84 版本开始直接拒绝 TLS 1.0/1.1 连接，Firefox 紧随其后。PCI DSS 3.2.1 规定 2018 年 6 月 30 日之后必须禁用 TLS 1.0。但规定是规定，实际执行中大量内网系统、API 网关的后端连接仍然在用。

我自己的判断标准很简单：任何面向公网的 HTTPS 服务，如果还接受 TLS 1.0 握手，就是一个需要立刻修的问题。不是因为它一定会被攻破——BEAST 在实际攻击中利用条件苛刻——而是因为它暴露了一种维护态度。一个连协议版本都不愿意升的团队，很难让人相信他们会及时打其他安全补丁。

修复方式取决于你的技术栈。Nginx 在 ssl_protocols 指令里去掉 TLSv1 即可。Apache 调整 SSLProtocol。Java 应用需要同时确认 JDK 版本和 jdk.tls.disabledAlgorithms 配置。负载均衡器、CDN 回源配置、数据库连接加密——这些容易被忽略的链路都得查一遍。

那个 2018 年的客户后来怎么解决的？他们把 JDK 从 6 升到了 8，改了一行连接池配置，前后花了不到两天。真正耗时间的是找到问题根源——他们的监控只报了超时，没有任何地方提示协议版本。所以检测这件事，主动做比被动等故障强。