SSL on/off on same port and IP

[Maxim Dounin]

Hello!

On Tue, Jun 23, 2015 at 04:43:23PM +0200, Ingo Lafrenz wrote:

> Hi,
> 
> consider the following very simple nginx config:
> http {
>     server {
>         listen 127.0.0.1:123;
>         server_name abc;
>     }
>     server {
>         listen 127.0.0.1:123 ssl;
>         server_name xyz;
>         ssl_certificate...;
>     }
> }
> 
> In words:
> I instruct nginx to listen on the same port and IP, one time without ssl,
> one time with ssl. IMHO this is a broken config, however nginx accepts it.
> 
> What would you say? Should nginx reject such a config? Right now you only
> get an error at request time.

The "listen 127.0.0.1:123 ssl;" means that nginx will use SSL on 
the 127.0.0.1:123 listen socket.  This works much like with any 
listen socket options: you may specify them once, and omit in other 
server{} blocks.

The only problem with the config in question is that there is no 
ssl certificate defined in the first server.  There is a ticket 
about complaining during configuration testing in such a case:

http://trac.nginx.org/nginx/ticket/178

But adding such a check isn't trivial and unlikely to happen soon.

> It gets even worse, if the 2nd server is configured with the ssl directive
> instead of "listen ssl":
>     server {
>         listen 127.0.0.1:123;
>         server_name xyz;
>         ssl on;
>         ssl_certificate...;
>     }
> 
> In that case you don't even see an error in the logs anymore and clients
> can't connect via https anymore.

There will be an error in the logs, but at the "info" level - 
and therefore rarely seen.  The socket in question won't have SSL 
enabled as there is no "ssl on" in the default (first) server, and 
therefore nginx will not expect SSL connections and will complain 
that "client sent invalid method" for all attempts to establish an 
SSL connection.

Anyway, that's why "ssl on" is deprecated - it's very easy to 
configure things wrongly when using it.

-- 
Maxim Dounin
http://nginx.org/