TLS 1.3如何用性能为HTTPS正名

Posted 2021-04-30 FreeBuf

序•魔戒再现

几天前，OpenSSL官方宣布即将发布的新版本 （OpenSSL 1.1.1） 将会提供 TLS 1.3 的支持，而且还会和之前的 1.1.0 版本完全兼容，这当然是个好消息。如果说 HTTP/2 是当前互联网 Web 发展的讨论热点之一，那么下一个热点应该就是 TLS 1.3 了。

谈到 TLS 那么就不得不说回 HTTPS，2016 年应该算是国内站点使用 HTTPS 激增的一年，从 Google Trend 上也可以看出该关键词的搜索热度从 2016 年开始飙升。不光如此，所有从事互联网 Web 技术相关的开发人员，也应该能够明显感受到，身边使用 HTTPS 的网站越来越多了。

为什么近两年来 HTTPS 被大家更广泛的应用？

一方面得益于「中国特色」的网络安全环境，运营商层出不穷的各种劫持给所有的用户和开发者都上了生动的一课。

用户每天被来自各种广告联盟漫天的牛皮癣广告和运营商话费余额查询所包围。不仅如此，随着公司流量不断的被劫持导流到其他地方。搞得很多公司连苦心经营的市场蛋糕都没办法安心的吃，终于大部分公司坐不住了。当然声讨和口诛笔伐是没有用的，所以拥有业务上拥有 HTTPS 和 HTTP DNS 解决方案，也就顺理成章的成了技术公司在伟大防火墙内生存的必备技能之一。

另一方面，从安全角度讲，互联网上通过明文传输数据本身就是一件高风险的事情，什么数据泄露、中间人攻击、用户被盗号、被竞争对手背后捅刀子 App 下载被劫持…..也是屡见不鲜。

那么说回主题，既然 HTTPS 可以一劳永逸的解决上述问题，而为什么大家之前不尽快的用起来？

问题在于：考虑到 HTTPS 要比 HTTP 更加消耗服务器资源，而且相比于 HTTP 建立连接握手时需要消耗的大量时间影响用户端的体验，使得很多人望而却步，尤其是在移动网络下。

当然，还有 SSL 证书的成本也要算进去。

王者归来

在 Web 领域，传输延迟（Transmission Latency）是 Web 性能的重要指标之一，低延迟意味着更流畅的页面加载以及更快的 API 响应速度。而一个完整的 HTTPS 链接的建立大概需要以下四步：

第一步：DNS 查询

第二步：TCP 握手（ 1 RTT）

和服务器建立 TCP 连接，客户端向服务器发送 SYN 包，服务端返回确认的 ACK 包，这会花费一个往返（1 RTT）

第三步：TLS 握手 （2 RTT）

该部分客户端会和服务器交换密钥，同时设置加密链接，对于 TLS 1.2 或者更早的版本，这步需要 2 个 RTT

第四步：建立 HTTP 连接（1 RTT）

一旦 TLS 连接建立，浏览器就会通过该连接发送加密过的 HTTP 请求。

我们假设 DNS 的查询时间忽略不计，那么从开始到建立一个完整的 HTTPS 连接大概一共需要 4 个 RTT，如果是浏览刚刚已经访问过的站点的话，通过 TLS 的会话恢复机制，第三步 TLS 握手能够从 2 RTT 变为 1 RTT。

总结：

建立新连接 ：

4 RTT + DNS 查询时间

访问刚浏览过的连接：

3 RTT + DNS 查询时间

那么 TLS 1.3 以及 0-RTT 是如何减少延迟的?

在此之前我们需要简单回顾一下 TLS 1.2 是如何工作的。

TLS 1.2 建立新连接

1.在一次新的握手流程中，Client Hello 总是客户端发送的第一条消息，该消息包含客户端的功能和首选项，与此同时客户端也会将本身支持的所有密码套件（Cipher Suite）列表发送过去

2.Server Hello 将服务器选择的连接参数传送回客户端，同时将证书链发送过去，进行服务器的密钥交换

3.进行客户端部分的密钥交换，此时握手已经完成，加密连接已经可以使用

4.客户端建立 HTTP 连接

TLS 1.2 会话恢复

会话恢复：

在一次完整协商的连接断开时，客户端和服务器都会将会话的安全参数保留一段时间。希望使用会话恢复的服务器会为会话指定唯一的标识，称为会话 ID。

1.希望恢复会话的客户端将相应的会话 ID 放入 ClientHello 消息中，提交给服务器

2.服务器如果愿意恢复会话，将相同的会话 ID 放入 Server Hello 消息返回，使用之前协商的主密钥生成一套新密钥，切换到加密模式，发送完成信息

3.客户端收到会话已恢复的消息，也进行相同的操作。

TLS 1.3 建立新连接

1.在一次新的握手流程中，客户端不仅会发送 Client Hello 同时也会将支持的密码套件以及客户端密钥发送给服务端，相比于 TLS1.2，该步骤节约了一个 RTT

2.服务端发送 Server Hello ，服务端密钥和证书

3.客户端接收服务端发过来的信息，使用服务端密钥，同时检查证书完整性，此时加密连接已经建立可以发送 HTTP 请求，整个过程仅仅一个 RTT

TLS 1.3 0-RTT 会话恢复

TLS 1.2 中通过 1 个 RTT 即可完成会话恢复，那么 TLS 1.3 是如何做到 0 RTT 连接的？

当一个支持 TLS 1.3 的客户端连接到同样支持 TLS 1.3 的服务器时， 客户端会将收到服务器发送过来的 Ticket 通过相关计算，一起组成新的 预共享密钥，PSK （PreSharedKey）。客户端会将该 PSK 缓存在本地，在会话恢复时在 Client Hello 上带上 PSK 扩展，同时通过之前客户端发送的完成（finished）计算出恢复密钥 （Resumption Secret）通过该密钥加密数据发送给服务器。服务器会从会话 Ticket 中算出 PSK，使用它来解密刚才发过来的加密数据。

至此完成了该 0-RTT 会话恢复的过程。

以上简单描述了 TLS 1.3 建立连接的大致流程，也解释了为什么 TLS 1.3 相比于之前的 TLS 1.2 会有更出色的性能表现。

当然 TLS 1.3 还有非常非常多的细节以及安全特性，优点以及缺点（去除静态 RSA 和 DH 密钥协商、禁止 RC4、有副作用的 0-RTT 握手存在重放攻击，不支持前向保密…..），限于篇幅并没有更深入的去探讨。

总结

TLS 1.3 将是 Web 性能以及安全的一个新的里程碑，随之 TLS1.3 带来的 0-RTT 握手，淡化了大家之前对使用 HTTPS 性能上的隐忧。于此同时，在未来随着 HTTP/2 的不断普及，强制性使用 HTTPS 成为了一种必然。

HTTPS 的推广也离不开一些公益性的组织，比如 Let’s Encrypt。

Let’s Encrypt 推动了基础 DV HTTPS 证书的普及，让互联网上的中小站长和独立博客用户很容易的用上 HTTPS。而对于企业来说，DV 证书是不能满足要求的。需要信任等级更高、安全级别更强的企业型 SSL 证书（OV SSL）以及增强型SSL证书（EV SSL），相比于 DV 证书，后两者价格虽会更贵一些，而带来的安全性保证却是前者 DV 证书不能相比的。