mhac-sha1在TLS 1.3中为何被弃用？

Question

**问题：** 为什么TLS 1.3彻底移除了MHAC-SHA1（即基于SHA-1的HMAC，如TLS_RSA_WITH_AES_128_CBC_SHA中的MAC机制）？这是否仅因SHA-1碰撞攻击而弃用？ 简答：是，但不止于此。TLS 1.3移除MHAC-SHA1并非单纯因2017年SHAttered碰撞攻击——该攻击虽证明SHA-1抗碰撞性失效，但对CBC模式下HMAC-SHA1的直接威胁有限（HMAC不依赖抗碰撞性，而依赖伪随机性）。真正关键原因是：**TLS 1.3全面转向AEAD（如AES-GCM、ChaCha20-Poly1305），彻底淘汰了“加密+独立MAC”的传统两段式认证加密模式**。MHAC-SHA1仅存在于CBC类密码套件中，而所有CBC套件（含SHA-1/SHA-256 HMAC）均被删除，以规避填充预言攻击（如POODLE、Lucky13）、简化协议逻辑、提升性能与安全性。此外，SHA-1已从NIST标准中正式降级（SP 800-131A Rev.2），主流实现（OpenSSL、BoringSSL）早在TLS 1.2后期就禁用其用于证书签名和PRF，TLS 1.3只是完成这一安全演进的终局裁决。

Answer 1

```html

一、表层现象：SHA-1碰撞攻击的公众认知冲击

2017年Google与CWI联合发布的SHAttered攻击首次在实践中实现了SHA-1的可控碰撞（两份不同PDF生成相同摘要），引发全球对SHA-1信任崩塌。TLS中MHAC-SHA1（如TLS_RSA_WITH_AES_128_CBC_SHA）因含SHA-1被天然归入“已破”范畴——这是最直观、传播最广的弃用动因。

二、协议架构演进：从“Encrypt-then-MAC”到AEAD的范式革命

TLS 1.3彻底废除所有非AEAD密码套件，包括全部CBC模式组合（无论HMAC用SHA-1还是SHA-256）。其核心设计哲学是：认证加密必须原子化。AEAD（如AES-GCM、ChaCha20-Poly1305）将机密性、完整性、认证三者内建于单次操作，消除传统“先加密+后计算MAC”的时序侧信道风险。

三、安全工程现实：CBC模式的结构性缺陷不可修复

• POODLE（2014）：利用SSL 3.0中CBC填充验证的明文泄露
• Lucky13（2013）：通过MAC验证时间差实施填充预言攻击
• RC4与CBC组合在TLS 1.2中长期存在部署惯性，但漏洞面持续扩大

四、密码学原理辨析：HMAC-SHA1 ≠ SHA-1碰撞等价威胁

HMAC的安全性依赖于哈希函数的抗原像性与伪随机函数（PRF）性质，而非抗碰撞性。即使SHA-1碰撞可行，构造满足HMAC验证的伪造消息仍需破解密钥K下的HMAC(K, m)——这在计算上仍属不可行。因此，单纯SHA-1碰撞并非MHAC-SHA1在TLS中失效的直接技术主因。

五、标准与生态协同演进：NIST降级与实现层先行禁用

时间	事件	影响范围
2011	NIST SP 800-131A Rev.1 禁用SHA-1用于新数字签名	证书签发领域
2015	OpenSSL 1.0.2f 默认禁用SHA-1用于TLS PRF及证书验证	主流库实现层
2018	TLS 1.3 RFC 8446 发布，明确移除所有CBC+HMAC套件	协议规范终局裁决

六、性能与复杂度权衡：简化状态机与减少握手往返

graph LR
  A[TLS 1.2 Handshake] --> B[ClientHello + ServerHello + Certificate + ServerKeyExchange + ...]
  A --> C[多轮RTT + 密钥派生分阶段]
  D[TLS 1.3 Handshake] --> E[ClientHello + ServerHello + EncryptedExtensions + ...]
  D --> F[1-RTT 或 0-RTT 原子密钥导出]
  G[AEAD模式] --> H[单次硬件指令加速 AES-GCM]
  G --> I[ChaCha20-Poly1305 无AES-NI依赖]

七、纵深防御视角：多重淘汰策略叠加效应

移除MHAC-SHA1实为“三重过滤”结果：①算法维度（SHA-1降级）、②模式维度（CBC淘汰）、③结构维度（两段式MAC解耦废弃）。任一单点失效均不足以触发全面删除，但三者收敛于TLS 1.3的设计目标——最小可证安全集（Minimal Provable Security Set）。

八、工程落地启示：遗留系统迁移的真实挑战

大量嵌入式设备、IoT网关、金融终端仍运行TLS 1.2 CBC-SHA套件。TLS 1.3强制AEAD导致其无法协商成功，暴露了“安全升级≠向后兼容”的残酷现实。运维团队需同步升级中间件、JVM TLS Provider、NGINX/OpenResty配置，并审计所有自定义SSL/TLS封装逻辑。

九、延伸思考：为何未保留HMAC-SHA256？——协议精简主义的胜利

即便HMAC-SHA256在密码学上仍安全，TLS 1.3仍将其与HMAC-SHA1一并剔除，根本原因在于：拒绝维护任何非AEAD路径。保留SHA256-HMAC意味着需继续支持CBC填充逻辑、独立MAC验证状态机、额外密钥派生分支——违背“一个目标，一种实现”的极简协议哲学。

十、未来映射：QUIC与Post-Quantum TLS的继承逻辑

TLS 1.3的AEAD-only原则已深度融入QUIC传输层设计；IETF正在标准化的TLS 1.3+ PQ方案（如ML-KEM+AES-GCM）同样严格沿用AEAD范式。这表明：MHAC-SHA1的消亡不是历史偶然，而是现代安全协议向“可证明安全、可硬件加速、可形式化验证”三位一体演进的必然里程碑。

```