宣布推出 NGINX Plus R17

[编辑– NGINX Plus 的NGINX ModSecurity WAF模块于2022 年 4 月 1 日正式停止销售，并将于2024 年 3 月 31 日停止使用。 有关更多详细信息，请参阅我们博客上的“F5 NGINX ModSecurity WAF 正在过渡到终止使用<.htmla>”。]

我们很高兴地宣布NGINX Plus Release 17 (R17)现已推出。 NGINX Plus 是唯一集负载均衡器、内容缓存、Web 服务器和 API 网关于一体的产品。 NGINX Plus 基于 NGINX 开源，并包含独有的增强功能和屡获殊荣的支持。

此版本中的新功能支持 TLS 1.3 ，这是负责互联网上所有安全流量的协议的最新版本。 TLS 1.2 发布已有 10 多年了，自那时起发生了很多变化。 TLS 1.2 中发现了许多安全漏洞，例如 FREAK、Heartbleed、POODLE 和 ROBOT。 许多漏洞是由于 TLS 1.2 中有太多不安全的配置选项导致网站容易受到攻击。

TLS 1.3 是通过减法来实现的。 许多不安全的密码已被删除，并且 Diffie-Hellman 密钥交换现在是强制性的。 结果是 TLS 变得更精简、更快、更安全。 截至撰写本文时，Alpine Linux 3.9、FreeBSD 12.0 和 Ubuntu 18.10 均支持 TLS 1.3，因此您可以在生产环境中将它们与NGINX Plus R17一起使用以实现 TLS 1.3；其他操作系统供应商无疑将在未来的版本中支持 TLS 1.3。 请注意， F5 BIG-IP和其他硬件负载均衡器目前不完全支持 TLS 1.3。

NGINX Plus R17还包括以下新功能：

• 两阶段速率限制——速率限制是 NGINX Open Source 和 NGINX Plus 中最受欢迎的功能之一。 它可用于减轻 DDoS 攻击，并通常保护应用服务器不因过多请求而无法承受。 新的延迟参数有助于 NGINX Plus 速率限制更好地适应典型的浏览器请求模式。 现在可以结合现有的延迟和拒绝执行方法，提供两阶段速率限制，即首先延迟过多的请求，如果仍然超过速率限制，则最终拒绝请求。
• 更简单的 OpenID Connect 配置– 在NGINX Plus R15中，我们引入了OpenID Connect 集成，使我们的客户能够向他们的应用添加单点登录 (SSO)。 在 R17 中，我们简化了配置以自动从身份提供商 (IdP) 获取 JSON Web 密钥 (JWK)。
• NGINX Modsecurity WAF 速度快 2 倍- NGINX ModSecurity WAF 是基于 ModSecurity v3 的 NGINX Plus 动态模块，可提供针对第 7 层攻击的强大保护。 ModSecurity 正在积极开发中，最新版本的 NGINX ModSecurity WAF 提供了 2 倍的更好性能和许多其他改进。

NGINX Plus R17中的其他增强功能包括与上游的 TCP 保持连接、集群环境中的 SNI 支持等。

行为方面的重要变化

• NGINX Plus R13引入了全新的NGINX Plus API，用于指标收集和上游组的动态重新配置，取代了之前实现这些功能的 Status 和 Upstream Conf API。 正如当时宣布的那样，弃用的 API 仍然可用并支持相当长的一段时间，直到NGINX Plus R16才结束。 如果您的配置包含status和/或upper_conf指令，则必须在升级到 R17 的过程中将它们替换为api指令。

  有关迁移到NGINX Plus API 的建议和帮助，请参阅我们博客上的过渡指南，或联系我们的支持团队。

• 支持的新操作系统：

  • Alpine Linux 3.8
  • Alpine Linux 3.9
  • FreeBSD 11.2
  • FreeBSD 12.0
  • SUSE Linux Enterprise Server 15
  • Ubuntu 18.10（宇宙）

• 已删除或计划删除的旧操作系统：

  • FreeBSD 10.4 和 11.1 不再受支持。
  • NGINX Plus R18将不再支持 CentOS/Oracle/RHEL 7.3 及更早版本。
  • NGINX Plus R19将不再支持 Ubuntu 14.04。

新功能详情

TLS 1.3： 减法加法

自 TLS 进行重大更新以来已经过去了 10 多年。 TLS 1.2 于 2008 年 8 月定义为RFC 5246 ，自那时起互联网发生了重大变化。 TLS 1.3 于 2018 年 8 月被批准为RFC 8446，以帮助解决 TLS 1.2 中发现的许多问题并为未来奠定一个更具可扩展性的平台。

更安全

多年来，TLS 1.2 中披露了许多安全漏洞，例如FREAK 、 Heartbleed 、 POODLE和ROBOT 。 例如，FREAK 允许攻击者降级 TLS 连接以使用密钥长度为 40 位的导出密码，这种密码可以被暴力破解。 TLS 1.3 完全删除了出口密码。

TLS 1.2 及更早版本规范中出现的许多问题都是由于用户可配置选项数量过多造成的。 选项的误用常常会导致不安全的配置，而这可能会被攻击者利用。 TLS 1.3 删除了许多以下选项：

• AES‑CBC
• 任意 Diffie‑Hellman 群
• 导出密码
• 数据加密标准/3DES
• MD5
• PKCS#1 v1.5 填充
• RC4
• RSA 密钥传输（Diffie-Hellman 是强制性的）
• SHA-1

更好的性能

删除列表中值得注意的是 RSA 密钥传输。 使用这种模式主要是因为它比 Diffie‑Hellman 更快，因为 Diffie‑Hellman 需要额外的往返才能建立具有完美前向保密 (PFS) 的连接。 有了 TLS 1.3，额外的往返就不再需要了。 配置选项越少，需要交换的信息就越少，并且 Diffie-Hellman 握手只需一次往返即可完成（该图还显示了握手后的GET请求）。

此外，TLS 1.3 支持会话恢复，通过消除客户端返回以前访问的站点时重复 TLS 握手的开销，可以加快连接建立速度。 这也称为0‑RTT（零往返时间）恢复，因为在恢复会话时客户端和服务器之间不需要来回传递握手消息。 会话恢复是通过在原始会话期间创建共享秘密并将其存储在会话票证中来实现的。 当客户端返回时，它会出示会话票证及其请求，该请求使用票证中的共享机密进行加密。

使用 0‑RTT 存在重放攻击的风险，如下所示。 在这种情况下，攻击者重新发送导致状态改变的数据包，例如在两个银行账户之间转账的请求。

为了防止重放攻击，客户端在 0‑RTT 数据（使用共享机密加密的数据）中应发送的唯一 HTTP 请求类型是GET 。 HTTP GET请求按照定义是幂等的（ RFC 7231 ），因此重放它们没有效果。 加载页面通常是客户端重新访问网站时做的第一件事，并且大多数页面加载都是从GET请求开始的，因此启用会话恢复可以加快大多数网站的大部分请求速度。 但是，在将 NGINX Plus 部署为 API 网关时，您可能不想启用 0-RTT 恢复，因为对于 API 流量，恢复的 TLS 会话更有可能包含非幂等请求类型。

TLS 1.3 本身也通过在会话票证和客户端请求中包含时间信息来防止重放攻击，这使得服务器能够确定请求是否在客户端发送请求后合理地迅速从客户端到达。 攻击者无法改变时间信息，因此如果请求花费太长时间才到达，则很可能被重放。

如何在 NGINX Plus 中启用 TLS 1.3

默认情况下未启用 TLS 1.3 和 0-RTT。

要启用 TLS 1.3，请将TLSv1.3参数添加到ssl_protocols指令中。 我们建议您还包括TLSv1.2 ，因为在撰写本文时并非所有浏览器都支持 TLS 1.3（请参阅下一部分）。 如果客户端支持 TLS 1.3，NGINX Plus 就会使用 TLS 1.3，否则则会回退到 TLS 1.2。

要启用 0-RTT，还需要将ssl_early_data指令设置为on 。

此配置可启用以下两个功能：

服务器 { 监听 443 ssl; ssl_certificate /etc/ssl/my_site_cert.pem; ssl_certificate_key /etc/ssl/my_site_key.pem; ssl_protocols TLSv1.2 TLSv1.3 ; ssl_early_data on ; # 启用 0-RTT（TLS 1.3）位置 / { proxy_pass http://my_backend; } }

支持的平台

在服务器端，TLS 1.3 需要 OpenSSL 1.1.1 或更高版本。 截至撰写本文时，只有 Alpine Linux 3.9、FreeBSD 12.0 和 Ubuntu 18.10 附带 OpenSSL 1.1.1。

在客户端，我们推荐使用 Chrome 70 或 Firefox 63。 它们支持 TLS 1.3 的最终版本，但默认不启用它；按照这些说明在浏览器中启用 TLS 1.3 。 截至撰写本文时，其他流行的浏览器（包括适用于 Android 的 Firefox 和适用于 iOS 和 Mac 的 Safari）尚不支持 TLS 1.3。 有关最新状态信息，请参阅我可以使用： TLS 1.3 。

两阶段速率限制

以前，NGINX Plus 可以通过两种方式强制限制请求速率：立即拒绝过多的请求，或者将过多的请求排队，直到它们能够按照定义的速率限制进行处理。 使用NGINX Plus R17 ，您可以将两种实施方法结合起来，实现两阶段速率限制，即最初延迟过多的请求，如果仍然超出速率限制，则最终拒绝请求。

在应用速率限制时，必须考虑合法客户端的典型行为。 例如，Web 浏览器通常会尝试同时下载多个资源，因此看到对 HTML 内容的请求，紧接着是样式表、JavaScript 代码和图像的请求，这是合理的。 因此，我们可能希望在应用速率限制之前允许 10 到 20 个快速请求的突发。

使用NGINX Plus R17，您现在可以允许突发流量来适应典型的 Web 浏览器请求模式，然后将额外的过度请求延迟到一定程度，超过该程度，额外的过度请求将被拒绝。 使用limit_req指令中的新delay参数可以启用两阶段速率限制。

为了说明两阶段速率限制，这里我们配置 NGINX Plus 来保护网站，通过施加每秒 5 个请求的速率限制 ( rate=5r/s )。 该网站通常每页有 4-6 个资源，并且不会超过 12 个资源。 该配置允许最多 12 个请求的突发，其中前 8 个请求会立即处理。 超过 8 次请求后会添加延迟，以强制执行 5 r/s 的限制。 超过 12 次请求后，任何进一步的请求都会被拒绝。

limit_req_zone $binary_remote_addr zone=ip:10m rate=5r/s;
服务器 {
listen 80;
位置 / {
limit_req zone=ip burst=12 delay=8;
proxy_pass http://website;
}
}

延迟参数定义了在突发大小内，过多的请求被限制（延迟）以符合定义的速率限制的点。 使用此配置，以 8 r/s 的速度发出连续请求流的客户端将遇到以下行为。

前 8 个请求（ delay的值）由 NGINX Plus 代理，无延迟。 接下来的 4 个请求（突发-延迟）被延迟，以便不超过定义的 5 r/s 的速率。 由于已超出总突发大小，接下来的 3 个请求将被拒绝。 后续请求将被延迟。

请注意，此图是对该过程的简化描述，因为它忽略了已完成的请求对计算正在处理的超额请求数量的影响。 实际上，每个完成的请求都会在延迟队列中开辟一个槽，以便另一个额外的请求适应配置的突发大小。 有关速率限制实施的更多信息，请参阅我们博客上的使用 NGINX 和 NGINX Plus 的速率限制。

更简单的 OpenID Connect 配置

在执行 JWT 验证时，现在可以将NGINX Plus R17配置为从新auth_jwt_key_request指令指定的远程位置（通常是身份提供者或 IdP）获取 JSON Web 密钥（JWK）集。 与频繁轮换密钥的 IdP 集成时，自动获取特别方便。

大多数 IdP 都提供一个固定的 URL，可以通过该 URL 获取当前的密钥集，尤其是在它们支持OpenID Connect Discovery 的情况下；在这种情况下，密钥的 URL 由jwks_uri值定义。

# 创建一个目录来缓存从 IdPproxy_cache_path /var/cache/nginx/jwk 收到的密钥 levels=1 keys_zone=jwk:1m max_size=10m;

server {
listen 80; # 在生产中使用 SSL/TLS

location / {
auth_jwt "closed site";
auth_jwt_key_request /_jwks_uri; # 密钥将由子请求获取

proxy_pass http://my_backend;
}

location = /_jwks_uri {
internal;
proxy_cache jwk; # 缓存响应
proxy_pass https://idp.example.com/oauth2/keys; # 从这里获取密钥
}
}

可以使用附加缓存指令来覆盖子请求返回的Expires和Cache-Control标头。 使用proxy_cache_use_stale使得 NGINX Plus 在密钥 URL 不可用时能够继续使用缓存的密钥。

我们的OpenID Connect 参考实现已更新，包括对auth_jwt_key_request的支持以及支持 OpenID Connect Discovery 的 IdP 的自动配置。

JWT 支持也已扩展，以支持Edwards 曲线数字签名算法(EdDSA) 的两种变体： Ed448 和 Ed25519。 请注意，EdDSA 需要 OpenSSL 1.1.1 或更高版本，在撰写本文时仅在 Ubuntu 18.10 和 FreeBSD 12.0 中可用。

笔记： OpenID Connect 支持是 NGINX Plus 独有的。

速度提升 2 倍的 NGINX ModSecurity WAF

NGINX Plus 的NGINX ModSecurity WAF模块是我们支持的开源 ModSecurity Web应用防火墙 (WAF) 版本，有超过一百万个站点在使用。 我们正在积极与 TrustWave SpiderLabs 团队合作，通过 NGINX Plus 提高 ModSecurity 的性能，并很高兴地报告最新版本的性能比以前的版本提高了两倍。

此版本还增加了对pdateActionById 、 ctl:requestBodyProcessor=URLENCODED和setenv操作的支持。

新的 NGINX ModSecurity WAF 构建基于 ModSecurity 3.0.3；有关更多详细信息，请参阅TrustWave SpiderLabs 博客。

笔记： NGINX ModSecurity WAF 是 NGINX Plus 独有的。

NGINX Plus R17中的其他新功能

向上游发送 TCP Keepalive

新的proxy_socket_keepalive指令控制是否在 NGINX Plus 和代理服务器之间启用 TCP keepalive。 TCP 保持连接可提高协议（如 WebSocket）的性能，其中 NGINX 和代理服务器之间存在状态 TCP 网络设备，并且连接长期存在且经常处于空闲状态。 如果没有 TCP 保持连接，此类设备可能会更频繁地关闭空闲的 TCP 连接，从而产生从头开始重新建立连接的开销。

该指令也可在FastCGI 、 gRPC 、 memcached 、 SCGI和uwsgi模块中使用。

上游 HTTP Keepalive 超时和请求上限

新的keepalive_timeout指令设置 NGINX Plus 和代理服务器之间的 HTTP 保持连接关闭之前的最大空闲时间。 此外， keepalive_requests指令设置了可通过保持连接发送的最大请求数（此时该连接将关闭并创建一个新的连接）。

有限的上游 UDP 会话大小

新的proxy_requests指令（Stream 模块）设置在创建新的 UDP“会话”之前从 NGINX Plus 发送到代理服务器的最大 UDP 数据包数量。 当单个客户端在短时间内发送大量 UDP 数据包时（例如，在存在下游代理的情况下可能会发生这种情况），这可以提供更均匀的 UDP 数据包负载均衡。

集群状态共享增强

在集群中使用状态共享时，您现在可以进行服务器名称验证，在连接到集群节点时使用 SNI 传递服务器名称。 这是通过zone_sync_ssl_name和zone_sync_ssl_server_name指令实现的。

笔记： 集群和zone_sync模块是 NGINX Plus 独有的

NGINX Plus 生态系统更新

Ingress 控制器增强功能

Kubernetes 官方 NGINX Ingress Controller 已更新至 1.4.0 版本。 变更日志列出了所有更改、修复和增强功能，其中最值得注意的已在我们的博客上重点介绍：

• 扩展 Prometheus 支持
• TCP/UDP 负载均衡
• 随机两种选择负载平衡算法是新的默认算法
• 自定义注释

在我们的网站和GitHub repo上了解有关 Kubernetes 的官方 NGINX Ingress Controller 的更多信息。

JavaScript 模块增强功能

NGINX Plus R17包含多项增强功能，扩展了 JavaScript 语言支持的范围：

• 参数对象
• 非整数分数
• 附加时间方法： console.time()和console.timeEnd()
• 现在可以重新声明变量和函数

与 TCP/UDP应用的 NGINX Stream 模块的集成已重构，以使用各种返回函数，包括用于修改入口流量的send()方法。 现在可以通过回调获得出口流量。

完整的更改内容可在NGINX JavaScript 模块更改日志中找到。

升级或尝试 NGINX Plus

NGINX Plus R17包含对 TLS 1.3 的支持，它比 TLS 1.2 更安全且性能更好。 如果您正在运行 NGINX Plus，我们强烈建议您尽快升级到 Release 17 和 TLS 1.3。 您还将获得许多额外的修复和改进，这将帮助 NGINX, Inc. 在您需要提出支持单时为您提供帮助。

在继续升级之前，请仔细查看本博客文章中描述的新功能和行为变化。

如果您还没有尝试过NGINX Plus或NGINX ModSecurity WAF ，我们鼓励您尝试一下 – 用于安全性、负载均衡和 API 网关，或作为具有增强监控和管理 API 的完全支持的 Web 服务器。 您今天即可免费开始使用30 天免费评估版。 亲自了解 NGINX Plus 如何帮助您交付和扩展您的应用。

[编辑– NGINX ModSecurity WAF 于2022 年 4 月 1 日正式停止销售，并将于2024 年 3 月 31 日停止使用。 有关更多详细信息，请参阅我们博客上的“F5 NGINX ModSecurity WAF 正在过渡到终止使用<.htmla>”。]