SSL/TLS 协议运行机制概述（二）

在SSL/TLS 协议运行机制概述（一）中介绍了TLS 1.2 的运行机制，现在我们来看年 TLS 1.3 的运行机制。会涉及到SSL/TLS 协议运行机制概述（一）中的一些概念，有需要的可以配合着看。

TLS 1.3 握手过程

与 TLS 1.2 握手一样，"Client Hello" 消息启动握手，但这次它包含了很多信息。TLS 1.3 将支持的密码套件从37个减少到5个。在握手的上下文中，这意味着客户端除了从它猜测的任何协议发送密钥共享外，还可以猜测将使用什么密钥协议/交换协议。
服务器将用自己的 "Server Hello" 消息响应。就像1.2握手一样，它也会在此时发送证书。并且，如果客户机猜对了，并且两端同意相同的 AEAD 协议，服务器将发送自己的密钥共享部分，计算会话密钥(session key)，并以 "Server Finished" 消息结束。
现在客户端已经拥有了所有相关信息，客户端将对 SSL 证书进行身份验证，并使用这两个密钥共享来计算它自己的会话密钥副本。完成后，它会发送自己的完成消息。

TLS 1.3 握手相对 TLS 1.2 的改进

1.更少的往返次数

最理想的情况是，TLS 1.2握手可以进行两次往返。在某些情况下，可能需要额外的往返行程，因此我们是在最佳情况下所讨论的往返行程的数量。对比如下两个图：

TLS 1.2 握手

TLS 1.3 握手

相比之下，TLS 1.3 的握手只是一次往返旅行

2.简化密码套件

TLS 1.2 支持的密码套件有37个，到目前为止有些已经很不安全了，而且过多的配置会导致过分的复杂，因此 TLS 1.3 将支持的密码套件从37个减少到5个。往返次数的减少归结于密码套件支持的减少。
最值得注意的是，关于密钥交换的整个选择都被删除了。Diffie-Hellman Ephemeral 方案是TLS 1.3 的唯一选择，它允许客户端在握手的第一部分将其密钥共享信息与 Client Hello 一起发送。RSA 加密与所有其他静态密钥交换方案一起被完全删除。完美前向保密(PFS)已经成为 TLS 1.3 的一项要求。

3.零往返恢复(0-RTT)

TLS握手在历史上一直很昂贵：增加服务器的负载和增加连接的延迟。所以缩小它的想法很有吸引力。0-RTT 只是通过存储一些有关客户端的秘密信息来实现这一点，通常是会话 ID (Session ID) 或会话票证(Session Tickets)，以便将来双方连接时使用。

尽管0-RTT带来了所有好处，但它实际上也带来了一些潜在的问题。
（1）它使客户端容易受到重播攻击。在重播攻击中，以某种方式设法访问加密会话的攻击者可以获取 0-RTT 数据（包括客户端的第一个请求），并将其再次发送到服务器，它可以欺骗服务器，因为它无法知道数据来自哪里。如果攻击者多次发送这个请求，就称为“重放攻击”。当然，它并不像听起来那么容易，有一些机制可以阻止这种攻击。

（2）更大的问题是，0-RTT 握手可能通过提供解密旧会话的途径破坏完美前向保密(PFS)。当然，通过定期轮换会话密钥可以轻松避免这种情况。

4.保护更多的 TLS 1.3 握手

在握手的早期，最大的担心之一是它的明文发送量。在 TLS 1.2 握手中，握手的协商阶段是不安全的，而是使用一个简单的 MAC 来确保没有人篡改传输的内容。TLS 1.3 握手对早期部分进行了数字签名(对 ServerHello 消息之后的握手信息加密)，这使得握手更安全，减少了降级攻击，并且通过扩展它们促进了许多攻击。这还提供了一种途径，通过验证私钥的拥有情况来更快速有效地对服务器进行身份验证。

参考链接：

https://www.thesslstore.com/blog/explaining-ssl-handshake/
https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4