HTTPS之TLS1.3特性解析（四）

TLS1.2 已是 10 年前（2008 年）的“老”协议了，虽然历经考验，但毕竟“岁月不饶人”，在安全、性能等方面已经跟不上现在的互联网了。

因而通过四年、近 30 个草案的反复打磨，TLS1.3 终于在前年（2018 年）“粉墨登场”，再次确立了信息安全领域的新标准。

咱们先来快速浏览一下 TLS1.3 的三个主要改进目标：兼容、安全与性能。

最大化兼容性

因为 1.一、1.2 等协议已经出现了不少年，不少应用软件、中间代理（官方称为“MiddleBox”）只认老的记录协议格式，更新改造很困难，甚至是不可行（设备僵化）。

在早期的试验中发现，一旦变动了记录头字段里的版本号，也就是由 0x303（TLS1.2）改成 0x304（TLS1.3）的话，大量的代理服务器、网关都没法正确处理，最终致使 TLS 握手失败。

为了保证这些被普遍部署的“老设备”可以继续使用，避免新协议带来的“冲击”，TLS1.3 不得不作出妥协，保持现有的记录格式不变，经过“假装”来实现兼容，使得 TLS1.3 看上去“像是”TLS1.2。

那么，该怎么区分 1.2 和 1.3 呢？

这要用到一个新的扩展协议（Extension Protocol），它有点“补充条款”的意思，经过在记录末尾添加一系列的“扩展字段”来增长新的功能，老版本的 TLS 不认识它能够直接忽略，这就实现了“后向兼容”。

在记录头的 Version 字段被兼容性“固定”的状况下，只要是 TLS1.3 协议，握手的“Hello”消息后面就必须有“supported_versions”扩展，它标记了 TLS 的版本号，使用它就能区分新旧协议。

强化安全

TLS1.2 在十来年的应用中得到了许多宝贵的经验，陆续发现了不少的漏洞和加密算法的弱点，因此 TLS1.3 就在协议里修补了这些不安全因素。

好比：

• 伪随机数函数由 PRF 升级为 HKDF（HMAC-based Extract-and-Expand Key Derivation Function）；
• 明确禁止在记录协议里使用压缩；
• 废除了 RC四、DES 对称加密算法；
• 废除了 ECB、CBC 等传统分组模式；
• 废除了 MD五、SHA一、SHA-224 摘要算法；
• 废除了 RSA、DH 密钥交换算法和许多命名曲线。

通过这一番“减肥瘦身”以后，TLS1.3 里只保留了 AES、ChaCha20 对称加密算法，分组模式只能用 AEAD 的 GCM、CCM 和 Poly1305，摘要算法只能用 SHA25六、SHA384，密钥交换算法只有 ECDHE 和 DHE，椭圆曲线也被“砍”到只剩 P-256 和 x25519 等 5 种。

减肥可让人变得更轻巧灵活，TLS 也是这样。

算法精简后带来了一个意料之中的好处：原来众多的算法、参数组合致使密码套件很是复杂，难以选择，而如今的 TLS1.3 里只有 5 个套件，不管是客户端仍是服务器都不会再犯“选择困难症”了。

提高性能

HTTPS 创建链接时除了要作 TCP 握手，还要作 TLS 握手，可能致使几十毫秒甚至上百毫秒的延迟，在移动网络中延迟还会更严重。

如今由于密码套件大幅度简化，也就没有必要再像之前那样走复杂的协商流程了。TLS1.3 压缩了之前的“Hello”协商过程，删除了“Key Exchange”消息，效率提升了一倍。

那么它是怎么作的呢？

其实具体的作法仍是利用了扩展。客户端在“Client Hello”消息里直接用“supported_groups”带上支持的曲线，好比 P-25六、x25519，用“key_share”带上曲线对应的客户端公钥参数，用“signature_algorithms”带上签名算法。

1.3握手图

握手分析

小结

1. 为了兼容 1.一、1.2 等“老”协议，TLS1.3 会“假装”成 TLS1.2，新特性在“扩展”里实现；
2. 1.一、1.2 在实践中发现了不少安全隐患，因此 TLS1.3 大幅度删减了加密算法，只保留了 ECDHE、AES、ChaCha20、SHA-2 等极少数算法，强化了安全；
3. TLS1.3 也简化了握手过程，彻底握手只须要一个消息往返，提高了性能。