3.3 TLS 版本与安全实践
3.3 TLS 版本特性与安全最佳实践
本节摘要：SOURCE 3.4–3.6：密码套件命名如
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256；PKI 验证含链、CRL/OCSP、域名匹配；实践上禁用弱算法、启用 HSTS、自动化证书（ACME）。
故障场景：套件含 EXPORT 或 NULL
安全扫描报 weak cipher。SOURCE 3.4 套件三元组：密钥交换_加密_MAC；应优先 ECDHE + AES-GCM + SHA256。
一、密码套件示例（SOURCE 3.4）
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 解读：
| 段 | 含义 |
|---|---|
| ECDHE | 椭圆曲线临时 DH，前向安全 |
| RSA | 证书签名算法 |
| AES_128_GCM | AEAD 加密 |
| SHA256 | 伪随机等哈希 |
二、证书验证步骤（SOURCE 3.5）
- 链到受信根 CA
- CRL 或 OCSP 检查吊销
- CN/SAN 与访问域名一致
- 有效期
notBefore/notAfter
三、运维清单
- 最低 TLS 1.2，优先 1.3
- 禁用 RC4、3DES、NULL、EXPORT
- Let's Encrypt / ACME 自动续期，避免 ERR_CERT_DATE_INVALID
- 配置 HSTS 防降级
⚠️ 常见坑：只换叶子证书不更新中间证书——Android 老设备链不完整。
💡 关键直觉：
ssl Labs测试是配置验收的快捷方式，但还要测真实客户端矩阵。
核心回顾
- 套件字符串读懂三段即可快速审计
- OCSP stapling 降低客户端延迟
- TLS 1.3 默认安全集大幅缩小误配空间
深入讨论：证书验证的四个步骤怎么逐一落地
证书验证的四步（链到根、吊销检查、域名匹配、有效期）在实际实现里各有坑。链验证要求中间证书完整下发，只发叶子证书是高频错误，浏览器会因无法拼出完整链而报不可信；吊销检查依赖 OCSP 或 CRL，网络不可达时客户端可能选择「硬失败」或「软失败」，策略差异影响可用性；域名匹配要同时看 CN 与 SAN，SAN 里缺了访问域名是常见配置事故；有效期看似简单，但跨时区与夏令时会造成边缘误差，自动化续期可以彻底规避。
运维上建议把证书的「观察-告警-续期」做成闭环：用 ssl Labs 或内部扫描定期测评得分，对即将到期、链不完整、域名缺失的证书发出告警，并用 ACME 自动签发续期。这样证书问题从「上线事故」变成「例行告警」，人力从反复救火中解放出来。
# 证书运维检查清单 检查项 命令/工具 通过标准 有效期 openssl x509 -enddate 距到期 > 30 天 链完整性 openssl s_client 输出 返回 verify return code 0 域名匹配 openssl x509 -text -noout SAN 包含访问域名 吊销可用 curl 触发 OCSP stapling 响应正常 算法强度 ssl Labs 测评 不低于 B 级 自动续期 ACME 客户端日志 最近 30 天有成功续期记录
这套清单可以在每次证书相关变更时跑一遍，也可以做成定时任务持续盯。证书是 TLS 里最容易被「配置出来就忘了」的部分，但它恰恰是身份认证的唯一锚点——把锚点管好，握手的其余环节才有意义。
附录速查：密码套件命名解析与合规套件表
# 密码套件命名三段解析 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | | | | | TLS 密钥交换 证书签名 加密算法 认证标签 哈希/PRF ECDHE: 椭圆曲线临时 DH（前向安全） RSA: 证书里公钥的签名算法 AES_128_GCM: 对称加密 AEAD SHA256: 伪随机函数与握手摘要 # 推荐启用 / 禁用套件对照 优先启用 TLS_AES_128_GCM_SHA256 （TLS 1.3 默认） TLS_AES_256_GCM_SHA384 （TLS 1.3 高安全） TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 必须禁用 TLS_RSA_WITH_RC4_128_MD5 RC4 偏差、MD5 碰撞 TLS_RSA_WITH_3DES_EDE_CBC_SHA 3DES 强度不足 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA CBC 历史风险 *EXPORT* 导出级弱加密 *NULL* 无加密 *CBC_SHA CBC + 旧 MAC 组合 # ssl Labs 测评关注点 评级标准：协议版本、套件强度、证书链、HSTS、前后向兼容 目标分数：A 或 A+；B 级需限期整改
套件是「版本安全」之下的第二道闸门。用上面两张表做基线，配合 ssl Labs 实测，线上套件配置的合理性就能量化评估，弱算法清理也有了明确清单。
补充一个容易被低估的配置点：HSTS 与证书吊销的配合。HSTS 的作用是让浏览器在一段周期内强制走 HTTPS，防降级攻击；但它的头字段只在首次安全连接时下发，如果首连被中间人劫持，HSTS 就来不及生效，所以业界还配合证书钉扎或预加载列表来加固。吊销侧则要避免「OCSP 不可达时静默放行」的软失败策略，敏感场景应选择硬失败并配合 OCSP stapling 减少外联。把「防降级」与「保吊销」当成配套动作一起配置，证书体系才真正闭环，这也是安全实践从「能跑」走向「可靠」的分水岭。
日常实践中，建议把 HSTS、OCSP stapling、证书到期告警三项放进同一个发布检查单，任何 TLS 变更同时过这三关，能显著减少「证书到期才发现的窘境」与「降级攻击」这两类高频事故。
如果资源有限，优先保证证书到期告警与自动续期——它是三关里最容易被忽视、一旦失守影响面最大的那一道。