HTTPS基础原理和配置-3

技术分享 2年前 (2023-02-16) 0 999+

关注

书接上文：HTTPS 基础原理和配置 - 2，接下来介绍：

配置 NGINX
后端 HTTPS
检查配置
配置 HSTS
OCSP Stapling

重要部分来了。如何使用这些选项并配置NGINX?

一、NGINX 的 HTTPS 配置

这里有一些基本的原语（或叫做指令），你可以使用:ssl_certificate、ssl_certificate_key、ssl_protocols 和ssl_ciphers。

1.1 NGINX 配置参数（OpenSSL）

在开始之前: NGINX 处理 TLS 的方式是使用 OpenSSL，我相信你已经在新闻中听说过这个库。它因 Heartbleed 和其他一些漏洞而闻名。它确实是最广泛使用的内置加密库。这是 NGINX 用于加密的。

因此，在服务器上要做的一件事是检查正在使用的 OpenSSL 版本。你可能不想使用 0.9.8 之类的版本。你希望在1.0.1p 或 1.0.2 范围内使用，因为多年来他们已经修复了许多 bug。你永远不知道下一个 OpenSSL 漏洞什么时候出现，但至少现在它是非常可靠的(1.0.1p)。它还拥有所有现代加密算法。

1.2 NGINX 配置证书链和私钥

所以，当你在 NGINX 中设置你的服务器部分时，ssl_certificate 就是你的证书链。这是你的证书加上所有的信任链一直到根证书。然后你还需要提供你的私钥。

ssl_certificate_key 就是你的私钥。

server {     listen 443 ssl http2;     listen [::]:443 ssl http2;      ssl_certificate /path/to/signed_cert_plus_intermediates;     ssl_certificate_key /path/to/private_key;     ssl_session_timeout 1d;     ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions     ssl_session_tickets off;      # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam     ssl_dhparam /path/to/dhparam;      # intermediate configuration     ssl_protocols TLSv1.2 TLSv1.3;     ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;     ssl_prefer_server_ciphers on; }

1.3 额外选项

你还可以添加一些与会话恢复有关的额外选项。如前所述，当你第一次建立 TLS 连接时，需要额外的两次往返，因为你必须完成整个握手和交换证书。如果你以前连接过一个客户端，并且他们已经缓存了会话传输所使用的密钥，那么你可以只恢复该会话。这是一个称为会话恢复的特性。

你只需要一个超时来说明你希望将会话保留多长时间，以及这些会话的缓存可以有多大。在本例中，默认是 10 MB 的会话;那应该够你用很长时间了。共享缓存是首选，因为这样你就可以在所有 NGINX worker 之间共享它们。

例如，如果你的一个 worker 是最初建立连接的那个，而第二个连接被建立到另一个 NGINX worker，你仍然可以恢复连接。还有另一个选项叫做「session ticket」。它只在 Chrome 内核浏览器和 Firefox 中使用，但本质上是一样的。你必须生成一个随机的 48 字节文件，但我建议暂时只使用会话缓存。

1.4 NGINX 的协议和密码配置

作为一个非常明显的下一步，你必须列出希望支持的协议和密码。在这种情况下，上文是 Mozilla 推荐的密码，以及从 1.2 版到 1.3 版的 TLS 协议。

1.5 其他

我提到过你如何协商你选择的密码; 你可以选择客户端的选择或服务器的选择。最好选择服务器的选择。这里有一个指令: ssl_prefer_server_ciphers——始终打开它。

1.6 同一证书多域

如果你有多个站点，并且它们使用相同的证书，那么你实际上可以分解 HTTP 定义。你可以在顶层使用 SSL 证书，在底层使用不同的服务器。这里你需要记住的一件事是如果你有 example.com 和 example.org ，你必须有一个证书对这两个名字都有效，这样才能工作。

ssl_certificate		multiSAN.crt; ssl_certificate_key	multiSAN.key;  server {     listen			443 ssl;     server_name		www.example.com;     ... }  server {     listen			443 ssl;     server_name		www.example.org;     ... }

以上基本上就是为 NGINX 设置 HTTPS。

二、后端 HTTPS

更高级的话题是:如何使用 NGINX 作为其他 HTTPS 服务的代理?

我们称之为后端加密。所以，你的访客访问你的 NGINX 服务器是完全加密的。NGINX 背后发生了什么? 在这种情况下，NGINX 必须充当浏览器访问你的后端服务。

2.1 NGINX 后端配置

这可以在 NGINX 中以类似的方式配置。也有类似于 ssl_protocols 和 ssl_ciphers 的指令; 在本例中，你将它放在一个代理下。NGINX 作为客户端将使用 proxy_ssl_protocols 和 proxy_ssl_cipher 指令。

http {     server {         proxy_ssl_protocols		TLSv1.2 TLSv1.3;	# 协议         proxy_ssl_ciphers		ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;	# 密码套件         proxy_ssl_trusted_certificate	/etc/ssl/certs/trusted_ca_cert.crt;	# 受信任的 CA                  proxy_ssl_verify		on;         proxy_ssl_verify_depth	2;         proxy_ssl_session-reuse	on;     } }

我建议使用完全相同的密码套件和协议集。这里的主要区别是客户端对服务器进行身份验证。所以，在浏览器的情况下，你有一组你信任的证书颁发机构，而 NGINX 作为客户端，你也需要一组你信任的证书颁发机构。

2.2 受信任的 CA 的选项

你可以使用两种不同的理念来实现这一目标，一种是创建你自己的内部证书颁发机构并在内部管理它。这有点棘手，但它更便宜，也更容易管理，因为你可以为任何服务颁发证书，并将它们颁发给你拥有并完全控制的证书颁发机构。在这种情况下，proxy_ssl_trusted_certificate 将被设置为你的证书颁发机构。

或者，你可以使用我在上一篇文章中描述的相同技术。你可以为你所有的服务购买证书，然后如果你的NGINX需要信任它们，它可以信任浏览器信任的同一套证书颁发机构。

对于 Ubuntu，磁盘上有一个列表，里面包含了几乎所有平台的所有证书。但是，如果你正在构建一组需要相互通信的大型服务，那么就很难为这些域颁发证书。你必须向证书颁发机构证明所有权才能实际获得证书。

我推荐内部 CA 机制。最困难的部分是——如何保证证书颁发机构的安全? 如何保证证书颁发机构的私钥的安全? 你可以通过使用脱机计算机和特殊管理员来实现这一点，但无论哪种情况，都存在一些挑战。

三、检查配置

NGINX 设置了 HTTPS。如何检查它的配置是否正确?

SSL Labs 是人们最喜欢的网站检查工具之一。SSL Labs 是 Qualys 运营的一个网站; 你只要输入你的域名，它就会运行所有类型的浏览器，所有类型的 SSL 连接，它会告诉你哪些设置正确，哪些设置错误。

在本例中，我们检查了一个名为 badSSL.com 的网站，它列举了所有可能导致 HTTPS 配置混乱的不同方法。你可以用 SSL Labs 扫描每一个，它会告诉你每一个有什么问题。在本例中，给出的等级是 C，因为它支持 SSL v3.0。

这里还提到了其他一些东西，你们可以修改，但在我如何设置 NGINX 的描述中，如果你这样设置，你基本上会得到 A。这意味着证书协议支持、密钥交换和密码强度都是顶级的。

3.1 CFSSL 扫描

这对互联网网站非常有效; 如果你有防火墙或 NGINX 后面的服务，CloudFlare 构建了这个叫做 CFSSL 扫描的工具。你可以在内部基础架构中使用它; 它是开源的，在 cloudflare/cfssl: CFSSL: Cloudflare's PKI and TLS toolkit (github.com)上。它将做本质上与 SSL Labs 相同的事情，只是在你的基础设施内。它会告诉你什么是对的，什么是错的。

四、加分项：配置 HSTS

之前提到过得到 A 的方法，那么 A+ 呢?事实证明，SSL Labs 就会给一个 A+，当你有了一个叫做 HSTS (Hypertext Strict Transport Security，超文本严格传输安全) 的特性。

4.1 什么是 HSTS？

本质上，这是一个 HTTP 头，你可以添加到你的请求，告诉浏览器总是通过 HTTPS 访问这个站点。即使他们最初是通过 HTTP 访问的，也总是重定向到 HTTPS。

然而，这实际上有一点危险，因为如果你的 SSL 配置中断或证书过期，那么访问者将无法访问该站点的纯 HTTP 版本。你还可以做一些更高级的事情。就是将你的站点添加到预加载列表中。Chrome 和火狐浏览器都有一个列表，所以如果你注册了，他们就永远不会通过 HTTP 访问你的网站。

4.2 为什么要这么做？

SSL Labs 将给你一个 A+ 如果其他一切正确的。你需要正确地设置 includeSubdomains 的 HSTS(这意味着它适用于所有子域名)，并且它必须有至少 6 个月的有效期，这使得它非常危险。这是因为如果你改变了你的配置，浏览器将会记住这六个月。所以你必须保持你的 HTTPS 配置正常工作。

这是一件好事，因为它可以防止任何人在中间修改它。使用 HSTS，浏览器甚至不会有机会访问你的 HTTP 端，因此人们不会在这方面干扰你的站点。所以 HSTS 是一个非常可靠的方法。

4.3 风险

正如我提到的，有几个风险：

阻止人们通过 HTTP 访问站点
如果 HTTPS 配置异常（比如证书过期），站点就无法访问了

4.4 NGINX 配置 HSTS

server {     listen 443 ssl http2;     listen [::]:443 ssl http2;      ssl_certificate /path/to/signed_cert_plus_intermediates;     ssl_certificate_key /path/to/private_key;     ssl_session_timeout 1d;     ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions     ssl_session_tickets off;      # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam     ssl_dhparam /path/to/dhparam;      # intermediate configuration     ssl_protocols TLSv1.2 TLSv1.3;     ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;     ssl_prefer_server_ciphers off;      # HSTS (ngx_http_headers_module is required) (15768000 seconds)     add_header Strict-Transport-Security "max-age=15768000" always;      # OCSP stapling     ssl_stapling on;     ssl_stapling_verify on;      # verify chain of trust of OCSP response using Root CA and Intermediate certs     ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;      # replace with the IP address of your resolver     resolver 127.0.0.1; }

要设置它，只需在 NGINX 的服务器配置中添加一个头文件，上面写着 Strict-Transport-Security，并给它一个最大时间（max-age）。在本例中，它被设置为6个月(这是预加载列表所需的最低时间)。你还可以在这里添加其他指令，如:includeSubdomains和preload，这意味着可以接受这个指令并将其添加到预加载列表中。这就是得到 A+ 的方法。

五、又一加分项：配置 OCSP 装订（OCSP Stapling）

这是一些人喜欢使用的另一个附加功能，它实际上可以帮助加快连接速度。

5.1 什么是 OCSP Stapling

正如我前面提到的，建立一个TLS连接需要有很多来回的。我没有提到的是，这些证书不仅可以过期失效，还可以被吊销。

因此，如果你丢失了你的私钥，出现了漏洞，或者有其他人非法拥有了你的私钥，那么你必须去你的证书颁发机构并撤销这个密钥。有几种机制可以告诉浏览器证书已被吊销; 它们都有点粗略，但最流行的是 OCSP(Online Certificate Status Protocol，在线证书状态协议)。

发生的情况是: 当浏览器收到证书时，它还必须检查它是否被吊销了。于是它联系了证书颁发机构，问「这个证书还有效吗?」他们会回答「是」或「不是」。这本身就是另一组连接，你需要查找 CA 的 DNS，你需要连接到 CA，这对你的网站来说是额外的减速。

HTTPS 不只需要三次往返，你还需要 OCSP。因此，OCSP 装订允许服务器获取证书未过期的证明。在后台，获取这个表示「是的，证书是好的」的 OCSP 响应，然后将它放入握手中。这样客户端就不需要实际接触 CA 并获取它。

5.2 会快多少？

完整 HTTPS 网站访问过程示例如下：

DNS（1334ms）
TCP 握手（240ms）
SSL 握手（376ms）
跟踪证书链（1011ms）
到 CA 的 DNS 记录（300ms）
到 CA 的 TCP （407ms）
到 CA 的 OCSP 第一次（598 ms）
到 CA 的 TCP 第二次（317ms）
到 CA 的 OCSP 第二次（444ms）
完成 SSL 握手（1270ms）

配置了 OCSP Stapling，上文的 5-9 步可以省略，这可以节省约 30% 的访问一个 HTTPS 网站的连接时间。

5.3 NGINX 配置 OCSP Stapling

见上文（4.4 NGINX 配置 HSTS)，用 NGINX 也很容易设置。有一个 OCSP Stapling 的指令。装订验证（Stapling verify）是指在装订证书之后对其进行验证。正如我前面（2.2 受信任的 CA 的选项）提到的，使用代理，你必须信任 CA。你可以从 CA 获得一个文件，并通过可信证书部分添加到该文件中。