Welcome! Log In Create A New Profile

Advanced

Re: ssl_reject_handshake breaks other server blocks

J Carter
March 01, 2024 03:22AM
Hello,

On Wed, 28 Feb 2024 21:45:37 -0300
Taco de Wolff <tacodewolff@gmail.com> wrote:

> Hi,
>
> I've noticed at least in 1.24.0 and 1.25.4 that adding an
> ssl_reject_handshake to the default server breaks SNI for other
> servers. Example:
>
> ```
> server {
> server_name _;
> listen 80 default_server;
> listen 443 default_server ssl;
> listen 443 default_server quic reuseport;
> listen [::]:80 default_server;
> listen [::]:443 default_server ssl;
> listen [::]:443 default_server quic reuseport;
>
> http2 on;
>
> # SSL
> ssl_certificate /etc/pki/lego/certificates/server.crt;
> ssl_certificate_key /etc/pki/lego/certificates/server.key;
> ssl_trusted_certificate /etc/pki/lego/certificates/server.crt;
> ssl_reject_handshake on;
>
> return 444;
> }
>
> server {
> server_name domain.com;
> listen 443 ssl;
> listen 443 quic;
> listen [::]:443 ssl;
> listen [::]:443 quic;
>
> http2 on;
>
> root /srv/www/html;
>
> # SSL
> ssl_certificate /etc/pki/lego/certificates/server.crt;
> ssl_certificate_key /etc/pki/lego/certificates/server.key;
> ssl_trusted_certificate /etc/pki/lego/certificates/server.crt;
>
> location / {
> try_files /index.html =404;
> }
> }
> ```
>
> There are two remarks for this example:
> - While enabling HTTP/3 I had to add the ssl_certificate lines to the
> default server, while using solely HTTP/2 this wasn't necessary. It
> will throw an error on trying to start Nginx, is that a bug?

TLS is mandatory for HTTP/3 (well, more accurately for QUIC).

https://stackoverflow.com/questions/72826710/quic-transfer-protocol-need-not-tls

> - The ssl_reject_handshake in the default server will prevent proper
> SNI matching for domain.com. If I run `curl https://domain.com/` it
> works fine, but `curl -k -H 'Host: domain.com'
> https://ipaddress-of-server/` does not. When I remove
> ssl_reject_handshake it works as expected
>

If you curl an IP Address rather than an FQDN, curl will not include
SNI extension in client hello at all.

ssl_reject_handshake, as the name suggests, rejects TLS handshakes prior
to completion. Nginx cannot perform secondary search for correct server
block using host/authority header, as that would require first
completing handshake, and then parsing host/authority header.

> My intent is to have a default server that responds to non-existing
> domain names. Preferably it responds with 444, but requests over TLS
> (such as old domains names with HTST) will throw a security warning
> that the server's certificates don't match the request's virtual
> host's domain name (as expected).
>

return 444; just a special return value that causes nginx to terminate
connection, nothing get's sent back to the client at all. return
directives (rewrite module more accurately) runs post TLS handshake
though. For default server TLS connections with your present
configuration - it will never get to that point.

Generally ssl_reject_hanshake is preferable for terminating connections
anyway, as it saves performing heavy TLS handshake.

The return 444 is still relevant for plain text connections that reach
your default server though, so I'd recommend still keeping it.

> Instead of showing a security warning in the browser I prefer a
> connection error, which is why I want to employ ssl_reject_handshake.

Your present configuration should work fine then.

> Kind regards,
> Taco de Wolff
_______________________________________________
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

ssl_reject_handshake breaks other server blocks

Taco de Wolff February 28, 2024 07:46PM

Re: ssl_reject_handshake breaks other server blocks

J Carter March 01, 2024 03:22AM

Re: ssl_reject_handshake breaks other server blocks

Taco de Wolff March 02, 2024 07:56AM

Re: ssl_reject_handshake breaks other server blocks

J Carter March 02, 2024 01:52PM

Re: ssl_reject_handshake breaks other server blocks

Taco de Wolff March 02, 2024 05:58PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 190
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready