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.
> 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...).
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.
Best regards,
Piotr Sikora
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
