Opened 10 years ago
Closed 10 years ago
#726 closed defect (wontfix)
NGINX will use least level of security for SSL with SNI enabled.
| Reported by: | Null Blank | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | nginx-core | Version: | 1.2.x |
| Keywords: | ssl, sni | Cc: | |
| uname -a: | Linux example 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.2.1
TLS SNI support enabled configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-auth-pam --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-echo --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-upstream-fair --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-dav-ext-module |
||
Description
When utilizing SNI feature, the SSL security level may be breached due to unrelated site configuration.
For example, a secure sub domain (secure.example.com) uses TLS and specific set of ciphers only. In the mean time all normal sub domains (www.example.com) on the same host uses default SSL configuration. With a valid wildcard *.example.com certification deployed, one can successfully connect to secure.example.com with banned ciphers.
I understand that SSL protocol and ciphers are determined at handshaking stage, when no SNI feature involved. But I still believe that we could do better, for example, close the connection with 403 or no data at all when we found connection state is inconsistent with the requirements.
I don't think we are in position to do anything with this. Ciphers are handled by the OpenSSL library, and nginx doesn't even try to understand which ciphers are allowed.
As of now, nginx disallows requests to different SNI servers with
ssl_verify_clientenabled. This is believed to be enough to protect the unwary. If you indeed do care about ciphers used, you can implement additional checks, e.g., using the rewrite module, or avoid using SNI.