☰

Nginx TLS 性能优化

tag-icon • tag-icon nginx ssl tcp
Nginx TLS 性能优化

上周，我将一个繁忙的网站切换到 TLS-everywhere 和 HTTP/2。性能并没有像预期的那样得到改善。事实上，根据你如何衡量它，你可以说它已经退化了。

在操作系统级别的 TCP 调整、Web 堆栈中的 TLS 配置等方面，还有很大的空间可以进一步优化服务器。为了确保我没有忽略任何需要改进的地方，我在这里发布了我的想法，以便其他人可以参与进来。

目前，SSL conf 显示如下。各方控制着其中的各个元素，我无法直接控制所有内容。域名已审查。

$ openssl s_client -state -CAfile Documents/Thawte\ Server\ CA.cer -connect xxxxxx.tld:443
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
---
Certificate chain
 0 s:/C=xxx
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
 1 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 3 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF1----shZZU
y1kFXCCRo78=
-----END CERTIFICATE-----
subject=/C=xxx
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 6240 bytes and written 328 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES128-SHA
    Session-ID: 09464B1CF8972B08267C33BF255FDA74216728E3599B24EAE02B13642C268483
    Session-ID-ctx: 
    Master-Key: ACC3529AC7C80162797397D4E3041D1720EE4BA6A8BA5D2C200F8B48ADD6960CA9E48D5FF975472A9E8B43B7023CA4E4
    Key-Arg   : None
    Start Time: 1457708322
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
SSL3 alert read:warning:close notify
closed
SSL3 alert write:warning:close notify

我看到的问题：

验证错误：num=19：证书链中的自签名证书

我希望链尽可能短，顺序正确（根据 ssllabs.com 的说法，顺序不正确），并且链中不需要自签名证书。编辑：我发现这实际上是 CA 根证书，它已经在浏览器的信任存储中了。无论如何都应该将其删除。

SSL_connect：SSLv3 读取服务器证书 A SSL_connect：SSLv3 读取服务器密钥交换 A SSL_connect：SSLv3 读取服务器完成 A SSL_connect：SSLv3 写入客户端密钥交换 A SSL_connect：SSLv3 写入更改密码规范 A SSL_connect：SSLv3 写入完成 A SSL_connect：SSLv3 刷新数据 SSL_connect：SSLv3 读取完成 A

我觉得这个握手序列很长。我在其他配置中看到来回次数较少。我希望将往返次数降至最低。

证书链 0、1、2、3 - 由 4 个 (Comodo) 证书组成，大小超过 5.5Kb，因此可能不适合 TCP 拥塞窗口大小（尚未验证）。可能是造成额外往返的原因（？）。

也许值得切换到提供更短链的 CA。有什么建议吗？

密码：DHE-RSA-AES128-SHA

弱 Diffie-Hellman 密码。SSLLabs 补充道：“使用常见的 DH 素数 是 如果可能，请用自定义 DH 参数替换”

我的问题是：

  • 我可以用哪些方法缩短证书链？
  • 我可以通过哪些方式减少握手下载的大小？
  • 我可以通过哪些方式减少握手往返次数？
  • 哪个 CA 提供比 Comodo 更短的链条？
  • 您在这个输出中看到其他问题点了吗？或者我还应该测试什么？
  • 我们可以通过哪些方式优化 Ubuntu 上的 TCP 配置以最大化 TLS 性能/网络吞吐量？
  • 为提高性能，选择密码套件顺序的最佳方法是什么？我运行了 $ openssl speed，但不确定如何解释和操作这些数据。

非常感谢您的见解。

答案1

让我们首先对证书链问题进行分类。这应该可以解决前 4 点。

您将收到来自 Comodo 的证书，并且您还需要更多证书链。证书列表可在以下位置找到这里。您需要检查证书以查明它是由哪个 CA 签署的。

确定 CA 后，下载该软件包并将其放在与发送给您的证书相同的目录中。然后，您需要使用以下命令将它们组合起来

cat name_of_file_you_were_sent name_of_bundle_file > www.example.com.crt

您可能会注意到，最终的 CA 在捆绑包中“缺失”，但这不会阻止您通过 ssllabs 上的这部分测试。

然后，你需要在 nginx 配置中引用此文件以及私钥文件（显然，为了完整性，你已这样做了），使用以下两行配置

ssl_certificate     www.example.com.crt;
ssl_certificate_key www.example.com.key;

测试 nginx 配置，如果一切正常则重新启动

至于其余的配置。

我发现为 nginx 生成 SSL 配置的最佳网站是Mozilla 安全我没有添加示例，因为仅在 serverfault 上就有很多示例

根据您的网站流量，您可以采用中级或现代版本（希望您不需要使用旧版本，如果需要，您可能需要处理这个问题，但这是另一个问题）

您不应该只是复制和粘贴这些配置而不了解这些设置的作用。例如，HSTS 可能会对网站访问者产生长期影响。

虽然这些配置总体上是“安全的”，但它们还可以进一步优化。具体来说

ssl_buffer_size 16k; #Better if you have video
ssl_buffer_size 4k; #Better for quicker first byte.

当然，可能还有一些其他原因导致切换到 http/2 并没有提高您的网站性能。

例如，http/2 打开了更多与服务器的连接。您是否考虑到了这一点并进行了调整worker_processes，worker_connections但上述内容处理了与 nginx 的 SSL 配置部分直接相关的任何内容。

相关内容