Plesk 12 Odin script to disable SSLv3 problems

[IATechsupport]

We have tested one of our CentOS 6.6 Plesk 12 servers to see if it was vulnerable to the poodle attack using the poodle.sh script from http://kb.odin.com/en/123160 and found it was.

Then downloaded the special script from the same article run the script and re tested and everything was no longer vulnerable. But then started getting complaints from customers that they could not send email anymore and looking at it found errors like:

qmail: 1436280789.522657 delivery 768: deferral: TLS_connect_failed:_error:14082174:SSL_routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh_key_too_small;_connected_to

After looking in the forum found an extended cyphers list, which when used starts to allow email to be sent as normal. But then checking with the vulnerability script agian find that it has also allowed connections to ports 587 and 465 agian via SSL3v

Webmail used is Roundcube and Horde.

We can't seem to get around this issue so any help would be great..

 

[UFHH01]

Hi IATechsupport,

I know it might be a bit confusing, IATechsupport, but please check the following command, to understand the recommendation you already tried:

openssl ciphers -v 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'

As you can see, this will list all your ciphers, which you will use, when following the suggestion from https://wiki.mozilla.org/Security/Server_Side_TLS for "Intermediate compatibility". This is the default recommendation, even that you will find some SSLv3 - ciphers - usage, which are NOT vulnerable.
The Poodle Test from Odin/Parallels only tests the SSL - version - definitions, but not their possible vulnerability; so if the test finds a SSLv3 - cipher, it will always declare the system as vulnerable, even that this is not the case, when you use the recommendation from Mozilla.org, as linked above.

If you are unsure, whether Mozilla.org is a trusted source or not, please inform yourself about the "Operations Security (OpSec) team" and their reputation(s) and efforts.

 

[IATechsupport]

Thanks for the info, it would have been nice if Parallels would have included this info in there original link.

 

[IATechsupport]

We are still seeing the odd error in the mail log like this;
failure: TLS_connect_failed:_error:14082174:SSL_routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh_key_too_small

It's not happening all the time, any ideas ?

 

[UFHH01]

Hi IATechsupport,

please have a closer look to this thread: Postfix with individual 2048bit DH group for PFS without Logjam, Poodle, FREAK ( Odin/Parallels - Forum link )

... if might explain a bit your issue with a suggestion, how you might solve it. Your error code states clear, that a client tries to exchange a DH key, lower than defined, which your own mail-server - settings and definitions denied.

 

[IATechsupport]

We use Qmail and not postfix, postfix is not running on our setup. I see the point but can't seem to find it in Qmail.

 

[UFHH01]

Hi IATechsupport,

qmail is very different to postfix on this behalf and because you can't force the remote hosts to update their openssl version on their server to the latest version, you can solve this issue, by adding trusted hosts and disable TLS for them, in order to continue receiving eMails from them. I personally don't recommend the usage of "notishosts/FQDN" ( http://wiki.qmailtoaster.com/index.php/Notlshosts/FQDN ) with qmail, but in some buisiness cases, the customer wants to give up the security options, to continue eMail - communication with poorly configured hosts/servers.

Another option is to downgrade your own openssl version on your server - which I don't recommend as well! As far that I know, on CentOS, openssl versions < 1.0.1e-30.el6.9 don't cause issues as described.


You can add trusted hosts in qmail like this:

mkdir /var/qmail/control/notlshosts
touch /var/qmail/control/notlshosts/mail.domain.com

restart qmail afterwards to make it work.

mail.domain.com has to be the MX - record of the trusted domain! Hint: use: dig mx domain.com to get the record, if you are unsure about it.