Hello!

On Sun, Sep 22, 2013 at 10:47:05PM -0700, Piotr Sikora wrote:

> Hi Andrei,
>
> > +#if (NGX_HTTP_SSL)
> > +
> > +static ngx_conf_bitmask_t ngx_http_proxy_ssl_protocols[] = {
> > + { ngx_string("SSLv2"), NGX_SSL_SSLv2 },
> > + { ngx_string("SSLv3"), NGX_SSL_SSLv3 },
> > + { ngx_string("TLSv1"), NGX_SSL_TLSv1 },
> > + { ngx_string("TLSv1.1"), NGX_SSL_TLSv1_1 },
> > + { ngx_string("TLSv1.2"), NGX_SSL_TLSv1_2 },
> > + { ngx_null_string, 0 }
> > +};
> > +
> > +#endif
>
> I'm a bit biased, because I was cleaning up patchset with
> "proxy_ssl_protocols" and "proxy_ssl_ciphers" directives to send to
> the mailing list when you committed this, but wouldn't it make more
> sense to either expose & reuse ngx_http_ssl_protocols or ideally push
> this and other definitions back to ngx_event_openssl module instead of
> having exactly the same bitmask & NGX_DEFAULT_CIPHERS defined in 3
> different places (ngx_http_ssl_module, ngx_http_proxy_ssl_module &
> ngx_mail_ssl_module)?

As of now, ngx_event_openssl.c mostly doesn't know about
configuration parsing (the only exception seems to be ngx_conf_t
used by ngx_ssl_certificate() and others to expand file name).
Please also note that ngx_event_openssl isn't a module, but rather
an SSL-library interface. While moving ssl protocols list into
ngx_event_openssl.[ch] is possible, it's certainly not how things
are currently done.

BTW, could you please clarify reasons for proxy_ssl_ciphers?
Andrei added proxy_ssl_protocols mostly as a workaround, because
previously used default resulted in connection failures with some
backends as seen by our customer. Not sure if adding
proxy_ssl_ciphers worth the effort from this point of view, and
actually that's why I stopped myself from asking him to add it.

--
Maxim Dounin
http://nginx.org/en/donation.html

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