[PATCH] Proxy: added the "proxy_ssl_ciphers" directive.

[Piotr Sikora]

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