Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#1169 closed defect (wontfix)

TLS works without supplying the ssl parameter without a WARN

Reported by: spleefer90@… Owned by:
Priority: minor Milestone:
Component: other Version: 1.11.x
Keywords: Cc:
uname -a:
Linux c0rn3jRPi3B 4.4.39-1-ARCH #1 SMP Sun Dec 18 18:25:13 MST 2016 armv7l GNU/Linux
nginx -V: nginx version: nginx/1.11.8
built with OpenSSL 1.0.2j 26 Sep 2016
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/bin/nginx --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock --user=http --group=http --http-log-path=/var/log/nginx/access.log --error-log-path=stderr --http-client-body-temp-path=/var/lib/nginx/client-body --http-proxy-temp-path=/var/lib/nginx/proxy --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-pcre-jit --with-file-aio --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_ssl_module --with-threads --with-stream_ssl_preread_module --with-stream_geoip_module --with-stream_realip_module

Description

If there is a server block for the same port/IP that already has the ssl parameter enabled, it doesn't need to be enabled in other server blocks and it works, without throwing an error or a warning when starting up/checking the config with -t.

The correct behavior in my opinion would be warning the user about the fact, as they can make the server blocks dependent on other server blocks.

server { # < ---- this works fine but it doesn't throw a warning

listen 443 http2;
listen [::]:443 http2;
server_name c0rn3j.com;
...

}
server {

listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name wiki.c0rn3j.com;
...

}

➜ ~ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Change History (4)

comment:1 by Maxim Dounin, 8 years ago

Resolution: wontfix
Status: newclosed

This behaviour is intentional. Listening sockets can be shared between multiple server{} blocks (see How nginx processes a request), and the ssl parameter can be either used in all listen directives to make it more obvious in the configuration that the socket in question is using SSL, e.g.:

server { listen 443 ssl; ... }
server { listen 443 ssl; ... }
server { listen 443 ssl; ... }

or not used at all in non-default servers, e.g.:

server { listen 443 ssl; ... }
server { listen 443; ... }
server { listen 443; ... }

We certainly don't want to break configurations using either of these approaches.

comment:2 by mnordhoff@…, 8 years ago

Logging a warning wouldn't break backwards compatibility, and would alert users to a confusing, brittle and possibly erroneous configuration. While annoying everyone who does it on purpose, of course.

comment:3 by spleefer90@…, 8 years ago

Annoying people who use this on purpose could be solved by setting some flag in the config file perhaps?

comment:4 by Maxim Dounin, 8 years ago

There can be a lot of listening options, and requiring users to specify them all in all the listen directives in the configuration is certainly counter-productive.

Note: See TracTickets for help on using tickets.