Do TLS standards require the server-side preference to always be used when negotiating ciphers to use?

Question

Someone told me the other day that the TLS standards require the server-side to always have the authority to decide which mutual cipher to use when negotiating with a remote client.

This makes sense, but gets me to wondering how long this has been the case and why there are options like: +SSL_OP_CIPHER_SERVER_PREFERENCE in openssl for CTX options: https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_options.html

SSL_OP_CIPHER_SERVER_PREFERENCE

When choosing a cipher, use the server's preferences instead of the client preferences. When not set, the SSL server will always follow the clients preferences. When set, the SSLv3/TLSv1 server will choose following its own preferences. Because of the different protocol, for SSLv2 the server will send its list of preferences to the client and the client chooses.

This doesn't make sense...

Answer 1

I think the key is to realize the difference between acceptability and preferences. Each side has a set of accepted ciphersuites, and a preference order among those ciphersuites. Non-accepted ciphersuites aren't considered for preferences at all.

Due to the design of the TLS protocol, the client sends its set of accepted ciphersuites to the server. It sends this set as an ordered list, and the order indicates the client's preferences. The server never shows the client what it accepts or what its preferences is. It makes a selection, and tells the client what that selection is. That's why the server has final authority to select the ciphersuite. The server doesn't have complete authority though: it can't make the client use a ciphersuite that the client doesn't want.

From the client's perspective, the server doesn't have an acceptable set, or preferences. All the client knows is that the server chose one particular ciphersuite among the ones that the client offered.

The server needs to select a ciphersuite that's acceptable to both the client and the server. If there's some ciphersuite that the client accepts but the server doesn't, the server won't consider it at all. Likewise, if there's some ciphersuite that the server accepts but not the client, then the server can't select it (that would violate the protocol and the client would shut the connection down).

Any ciphersuite that's both in the client's preference list and in the server's preference list is by construction acceptable to both parties. Among the mutually-acceptable ciphersuites, the server has authority to decide which one to choose.

It could pick one randomly, or based on the phase of the moon, or it could take a hash of the concatenation of the two lists modulo the size of the mutually-acceptable set and use that as an index in the mutually-acceptable list sorted in reverse alphabetical order of the rot13 transform of the official ciphersuite names. Or it can make its choice in a saner way, and OpenSSL offers the two ways that actually make sense: amongst the mutually-acceptable set, pick either the one that the server prefers most, or the one that the client prefers most.

Answer 2

Within TLS the client sends a list of supported ciphers in the order of their preference by the client. The server has its own lists of ciphers it is willing to support. The server is free to choose any of the ciphers the client offers and which are also supported on the server side. How this choice is done is not specified. To keep the choice simple the OpenSSL API lets the server application choose between two strategies: use the client's preference of ciphers or use the server's preference. There are arguments for both of these strategies:

• use the client's preference:
  The client might show a preference for ciphers which are strong enough but need low computing resources on the client. For example clients having native instructions for AES will probably prefer some AES based cipher. Clients without such instructions (like low end ARM processors) might prefer ChaCha20 instead since this algorithm needs much fewer resources in this case.
• use the server's preference:
  Encryption is not really cheap and the server might thus prefer ciphers which needs the fewest resources on the server (but which are still strong) in order to serve many clients in parallel. Thus even if the client would prefer ChaCha20 to save resources on his site the server might choose an AES based cipher since it is much cheaper to do on the server if the server has hardware support for AES (most do).