[PATCH] SSL: add "{proxy, uwsgi}_ssl_verify" and supporting directives

[Maxim Dounin]

Hello!

On Tue, Feb 11, 2014 at 01:16:41PM -0800, Piotr Sikora wrote:

> Hey Maxim,
> 
> > Well, there is no real difference, but I think that it would be
> > easier to use distinct flags instead.  Note that it also matches
> > what Apache has:
> >
> > http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxycheckpeername
> >
> > By looking around you may also find various other flags in Apache
> > to control verification (like SSLProxyCheckPeerExpire).  I suspect
> > eventually we may need to add at least some of them.  Having all
> > this controlled in a single directive would be a pain.
> 
> But isn't having multiple parameters on the directive line kind of
> nginx style? ;)
> 
> Anyway, I'll do it your way.
> 
> > My original suggestion is as follows:
> >
> > proxy_ssl_name <value>
> >
> >     default: $proxy_host
> >     complex value, controls a name used in SNI (if
> >     enabled)
> >
> > proxy_ssl_verify on|off
> >
> >     default: off
> >     flag, controls if remote certificate verification is enabled
> >
> > proxy_ssl_verify_name on|off
> >
> >     default: on
> >     flag, controls if remote certificate verification needs to
> >     check peer's name;  must be explicitly switched off
> >     if certificate verification is switched on, but
> >     the name can't be checked due to too old OpenSSL
> 
> Got it.

Just a quick note:

We've discussed this with Igor, and he thinks that peer's name 
should be always checked, without an ability to check switch the 
check off selectively.  Mostly to simplify user experience.  This 
implies that we either need our own peer's name check code, or 
verification won't work at all if OpenSSL is too old.

> > proxy_ssl_sni on|off
> >
> >     default: off (?)
> >     flag, controls if SNI (Server Name Indication) will be used
> >     while connecting to backends;
> >
> > (I tend to think that "proxy_ssl_sni" is a better name compared to
> > "proxy_ssl_server_name", as Server Name Indication is usually
> > called SNI in various places.)
> 
> I dislike the "_sni" suffix, it just looks ugly in lowercase and most
> of the variable and directive names in nginx is rather verbose...
> "proxy_ssl_server_name" would also match "$ssl_server_name" (if that
> ever gets merged...).

Well, I don't think I care too much about the color.  The 
"proxy_ssl_server_name" looks a bit too long for me, but I 
certainly can live with it.

> I also believe that it should be turned on by default. Other than
> broken upstream that can't handle large SSL Client Hello (F5, etc.),
> there is no reason for any HTTP client to not use SNI.

I mostly agree.  What raises the question is $proxy_host default, 
which may not be appropriate if "proxy_set_header Host" is used.  
But probably we can live with it, at least till some better 
solution is implemented.  It's also not clear what should be used 
in case of uwsgi.

(Being paranoid enough, I also think that sending server name in a 
clear text is a privacy problem, but it's mostly browser-related 
problem, and as long as it can be switched off it's certainly ok.)

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