Has server cipher order? explanation

[garthoidQlik]

Hi,

I am having a hard time finding information on what this test really means. Any help getting my head around it is greatly appreciated. I mean, I thought the server selects the best it supports from a client supplied list.

G

[teward]

This test is used to determine whether the server enforces its own order of which to try and use ciphers, or whether it lets the client connecting to it.

This is designed to be used with strongest-to-weakest cipher lists on server-side to try and prohibit clients from using weaker ciphers before trying stronger ciphers. In a nutshell.

[garthoidQlik]

ok. So is this a server implementation/configuration problem or a protocol problem?

[teward]

What exactly are you seeing?

It's usually a server configuration issue when you see server cipher order not being enforced, not a client issue, but without seeing exactly what you are looking at...

[garthoidQlik]

Thanks. I am noticing that the built in REST (golang) binary implements the REST API for the server and testssl.sh is showing:

Has server cipher order? nope (NOT ok)

So I wanted to understand the issue since I thought it was the basis for the protocol to enforce the server ciphersuite order. This test, and upon searching finding things like ssl_prefer_server_ciphers default to off in nginx made me pause.

[teward]

It's not a protocol spec. It's a server-side implementation spec. This is why it's necessary to set such server side enforcement in the library being used, like the nginx binary permits setting server cipher preference to "off" in a default would not enforce it. In Debian, the default nginx configs set server cipher enforcement to "on". Default behavior however does show you how it's not part of the protocol definition itself.

(That said, I don't think this needs to remain open as an issue since we have shown it isn't one)

[garthoidQlik]

Agreed. Thank you for the explanation.

[misilot]

Sorry to bring up an old issue, but is there a way to disable this as being a negative when using the nagios check? It seems that the recommendation at least for apache is to set it SSLHonorCipherOrder off when looking at Mozilla's SSL Configuration Generator at least for modern or intermediate configurations.

[dcooper16]

At the moment, there is no way to disable this, if the server preference test is run. Note, that it is only noted as being negative if a server preference order is not enforced for TLS 1.2 and below. So, in the case of Mozilla's modern configuration, which only supports TLS 1.3, it would not be noted as negative.

For TLS 1.2 and earlier, see #1311. The idea in #1311 hasn't been implemented yet, but it would result in the lack of a server-enforced cipher order not be noted as negative, if the server only supports "strong" ciphers.

[drwetter]

It seems that the recommendation at least for apache is to set it SSLHonorCipherOrder off when looking at Mozilla's SSL Configuration Generator at least for modern or intermediate configurations.

The argument with Mozilla's recommendation is a weak one from our perspective: the baseline is that modern systems even with intermediate settings there are ciphers specified. And none of them is really weak.

As David noted, we still have the one-size-fits-all approach until then.

[misilot]

Ok, so if as long as we still support TLS1.2, we would need to ensure we set SSLHonorCipherOrder on, so it doesn't show up as a warning? I just wanted to make sure I am following correctly.

Thanks!

[drwetter]

... if the warning from testssl.sh bothers you and if otherwise the ciphers you're offering aren't weak: yes.

[misilot]

It was more when using it with https://github.com/dnmvisser/nagios-testssl, but I had missed the --ignore-ids option that was in there. So all is good. Thanks!

[doggodanubus]

https://ssl-config.mozilla.org/#server=apache&version=2.4.54&config=modern&openssl=1.1.1q&guideline=5.6
This is pretty ruthless in disabling old crap unlike my hellcare providers setups still using SSL. It disables every junk or obsolete cipher and protocol. The creator(s) do not seem to care if the client picks the cipher after this is done.

If the script could check that bad ciphers and protocols are disabled and give an not applicable or give an explanation that the scary red error might not apply that would be calming. ;)

Thanks for the script it's a peach and makes checking out configurations quite easy.

[drwetter]

Thanks. Lets continue the discussion in #1311