TLS 1.3即将发布，TLS 1.3握手 VS TLS 1.2握手详解

万众期待的TLS 1.3在经历了27稿草案的漫长等待后，终于有了要发布的迹象。而它之所以受到如此高的关注度，是因为它改善了我们对SSL / TLS系列中最好且服务时间最长的TLS 1.2的支持。相比TLS 1.2，TLS 1.3在安全性和速度上将有很大的提升，摒弃了前任版本中过时且鸡肋的隐患加密选项。本文将为您解释TLS 1.3在握手方面较TLS 1.2的提升。

TLS 1.2握手

TLS 1.2握手与TLS 1.0和1.1类似，涉及客户端和服务器之间的一系列来回通信。

第1步：整个连接/握手从客户端向服务器发送“客户端问候”消息开始。该消息由加密信息组成，如支持的协议和支持的密码套件。它也包含一个随机值或随机字节串。

第2步：响应客户端的“客户端问候”消息，服务器以“服务器问候”消息响应。此消息包含服务器已从客户端提供的CipherSuite中选择的CipherSuite。服务器还会将其证书以及会话ID和另一个随机值一起发送。

第3步：客户端验证服务器发送的证书。验证完成后，它会发送一个随机字节字符串，也称为“预主密钥”，并使用服务器证书的公钥对其进行加密。

第4步：一旦服务器收到预主密钥，客户端和服务器都会生成一个主密钥以及会话密钥(临时密钥)。这些会话密钥将用于对称加密数据。

第5步：客户端向服务器发送“更改密码规范”消息，通过会话密钥的帮助让它知道它将切换到对称加密。与此同时，它还发送“客户端已完成”消息。

第6步：在答复客户端的“更改密码规范”消息时，服务器执行相同操作并将其安全状态切换为对称加密。服务器通过发送“服务器已完成”消息来结束握手。

如您所见，在客户端和服务器之间进行了两次往返以完成握手。 平均而言，这需要0.25秒到0.5秒之间的时间。 但是，它可能需要更多取决于几个因素。 起初，半秒时间似乎不是很多时间，但记住; 这只是握手，数据传输还没有开始。 当比较HTTP和HTTPS站点的TTFB(第一个字节的时间)时，与HTTP站点相比，HTTPS站点的TTFB需要更长的时间，尤其是当站点运行在HTTP / 1上时。

TLS 1.3握手

TLS 1.3握手过程相较TLS 1.2只涉及一次往返，这无疑降低了延迟。

第1步：与TLS 1.2握手类似，TLS 1.3握手从“客户问候”消息开始并包含一个重大变化。客户端发送支持的密码套件列表并猜测服务器可能选择的密钥协议协议。客户端还发送其特定密钥协议协议的密钥份额。

第2步：在回复“客户端问候”消息时，服务器回复它所选择的密钥协议协议。 “服务器问候”消息还包含服务器的密钥共享，其证书以及“服务器已完成”的消息。而TLS 1.2握手过程的第6步——“服务器完成”消息，将在TLS 1.3的第2步中完成。因而省了整整四个步骤。

第3步： 客户端检查服务器证书，生成密钥并发送“客户端已完成”的消息。至此，数据的加密开始了。

通过这个方法，TLS 1.3握手节省了整个通信往返以及数百毫秒的时间。这个数字或许听起来不大，但人们对于网页延迟的耐性其实相当有限。据2006年的一则调查报告显示，延迟半秒会导致网站流量下降20%!

0-RTT恢复

TLS 1.3的另一个里程碑是添加了0-RTT恢复。也就是说，如果客户端之前连接过某服务器，TLS 1.3将允许0次握手。这是通过储存先前会话的秘密信息来实现的。

然而，很少有人会注意到0-RTT恢复会话中的安全问题。首先是缺乏充分的前向保密。这意味着如果这些会话票据密钥受到攻击，攻击者可以解密客户端在第一次握手上发送的0-RTT数据。当然，通过定期轮换会话密钥可以轻松避免这种情况。但考虑到TLS 1.2完全不支持完全向前保密，TLS 1.3绝对是一种改进。

当谈到TLS 1.3 0-RTT时，第二个安全问题是它不能保证连接之间不重播。如果攻击者以某种方式管理你的0-RTT加密数据，它可以欺骗服务器认为请求来自服务器，因为它无法知道数据来自哪里。如果攻击者多次发送这个请求，就称为“重放攻击”。当然，它并不像听起来那么容易，有一些机制可以阻止这种攻击。

TLS 1.3在安全性和延迟方面提供了重大改进。现在Chrome和Firefox已启用对其草案的支持，因此您可以提前体验到TLS 1.3的强大功能。 然而它何时发布并成为标准仍是一个未知数。 但可以肯定的是，它将为我们服务多年!