Defining a default server for when vhost does not exist for requested hostname (including blank host

Server NGINX
#1

Hello,

We run multiple vhosts in nginx. Occasionally, a vhost will be
mis-configured or disabled (via the website management software that we
use), and public requests for the domain will fall-back to nginx’s
default vhost, which can have very unintended consequences (e.g., an
incorrect and completely unrelated website is displayed).

The nginx documentation suggests doing something like this to combat
this type of problem:

server {
listen *:80 default_server;
server_name “”;
return 444;
}

server {
listen *:443 default_server ssl;
ssl_certificate /var/www/clients/client1/web1/ssl/localhost.com.crt;
ssl_certificate_key
/var/www/clients/client1/web1/ssl/localhost.com.key;
server_name “”;
return 444;
}

I’ve placed this snippet at the top of nginx’s “default” vhost
configuration file and it does exactly what I want. But I’m wondering if
this is the “correct” and “best” approach to the problem I describe.

Also, I noticed that this doesn’t seem to work for SSL when an SSL
certificate and key are not specified, with the following appearing in
nginx’s error log:

no “ssl_certificate” is defined in server listening on SSL port while
SSL handshaking, client: 10.0.1.57, server: 0.0.0.0:443

That’s fine; I just want to ensure that the certificate I’ve specified
in order to make this work will never be transmitted nor presented to
the user-agent. When I test this in a web browser, the browser never
seems to display or mention the certificate (no mismatch or anything;
just the 444 response).

However, when I test this with cURL, it does seem to be privy to the
certificate (disregard the fact that the cert verification fails; it’s
self-signed):

$ curl https://10.0.1.50
curl: (60) SSL certificate problem, verify that the CA cert is OK.
Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

Is there any way to avoid this certificate being presented, but still
return the 444 response under the conditions I’ve described?

Thanks for any tips here!

-Ben

#2

On 28 March 2014 14:31, Ben J. [email protected] wrote:

Is there any way to av,oid this certificate being presented, but still
return the 444 response under the conditions I’ve described?

I’d /suspect/ not, as the 444 response can’t be “delivered” (i.e. the
connection closed) until sufficient information has been passed over
the already-SSL-secured connection. In other words, the cert has to
be used to secure the channel over which the HTTP request will be
made, and only after its been made can the correct server{} block be
chosen and the response delivered - even if the response is simply to
close the connection.

J

#3

Hello!

On Fri, Mar 28, 2014 at 02:53:18PM +0000, Jonathan M. wrote:

close the connection.
If SNI is used, it’s in theory possible to close a connection
early (during an SSL handshake, after ClientHello but
before sending enything). The following tickets in trac are
related:

http://trac.nginx.org/nginx/ticket/195
http://trac.nginx.org/nginx/ticket/214

–
Maxim D.
http://nginx.org/

#4

On 3/28/2014 11:45 AM, Maxim D. wrote:

the already-SSL-secured connection. In other words, the cert has to
http://trac.nginx.org/nginx/ticket/195
http://trac.nginx.org/nginx/ticket/214

Thanks for the input, Jonathan and Maxim.

Maxim, when you say, “If SNI is used, it’s in theory possible to close a
connection early,” do you mean to imply that while possible, this
capability has not yet been implemented in nginx (the tickets are still
open after almost two years)?

Thanks again,

-Ben

#5

On 28 March 2014 16:51, Ben J. [email protected] wrote:

Maxim, when you say, “If SNI is used, it’s in theory possible to close a
connection early,” do you mean to imply that while possible, this
capability has not yet been implemented in nginx (the tickets are still
open after almost two years)?

I’d suggest that, across all software (including nginx!), SNI
bugs/features like this will get exponentially more attention after
Windows XP goes EOL this April, as (I believe) it’s the last major
platform not to support SNI.

J

#6

Jonathan M. Wrote:

bugs/features like this will get exponentially more attention after
Windows XP goes EOL this April, as (I believe) it’s the last major
platform not to support SNI.

Which is a moot case since there are at least 5 other browsers for XP
who
support SNI.

"SSL support with SNI on shared IP addresses requires that the user’s
browser supports SNI. Most modern web browsers support it (e.g., IE 7
and
above, Firefox, Opera, and Chrome). However, there are a few outlier
exceptions:

Any Internet Explorer browser on Windows XP
Chrome 5 and older on Windows XP
Blackberry web browser
Windows Mobile phones up to version 6.5
Android mobile phone default browser on Android OS 2.x"

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,248808,248822#msg-248822

#7

Hello!

On Fri, Mar 28, 2014 at 12:51:17PM -0400, Ben J. wrote:

before sending enything). The following tickets in trac are
capability has not yet been implemented in nginx (the tickets are still
open after almost two years)?

Nobody care enough to submit a patch.
Likely due to the fact that SNI isn’t considered to be an option
for serious SSL-enabled sites anyway due to still limited
client-side support, see here for details:

http://en.wikipedia.org/wiki/Server_Name_Indication#Client_side

–
Maxim D.
http://nginx.org/

#8

On 3/28/2014 1:58 PM, Maxim D. wrote:

Nobody care enough to submit a patch.
Likely due to the fact that SNI isn’t considered to be an option
for serious SSL-enabled sites anyway due to still limited
client-side support, see here for details:

http://en.wikipedia.org/wiki/Server_Name_Indication#Client_side

Makes sense! And I can live with the SSL warning that results when I
employ the method I described a few posts back.

Thanks again for your help, everyone!

-Ben