TLS-protocol-dependent option for ssl_prefer_server_ciphers

[https://stackoverflow.com/users/2646354/knoepfchendruecker]

The option ssl_prefer_server_ciphers from ngx_http_ssl_module currently does support either "on" or "off". A TLS-protocol-dependant option might be a useful enhancement.

In TLS 1.0/1.1, ssl_prefer_server_ciphers on is a common best current practice, as TLS 1.0/1.1- clients may not be using the best cipher suites available. Accordingly, the server enforces a "better" list of cipher suites.

Starting with TLS 1.2, ssl_prefer_server_ciphers off is a preferred choice, as modern clients should be able pick a reasonably secure cipher suite from the list presented by the server. Many clients like web browsers are automatically being updated and so more up-to-date than some less-managed servers and many devices do have different requirements unknown to the server.

For example, many mobile devices do have crypto hardware acceleration, but the server doesn't know which kinds of algorithms are supported by that accelerator. Having the server enforce some specific cipher suite does risk selecting a cipher suite not supported by the hardware accelerator. Accordingly, the device is spending more CPU cycles on encryption, requires more battery and more time to exchange data between server and client.

While we're all trying to migrate our clients to TLS 1.2+, there are still many 3rd-party applications, users and appliances out there who don't yet support TLS 1.2/1.3 and who simply do require "more time".
Unless (more serious) vulnerabilities do show up in TLS 1.0/1.1, it'll be hard for some users to argue removing support for TLS 1.0/1.1 from their nginx configuration. Based on how long it took to finally deprecate SSLv3 (almost 15 years), the migration to TLS 1.2+ may take at least a few more years. During this migration period, ssl_prefer_server_ciphers off does hurt or impact the connection security of "older" clients, while ssl_prefer_server_ciphers on does impact the speed for modern clients.

I do suggest adding a "protocol-specific" option for ssl_prefer_server_ciphers, e.g. by specifying a list of TLS protocol versions where the value is expected to be "on".

For example, ssl_prefer_server_ciphers TLSv1 TLSv1.1; could be such an option:

• if the ClientHello message does advertise a ClientVersion of TLSv1 or TLSv1.1 and those versions are not supported by ssl_protocols, the connection will be rejected (as usual).
• if the ClientHello message does advertise a ClientVersion of TLSv1 or TLSv1.1 and those versions are supported by ssl_protocols, the connection will be setup as if ssl_prefer_server_ciphers on; has been set.
• if the ClientHello message does advertise a ClientVersion supported by ssl_protocols and not listed in ssl_prefer_server_ciphers, the connection will be setup as if ssl_prefer_server_ciphers on; has been set.

By doing so, a server operator can provide the best experience and security level to their clients without impacting users.

[Maxim Dounin]

In TLS 1.0/1.1, ssl_prefer_server_ciphers on is a common best current practice, as TLS 1.0/1.1- clients may not be using the best cipher suites available. Accordingly, the server enforces a "better" list of cipher suites.

Well, "clients may not be using the best cipher suites available" is a claim which is always true, regardless of the protocol used. Accordingly, you may either apply it universally to all protocols as a reason to prefer server ciphers, or not - and let clients decide which ciphers to use.

The default in nginx is ssl_prefer_server_ciphers off;, and this is what we recommend to use unless you have some better reasons than "clients may not be using the best cipher suites available".

Further, protocol-specific ssl_prefer_server_ciphers is not something nginx can implement itself at a reasonable cost, as SSL/TLS handshake is handled by the OpenSSL library. OpenSSL currently only provides the SSL_OP_PRIORITIZE_CHACHA flag, which is rather a hack, see #1445, which is currently can be enabled via OpenSSL configuration. A better solution, equal preference cipher groups, is available in BoringSSL.

Closing this as a duplicate of #1445, as clearly it tries to address the same problem.