老左笔记
我们在设置SSL证书的时候，是不是有听到 TLS1.2和TLS1.3，这个到底有什么区别呢？
| 对比维度 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 发布时间 | 2008 年（RFC 5246） | 2018 年（RFC 8446） |
| 设计目标 | 在 TLS 1.1 基础上增强安全性（如支持更强的加密套件），兼容性优先。 | 彻底简化协议、提升安全性（移除不安全特性）、显著优化性能（减少握手延迟）。 |
| 握手流程 | 需要 2-RTT（两次往返）完成握手： - ClientHello → ServerHello - 交换密钥参数（如证书、密钥交换材料） - 完成密钥协商后传输应用数据。 |
默认 1-RTT（一次往返）完成握手： - ClientHello 直接携带密钥共享参数（如 ECDHE 公钥） - ServerHello 返回密钥共享参数 + 证书 - 立即生成会话密钥并传输应用数据。 支持 0-RTT（零往返）：客户端缓存上次会话的密钥，首次连接可直接发送加密数据（牺牲部分前向安全性）。 |
| 密钥交换算法 | 支持多种算法（如 RSA、DH、ECDH），但 RSA 密钥交换存在前向安全性问题（若私钥泄露，历史通信可被解密）。 | 仅支持前向安全的密钥交换算法： - ECDHE（椭圆曲线迪菲-赫尔曼临时密钥交换） - 移除 RSA 密钥交换、静态 DH 等不安全算法。 |
| 加密套件 | 支持大量套件（如 AES-CBC、RC4、3DES 等），部分套件存在已知漏洞（如 POODLE、BEAST）。 | 大幅精简加密套件： - 仅支持 AEAD（认证加密关联数据）算法： - AES-GCM（128/256）、ChaCha20-Poly1305 - 移除 CBC 模式、RC4、3DES 等不安全或低效算法。 - 固定哈希算法（SHA-256/SHA-384）用于 HMAC 和密钥派生。 |
| 密钥派生机制 | 使用 PRF（伪随机函数，基于 MD5 和 SHA-1 混合）生成密钥材料，存在哈希算法过时风险。 | 简化密钥派生： - 基于 HKDF（基于 HMAC 的密钥派生函数，使用 SHA-256/SHA-384） - 直接从握手密钥材料派生会话密钥，减少中间步骤。 |
| 证书验证 | 支持多种证书类型（如 RSA、DSA），客户端需验证证书链和签名算法（可能支持弱算法如 SHA-1）。 | 强化证书验证： - 仅支持强签名算法（如 SHA-256WithRSAEncryption、ECDSAWithSHA256） - 移除对 SHA-1 证书的支持（强制使用 SHA-256 及以上）。 |
| 会话恢复机制 | 依赖 Session ID 或 Session Ticket 实现会话恢复，但 Ticket 可能被服务器解密（存在隐私风险）。 | 改进会话恢复： - 使用 PSK（预共享密钥）机制： - 基于前次握手的密钥派生 PSK，支持 0-RTT/1-RTT 恢复 - PSK 绑定到当前握手参数（防止重放攻击） - 移除 Session ID 方式（减少状态管理复杂度）。 |
| 前向安全性 | 依赖 ECDHE/DH 密钥交换实现前向安全，但 RSA 密钥交换会破坏前向安全（若私钥泄露，历史通信可被解密）。 | 强制前向安全： - 所有密钥交换必须使用 ECDHE（临时密钥），即使使用 PSK 也需结合 ECDHE 保证前向安全。 |
| 抗重放攻击 | 依赖时间戳和随机数，但实现复杂且可能存在漏洞（如 CBC 模式下的重放风险）。 | 内置抗重放机制： - 0-RTT 数据可能被重放（需应用层额外防护） - 1-RTT 握手通过密钥派生绑定握手参数（防止重放）。 |
| 协议扩展性 | 通过扩展（Extensions）支持新功能（如 SNI、ALPN），但部分扩展可能引入安全风险（如不安全的压缩扩展）。 | 精简扩展： - 移除不安全扩展（如压缩扩展，防止 CRIME 攻击） - 新增必要扩展（如 KeyShare、PreSharedKey）以支持新特性。 - 扩展必须显式声明，避免隐式依赖。 |
| 典型应用场景 | 旧系统兼容（如老旧服务器/客户端）、需要支持 RSA 密钥交换的场景（逐渐淘汰）。 | 现代应用首选（如 HTTPS、API 通信），尤其注重安全性、低延迟的场景（如移动端、实时应用）。 |
TLS 1.3 移除了不安全算法（如 RSA 密钥交换、CBC 模式），强制前向安全，抗攻击能力更强。精简加密套件和扩展，减少漏洞风险。TLS 1.3 为后续加密技术（如后量子密码）预留了扩展空间，而 TLS 1.2 已逐渐被主流浏览器和服务端弃用（如 Chrome/Firefox 默认禁用）。
