NGINX Plus R17正式发布

Liam Crilly产品管理高级总监

［编辑：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 Open Source构建，并提供专属增强功能和屡获殊荣的支持服务。

此版本新增对TLS 1.3的支持。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攻击，并在一般情况下保护应用服务器，避免其因请求过多而不堪重负。新的delay参数有助于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 API 和 Upstream Conf API。正如当时所宣布的，已弃用的 API 在相当长一段时间内仍可使用并获得支持，直至 NGINX Plus R16。如果配置中包含 status 和/或 upstream_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 (Cosmic)
• 已移除或计划移除的旧版操作系统：
  • 不再支持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组
• 出口级密码套件
• DES/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 1.3还支持会话恢复。当客户端再次访问之前访问过的站点时，会话恢复无需重复执行TLS握手，从而减少开销，加快连接建立速度。这也称为0‑RTT（零往返时间）恢复，因为恢复会话时，客户端与服务器之间无需来回传递握手消息。会话恢复的实现方式是：在初始会话期间创建共享密钥，并将其存储在会话票证中。当客户端再次访问时，会在发送请求的同时提供会话票证；该请求使用票证中的共享密钥进行加密。

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。

此配置会启用这两项功能：

server {    listen 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; # Enable 0-RTT (TLS 1.3)

    location / {
        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。有关最新支持状态，请参阅Can I Use：TLS 1.3。

两阶段速率限制

此前，NGINX Plus可通过两种方式实施请求速率限制：立即拒绝超量请求，或将超量请求加入队列，直至能够按照定义的速率限制进行处理。借助NGINX Plus R17，可以结合使用这两种实施方式，实现两阶段速率限制：先延迟处理超量请求；如果请求速率最终仍超出限制，则拒绝这些请求。

应用速率限制时，必须考虑合法客户端的典型行为。例如，Web浏览器通常会尝试同时下载多个资源，因此在请求HTML内容后，很快又发出样式表、JavaScript代码和图像请求是正常现象。为此，可以先允许突发的10至20个快速请求，再应用速率限制。

借助NGINX Plus R17，现在可以允许一定数量的突发请求，以适应Web浏览器的典型请求模式；随后将额外的过量请求延迟到设定阈值，超过该阈值的过量请求将被拒绝。通过为delay指令新增的limit_req参数，可启用两阶段速率限制。

为说明两阶段速率限制，下面将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;
server {
    listen 80;
    location / {
        limit_req zone=ip burst=12 delay=8;
        proxy_pass http://website;
    }
}

在突发请求数量范围内，delay参数用于定义从何处开始对超额请求进行限流（延迟），以符合设定的速率限制。采用此配置后，如果客户端以8 r/s的速率持续发送请求，将出现以下行为。

以下参数下的速率限制行为示意图：rate=5r/s burst=12 delay=8

前8个请求（即delay的值）由NGINX Plus代理转发，不会延迟。接下来的4个请求（burst - delay）会被延迟，以免超过设定的5 r/s速率。再接下来的3个请求因超出总突发大小而被拒绝。后续请求会被延迟。

请注意，此图对该过程进行了简化说明，因为在计算正在处理的超额请求数量时，它忽略了已完成请求的影响。实际上，每完成一个请求，延迟队列中就会空出一个位置，使另一个超额请求能够纳入配置的突发大小范围内。有关限速实现的更多信息，请参阅我们博客中的《使用NGINX和NGINX Plus进行限速》。

更轻松地配置OpenID Connect

执行JWT验证时，现在可以配置NGINX Plus R17，使其从新指令auth_jwt_key_request所指定的远程位置（通常是身份提供商，即IdP）获取JSON Web密钥（JWK）集。与频繁轮换密钥的IdP集成时，自动获取功能尤其方便。

大多数IdP都会提供一个固定URL，用于获取当前密钥集，尤其是在支持OpenID Connect Discovery的情况下；此时，密钥URL由jwks_uri值定义。

# Create a directory to cache the keys received from IdPproxy_cache_path /var/cache/nginx/jwk levels=1 keys_zone=jwk:1m max_size=10m;

server {
    listen 80; # Use SSL/TLS in production

    location / {
        auth_jwt "closed site";
        auth_jwt_key_request /_jwks_uri; # Keys will be fetched by subrequest

        proxy_pass http://my_backend;
    }

    location = /_jwks_uri {
        internal;
        proxy_cache jwk; # Cache responses
        proxy_pass https://idp.example.com/oauth2/keys; # Obtain keys from here
    }
}

可以使用其他缓存指令覆盖子请求返回的Expires和Cache-Control标头。使用proxy_cache_use_stale后，当密钥URL不可用时，NGINX Plus仍可继续使用缓存的密钥。

我们的OpenID Connect参考实现已更新，新增了对auth_jwt_key_request的支持，并可自动配置支持OpenID Connect Discovery的IdP。

JWT支持也已扩展，可支持爱德华兹曲线数字签名算法（EdDSA）的两种变体：Ed448和Ed25519。请注意，EdDSA需要OpenSSL 1.1.1或更高版本；截至本文撰写时，该版本仅在Ubuntu 18.10和FreeBSD 12.0中提供。

注意：仅NGINX Plus支持OpenID Connect。

NGINX ModSecurity WAF速度提升至2倍

适用于NGINX Plus的NGINX ModSecurity WAF模块是我们为开源ModSecurity Web应用防火墙（WAF）提供的受支持版本，该防火墙已被超过100万个网站采用。我们正积极与TrustWave SpiderLabs团队合作，提升ModSecurity与NGINX Plus配合使用时的性能。最新版本的性能已达到以往版本的2倍。

NGINX WAF 可防御第 7 层攻击

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

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

注意： NGINX ModSecurity WAF仅适用于NGINX Plus。

NGINX Plus R17 的其他新功能

到上游的TCP保活

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

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

上游HTTP长连接超时时间和请求数上限

新的keepalive_timeout指令用于设置NGINX Plus与代理服务器之间的HTTP keepalive连接在关闭前的最长空闲时间。此外，keepalive_requests指令用于设置可通过keepalive连接发送的最大请求数（达到该数量后，连接将关闭并创建新连接）。

有限的上游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 Controller 增强功能

官方 NGINX Ingress Controller for Kubernetes 已更新至版本 1.4.0。变更日志列出了所有变更、修复和增强功能，其中较为重要的内容已在我们的博客中重点介绍：

• 扩展了对Prometheus的支持
• TCP/UDP负载均衡
• “二选一随机”负载均衡算法现已成为新的默认算法
• 自定义注解

在我们的网站和GitHub代码仓库中详细了解适用于Kubernetes的官方NGINX Ingress Controller。

JavaScript模块增强功能

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

• arguments 对象
• 非整数分数
• Additional time methods: console.time() and console.timeEnd()
• 现在可以重新声明变量和函数

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

完整的变更内容可参阅NGINX JavaScript Module changelog。

升级或试用NGINX Plus

NGINX Plus R17新增了对TLS 1.3的支持。与TLS 1.2相比，TLS 1.3更安全，性能也更出色。如果您正在运行NGINX Plus，强烈建议尽快升级到Release 17和TLS 1.3。升级后还可获得多项其他修复和改进，并有助于NGINX, Inc.在您需要提交支持工单时提供协助。

升级前，请仔细查看本博文中介绍的新功能和行为变更。

如果您尚未试用NGINX Plus或NGINX ModSecurity WAF，不妨亲自体验。它们可用于安全防护、负载均衡和API网关，也可用作获得全面支持的Web服务器，并提供增强的监控和管理API。立即通过30天免费试用开始体验，了解NGINX Plus如何帮助您交付应用并实现扩展。

［编辑注：NGINX ModSecurity WAF已于2022年4月1日正式停止销售，并将于2024年3月31日终止生命周期。有关更多详情，请参阅博客文章《F5 NGINX ModSecurity WAF即将终止生命周期<.htmla>》。］

关于作者

Liam Crilly产品管理高级总监

Liam Crilly 的更多博客文章