F5 NGINX Plus R33 Release Now Available

We’re excited to announce the availability of F5 NGINX Plus Release 33 (R33). Based on NGINX Open Source, NGINX Plus is the only all-in-one software web server, load balancer, reverse proxy, content cache, and API gateway.

New and enhanced features in NGINX Plus R33 include:

Licensing Changes in NGINX Plus: Starting with NGINX Plus R33, all customers are required to deploy a JSON Web Token (JWT) license on each commercial NGINX Plus instance. Each instance will also validate its license status, and report F5 NGINX usage to the F5 licensing endpoint for connected customers or to F5 NGINX Instance Manager for offline/air-gapped customers.

Support for Post Quantum Cryptography NGINX Plus R33 announces support for post quantum cryptography in NGINX ensuring long-term data transmission security and allowing enterprises to be prepared for future changes in cryptography.

QuickJS runtime support in NGINX JavaScript : QuickJS is a lightweight, embeddable JavaScript engine that supports the ES2023 specification, provides garbage collection out of the box and offers performance improvements over the existing JavaScript runtime engine. For ease of use, this runtime will co-exist and be delivered as a drop-in replacement to the existing JavaScript runtime in the NGINX JavaScript module.

OCSP Stapling Support in Stream module: NGINX Plus R33 introduces support for Online Certificate Status Protocol (OCSP) stapling and client certificate verification in the stream module.

Rounding out the release are new features and bug fixes inherited from NGINX Open source and updates to the NGINX JavaScript module.

Important Changes in Behavior

Note: If you are upgrading from a release other than NGINX Plus R32, make sure to review the Important Changes in Behavior section in previous NGINX Plus release announcement blogs for all releases between your current version and this one.

Changes to NGINX Licensing

Starting with the NGINX Plus R33 release, a valid JWT license is necessary for NGINX to operate. There is a single JWT license per subscription and it must be placed on each NGINX instance associated with that subscription.

Additionally, all customers are required to report their commercial NGINX usage to F5. By default, your usage report is automatically sent to the F5 licensing endpoint. For network restricted environments, there are options to route the usage report through NGINX Instance Manager.

See here for more details.

Changes to Platform Support

The following changes have been made to supported platforms in this release.

Added Platforms:

Alpine Linux 3.20

Removed Platforms:

CentOS 7 / RHEL 7 / Oracle Linux 7
Alpine Linux 3.16

Deprecated Platforms:

Alpine Linux 3.17
SLES 12

New Features in Detail

Licensing Changes in NGINX Plus:

With the NGINX Plus R33 release, we are introducing notable changes to how NGINX commercial products are licensed. As a pre-requisite, a JWT license is required to be deployed on all NGINX instances. There is a single license per subscription, and it must be installed on all the instances included in that subscription. The license can be obtained from your MyF5 account. Refer the instructions here on how to get your license and deploy it on your NGINX instances.

With the NGINX Plus R33 release, all NGINX customers are also required to report their commercial NGINX usage to F5.

By default, the usage is reported to the F5 licensing endpoint. Refer to the instructions here for connectivity requirements.

For environments where NGINX instances have external network restrictions, the usage must be reported to NGINX Instance Manager which provides both connected and disconnected modes of sending NGINX usage to F5. Refer to the instructions here on how to configure your NGINX instances and send commercial usage telemetry to NGINX Instance Manager.

Refer to NGINX licensing documentation for a complete overview of these changes.

Support for Post Quantum Cryptography:

With the advancement of quantum computing, traditional cryptographic algorithms such as RSA and ECC are becoming vulnerable to potential quantum computer attacks. This necessitates a transition to post-quantum cryptography (PQC), which is resistant to such attacks.

We are pleased to announce initial support for Post Quantum Cryptography (PQC) in NGINX Plus R33.

NGINX provides PQC support using the Open Quantum Safe provider library for OpenSSL 3.x (oqs-provider). This library is available from the Open Quantum Safe (OQS) project. The oqs-provider library adds support for all post-quantum algorithms supported by the OQS project into network protocols like TLS in OpenSSL-3 reliant applications. All ciphers/algorithms provided by oqs-provider are supported by NGINX.

To configure NGINX with PQC support using oqs-provider, follow these steps:

Install the necessary dependencies

sudo apt update
sudo apt install -y build-essential git cmake ninja-build libssl-dev pkg-config

Download and install liboqs

git clone --branch main https://github.com/open-quantum-safe/liboqs.git
cd liboqs
mkdir build && cd build
cmake -GNinja -DCMAKE_INSTALL_PREFIX=/usr/local -DOQS_DIST_BUILD=ON ..
ninja
sudo ninja install

Download and install oqs-provider

git clone --branch main https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local -DOPENSSL_ROOT_DIR=/usr/local/ssl ..
make -j$(nproc)
sudo make install

Download and install OpenSSL with oqs-provider support

git clone https://github.com/openssl/openssl.git
cd openssl
./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl linux-x86_64
make -j$(nproc)
sudo make install_sw

Configure OpenSSL for oqs-provider

/usr/local/ssl/openssl.cnf:
openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect

[default_sect]
activate = 1

[oqsprovider_sect]
activate = 1

Generate post quantum certificates

export OPENSSL_CONF=/usr/local/ssl/openssl.cnf

# Generate CA key and certificate
/usr/local/ssl/bin/openssl req -x509 -new -newkey dilithium3 -keyout ca.key -out ca.crt -nodes -subj "/CN=Post-Quantum CA" -days 365
# Generate server key and certificate signing request (CSR)
/usr/local/ssl/bin/openssl req -new -newkey dilithium3 -keyout server.key -out server.csr -nodes -subj "/CN=your.domain.com"
# Sign the server certificate with the CA
/usr/local/ssl/bin/openssl x509 -req -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -CAcreateserial -days 365

Download and install NGINX Plus

Configure NGINX to use the post quantum certificates

server {

        listen       0.0.0.0:443 ssl;
        ssl_certificate      /path/to/server.crt;
        ssl_certificate_key  /path/to/server.key;
        ssl_protocols TLSv1.3;
        ssl_ecdh_curve kyber768;

        location / {
            return 200 "$ssl_curve $ssl_curves";
        }
    }

QuickJS runtime support in NGINX JavaScript module:

NGINX JavaScript is a unique JavaScript implementation for NGINX and NGINX Plus, designed specifically for server-side use cases and per request processing. It extends NGINX configuration syntax with JavaScript code to implement sophisticated configuration solutions.

Today, the JavaScript runtime engine used in the NGINX JavaScript module is developed and maintained entirely by the NGINX team. While it has its obvious advantages in terms of feature development and prioritization, the rapidly evolving JavaScript specification is a challenging task to keep up with. NGINX JavaScript currently follows ECMAScript 5.1 with elements of ECMAScript 6 and above.

To address spec challenges, we are pleased to introduce preview support for QuickJS runtime in NGINX JavaScript module version 0.8.6. QuickJS is a lightweight, embeddable JavaScript engine that supports the ES2023 specification, provides garbage collection out of the box and improved performance. And to offer best of both worlds, QuickJS will co-exist with NGINX JavaScript runtime and will be available as drop-in replacement in your njs scripts. Full support of the existing functionality will be available in future releases.

For details on how you can leverage QuickJS in your njs scripts and the functions supported today, please refer to our documentation.

OCSP Client Verification and Stapling Support in Stream module:

The Online Certificate Status Protocol (OCSP) is a protocol for checking if an SSL certificate has been revoked. It was created as an alternative to CRL to reduce the SSL negotiation time. With CRL (Certificate Revocation List) the browser downloads a list of revoked certificate serial numbers and verifies the current certificate, which increases the SSL negotiation time. In OCSP, as the client certificates are presented, the browser sends a request to a OCSP URL and receives a response containing the validity status of the certificate.

Today, NGINX Plus supports OCSP client certificate verification and stapling in the http module. In R33, we are bringing the OCSP client certificate verification and stapling support to the stream module as well.

To enable OCSP validation of SSL client certificates, include the new ssl_ocsp directive along with the ssl_verify_client directive (should be set to on or optional), which enables certificate verification.

Syntax:

ssl_ocsp on | off | leaf;
(default is off, the leaf parameter enables validation of the client certificate only.)

OCSP however has two issues - privacy and heavy load on CA’s servers. Since OCSP requires the browser to contact the CA to confirm certificate validity it compromises privacy. The CA knows what website is being accessed and who accessed it. Also, if a HTTPS website gets lots of visitors, the CA’s OCSP server must handle all the OCSP requests made by the visitors.

This is where OCSP stapling comes into play. OCSP stapling is a TLS/SSL extension which aims to improve the performance of SSL negotiation while improving performance and maintaining visitor privacy. With OCSP stapling, the certificate holder (read web server) queries the OCSP server directly and caches the response. This response is “stapled” with the TLS/SSL Handshake via the Certificate Status Request extension response. As a result, the CA’s servers are not burdened with requests and browsers no longer need to disclose users’ browsing habits to any third party.

To enable OCSP stapling, use the ssl_stapling directive.

ssl_stapling on | off;
(default is off)

Refer to the NGINX documentation for details on how to use these and related directives for OCSP certificate verification and stapling in stream context.

Other Enhancements and Bug Fixes in NGINX Plus R33

HTTP Response trailers support

HTTP Response trailers allow senders to add additional fields at the end of a chunked message and can be used to pass additional dynamic content like processing status, digital signatures etc. along with the response body. Refer here for enabling trailers with HTTP/1.1 and use cases where HTTP trailers cannot be used.

Today, trailers are only supported in gRPC proxying using the grpc_pass directive. This enhancement adds support for trailers in proxy_pass as well. A new directive proxy_pass_trailers is introduced which allows passing trailer fields from the proxied upstream to clients.

Sample Configuration

location / {
    proxy_http_version 1.1;
    proxy_set_header Connection "te";
    proxy_set_header TE "trailers";
    proxy_pass_trailers on;
   proxy_pass ...
}

SSL Key Logging

This enhancement allows logging SSL keys created during client and upstream connections to a file. This is useful for troubleshooting cases where you want to decrypt SSL traffic and examine SSL keys. The file is in SSLKEYLOGFILE format and is passed as an argument to the directive.

ssl_key_log, proxy_ssl_key_log, grpc_ssl_key_log and uwsgi_ssl_key_log directives are being introduced in the R33 release to support SSL key logging.

Sample configuration for logging SSL keys to a file:

ssl_key_log /tmp/sslkey.log;
proxy_key_log /tmp/sslkey.log;

Improvements to SSL Client certificate verification

With the NGINX Plus R33 release, the "ssl_client_certificate" directive is no longer required for client SSL certificates verification when using ssl_verify_client directive. This change relaxes the prior requirement to have at least one trusted CA certificate in the ssl_client_certificate directive. All trusted CA certificates can be specified using the ssl_trusted_certificate directive as well, if required.

Bug Fixes:

SSL Certificate Caching: Fixed loading of trusted CA bundles containing entries with duplicate Distinguished Name (DN).

Changes Inherited from NGINX Open Source

NGINX Plus R33 is based on NGINX Open Source 1.27.2 and inherits functional changes, features, and bug fixes made since NGINX Plus R32 was released (in NGINX open source 1.27.0, 1.27.1 and 1.27.2).

Features:

SSL certificates, secret keys, and CRLs are now cached on start or during reconfiguration.
Added support for client certificate validation with OCSP in the stream module.
Added support for OCSP stapling in the stream module.
Added support for proxy_pass_trailers directive in the ngx_http_proxy_module.
The ssl_client_certificate directive now supports certificates with auxiliary information.
Variables support in the "proxy_limit_rate", "fastcgi_limit_rate", "scgi_limit_rate", and "uwsgi_limit_rate" directives.

Changes:

The ssl_client_certificate directive is no more required for client SSL certificates verification.
The stream module handler is no longer mandatory.

Bug Fixes:

New HTTP/2 connections might ignore graceful shutdown of old worker processes.
Reduced memory consumption for long-lived requests when "gzip", "gunzip", "ssi", "sub_filter" or "grpc_pass" directives are used.

Security:

CVE-2024-7347 - Processing of a specially crafted mp4 file by the ngx_http_mp4_module might cause a worker process crash.

For the full list of new changes, features, bug fixes, and workarounds inherited from recent releases, see the NGINX changes .

Changes to the NGINX JavaScript Module

NGINX Plus R33 incorporates changes from the NGINX JavaScript (njs) module version 0.8.7. The following is a list of notable changes in njs since 0.8.4 (which was the version shipped with NGINX Plus R32).

Features

Introduced initial support for QuickJS JavaScript engine.
Added optional nocache flag for js_set directive.
Exposed capture group variables in HTTP module.
Added timeout argument for add(), set(), and incr() methods of a shared dictionary.

Changes

The bytes invalid in UTF-8 encoding are converted into the replacement character in:
- r.variables.var, r.requestText, r.responseText, s.variables.var
- the data argument of the s.on() callback with upload or download event types
- the data argument of the js_body_filter directive.

Bug Fixes

Fixed handling of empty labelled statement in a function.
Fixed Function constructor handling when called without arguments.
Fixed Buffer.prototype.writeInt8() and friends.
Fixed Buffer.prototype.writeFloat() and friends.
Fixed Buffer.prototype.lastIndexOf().
Fixed Buffer.prototype.write().
Fixed maybe-uninitialized warnings in error creation.
Fixed 'ctx.codepoint' initialization in UTF-8 decoding.
Fixed 'length' initialization in Array.prototype.pop().
Fixed handling of encode arg in fs.readdir() and fs.realpath().
Fixed checking for duplicate js_set variables.
Fixed request Host header when the port is non-standard.
Fixed handling of a zero-length request body in ngx.fetch() and r.subrequest().
Fixed heap-buffer-overflow in Headers.get().
Fixed r.subrequest() error handling.
Fixed zlib.inflate().
Fixed String.prototype.replaceAll() with a zero-length argument.
Fixed retval handling after an exception in Array.prototype.toSpliced(), Array.prototype.toReversed(), Array.prototype.toSorted().
Fixed RegExp.prototype[@@replace]() with replacements containing $', $` and strings with Unicode characters.
Fixed a one-byte overread in decodeURI() and decodeURIComponent().
Fixed tracking of argument scope.
Fixed integer overflow in Date.parse().