RFC 8996《废止 TLS 1.0 与 TLS 1.1》中文导读
非官方中文导读声明：本页为 IETF RFC 8996《Deprecating TLS 1.0 and TLS 1.1》 的非官方中文技术导读，按原文章节顺序梳理规范要点，并非逐字全文翻译；任何规范性判断均以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc8996.txt。
1. 结论先行
RFC 8996 正式废止 TLS 1.0（RFC 2246）与 TLS 1.1（RFC 4346），相应文档转为历史（Historic）状态；同时废止 DTLS 1.0（RFC 4347），但 DTLS 1.2 不受影响（不存在 DTLS 1.1）。它被收录为 BCP 195 的一部分。
理由是：这两个版本缺少对当前推荐密码算法与机制的支持；政府与行业的多种 TLS 应用剖面已要求避免使用它们；TLS 1.2 自 2008 年起即为 IETF 协议推荐版本（2018 年被 TLS 1.3 取代其推荐地位），迁移窗口已足够长。从实现中移除旧版本可以缩小攻击面、减少配置错误机会，并简化库与产品维护。
2. 技术根因：SHA-1 与 MD5 被写死在协议结构里
这是本文最值得理解的一节。TLS 1.0/1.1 对 SHA-1 与 MD5 的依赖不是“可以换掉的密码套件选项”，而是结构性依赖：
- 它们的伪随机函数（PRF）把 MD5 与 SHA-1 组合在一起使用，无法在握手中协商为更强的哈希；
- 数字签名的构造同样固定使用 MD5 与 SHA-1 的组合，无法协商替换；
- 服务器签名部分仅使用 SHA-1，无法协商为更强算法。
因此，即便在 TLS 1.0/1.1 上只启用“看起来现代”的密码套件，握手过程本身仍然依赖已被削弱的哈希算法。TLS 1.2 引入了可协商的哈希与签名算法，才从根本上解决这一问题。
3. 规范性要求
- 不得再协商 TLS 1.0：客户端不得发送 ClientHello 宣称支持 TLS 1.0，服务端也不得选择 TLS 1.0；收到对端提议 TLS 1.0 时应当以
protocol_version告警终止。 - 不得再协商 TLS 1.1：要求与 TLS 1.0 完全一致。
- 同样地，DTLS 1.0 也不得再被协商。
- 仍需与旧系统互通的场景，应当明确记录风险并设定退出时间表，而不是默认长期保留。
本文档相应更新了 RFC 7525（TLS/DTLS 安全使用建议）中关于最低版本的条款：原先允许在必要时回落到 TLS 1.0/1.1 的措辞被收紧为以 TLS 1.2 为下限。
4. 对邮件系统的具体影响
邮件生态是这条规则落地摩擦最大的场景之一，因为 SMTP 之间的 TLS 大多是机会性的：如果对端只支持 TLS 1.0，强制下限会导致投递失败而不是降级为明文。文档在运维考量中提示，实施方需要评估自身流量中旧版本的占比后再切换。
具体检查面包括：MTA 之间的 STARTTLS（25 端口）、提交服务（587/465）、IMAP/POP（143/993/110/995）、Webmail 前端 HTTPS，以及各类通过 SMTP 发信的业务系统与打印机、扫描仪等嵌入式设备——后者往往是唯一卡住升级的一环。
推荐的推进方式是先在日志中统计按协议版本分布的会话量，识别出仍在使用 TLS 1.0/1.1 的对端与内部设备，逐个整改后再收紧下限，避免一刀切造成邮件积压。
参考：https://www.rfc-editor.org/rfc/rfc8996.txt