7

I've seen conflicting opinions on whether or not setting a cipher order is recommended. testssl.sh prints a red warning when no cipher order is encountered, implying that a lack of cipher order is considered a deficit. It also makes intuitive sense that a server should begin by offering the strongest ciphers first, and only then offer weaker ciphers.

Mozilla on the other hand recommends not setting a cipher order, as the client will know best which ciphers they prefer (e.g. depending on which ciphers have hardware support).

So, which one is it? Should a server cipher order be set or not?

Improve this question
8

... a server should begin by offering the strongest ciphers first, and only then offer weaker ciphers.

As long as the server only supports ciphers which are strong enough it does not actually matter in terms of security who chooses the cipher. Instead of security other criteria are relevant, typically performance from the perspective of the client or of the server. Just using a "stronger" cipher might add a perceived value but not an actual value (still assuming that only sufficiently string ciphers are supported in the server).

See also Do TLS standards require the server-side preference to always be used when negotiating ciphers to use? on why one would prefer client cipher order or why not.

Improve this answer
2
  • The problem is that your first statement "as long as the server only supports ciphers which are strong enough" is often not true for practical reasons. Servers must often support old, less secure cipher combos because they must support legacy clients. – Steve Sether Mar 10 at 0:51
  • @SteveSether: "Servers must often support old, less secure cipher combos because they must support legacy clients." - I challenge your statement with the same amount of facts (i.e. none) with which it was given. My gut feeling says it is not often such an actual requirement, at most sometimes and in limited environments. And even then it might be that the server administrators are simply not sure about the clients and therefore try to support even clients they don't actually have as a relevant part of their business. – Steffen Ullrich Mar 10 at 4:48
0

I don't think the order is relevant from a security perspective. The only thing that is relevant is whether the ciphers are considered safe or not; that's why, in general, you should remove the weak ciphers from the server list. Bear in mind that the client will choose from what the server offers to the client, and it is up to the clients to choose one depending on what they have implemented or what hardware they have. I know that in openssl you can choose the order, and it looks nice to have it, but it is up to the client to choose one from that list depending on their requirements.

Improve this answer
1
  • One correction: the client doesn't choose, the server does. The client offers a list of cipher suites it supports, and the server chooses which one to use. The first two sentences of the answer are correct, but the rest has the client and server roles backwards. – Xander Feb 23 at 16:38
0

There is no back and forth in the standard TLS negotiation process*, the client sends a list of supported cipher suites and the server picks one. According to the standard servers are supposed to respect the clients preferences but many don't.

There are legitimate reasons to let the client choose the cipher, for example for a low-power client without hardware crypto support chacha20 is likely a faster option than AES, but if the low power client does have hardware support for AES then it's likely the better option.

The problem comes when you need to support legacy clients. You sometimes end up in a situation where there are cipher suites you would rather not use if you can avoid it, but you can't disable completely because it would cut of clients that you need to support.

Ideally you would let the client choose between equally good ciphersuites, but only use the less good ciphersuites if they are the only option. Sadly i'm not aware of any server software that actually supports doing that, the option for the server to force ciphersuite order is all or nothing.

* Though some clients will make multiple connection attempts with different cipher lists.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.