The change introduces an SNI based virtual server selection during early ClientHello processing. The callback is available since OpenSSL 1.1.1; for older OpenSSL versions, the previous behaviour is kept. Using the ClientHello callback sets a reasonable processing order for the "server_name" TLS extension. Notably, session resumption decision now happens after applying server configuration chosen by SNI, useful with enabled verification of client certificates, which brings consistency with BoringSSL behaviour. The change supersedes and reverts a fix made in 46b9f5d38 for TLSv1.3 resumed sessions. In addition, since the callback is invoked prior to the protocol version negotiation, this makes it possible to set "ssl_protocols" on a per-virtual server basis. To keep the $ssl_server_name variable working with TLSv1.2 resumed sessions, as previously fixed in fd97b2a80, a limited server name callback is preserved in order to acknowledge the extension. Note that to allow third-party modules to properly chain the call to ngx_ssl_client_hello_callback(), the servername callback function is passed through exdata.
Found by Coverity (CID 1662016).
The ssl_certificate_compression directive allows to send compressed server certificates. In OpenSSL, they are pre-compressed on startup. To simplify configuration, the SSL_OP_NO_TX_CERTIFICATE_COMPRESSION option is automatically cleared if certificates were pre-compressed. SSL_CTX_compress_certs() may return an error in legitimate cases, e.g., when none of compression algorithms is available or if the resulting compressed size is larger than the original one, thus it is silently ignored. Certificate compression is supported in Chrome with brotli only, in Safari with zlib only, and in Firefox with all listed algorithms. It is supported since Ubuntu 24.10, which has OpenSSL with enabled zlib and zstd support. The actual list of algorithms supported in OpenSSL depends on how the library was configured; it can be brotli, zlib, zstd as listed in RFC 8879.
The gRPC module context has connection specific state, which can be lost after request reinitialization when it comes to processing early hints. The fix is to do only a portion of u->reinit_request() implementation required after processing early hints, now inlined in modules. Now NGX_HTTP_UPSTREAM_EARLY_HINTS is returned from u->process_header() for early hints. When reading a cached response, this code is mapped to NGX_HTTP_UPSTREAM_INVALID_HEADER to indicate invalid header format.
There were a few random places where 0 was being used as a null pointer constant. We have a NULL macro for this very purpose, use it. There is also some interest in actually deprecating the use of 0 as a null pointer constant in C. This was found with -Wzero-as-null-pointer-constant which was enabled for C in GCC 15 (not enabled with Wall or Wextra... yet). Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059>
The functions ngx_http_merge_types() & ngx_conf_merge_path_value() return either NGX_CONF_OK aka NULL aka ((void *)0) (probably) or NGX_CONF_ERROR aka ((void *)-1). They don't return an integer constant which is what NGX_OK aka (0) is. Lets use the right thing in the function return check. This was found with -Wzero-as-null-pointer-constant which was enabled for C in GCC 15 (not enabled with Wall or Wextra... yet). Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059>
The change implements processing upstream early hints response in
ngx_http_proxy_module and ngx_http_grpc_module. A new directive
"early_hints" enables sending early hints to the client. By default,
sending early hints is disabled.
Example:
map $http_sec_fetch_mode $early_hints {
navigate $http2$http3;
}
early_hints $early_hints;
proxy_pass http://example.com;
Passwords were not preserved in optimized SSL contexts, the bug had
appeared in d791b4aab (1.23.1), as in the following configuration:
server {
proxy_ssl_password_file password;
proxy_ssl_certificate $ssl_server_name.crt;
proxy_ssl_certificate_key $ssl_server_name.key;
location /original/ {
proxy_pass https://u1/;
}
location /optimized/ {
proxy_pass https://u2/;
}
}
The fix is to always preserve passwords, by copying to the configuration
pool, if dynamic certificates are used. This is done as part of merging
"ssl_passwords" configuration.
To minimize the number of copies, a preserved version is then used for
inheritance. A notable exception is inheritance of preserved empty
passwords to the context with statically configured certificates:
server {
proxy_ssl_certificate $ssl_server_name.crt;
proxy_ssl_certificate_key $ssl_server_name.key;
location / {
proxy_pass ...;
proxy_ssl_certificate example.com.crt;
proxy_ssl_certificate_key example.com.key;
}
}
In this case, an unmodified version (NULL) of empty passwords is set,
to allow reading them from the password prompt on nginx startup.
As an additional optimization, a preserved instance of inherited
configured passwords is set to the previous level, to inherit it
to other contexts:
server {
proxy_ssl_password_file password;
location /1/ {
proxy_pass https://u1/;
proxy_ssl_certificate $ssl_server_name.crt;
proxy_ssl_certificate_key $ssl_server_name.key;
}
location /2/ {
proxy_pass https://u2/;
proxy_ssl_certificate $ssl_server_name.crt;
proxy_ssl_certificate_key $ssl_server_name.key;
}
}
It was possible to write outside of the buffer used to keep UTF-8 decoded values when parsing conversion table configuration. Since this happened before UTF-8 decoding, the fix is to check in advance if character codes are of more than 3-byte sequence. Note that this is already enforced by a later check for ngx_utf8_decode() decoded values for 0xffff, which corresponds to the maximum value encoded as a valid 3-byte sequence, so the fix does not affect the valid values. Found with AddressSanitizer. Fixes GitHub issue #529.