2、常见漏洞概览：中间人攻击原理、证书伪造风险、证书吊销失效、弱加密算法
好，咱们直接进入正题。证书链配置如果出了问题，攻击者就有机可乘。我这些年排查过的生产事故，十有八九都跟这四大类漏洞有关。说白了，它们就是 PKI 世界里最经典的“四大天王”。
你想想看，一个 HTTPS 连接从建立到结束，要经过握手、证书验证、密钥协商、加密传输好几个阶段。每个阶段都可能被钻空子。下面这张图，就是这四类漏洞的攻击面全景。
2.1 中间人攻击原理
中间人攻击，简称 MITM。攻击者把自己插在客户端和服务器之间，两边都以为自己在跟对方说话。实际上，所有数据都经过攻击者中转。
我记得有一次帮一家电商平台做安全审计。他们的移动端 App 没有做证书固定（Certificate Pinning），结果在公共 Wi-Fi 环境下，攻击者用一个自签名证书就完成了 MITM。用户登录名、密码、支付信息全被截获。嗯，这其实是个老问题，但直到今天依然频繁出现。
典型的 MITM 攻击流程如下：
- 拦截：攻击者通过 ARP 欺骗、DNS 劫持或恶意代理，截获客户端到服务器的网络流量。
- 伪造证书：攻击者向客户端出示一个伪造的服务器证书。如果客户端没有严格验证证书链，就会信任这个假证书。
- 建立双通道：攻击者与客户端建立一个 TLS 连接（使用假证书），同时与真正的服务器建立另一个 TLS 连接（使用真证书）。
- 透明转发：攻击者在两个连接之间转发数据，同时可以解密、查看、修改明文内容。
核心防御点：客户端必须完整验证服务器证书链，包括根证书是否受信任、证书是否在有效期内、证书是否被吊销。任何一环缺失，MITM 都可能成功。
2.2 证书伪造风险
证书伪造，就是攻击者伪造一个看起来合法的证书，让客户端误以为它是真正的服务器。这里分两种情况：
- 自签名证书伪造：攻击者自己生成一个根 CA，然后签发服务器证书。如果客户端没有把攻击者的根证书加入信任库，这种攻击通常不会成功。但很多开发环境或老旧系统，会直接跳过证书验证，这就给了攻击者可乘之机。
- CA 私钥泄露导致的伪造：这才是真正可怕的情况。如果某个受信任的 CA 的私钥被泄露，攻击者可以用它签发任意域名的合法证书。2011 年的 DigiNotar 事件就是典型——攻击者利用泄露的 CA 私钥，签发了包括 google.com 在内的数百个假证书。
我个人习惯在配置服务器时，一定要检查证书链的完整性。很多运维人员只上传了服务器证书，忘了上传中间 CA 证书。结果呢？客户端无法构建完整的证书链，验证失败。但有些客户端为了“用户体验”，会忽略这个错误，直接信任不完整的链——这等于给伪造证书开了绿灯。
避坑指南：我曾经见过一个项目，他们把中间 CA 证书和根证书搞混了。服务器上配的是根证书而不是中间证书。客户端验证时发现证书链断裂，但因为配置了“允许部分链”，竟然通过了。这个漏洞在线上跑了半年才被发现。记住：证书链必须完整，顺序必须正确（服务器证书 → 中间 CA → 根 CA）。
2.3 证书吊销失效
证书吊销，就是 CA 宣布某个证书不再有效。比如私钥泄露、域名变更、员工离职等场景。吊销机制主要有两种：CRL（证书吊销列表）和 OCSP（在线证书状态协议）。
但现实是，吊销机制经常失效。为什么？
- CRL 更新不及时：CRL 列表通常每天或每周更新一次。如果攻击者在更新间隙使用一个已被吊销的证书，客户端可能无法及时发现。
- OCSP 响应器不可用：OCSP 需要实时查询 CA 的服务器。如果 CA 的 OCSP 响应器宕机或网络不通，很多客户端会“软失效”——即跳过检查，继续信任证书。这叫“OCSP 软失败”问题。
- OCSP Stapling 配置错误：OCSP Stapling 让服务器自己携带 OCSP 响应，减少客户端查询开销。但如果服务器没有正确配置，或者 stapled 响应过期了，客户端可能收到过时的状态信息。
| 吊销机制 | 工作原理 | 常见失效原因 |
|---|---|---|
| CRL | CA 定期发布被吊销证书的序列号列表 | 列表更新延迟、客户端不下载、列表过大 |
| OCSP | 客户端实时查询 CA 获取证书状态 | 响应器不可用、软失败、隐私泄露 |
| OCSP Stapling | 服务器缓存 OCSP 响应并随握手发给客户端 | 缓存过期、服务器未配置、中间人篡改 |
我的建议：不要完全依赖 OCSP 软失败。如果 OCSP 响应器不可用，应该拒绝连接，而不是继续信任。另外，CRL 的缓存时间不要设置太长，我一般建议不超过 24 小时。
2.4 弱加密算法
弱加密算法，说白了就是那些已经被证明不够安全的密码学原语。攻击者可以利用它们的数学弱点，在合理时间内破解加密通信。
常见的弱加密算法包括：
- RC4：流密码，存在多种偏差攻击。2015 年已被 RFC 7465 明确禁止用于 TLS。
- 3DES：虽然比 DES 强，但 56 位的有效密钥长度在现代计算能力面前已经不够看了。NIST 在 2023 年正式弃用。
- MD5/SHA-1：用于证书签名的哈希算法。MD5 已被彻底攻破，SHA-1 也已在 2017 年被 Google 成功碰撞。现在主流 CA 都使用 SHA-256。
- RSA 1024 位：密钥长度太短，预计在 2025-2030 年间可能被破解。业界已普遍要求至少 2048 位。
- Diffie-Hellman 参数过小：如果 DH 交换的素数 p 只有 512 位或 768 位，攻击者可以用预计算的方式破解。
我记得有一次帮客户做 TLS 配置扫描，发现他们的服务器竟然还支持 EXPORT 级别的加密套件。那是 90 年代美国出口管制时期的产物，密钥长度只有 40 位。用一台普通笔记本电脑，几分钟就能暴力破解。嗯，这种配置现在基本等于裸奔。
安全基线：TLS 1.2 及以上，禁用 RC4、3DES、MD5、SHA-1，RSA 密钥至少 2048 位，DH 参数至少 2048 位。推荐使用 ECDHE 密钥交换 + AES-GCM 加密 + SHA-256 签名。
好了，这四类漏洞就是证书链配置中最常见的“坑”。中间人攻击利用的是验证缺失，证书伪造利用的是信任链断裂，吊销失效利用的是检查机制的不完善，弱加密算法利用的是密码学原语的过时。后面的章节，我会逐一深入讲解如何发现和修复这些问题。