Issue Security -> TLS versions and ciphers by Mozilla

[mr-wolf]

I recently installed a new Plesk Obsidian server and started to migrate clients to this new server.
One of those clients called me and told me that her Outlook was not working.
It of course had to be related to that migration, but she wasn't the first to be migrated there and others were working fine.

During a Teamviewer session it was clear that her Outlook 2010 did not want to connect.
I then thought of my decision to use the "Modern" ciphers.
On all my previous servers I changed these versions manually in Nginx, but on this server I tried the "lazy option".

Indeed, it was that setting as it started to work after I switched to "Intermediate".

Because I would prefer Modern ciphers on Nginx, but another setting for my Dovecot, I would prefer it that these settings are split.
Isn't this a good feature suggestion or what?

 

[learning_curve]

....Because I would prefer Modern ciphers on Nginx, but another setting for my Dovecot, I would prefer it that these settings are split. Isn't this a good feature suggestion or what?

Meantime, as far as we're aware / can remember, you could specify your own level of ciphers in this file: /etc/dovecot/conf.d/11-plesk-security-ssl.conf if you wanted too, but, this is usually over written with each Plesk Upgrade, if, it differs from the specific settings stored within the Plesk sslmng utility which takes precedence during the upgrade. Or, you could modify the ciphers there directly, e.g. plesk sbin sslmng --services=dovecot --custom --ciphers="YOUR-DESIRED-CIPHERS-LISTS" which would then provide the data that is used for the previously metioned ssl.conf file at each Plesk upgrade. Check and test all this first, but that should separate your Nginx and Dovecot ciphers as a workaroud we think.

 

[mr-wolf]

Thanks, but I can do it manually if I want to.
It seems to me this should have been separate by design in the first place (or at least the option to split like you would do playing blackjack)

I also see it done for WiFi-credentials on dual-radio AP's

 

[trialotto]

@mr-wolf

I fully agree that specific settings of a specific extension should not have any impact on general (server-wide) cipher configuration.

Moreover, the whole combination of cipher settings, tools to manage them and extensions is a bit messy.

In fact, the following applies :

- the "TLS versions and ciphers by Mozilla" settings are part of the SSLit! extension configuration, (and)
- the "TLS versions and ciphers by Mozilla" settings have to be manually updated - no automatic updates here, even though this is important (!), (and)
- all ciphers can be managed via the sslmng (CLI) utility and edited manually, (and)
- all ciphers can be adjusted to meet PCI DSS compliant configuration by using the pci_compliance_resolver (CLI) utility, (and)
- the Let's Encrypt certificates are managed and/or generated by the Let's Encrypt extension, (and)
- the "TLS versions and ciphers by Mozilla" settings have little or no impact on the generated Let's Encrypt certificates on the server-wide level, (and)
- the SSLit! extension allows for adjustment of the type of Let's Encrypt generated certificates on the domain level, (and)
- the "TLS versions and ciphers by Mozilla" settings are not configurable or adjustable on the domain level,

and so on.

All of the above simply means that development is taking a wrong direction - one comprehensive extension (with CLI utilities) should be sufficient or better.

Sure, that one comprehensive extension should also allow to configure cipher settings on a service level - there is no valid reason for using identical cipher suites for services that are completely different by nature, such as Apache versus Dovecot.

In addition, cipher suite levels are intended to reduce vulnerabilities - specific services should have more strict cipher suites than other services.

In short, I fully agree........ for many (obvious) reasons.

Kind regards..............