Question TLS 1.2 and 1.3 only

[E42]

Server operating system version

Debian 11

Plesk version and microupdate number

Obsidian

Hello,
I followed the guide here https://support.plesk.com/hc/en-us/...able-TLS-protocol-versions-in-Plesk-for-Linux

But this command:
plesk bin server_pref -u -ssl-protocols 'TLSv1.2 TLSv1.3'
Does not seem enough.
A simple test with the tester on Qualys SSL Labs will give "B" rating and show TLS 1.0/1.1 ciphers. So my guess is that we should also explicitly set TLS 1.2/1.3 only ciphers. How can I found such an updated / tried-and-tested / approved list? Is the one in the article above correct for TLS 1.2/1.3?

 

[Jürgen_T]

I just found your question. If it is still open then it could help to look in Plesk-UI for websites/domains/your domain/ssl-certificates/serverconfiguration. Here you can choose an appropriate variant for TLS/ciphers provided by mozilla which comes together with relevant ciphers. If you do this be aware that the modern variant only provides TLSv1.3 but the variant intermediate provides both TLSv1.2 and 1.3 . Having done this you will proably get A or A+ with ssl-labs test depending on HSTS enabled or not..
This works in my case now seamless in Plesk-UI and I do not configure it any longer in the bash.

 

[Benemortasia]

If you arent looking for a specific kind of setup. But just want to be compliant with the current best
practices for SSL configuration, following one of the 3 levels of configuration current defined in:

Mozilla SSL Configuration Generator



Modern: Services with clients that support TLS 1.3 and don't need backward compatibility
Intermediate: General-purpose servers with a variety of clients, recommended for almost all systems
Old: Compatible with a number of very old clients, and should be used only as a last resort

The most simple way to apply one of those 3 templates in a few clicks is using SSL It!
- Make sure it is installed and open the SSL It! extension settings
(Tools&Settings->Security->TLS versions and ciphers management-> click settings)



- Here you can enable Mozilla ciphers and sync them to apply it.

(In your case. AND if you are aiming for an A or A+ rating. Select intermediate)





I suggest you reboot the server after configuring.

 

[Shamrock]

If you arent looking for a specific kind of setup. But just want to be compliant with the current best
practices for SSL configuration, following one of the 3 levels of configuration current defined in:

Mozilla SSL Configuration Generator

View attachment 22967

Modern: Services with clients that support TLS 1.3 and don't need backward compatibility
Intermediate: General-purpose servers with a variety of clients, recommended for almost all systems
Old: Compatible with a number of very old clients, and should be used only as a last resort

The most simple way to apply one of those 3 templates in a few clicks is using SSL It!
- Make sure it is installed and open the SSL It! extension settings
(Tools&Settings->Security->TLS versions and ciphers management-> click settings)

View attachment 22966

- Here you can enable Mozilla ciphers and sync them to apply it.

(In your case. AND if you are aiming for an A or A+ rating. Select intermediate)

Looks like that option is no longer available within the Plesk panel.
Any alternative suggestion to get the Mozilla template imported as default cypher suite within Plesk?
Anybody tried the Mozilla SSL configuration generator for this?

Redirecting to ssl-config.mozilla.org...

At the moment, default Plesk it seems, cypher suites are active that have the status "face out", this is the reason for us to see if we can update the list to a properly secured set.

 

[Sebahat.hadzhi]

@Shamrock , you should be able to adjust the cipher with:

plesk bin server_pref -u -ssl-ciphers 'example cipher'

More details:

• How to enable or disable TLS protocol versions or SSL ciphers via CLI in Plesk for Linux?

 

[Shamrock]

@Shamrock , you should be able to adjust the cipher with:

plesk bin server_pref -u -ssl-ciphers 'example cipher'

More details:

• How to enable or disable TLS protocol versions or SSL ciphers via CLI in Plesk for Linux?

Yeah I know, I thought there may be an easier way considering the option was A) there before apparently and B) it would be much easier to use the Mozilla config generator to set this up instead of having to type out the entire config line as the docs suggests (which obviously comes with the risk of errors as well).

 

[trialotto]

Yeah I know, I thought there may be an easier way considering the option was A) there before apparently and B) it would be much easier to use the Mozilla config generator to set this up instead of having to type out the entire config line as the docs suggests (which obviously comes with the risk of errors as well).

@Shamrock

The Mozilla config generator is one of the kind "pick me (Mozilla), don't think and mess up your config with what I say - trust me!".

In essence, most of the valuable recommendations made by the Mozilla config generator are already present in the default Plesk config.

Some recommendations made by the Mozilla config generator are not even desirable - they are risky in terms of security or are "odd" in every way.


@Sebahat.hadzhi has given you a rock-solid alternative - the CLI option.

Nevertheless, you have give a valid counterargument, being the personal selection and/or manual entry of the entire (!!!!) Cipher suite.


There is a simpler alternative that is - generally speaking - the best method - the PCI compliance utility.

Just run : plesk sbin pci_compliance_resolver --enable all

Afterwards, do a check with SSL Labs and adjust the cipher suite manually - for instance, in Nginx conf (since the Apache config barely matters).


As a final note, it really has to be emphasized that the Cipher suite and the nature thereof can help.

Nevertheless, the Cipher suite is not really related to the question "TLS or not and which version?" - the Cipher suite simply can improve security within a given context of allowed TLS protocols.

This does not mean that security actually will be improved.

The simple fact is this : security can only be improved by minimizing the extent to which your servers are exposed to bad clients.

Since there are a lot of bad clients (and some companies are more prone to be exposed to be bad clients) out there, there is not always added valuable to get the Cipher suite fine-tuned and the A's and B's that SSL labs assign are of no value if one is exposed to bad clients.

Stated differently, given any combination of TLS protocols + Cipher Suite, a bad client connecting to your server will be a bad client.

The TLS protocol and/or the Cipher suite will only make the connection a (tiny) bit better for a bad client.


In summary, the best thing that you can do within any Plesk environment is to run the PCI compliance resolver.

And do not forget to read this article.


I hope the above helps a bit.

Kind regards....

 

[Shamrock]

@Shamrock

The Mozilla config generator is one of the kind "pick me (Mozilla), don't think and mess up your config with what I say - trust me!".
cheers.

In essence, most of the valuable recommendations made by the Mozilla config generator are already present in the default Plesk config.

Some recommendations made by the Mozilla config generator are not even desirable - they are risky in terms of security or are "odd" in every way.
Probably depending on the selection of template. But they can have it wrong as well

@Sebahat.hadzhi has given you a rock-solid alternative - the CLI option.

Nevertheless, you have give a valid counterargument, being the personal selection and/or manual entry of the entire (!!!!) Cipher suite.


There is a simpler alternative that is - generally speaking - the best method - the PCI compliance utility.

Just run : plesk sbin pci_compliance_resolver --enable all

Thanks,tryingto find something like this, I presume it will remove cypher suites as well?
,

Afterwards, do a check with SSL Labs and adjust the cipher suite manually - for instance, in Nginx conf (since the Apache config barely matters).
Indeed, internet.nl is an interesting test location too (available in English as well).

As a final note, it really has to be emphasized that the Cipher suite and the nature thereof can help.

Nevertheless, the Cipher suite is not really related to the question "TLS or not and which version?" - the Cipher suite simply can improve security within a given context of allowed TLS protocols.

This does not mean that security actually will be improved.

The simple fact is this : security can only be improved by minimizing the extent to which your servers are exposed to bad clients.
Agreed, though it also helps with making it a little more difficult for cryptographic attacks including cypher suite downgrading and similar methods.

Obviously noted regarding bad clients (FYI I have been in the security field for 25 years ).

Since there are a lot of bad clients (and some companies are more prone to be exposed to be bad clients) out there, there is not always added valuable to get the Cipher suite fine-tuned and the A's and B's that SSL labs assign are of no value if one is exposed to bad clients.

Stated differently, given any combination of TLS protocols + Cipher Suite, a bad client connecting to your server will be a bad client.

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.

The TLS protocol and/or the Cipher suite will only make the connection a (tiny) bit better for a bad client.


In summary, the best thing that you can do within any Plesk environment is to run the PCI compliance resolver.

And do not forget to read this article.
Check, will do.

I hope the above helps a bit.
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.

Hence the reason for getting them sorted.

Thanks for the note regarding the Mozilla generator, always valuable to know.

 

[trialotto]

@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....

 

[Kaspar]

Looks like that option is no longer available within the Plesk panel.

Not sure if it's still relevant for you, but just in in case: the ciphers option got hidden from Plesk last year due to outdated ciphers. But can enabled again, see release not on the change log.

 

[Shamrock]

Not sure if it's still relevant for you, but just in in case: the ciphers option got hidden from Plesk last year due to outdated ciphers. But can enabled again, see release not on the change log.

Thanks, Plesk support actually noted the same thing this afternoon.
Looks like they may have it under development as well.
Would be a good thing to have this, likely based on the cyphersuites.info list.

They were also kind enough to translate, where necessary, the relevant algorithms from IANA to OpenSSL naming convention and help update the set via the command shared previously in this thread.
The list used was from www.cyphersuites.info where only the good and recommended TLS 1.3 and 1.2 suites were taken.
Not sure if that's the best list, but at least the 21 weak cypers are now off the configuration.

 

[trialotto]

@Shamrock

Looks like they may have it under development as well.

Do not expect too much.

It is rather impossible to make sense of what can be labelled as a "set of secure ciphers" - this differs across use-case scenario's and it changes over time.

Manual adjustments will always be required, if any adjustment is necessary.

The list used was from www.cyphersuites.info where only the good and recommended TLS 1.3 and 1.2 suites were taken.
Not sure if that's the best list, but at least the 21 weak cypers are now off the configuration.

Certainly not the best list.

One can use SSL Labs via a trial-and-error method : they provide a reasonably thorough check with some explanatory information.

Nevertheless, nobody will tell you which ciphers are dangerous in terms of vulnerability (read: potential threats) or actual threats.

For that kind of information, one has to dig through scientific articles, online (opinion) articles, vulnerability reports and so on.

For that reason, I recommended to (first) use a limited set of (strong) ciphers and only include (weaker) ciphers if really necessary.


Kind regards....

 

[Shamrock]

@Shamrock



Do not expect too much.

It is rather impossible to make sense of what can be labelled as a "set of secure ciphers" - this differs across use-case scenario's and it changes over time.

Manual adjustments will always be required, if any adjustment is necessary.




Certainly not the best list.

One can use SSL Labs via a trial-and-error method : they provide a reasonably thorough check with some explanatory information.

Next step probably. So does www.internet.nl btw.

Nevertheless, nobody will tell you which ciphers are dangerous in terms of vulnerability (read: potential threats) or actual threats.

Hence we need to rely on such lists to get the best possible outcome. I'm not a cryptologist and don't have time to read all those publications.
Risk based, this was the best/reasonable outcome without limiting access too much for (potential) customers.

For that kind of information, one has to dig through scientific articles, online (opinion) articles, vulnerability reports and so on.

For that reason, I recommended to (first) use a limited set of (strong) ciphers and only include (weaker) ciphers if really necessary.


Kind regards....

Indeed, yet I need to account for public people visiting, without a proper updated setup, or I would have ditched TLS 1.2 probably as well.
In this respect, the list is mostly also comparable to the Dutch NCSC (National Cyber Security Center) and the test tool internet.nl documentation, lets hope then they have done their homework.
Manual adjustments may still be required, but at least all the weak cyphers in accordance with that scanning tool are off the system. Which is an improvement, small gain yes as we discussed before

 

[trialotto]

@Shamrock

If this

Indeed, yet I need to account for public people visiting, without a proper updated setup, or I would have ditched TLS 1.2 probably as well.

is the only objective (people visiting), then you do not need to think about NCSC or go to internet-dot-nl (vague site, by the way).


If "visiting" is defined as "making your website accessible to modern browsers", then TLS 1.3 with a very strict cipher suite will always suffice.

If "visiting" is also defined as "making your website accessible to mobile devices too", then you probably need a TLS 1.2 + TLS 1.3 ( + TLS 1.1 - yes!!) + strong + weak ciphers combination.

That combination can only be effectively determined by using a development kit that can emulate all kinds of mobile devices - for each emulated device and/or app run on an emulated device, one has to determine the nature of the "client" and the requirements imposed to the TLS setup.

That is the odd thing - modern mobile devices all have modern browsers installed, but most apps do make connections via their own clients.

Having said that, it is not necessary to worry about mobile devices - one should simply have a golden rule that there is a "policy" concerning secure connections and devices that do not respect that policy should not have access.

It is a common mistake to focus on mobile devices and allow weak TLS + weak ciphers to be reachable for those devices - one the one hand, it might not even be necessary and on the other hand, it will make servers vulnerable to attack scripts that use clients that only connect via weak TLS + weak ciphers.


Kind regards.....