Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relax recommendation on cipher order #1311

Open
exploide opened this issue Aug 30, 2019 · 3 comments

Comments

@exploide
Copy link

commented Aug 30, 2019

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.
https://github.com/mozilla/ssl-config-generator

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.

@drwetter

This comment has been minimized.

Copy link
Owner

commented Aug 30, 2019

Mozilla recently relaxed their recommendations regarding cipher order.

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.

If only strong cipher suites are supported anyway, why not deciding according to the client's preferences.

yes, if . Means, it would need a test for every cipher upfront.

@exploide

This comment has been minimized.

Copy link
Author

commented Aug 31, 2019

Thanks for your reply.

you have a pointer?

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.

Discussion is hard to follow because spread over several issues. E.g. mozilla/ssl-config-generator#48, mozilla/ssl-config-generator#34 and starting at mozilla/server-side-tls#178 (comment)

but I can tell you that there are really bad clients out there

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.

Means, it would need a test for every cipher upfront.

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.

@drwetter

This comment has been minimized.

Copy link
Owner

commented Sep 1, 2019

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.

@drwetter drwetter added this to the 3.1dev milestone Sep 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.