@Shamrock,
This question
Thanks,tryingto find something like this, I presume it will remove cypher suites as well?
is probably best answered as : yes.
However, you can make a backup of relevant config files first.
If you have Nginx config, then copy the /etc/nginx/conf.d/ssl.conf to a file like [filename].bak - leave the ssl.conf file as is (and do not remove).
Afterwards, one can still tweak the Cipher suite in ssl.conf, but I would
not recommend manual adjustments.
The Cipher suite applied is short in the sense that only a couple of ciphers are allowed - this is good, adding ciphers will always increase the attack surface.
In some scenario's, one really needs the older / weak ciphers - this is not good, but necessary for some applications and purposes.
The golden rule is that one should add the older / weak ciphers
only if you see in the logs that "old" (or "bad") clients fail to connect for reasons related to TLS protocol version and/or related to the cipher suite (read: missing ciphers in the cipher suite).
In most cases, you will not need to add (additional) ciphers afterwards.
It is important to note that on each and every level (read: Apache / Nginx / mail server / etc) , one has to determine and/or use an appropriate and strict suite of ciphers that is optimal for the use-case scenario.
For instance, when using Nginx
as a reverse proxy for Apache, all ciphers allowed should go into ssl.conf - no need for weak ciphers, at least in most cases.
Also, when using Nginx
as a reverse proxy for Apache, the cipher suite on the Apache level can - in theory - be absent and - in practice - should be very strict!
As another example, ciphers for mail purposes and/or related to the mail server are often required to be more weak - many bad mail clients out there.
In addition, when being confronted with customers that use outlook, one always gets the challenge to downgrade the TLS verions and add weak ciphers.
In summary, do not care about SSL Labs A's or B's - just have a look
per level and set appropriate cipher suites (and TLS versions) per level.
This note
Obviously noted regarding bad clients (FYI I have been in the security field for 25 years
was a clear indication for me that - at least part of - my post should not be necessary.
However, other people can also read the posts and pick out what they find valuable, right?
But yes, you and me are - probably - equally surprised how some (bad) things have never changed.
I am always trying to envision how a development team could think "let's go ahead and add a thingy or two to the GUI, but still work with 1960s code".
I have that feeling of "well, didn't we have that nuclear arsenal running on old machines and old code that cannot be upgraded anymore?"
We are not quite there yet in the area of "bad clients", but we are destined to follow the path to that future.
The latter part of the statement
That holds for all connections, even worse for e-mail security protocols like SPF, DKIM, DMARC. If the receiving end doesn't check, none of it will matter.
is quite interesting, since that is absolutely true.
Quite annoying, that situation of mail not being delivered or received when the other mail server is badly configured.
Again, also a path that we are destined to follow.
Consider the annoying roll-out of TLSA enforcement by Microsoft, with most people not even realizing that they miss out on thousands of mails.
Your statement
"Definitely, issue is that there are 21 cypher suites on our installation, this may be a remnence from the DirectAdmin migration, that are have the status "face out" in accordance with NCSC NL guidelines. "
is a little bit scary.
In general, one can safely conclude that a great part of your ciphers is causing vulnerability.
In order to "get" 21 cyphers, there has to be a subselection of ciphers that are often
only associated with very old and bad clients, often used for bad traffic or even malicious attempts to connect.
In my humble opinion, it is not a viable option to use the "remove-one-and-retry-and-lets-see-what-happens" method.
One should really start over with a very strict set of ciphers, then
only add ciphers if really needed.
Kind regards....