本文主要从TLS 1.3的优势、部署和时间发展线介绍了这种用于为计算机网络通信提供安全性的密码协议TLS。
TLS简介
按照维基百科的定义,TLS 是一种用于为计算机网络通信提供安全性的密码协议,其前身安全套接层(SSL)想必很多人都听说过。TLS 被广泛应用于基于 IP 的网络协议,如 HTTP、SMTP、FTP 等。最近几年内,Let's Encrypt 提供的免费证书服务、浏览器只对 HTTPS 站点启用 HTTP/2 和把未使用 HTTPS 而要求输入密码的网站标记为不安全等因素强力推动了 HTTPS 的部署,国际上 HTTPS 的部署率现已超过 50%。在各种因素的推动下,国内站点和应用也在大力推广 TLS 等密码协议的使用。
Figure 1: 数据来自谷歌 Transparency Report,2018年9月14日获取
TLS 1.3 移除了很多过时的密码学原型和功能(例如压缩、重协商),强制要求完美前向安全。TLS 1.2 支持了很多加密算法(包括 3DES、静态 DH 等),这导致了 FREAK、Logjam、Sweet32 等攻击的出现。TLS 1.3 缩紧了对加密原型的限制,避免了因服务器启用不安全的算法导致协议的安全性受到影响。在这方面的简化也使得运维和开发者配置 TLS 变得更容易,不再容易误用不安全的配置。
TLS 1.3 之前,整个握手环节都是没有加密保护的,这泄漏了很多信息,包括客户端和服务器的身份。TLS 1.3 对握手的绝大部分信息进行了加密,这保护了用户隐私,也在一定程度上防止了协议僵化问题。
虽然电脑越变越快,但在互联网上传输数据耗费的时间依然受限于光速,所以两个节点间来回传输一次的时间(RTT)成为了限制协议性能的因素之一。TLS 1.3 只需要一个 RTT 就能完成握手,相比 TLS 1.2 省去了一个 RTT。并且 TLS 1.3 支持 “0-RTT” 模式,在该模式下客户端可以在握手的同时发送数据,极大地加快了页面的加载速度。TLS 1.3 还增加了 ChaCha20/Poly1305 支持,在不支持 AES 硬件指令的老设备上能提升加、解密性能。
TLS 1.3的部署
Tengine 2.2.2 / nginx 1.13.0 提供了 TLS 1.3 支持,和 OpenSSL 1.1.1 配合即可将网站升级到 TLS 1.3。在配置文件里将 TLSv1.3 加到 ssl_protocols 中就可以启用 TLS 1.3 支持了。Qualys 的 SSL 服务器测试[1]是很方便的 TLS 配置测试工具,可以很方便地检测公网站点的 TLS 配置及其安全性。
协议僵化问题
当一个互联网协议长时间不发生变化时,基于该协议开发的设备就可能无视其预留的变通手段而对其特性作出超出标准的假设,这就是协议僵化现象。在 TLS 1.3 的完善过程中,新的协议因协议僵化问题而不得不模拟老协议的一些行为,这大大拖慢了 TLS 1.3 标准化的进度。尽管在制定 TLS 1.3 标准时工作组针对很多实际测试时出现的问题进行了处理,但我们部署到线上环境还是需要注意可能出现的兼容性问题。
2017年4月25日,nginx 1.13.0 发布,增加了 TLS 1.3 支持。
2018年3月21日,IESG 批准了 TLS 1.3 草案。
2018年4月17日,Chrome 66 默认开启了对 TLS 1.3 草案的支持。
2018年5月9日,Firefox 60 默认开启了对 TLS 1.3 草案的支持。
2018年8月10日,IETF 发布了 TLS 1.3 标准。
2018年9月11日,OpenSSL 1.1.1 (LTS) 版本发布,提供 TLS 1.3 支持。TLS 1.3 超过 TLS 1.0 成为 Cloudflare 上使用率排名第二的 TLS 版本。
2018年10月16日,Chrome 70 支持 TLS 1.3 正式标准。
2018年10月23日,Firefox 63 支持 TLS 1.3 正式标准。
[1]https://www.ssllabs.com/ssltest/
[2]https://tools.ietf.org/html/rfc8446
[3]https://en.wikipedia.org/wiki/Transport_Layer_Security
[4]https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/
[5]https://ietf.org/blog/tls13/
[6]https://kinsta.com/blog/tls-1-3/