两步搞定 TLS1.2 + HSTS + HTTP/2 配置

Posted 2023-05-03

参考技术A 之前看到一个安全测评网站： SSL 服务器测试 ，就测了一下，然后发现才 A 级，“强迫症”病发的我想提升到最高级 A+ ，经过一番折腾最后评级如下：

今天晚上闲来无事把资料整理一下，发出来，如果你有兴趣就折腾一下吧～

这是一篇把普通网站升级到 TLS1.2 + HSTS + HTTP/2 的文章，至于什么是 HSTS 之类的自己百度。

TLS1.2 和 HTTP/2 相信大家都熟悉，但是 HSTS 相对来说比较少听到。

HSTS 是 “HTTP Strict Transport Security”（HTTP 严格安全传输）的缩写，开启了这项设置以后，主流浏览器会强制性地使用 HTTPS 来请求资源，能够更加有效地保护你网站和用户的数据安全。

一般情况（未启用 HSTS），浏览器会允许用户在了解了安全风险之后继续使用不安全的连接来访问，但如果启用了 HSTS，则不允许这样做，所以你得有一定要长期使用 HTTPS 的打算，才能启动 HSTS。

首先我的站点负载工具是 nginx，SSL 证书从 Certbot 申请，先克隆仓库，然后生成证书：

域名改你自己的，然后选择第二个模式，安装一些东西，等一会就好了（先关掉占用80端口和443端口的程序，避免冲突，申请结束后再恢复即可）：

生成下面文字即为成功：

为了确保证书更新正常，执行下面这句验证一下：

然后用 openssl 生成一个中间证书，后面的 2048 你可以自己根据服务器性能修改，比如改成 4096 之类的，数值越大加密程度越高：

前面生成的文件不用移动，后面会一步搞定处理这些，那么接下来就好办了，首先新建一个 Nginx 配置文件：

sudo vim ~/nginx/nginx.conf

保存退出，你已经完成了全部准备工作，剩下只需要启动即可。

为什么使用 Docker 来启动 Nginx？因为我懒得重新编译 Nginx 更新 OpenSSL，使用官方的 nginx:alpine 可以马上拥有最新版本的 Nginx 和最新版的 OpenSSL 啊。

如果没有安装 Docker，就先安装吧：

sudo curl -sSL https://get.docker.com/ | sh

然后再安装 Docker-Compose：

新建一个文件叫做 docker-compose.yml：
sudo vim ~/nginx/docker-compose.yml
然后复制粘贴下面内容，修改域名即可。

搞定之后执行 dokcer-compose up -d 就可以跑起来了，现在打开你网站，已经同时启用 TLS1.2 + HSTS + HTTP/2 了！

设置自动更新证书：

HSTS 必须要在浏览器访问过你的网站一次以后才会生效，如果希望提前生效，需要申请 HSTS Preloading List。

目前这个 Preload List 由 Google Chrome 维护，Chrome、Firefox、Safari、IE 11 和 Microsoft Edge 都在使用。如果要想把自己的域名加进这个列表，首先需要满足以下条件：

觉得妥了就去 HSTS Preload List (hstspreload.appspot.com) 这个页面申请。

在唯一一个文本框输入你的网站即可，这个列表是人工审核，因此可能需要一段时间。申请成功之后查询会显示：“Status: example.com is currently preloaded.”

经过将近两个月的时间，域名已经进入正式版 HSTS 列表。

最后提醒一句，如果不能保证你所有域名都使用HTTPS的话请不要使用HSTS，不然浏览器会拒绝打开你的网站。

HTTPS 传输优化详解之动态 TLS Record Size

笔者在过去分析了诸多可以减少 HTTPS 传输延迟的方法，如分布式 Session 的复用；

启用 HSTS，客户端默认开启 HTTPS 跳转；采用 HTTP/2 传输协议；使用 ChaCha20-Poly1305 算法减少移动端 CPU 运算时间等。

通过这些方法，可以在很大程度上优化 HTTPS 在传输上的延迟，给网站用户带来较好的访问体验。

最近笔者又在考虑通过动态调节 TLS Record Size 来减少 HTTPS 传输延迟。

TLS 与 TCP

TLS 协议是由记录层（TLS Record Layer）和握手层（TLS Handshake Layer）组成的，记录层处于协议的最底层，为 TLS 协议提供安全可靠的连接，为高层协议提供数据封装、压缩、加密等基本功能的支持。握手层协议处于记录层协议之上，握手层协议的作用在真正的应用数据传输之前，可以使客户端和服务器互相进行身份认证，协商加密算法以及生成加密密钥。一般来说，最大的 TLS Record 的大小为 16KB，而每个 TLS Record 包含一个 5Byte 的头部。

TCP（Transmission Control Protocol 传输控制协议）是一种面向连接（连接导向）的、可靠的、 基于 IP 的传输层协议。

TLS 是建立在可靠的数据传输的基础之上，运行在 TCP 层之上，一个 TLS Record Size 由多个 TCP 包组成，通过 WireShark 抓包可以看出，一个 TLS Record 大小为 16408 Byte ，被分为了 12 个 TCP 包。

△ WireShark 抓包

动态 TLS Record Size 调整原理

Nginx 默认的 ssl_buffer_size 大小为 16KB（不支持动态调整），这就是一个 TLS Record Size 的大小。举例说明， 假如资源文件的大小为 1600KB，那么就会被拆分为 100 个 TLS Record 传送到客户端。

在传输过程中此时会出现这样的问题：

1. TLS Record Size 越大，被拆分的 TCP 包会过多，在传输过程中，如果 TCP 出现丢包情况，那么 TLS Record 到达客户端的时间就会变长，而客户端必须等到收到完整的 TLS Record 才能够进行解密；TLS Record 及 TCP 包的关系如下图所示：

△ 图片来源：igvita.com

2. 如果 TLS Record Size 较小，则 TCP 丢包对 TLS Record 的影响就较小了，但是于此同时，TLS Record 头部就变多了，可能还会降低连接的吞吐量。

综上所述，可以知道切割过小的 Record Size 会产生额外的消耗；而切割过大的 Record Size 会导致延迟。笔者认为可以根据 TCP 窗口大小来合理调整 TLS Record 大小可以有效降低 HTTPS 传输时造成的延迟。

如何进行 Record Size 大小调整

根据以上的论点，我们可以得出这样的结论：在 TCP 慢启动的过程中，可以将 TLS Record Size 调整小点；因为这个过程中 TCP 链接的拥塞窗口（cwnd ）较小，TCP 链接的吞吐量也较小；在 TCP 连接结束慢启动之后，TLS Record 的大小可以增大一些，随着时间的推移，最终将 TLS Record 的大小调整到最大（也即 16KB）。

大致的算法规则为：

1. 在新连接以及 TCP 慢启动阶段，将 TLS Record 大小调整为大约 1 个 TCP 包的大小；
2. 在一定的阶段，也即发送一定数量的 Record Size 之后，采用较大的 TLS Record Size ；
3. 随着时间的推移，采用最大的TLS Record Size 大小，也即 16KB。

WireShark 抓包验证

通过 WireShark 抓包，对这个过程进行验证：

阶段一：在刚开始，TLS Record Size 为 1393 Byte。

阶段二：一段时间之后，TLS Record Size 为 4253 Byte。

 

阶段三：最后，TLS Record Size 动态变为 16408 Byte。

上图三个阶段的抓包结果验证了动态 TLS Record Size 的算法规则，通过对动态调节 TLS Record Size 可以有效降低 HTTPS 传输时的延迟，为客户带来更好的体验。

目前，又拍云 CDN 平台已经完全支持动态调整 TLS Record Size ，对网站速度有更高要求的朋友可以通过开启又拍云 CDN，来使用动态 TLS Record Size，让网站传输速度更快，给用户更好的体验。

 

推荐阅读：

从 HTTP 到 HTTPS 再到 HSTS

HTTPS系列干货（一）：HTTPS 原理详解