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

[Piotr Sikora]

Hey Maxim,

> I think that automatic checking peer name is how it should work (I
> believe examples above imply this, please let me know if you need
> more clarification on the proposal above).  Moreover, I think it
> should complain if verify is on but checking isn't supported, and
> ask administrator to explicitly switch off peer name check.
>
> I strongly disagree with the idea of verify being on by default
> though, at least for now, it will break too many configurations.
>
> And I also think that there should be a way to at least switch off
> SNI, and do this independently from peer verification.

Got it, I mis-read your previous comment.

To make sure we're on the same page:
- proxy_ssl_name - complex value, defaults to $proxy_host,
- proxy_ssl_verify - on / no_name / off (default) switch, verifies
upstream's certificate and optionally checks that it matches value
from proxy_ssl_name,
- proxy_ssl_server_name - on (default) / off switch, sends value from
proxy_ssl_name to SNI to upstream.

I don't like adding proxy_ssl_verify_name directive just to configure
the host checking logic. IMHO, it's part of the verification process
and should be configureable via proxy_ssl_verify.

I'm also not 100% convinced that we should allow users to configure
proxy_ssl_name... Maybe just force it to $proxy_host?

Does it match your proposal or did I miss something?

Regarding complaining - do we want to re-implement X509_check_host()
(from OpenSSL-1.0.2) or do we want to complain to virtually anybody
that turns upstream SSL verification on?

> My point is that connections can be quite different anyway, and
> e.g. have much different ciphers negotiated (up to eNULL ciphers I
> think).  It's up to administrator to configure upstream{} blocks
> appropriately to avoid such clashes if they aren't allowed.

Ah, right, I forgot about the SSL connection parameters.

Best regards,
Piotr Sikora