Opened 8 years ago

Closed 5 years ago

#214 closed enhancement (fixed)

Ability to detect presence of SNI header

Reported by: Aaron Q Owned by: somebody
Priority: minor Milestone:
Component: nginx-core Version: 1.3.x
Keywords: sni, ssl Cc:
uname -a: Linux haboob1 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.2.3
built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
TLS SNI support enabled
configure arguments: --with-http_ssl_module --user=nobody --group=nobody

Description

I think it would be a great feature to be able to detect the lack of the SNI header inside of a server block for an SSL listener.

Something like:

server {

listen 10.0.0.1:443 default_nosni;
server_name test.host.com
ssl_certificate ...;
ssl_key ...;
location / {

rewrite .* /no_sni.html;

}

}

Could be the catch-all for all SSL requests hitting test.host.com that do include the headers needed for SNI to work (Windows XP + Internet Explorer 7/8). We could then display a page to the user that requests them to use a different browser or upgrade instead of them being served a possibly invalid or mismatching SSL certificate than the host they are trying to reach.

Change History (7)

comment:1 by is, 8 years ago

Resolution: invalid
Status: newclosed

There is no necessity of special listen option.
This could be achieved by default_server option with non-existent server_name:

server {

listen 443 default_server ssl;
server_name _;
...

}

Please note, that there is no way to prevent sending mismatching SSL certificate to a client which does not support SNI.

comment:2 by Aaron Q, 8 years ago

You the default won't be hit if there is a server_name that matches the host name. The default is only hit if there is no server block at all for the server name.

If there is a server set up like

server {

listen 443 ssl;
server_name abc.com;

}

It will be hit instead of the default_server block even if there is no SNI support. I tested this on several browsers and was unable to get nginx to serve up the default page since there is a server block that matches the host name. The mismatched SSL certificate is less of an issue than being served the secure content when I would want the visitor to see a generic message to upgrade their browser instead (after they accept the mismatched cert). Does that make sense?

comment:3 by is, 8 years ago

Resolution: invalid
Status: closedreopened

Well, you are right.

comment:4 by is, 8 years ago

BTW, what is user benefit of the upgrade message page ? Even if you will use SSI-generated page with a link to original URL, the user will not be able to go there. As for me, I would like to see the desired page after all these cryptic certificate warnings, but not the upgrade message. I do not want to upgrade my browser just to see the page.

comment:5 by Aaron Q, 8 years ago

There would not be a link to the original URL. In my case, I do not want any user to view the "real" site with the mismatched certificate. I would like to say on that no-sni page that the site is only compatible with modern browsers and the user must use a modern browser to continue.

comment:6 by Maxim Dounin, 8 years ago

Priority: majorminor
Status: reopenedaccepted

See also #195, which is somewhat related.

comment:7 by Maxim Dounin, 5 years ago

Resolution: fixed
sensitive: 0
Status: acceptedclosed

The $ssl_server_name variable was introduced in nginx 1.7.0, and it allows to do relevant checks.

Note: See TracTickets for help on using tickets.