认证与加密的组合方式
认证与加密有三种组合方式，安全性差异很大。先做认证再加密存在于传统协议的分组套件中，历史攻击面较多；先加密再做认证是推荐做法，验证失败时统一报错；并行计算两种结果的方式可能泄漏明文信息。现代协议直接使用认证加密模式，从根本上消除了组合顺序带来的问题。
基本信息
| 先认证后加密 | 历史攻击面较多，出现在旧版协议的分组套件 |
|---|---|
| 先加密后认证 | 推荐做法，先验后解，错误统一 |
| 并行计算 | 认证值可能泄漏明文信息 |
| 现代做法 | 直接使用认证加密模式 |
典型使用场景
- 兼容性检查：确认服务端是否仍协商旧版分组套件
- 自研协议设计：选择组合顺序与错误返回策略
- 排错：确认实现的验证与解密顺序是否正确
- 迁移规划：把旧套件替换为认证加密模式
- 代码审计：检查自研代码里拼接与验证的先后关系
检查是否仍协商分组套件
检查是否仍协商分组套件
openssl s_client -connect example.com:443 -tls1_2 -cipher 'ECDHE-RSA-AES128-SHA' </dev/null 2>&1 | grep -i 'cipher\|alert'
openssl ciphers -v 'DEFAULT' | grep -c CBC # 统计默认集合中的分组套件
# 高版本工具中部分旧套件已默认禁用，需显式指定安全级别才能观察三种组合方式
| 方式 | 顺序 | 典型场景 | 要点 |
|---|---|---|---|
| 先认证后加密 | 先认证再加密 | 旧版协议分组套件 | 历史攻击面较多 |
| 先加密后认证 | 先加密再认证 | 安全通道类协议 | 先验再解，错误统一 |
| 并行计算 | 两者同时 | 早期安全通道模式 | 认证值可能泄漏明文 |
旧版协议的分组套件属于先认证后加密家族，是历史攻击的来源；新部署应移交给认证加密模式，存量系统可用扩展特性过渡。
落地建议
- 实现里先验证认证值再解密，顺序不要写反
- 认证失败与解密失败返回同一种错误
- 加密与认证使用独立派生的密钥
- 新协议默认选用认证加密模式
组合顺序问题的根源在于解密端对失败原因的差异化反馈；统一错误信息并让耗时接近，是最直接的缓解手段，比逐个修补具体攻击更有效。