Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Relax recommendation on cipher order #1311
Currently, testssl prints a big red warning when a server has no server preferred cipher order.
Mozilla recently relaxed their recommendations regarding cipher order. If only strong cipher suites are supported anyway, why not deciding according to the client's preferences. Maybe it's a phone that wants to optimize for performance on low hardware. Additionally, often browsers are better maintained than web servers updated. So the client's preferences are probably not bad.
So Mozilla decided to prefer server order only for the "old" compatibility configuration.
There were several discussions about this, but this was the outcome so far.
I propose that testssl also relaxes its recommendation regarding cipher order.
To be more precise: Either print the warning just in yellow instead of red, or make it dependent on the supported TLS versions and algorithms. E.g. when no cipher concerns are present, make the order setting also no concern.
you have a pointer?
Please keep in mind that testssl.sh tests not only HTTP services but almost everything. Realistically nowdays browsers are not a big concern, but I can tell you that there are really bad clients out there.
yes, if . Means, it would need a test for every cipher upfront.
Thanks for your reply.
See https://ssl-config.mozilla.org/ for the outcome of the popular Mozilla config generator. Note that server cipher order is off for modern and intermediate and only on for old.
I agree. I do not propose to remove the cipher order rating altogether. But maybe if it would be only written in yellow. Or if it is a bit more explanatory in which cases it is important.
Not necessarily. It might be sufficient to utilize the already existing cipher "category" rating from the top. I.e. only warn about cipher order when already warned about NULL, ANON, EXPORT, or LOW.
Thanks for the pointers.
From a server side when you already know what you configure, things might seem easier. Albeit still I think to set server side preference should be best practice in TLS <= 1.2.
For testssl.sh in 3.0 I am hesitant to make bigger changes, i.e. introducing dependencies between checks. The implementation problem with your (in theory good) suggestion is that not necessarily the cipher category has been run already. And also if this is the case somehow the worst ciphers from the client side need to be deducted and this needs to be color encoded.
OTOH to relax the color code without the knowledge what bad ciphers are configured might reflect 90% of the use cases but I wouldn't like the 10% to get no suggestion like "please look at the cipher order". This is where the config generator has an easier decision.
So at the moment the results may seem overly pessimistic but that doesn't hurt as much.