标签归档：nginx

TLS 1.3 当前(2018.10)支持与部署之现状

发表于由
回复

今年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:

扩展阅读

从源代码编译 nginx docker 镜像开启 TLS 1.3

发表于由
回复

nginx最近更新挺频繁的，其中TLS 1.3和是HTTP/2 Server Push是两个比较有意思的特性。前者可以有效的减少握手次数，降低延迟，尤其在恢复会话时候可以将握手开销降低到 0-RTT，后者则可以通过服务器主动推送资源，可以认为是在资源预加载之上更进一步的「资源主动加载」，有效提高网页性能和用户体验。

考虑到平时自己需要比较频繁的测试不同的nginx的新版本，但是又不想破坏机器本地已经安装好的nginx环境，因此我决定制作一个nginx docker镜像。需要说明的是，dockerhub官方是有一个nginx镜像的，但我们希望自己定制nginx版本和需要开启的模块，因此该镜像并不符合需求。

这里以开启TLS 1.3为例制作一个以ubuntu:16.04为基础镜像的 nginx dockerm镜像。顺便把上次在Ubuntu 14.04开启nginx http2支持的方法中埋的坑填了?

nginx开启TLS 1.3的前置条件

  1. nginx >= 1.13.0
  2. openSSL >= 1.1.1 alpha

openSSL版本有几点点需要注意：

  1. 以前可以使用分支tls1.3-draft-18编译支持TLS 1.3，但是现在已经merge到1.1.1版本中了，因此，这里不再推荐使用tls1.3-draft-18编译nginx. 使用openSSL 1.1.1编译nginx会触发nginx的一个config bug: undefined reference to 'pthread_atfork', 解决办法可以参见这里以及nginx mailing list, 这里暂时回退到使用tls1.3-draft-18.
  2. 不要尝试使用tls1.3-draft-19编译nginx, 使用Chrome 64测试无法在nginx 1.13.9上成功开启TLS 1.3, 应该跟Chrome对draft版本的支持有关系。
    • 2018-03-14更新：升级到Chrome 65以后，发现默认支持为TLS 1.3 Draft 23, 后面顺带连通config bug一起解决了再更新。
  3. openSSL目前最新版本是OpenSSL_1_1_1-pre2, 还不是stable版本，因此，不要在生产环境中使用。

Dockerfile

Nginx 开启 TLS1.3

一个完整的配置模板参考如下：

主要新增两个修改：

  1. ssl_protocols添加TLSv1.3.
  2. ssl_ciphers加入TLS13_为前缀的密码套件。

完整项目地址：docker-nginx

验证TLS 1.3

  • Chrome: 将 chrome://flags/ 中的 Maximum TLS version enabled 改为 Enabled (Draft).

如果你刚刚升级到了Chrome 65，选项中开启TLS1.3有三个选项：Enabled(Experiment 2), Enabled(Draft 22), Enabled (Draft 23). 同时很遗憾的告诉你，本文中使用的是Draft 18编译nginx，因此无法配合Chrome 65无法开启TLS1.3，请下面介绍Firefox的开启方法测试TLS1.3?

  • Firefox: 将 about:config 中的 security.tls.version.max 改为 4.

以Chrome 64为例，如果开启成功后Protocol显示TLS 1.3:

你也可以访问tls.liudanking.com来测试自己的浏览器是否已经成功开启TLS 1.3.

参考资料

本博客开始支持 TLS 1.3

Ubuntu 14.04开启nginx http2支持的方法

发表于由
回复

再过不到两个月，Ubuntu18.04就要出来了，但是手上还有一些老机器还停留在14.04?：

没有足够的时间和动力来升级这几台老机器，但是一些常用的软件准备顺手升级一下。最基本的自然是升级nginx支持http2. http2的优势可以参见《当我们在谈论HTTP队头阻塞时，我们在谈论什么？》以及《低延迟与用户体验杂谈》。

Ubuntu 14.04开启nginx http2支持的前置条件

  1. nginx >=1.9.5
  2. openSSL >= 1.0.2

第一个条件大家一般都不会漏掉。但是第二个条件一般是http2无法成功开启时才发现。这是因为随14.04一起分发的openSSL版本是1.0.1f. 那么要开启http2支持，有两种方式：

  1. 使用他人编译好的ngingx with http2 support package安装；
  2. 升级本地openSSL版本，然后从源码编译安装。

而随Ubuntu 18.04一起分发的openSSL版本为1.1.0g, 因此不存在这个问题。

使用packaege安装（懒人专用）

这里需要注意一下，很多为提供14.04提供nginx安装包的源虽然可以让你安装更高版本的nginx，但是大多是使用openSSL 1.0.1编译的，因此无法支持http2, 比如jessis, nginx mainline为14.04提供的安装包是使用1.0.1编译的，因此不支持http2的。这里我们使用ondrej提供的源。

  • 卸载已经安装的nginx（会保留配置文件，take is easy）:

  • 添加ondrej nginx安装源：

如果出现如下错误：

应该是终端编码问题，尝试使用LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/nginx解决。

  • 更新源，并安装：

从源码安装

修改nginx配置开启http2

设置nginx支持http2最关键是在https端口添加http2指令：

一个网站的参考配置模板如下：

小结

nginx开启http2的支持不要忘记了对openSSL最低版本的要求。其实http2已经不再时髦啦，http2+TLS1.3才是未来，可以参见《低延迟与用户体验杂谈》。后面会讲讲docker+nginx开启http2和TLS1.3的方式，这种方式即可以方便的尝试各个nginx版本，同时也不会破坏本地的nginx环境。