Hello!

On Thu, Feb 06, 2014 at 02:38:30PM -0800, Piotr Sikora wrote:

> > 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.

Uhm? SSL used to work without SNI for years, and works now
as SNI still not supported by many clients. The name asked by a
connecting to an IP address into which the name resolves.

> > 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)?

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.

> > 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.

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.

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

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel