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

[Piotr Sikora]

Hey Maxim,

> Nitpicking:
>
> It may be better to write about "proxy_..." directives, and
> mention uwsgi counterparts separately and/or introduce them in a
> separate patch.  Cryptic names to mention all the modules aren't
> very readable and hardly searchable, so we generally try to avoid
> them now.

Will do.

> I don't really like this approach of a special "server_name" value
> and SNI dependency, it looks counterintuitive.  Peer name
> verification should be done by default, and probably there should
> be a separate option to turn it off if needed for some reason.
>
> I believe the main reason for SNI dependency is a name to verify
> against.  In case of proxy, shouldn't it be $proxy_host by
> default?

I strongly disagree with you on that. IMHO, peer has no obligation to
deliver certificate matching hostname if we don't ask for it using SNI
and therefore we can't complain if it doesn't match.

> Something like this:
>
>     proxy_ssl_verify on;
>     proxy_ssl_name $proxy_host;
>
> or this:
>
>     proxy_ssl_verify on;
>     proxy_ssl_verify_name off;
>
> And the same name probably may be used for SNI, with an
> additional flag to switch it on, like this:
>
>     proxy_ssl_sni on;
>     proxy_ssl_name $proxy_host;
>
> (Well, it might be better to introduce something more generic to
> also resolve default proxy_cache_key vs. "proxy_set_header Host"
> issue, but I don't see any obvious solution yet.)
>
> What do you think?

What about defaults being:

    proxy_ssl_verify  on;
    proxy_ssl_server_name  $proxy_host;

where "proxy_ssl_verify on" automatically checks server name if
supported (basically, merging "server_name" and "on" from my patch)?

> Not sure if it's needed at all.  I think we can safely assume that
> verification options are the same in all cases.

I'd rather be safe and do one more comparison than allow server block
with proxy SSL verification to reuse connection established by a
server block without it.

Best regards,
Piotr Sikora