SSL 2.0 和 SSL 3.0 这两个协议版本，版本和现在拿出来单独讲，协议不是检测因为它们还能用，而是漏洞因为它们太容易被打穿。去年帮一个客户做内网资产梳理，版本和扫描器报出某台老旧的协议打印服务器还在跑 SSL 3.0，我当时就顺手用 PoC 验证了一下——从发送 ClientHello 到拿到明文数据，检测前后不到三秒。漏洞那台机器上跑的版本和还是内部工资单打印队列。

问题出在哪？协议SSL 2.0 的设计几乎没考虑过对手能主动篡改握手过程。它允许匿名 Diffie-Hellman 交换，检测中间人可以悄悄把加密套件降级成出口级弱加密，漏洞甚至直接替换成空加密。版本和更离谱的协议是，SSL 2.0 的检测 MAC 计算把序列号排除在外，这意味着攻击者可以截获密文后重新排序、重放，接收端根本察觉不到。1995 年 Wagner 和 Schneier 那篇论文已经把这些问题扒得差不多了，但真正让运维头疼的是：很多嵌入式设备、老版本 Java 应用、甚至某些 VPN 网关的固件里，SSL 2.0 是默认开启的，而且没有图形界面让你关掉。

SSL 3.0 看起来修补了不少，但它引入了新的坑。2014 年 POODLE 攻击公布时，我正好在做一个金融客户的渗透测试。他们的负载均衡器配置了 SSL 3.0 作为回退选项，理由是“兼容旧版 IE 浏览器”。我用 Python 写了个简单的脚本，在 CBC 模式下利用填充 oracle 逐字节解密 Cookie，平均每个字节 256 次请求，整个会话令牌不到两分钟就出来了。POODLE 的根因是 SSL 3.0 对 CBC 填充的校验不够严格——只检查最后一个填充字节，其余填充内容可以任意篡改。TLS 1.0 之后改成了全填充校验，但 SSL 3.0 永远停在了那个有缺陷的版本上。

检测这两个协议其实不复杂。命令行里 openssl s_client -connect host:443 -ssl2 和 -ssl3 就能直接看握手结果。如果返回 “unknown protocol” 说明服务端已经禁用了；如果返回证书链和会话参数，那就得处理了。Nmap 的 ssl-enum-ciphers 脚本也能列出支持的协议版本，但要注意有些服务端会故意对 SSL 2.0 的 ClientHello 返回 TLS 握手失败，这时候得用 --script ssl-heartbleed 之类的组合去交叉验证。我个人的习惯是先用 testssl.sh 跑一遍全量扫描，它会把 SSL 2.0/3.0 单独标红，比手工敲命令省事。

修复方案没什么好犹豫的——直接禁用。Nginx 里写 ssl_protocols TLSv1.2 TLSv1.3;，Apache 里用 SSLProtocol all -SSLv2 -SSLv3，Tomcat 改 server.xml 的 sslEnabledProtocols 属性。麻烦的是那些关不掉的老设备：一台 2008 年的 Cisco 路由器，固件里 SSL 2.0 是硬编码的，最后只能加个前置代理做协议剥离。还有一次遇到某医院的影像归档系统，厂商说升级固件要停机两天，院方不肯，最后在防火墙层面做了 SSL 拦截和重写，算是临时方案。

有个细节值得单独说：很多扫描器把 SSL 2.0 和 SSL 3.0 混在一起报，但两者的利用难度差很多。SSL 2.0 基本是明文级别的风险，SSL 3.0 需要特定条件（CBC 模式、攻击者能注入恶意 JS 或控制网络路径）。所以修复优先级上，SSL 2.0 应该是 P0，SSL 3.0 可以稍缓，但别拖过下一个维护窗口。我见过太多团队把这两个一起扔进“低危”列表，结果半年后被人用 POODLE 变种打穿了内网。

最后提一句：有些合规扫描器只检查 TLS 版本，对 SSL 2.0/3.0 的检测逻辑写得很粗糙——发个 ClientHello 看有没有 ServerHello 就完事。实际上服务端可能只在特定 SNI 或特定密码套件下才启用 SSL 3.0。要准确判断，得用多个 ClientHello 变体去探测，比如带不同 SNI、不同扩展字段的组合。这事儿没捷径，只能多跑几轮。

(责任编辑：百科)