Opened 12 years ago
Closed 9 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 , 12 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 12 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:4 by , 12 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 , 12 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 , 12 years ago
Priority: | major → minor |
---|---|
Status: | reopened → accepted |
See also #195, which is somewhat related.
comment:7 by , 9 years ago
Resolution: | → fixed |
---|---|
sensitive: | → 0 |
Status: | accepted → closed |
The $ssl_server_name variable was introduced in nginx 1.7.0, and it allows to do relevant checks.
There is no necessity of special listen option.
This could be achieved by default_server option with non-existent server_name:
server {
}
Please note, that there is no way to prevent sending mismatching SSL certificate to a client which does not support SNI.