Hi Maxim, >> Proxy: added the "proxy_ssl_ciphers" directive. > > Already asked in another thread if it really worth adding.
Yes, it is, and in my experience this one is much more useful than "proxy_ssl_protocols". Basically, there are 2 categories of broken SSL servers: 1. cannot accept ClientHello that's > 255 bytes, 2. cannot downgrade gracefully to a common supported TLS version. First category wasn't an issue until recently, because clients using anything older than TLS 1.2 fit nicely below that limit (ClientHello size is 205 bytes for "DEFAULT" / 233 bytes for "ALL" without SNI). However, starting with OpenSSL-1.0.1, clients started talking TLS 1.2 and advertising support for much bigger list of cipher suites, which doesn't fit within that limit anymore (316 bytes for "DEFAULT" / 358 bytes for "ALL" without SNI). Broken servers just drop such packets and time-out. Offenders in that category include F5 load balancers (without fix for that issue applied) and some ancient OpenSSL versions. While lowering TLS version via "proxy_ssl_protocols" decreases number of advertised cipher suites and brings ClientHello size < 256 bytes, it's suboptimal solution, because the same result can be achieved by limiting number of advertised cipher suites via "proxy_ssl_ciphers" while still using TLS 1.2 and hence providing much better security. Chrome does the same thing, btw. Servers from the second category accept TLS 1.2 ClientHello and downgrade to TLS 1.0 via ServerHello, but send corrupted packets afterwards. The only offender in that category, that I know of, is Oracle's KSSL and that's the only case when you need to use "proxy_ssl_protocols" to lower TLS version. > This modifies current behaviour, and only allows to use > HIGH:!aNULL:!MD5 chipers by default. Are there any specific > reasons to? > > The "!aNULL" looks especially wierd, as we don't check peers > certificates anyway. Good catch! Because of the issues above, we specify our own (rather limited) list of cipher suites that we advertise to the backend servers during SSL handshake, so I didn't notice that the defaults I provided are much stricter than necessary. In that case, I'd probably stick with "DEFAULT" (updated patch will follow)... Just keep in mind that nginx compiled against OpenSSL-1.0.1 will be sending ClientHello that's 316 bytes in size and will have issue with broken SSL servers... Whether or not that's something that nginx should worry about it's another matter, but just to give you some perspective, last time I checked it was ~0.15% of servers that didn't like big ClientHello messages. Best regards, Piotr Sikora _______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
