科普 TLS 1.3 — 新特性
TLS 1.3 协议针对安全强化及效率提升等方面进行了大量修改，相继推出 20 多个草案版本，即将完成最终的标准化。标准完成后，OpenSSL 组织将推出 OpenSSL 1.1.1 版本，对 TLS1.3 协议标准提供支持。
在谈 TLS 1.3 之前，我们先来看下 TLS 1.2 的工作模式，如图所示是 TLS 1.2 客户端和服务端交互的过程，如图所示:
我们也可以通过 Wireshark 抓包得到的数据
以 ECDHE 密钥交换算法为例，TLS1.2 协议完整的 SSL 握手过程如下:
第一步，首先客户端发送 ClientHello 消息，该消息中主要包括客户端支持的协议版本、加密套件列表及握手过程需要用到的 ECC 扩展信息；
第二步，服务端回复 ServerHello，包含选定的加密套件和 ECC 扩展；发送证书给客户端；选用客户端提供的参数生成 ECDH 临时公钥，同时回复 ServerKeyExchange 消息；
第三步，客户端接收 ServerKeyExchange 后，使用证书公钥进行签名验证，获取服务器端的 ECDH 临时公钥，生成会话所需要的共享密钥；生成 ECDH 临时公钥和 ClientKeyExchange 消息发送给服务端；
第四步，服务器处理 ClientKeyExchange 消息，获取客户端 ECDH 临时公钥；服务器生成会话所需要的共享密钥；发送密钥协商完成消息给客户端；
第五步，双方使用生成的共享密钥对消息加密传输，保证消息安全。
可以看到，TLS1.2 协议中需要加密套件协商、密钥信息交换、ChangeCipherSpec 协议通告等过程，需要消耗 2-RTT 的握手时间，这也是造成 HTTPS 协议慢的一个重要原因之一。
我们来看下 TLS 1.3 的的交互过程，如图所示:
其抓包得到的数据流如下:
在 TLS 1.3 中，客户端首先不仅发送 ClientHello 支持的密码列表，而且还猜测服务器将选择哪种密钥协商算法，并发送密钥共享,这可以节省很大一部分的开销，从而提高了速度。
TLS1.3 提供 1-RTT 的握手机制，还是以 ECDHE 密钥交换过程为例，握手过程如下。将客户端发送 ECDH 临时公钥的过程提前到 ClientHello，同时删除了 ChangeCipherSpec 协议简化握手过程，使第一次握手时只需要 1-RTT，来看具体的流程:
客户端发送 ClientHello 消息，该消息主要包括客户端支持的协议版本、DH 密钥交换参数列表 KeyShare；
服务端回复 ServerHello，包含选定的加密套件；发送证书给客户端；使用证书对应的私钥对握手消息签名，将结果发送给客户端；选用客户端提供的参数生成 ECDH 临时公钥，结合选定的 DH 参数计算出用于加密 HTTP 消息的共享密钥；服务端生成的临时公钥通过 KeyShare 消息发送给客户端；
客户端接收到 KeyShare 消息后，使用证书公钥进行签名验证，获取服务器端的 ECDH 临时公钥，生成会话所需要的共享密钥；
双方使用生成的共享密钥对消息加密传输，保证消息安全。
如果客户端之前已经连接，我们有办法在 1.2 中进行 1-RTT 连接，而在 TLS 1.3 中允许我们执行 0-RTT 连接，如图所示:
需要说明的是，如需查看 TLS 1.3 的报文，需要使用 2.5 版本的 wireshark，可以去 www.wireshark.org/download/automated下载
TLS 1.3 的新特性
- 废除不支持前向安全性的 RSA 和 DH 密钥交换算法；
- MAC 只使用 AEAD 算法；
- 禁用 RC4 / SHA1 等不安全的算法；
- 加密握手消息；
- 减少往返时延 RTT，支持 0-RTT；
- 兼容中间设备 TLS 1.2；
- 加密握手消息；
TLS1.2 及之前版本的协议中各种扩展信息在 ServerHello 中以明文方式发送，但是 TLS 1.3 协议要求 ServerHello 消息之后的握手信息都需要加密。
△ TLS1.2
△ TLS1.3
至于服务器端和浏览器里开启支持 TLSv1.3，大家可以参考【时隔快半年再次体验 HTTPS 的 TLSv1.3 协议】和【又拍云 CDN 的 HTTPS 已率先支持 TLS 1.3】一文即可，具体的 TLSv1.3 效果，大家浏览本博客即可体验的，验证的话只需要通过谷歌浏览器的开发者工具（按 F12 可调出）在 Security 下即可看到当前页面的支持情况了，记得要开启 Chrome 浏览器的 TLSv1.3 支持哦，开启后等待缓存更新即可！