Preventing SSL access to an Nginx Server

Question

I have a server that runs multiple virtual hosts. Some of those sites have SSL components and others don't. Today I noticed that if I try to access one of the non-SSL sites via https, Nginx just finds a virtual host that does use SSL and attempts to render it -- giving the familiar "untrusted" warning before doing so.

I've tried several solutions, but none quite work and I've exhausted my Nginx knowledge and/or reading comprehension. Ideally, I'd like to see a 404 error if a site is accessed via a protocol that it doesn't support.

I tried various edits to the default server block, but none worked. I also tried capturing and redirecting port 443 access to that particular site, but that (predictably) failed as well.

Can someone point me in the right direction?

Answer 1

No can do. Without Server Name Indication (SNI), the hostname is part of the encrypted payload. Even with SNI, a browser won't accept a redirect from a HTTPS URL without first going through the HTTPS handshake + validation process.

If you want, you could use two IP addresses, one for your secure site and one for the non-secure sites, and only listen to 443 on the secure IP.

Answer 2

I don't think any of the other answers covers the whole story:

What you want to do is possible for a server to do, because of SNI. However, nginx, even though it supports SNI, does not support doing what you want to do. nginx will react to an unmatched SNI name by treating the request as if it's for your default SSL site (and if you have marked no SSL site as your default, the first SSL site in its configuration). This will usually result in the user seeing a certificate warning notice, because the name on the certificate nginx sends doesn't match the name the client requested.

The RFC for SNI specifies that the server MAY consider an unrecognized SNI name as fatal:

If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal).

As far as I can tell, however, both Apache and nginx proceed with the connection and treat it in the same way as they would treat an unmatched or missing "Host:" header, which is to select the virtual host marked as default for that address:port.

Unless you have acquired an SSL certificate matching every possible domain name the client may use when contacting your server, it is not possible to prevent the user seeing a warning about an invalid certificate before proceeding. Even if you do a redirect as soon as they come to the site, this will be processed only after the invalid certificate is accepted.

2017 update: since it's easy to get free SSL certificates for all your domains now, you could get SSL certs for all your domains, even if you don't intend to serve actual content though HTTPS on them, just to ensure that any redirects or error messages will work without any warning about mismatched certificates.

Answer 3

You can do what you are looking for by adding a server entry with a fake ( I use self-signed for localhost ) ssl certificate that returns the error you want. This should be the first server block or at least before any other ssl blocks. Note that I normally use deny all but in this case added the 404.

server {
        listen       443 ssl default_server;
        server_name    localhost;
        ssl_certificate_key  /etc/ssl/private/localhost.key;
        ssl_certificate /etc/ssl/certs/localhost.crt;
#       deny  all;
        return 404;
}

To generate the self signed certificate you can use the following commands

openssl genrsa 4096 > localhost.key
openssl req -new -sha256 -key localhost.key -subj "/CN=localhost" > localhost.csr
openssl x509 -req -days 3650 -in localhost.csr -signkey localhost.key -out localhost.crt
chmod 600 localhost.key
mv localhost.key /etc/ssl/private/
mv localhost.crt /etc/ssl/certs/

Answer 4

It is not possible with NGinx (or, by default, with anything else).

If you totally do not care about older clients (such as the ones using Chrome or IE on Windows XP) and you are ok supporting only clients that use the SNI extension of the TLS protocol, then you can use haproxy in front of nginx to do this.

Another solution would be to put all non-SSL websites on a completely separate IP address that does not have a listen on the https port.

Answer 5

I'm not sure what exactly you tried, but if you do have SNI support, one method is to form a catch-all:

server {
    listen [::]:443 default_server ssl;
    listen 443 default_server ssl;
    server_name _;
    return 444;
}

    server {
    listen  [::]:443 ssl;
        listen  443 ssl;
    server_name  ssl.site.net;
    ssl_certificate      your.crt;
    ssl_certificate_key  your.key;
....etc...

which will dump non-matched servers (from a config i used to use, i don't currently, so apply grain-of-salt) As others pointed out, i don't believe you can do a redirect this way, only a drop.

For non-SNI support (read: legacy) you could always get a cheap certificate for wildcard-catching, then you'd be able to handle all connections and redirect as wish with no issues.

Edit: on second thought, if i recall, because nginx supports SNI, even if a client that doesnt support SNI connects, it will still cause nginx to return 444 while trying to match a certificate to send...thoughts?