今年8月10日，历经三年有余，TLS 1.3 最终版本终于得以发布——RFC 8446. 关于 RFC 的详细介绍可以进一步阅读 A Detailed Look at RFC 8446 (a.k.a. TLS 1.3). TLS 1.3 因为其在握手延迟以及安全性上的改进 (可以参考拙文《TLS1.3/QUIC 是怎样做到 0-RTT 的》)，毫不夸张的说，这是一件将深刻而长远影响互联网发展的技术里程碑。那么将 TLS 1.3 尽快平滑应用到线上环境无疑是一件势在必行的事情了。
在我日常的工作中，对于 TLS 1.3 的支持和部署主要关注两个层面： 编程语言（Go, Java）、 API gateway (Nginx) 和浏览器. 下面分别介绍一下这三个层面 TLS 1.3 的支持部署现状。（因为 RFC 8446 已经发布，因此本文中说的支持如无特殊说明，都是指对最终版本 RFC 8446 的支持。）
编程语言对 TLS 1.3 的支持
Go 方面，官方在 TLS 1.3 draft 阶段一直没有跟进。因此，有一个关于对 TLS 1.3 支持的 issue 从 2015 年 open 至今都没有关闭：crypto/tls: add support for TLS 1.3. 其实 Go 发布版本和改进标准库的效率还是挺高的，对于 TLS 1.3 上的“不作为”更多是因为 Go 在兼容性上的承诺导致其并适合在最终版发布前实现互不兼容的 draft 方案。
而 Go 1.11 的发布时间（2018.08.24）与 RFC 8446 的发布时间比较接近，没有足够时间实现并发布该特性。从 golang-dev 小组讨论 Re: crypto/tls and TLS 1.3 看，由于 1.11 没有实现 TLS 1.3 ，那么 1.12 实现 TLS 1.3 基本是板上钉钉的事了：
The key scheduling fact is that the Go 1.11 feature freeze is just a week away, so we decided that it would be too rushed to merge the 1.3 patches for it. I definitely aim to have TLS 1.3 in Go 1.12.
根据惯例， Go 1.12 的发布时间将会是 2019.02~03. 如果期间你实在想用 Go 编程测试 TLS 1.3, 可以尝试使用 CloudFlare 的 tls-tris 库。根据 Go net/http 标准库维护者 Brad Fitzpatrick 的消息，这个库将会被合并到标准库作为 Go 官方 TLS 1.3 的实现。因此，如果你不得不用这个库干一些生成环境的活也大可放心，即使日后升级 Go 1.12, 接口兼容性还是有保证的。
Java 方面，由于 Java 11 出生时间好（2018.09.25）, 因此是出生就支持 TLS 1.3 RFC 8446, 具体可以参见 JEP 332: Transport Layer Security (TLS) 1.3. Java 11 是 LTS 版本，因此，如果有条件升级到 11, 推荐使用 Java 11 实现的 TLS 1.3 以及配套的 HttpClient；如果生产环境暂无法升级 Java 版本，推荐使用 OkHttp. 关于 Java Http Client 选型可以参见Java HTTP 组件库选型看这篇就够了。
Nginx 对 TLS 1.3 的支持
准确讲应该是 Nginx 所使用 SSL lib 对 TLS 1.3 的支持。在这方面，Boring SSL 跟进速度飞快，在 RFC 发布后第4天实现了对最终版本的支持。OpenSSL 虽然很早就跟进了 draft 的实现，但是对最终版本的支持需要 1.1.1-pre9 及以后的版本：
The OpenSSL git master branch (and the 1.1.1-pre9 beta version) contain our development TLSv1.3 code which is based on the final version of RFC8446 and can be used for testing purposes (i.e. it is not for production use). Earlier beta versions of OpenSSL 1.1.1 implemented draft versions of the standard. Those versions contained the macro TLS1_3_VERSION_DRAFT_TXT in the tls1.h header file which identified the specific draft version that was implemented. This macro has been removed from 1.1.1-pre9 and the current master branch.
TLSv1.3 is enabled by default in the latest development versions (there is no need to explicitly enable it). To disable it at compile time you must use the “no-tls1_3” option to “config” or “Configure”.
Although the latest 1.1.1 versions support the final standard version, other applications that support TLSv1.3 may still be using older draft versions. This is a common source of interoperability problems. If two peers supporting different TLSv1.3 draft versions attempt to communicate then they will fall back to TLSv1.2.
而第一个 OpenSSL 1.1.1 release 是在 2018.09.11, 因此如果你跟我一样是 OpenSSL 的死忠粉，当前阶段 Nginx 支持 TSL 1.3 的最佳方式是 Nginx 1.15.5 + OpenSSL 1.1.1. 而这种脏活、苦活、累活当然是交给 Docker 解决了：从源代码编译 nginx docker 镜像开启 TLS 1.3，项目地址可以参见 docker-nginx.
配置 Nginx 支持 TLS 1.3 需要注意一点：默认情况下 Nginx 因为安全原因，没有开启 TLS 1.3 0-RTT，可以通过添加 ssl_early_data on; 指令开启 0-RTT. 完整配置可以参考 nginx.conf.
浏览器对 TLS 1.3 的支持
当前阶段，Chrome 69 和 Firefox 62 都只支持到 draft 28, 而 draft 28 与最终版本是不兼容的。因此，要测试体验 TLS 1.3 final 需要使用 Chrome Beta 测试版。然后在 chrome://flags/#tls13-variant 开启 TLS 1.3 final:
扩展阅读
–EOF–
转载请注明出处，本文原始链接