SSL POODLE / SSLv3 bug

[cmaxwell]

Solved!

Hi guys!

Finally solved courier-imap issues with:

****************************************
TLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="ECDH+AESGCMH+AESGCM:ECDH+AES256H+AES256:ECDH+AES128H+AES:ECDH+3DESH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"
****************************************

It has been update on KB123160

Now my plesk is OK about poodle for POP3S and IMAPS too:

myplesk:993 - Not vulnerable. Failed to establish SSLv3 connection.
myplesk:995 - Not vulnerable. Failed to establish SSLv3 connection.

Tested with Thunderbird client.

Thanks all!

Thanks for letting us know the KB article has been revised - the new ciphers work well for for Courier POP/IMAP.

Only vulnerable port left now is port 465 (Qmail). Do you use Qmail or Postfix? The fix in ssl_v3_disable.sh for Qmail is to add this line to /var/qmail/control/tlsserverciphers:

ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:+HIGH:+MEDIUM

But with that code, no mail clients can send mail. Is there a fix for Qmail that works properly with Plesk 11.5.30?

 

[StewartGC]

Thanks UFHH01 we had a look at this and the other posts but our poodle.sh always reports 993 & 995 as vulnerable unless we have :!SSLv2:!SSLv3 in the IMAP/POP Cipher list.

If we do then of course SSL is disabled and all is reported as not vulnerable by poodle.sh

However then any client using an IPhone for example cannot connect to mailboxes on POP/IMAP 993/995 as the IPhone only supports SSL and does not have a TLS option like Android.

Can anyone help on how to make all ports not vulnerable but still allow IPhone to connect on 993/995 POPS/IMAPS?

 

[cmaxwell]

Thanks UFHH01 we had a look at this and the other posts but our poodle.sh always reports 993 & 995 as vulnerable unless we have :!SSLv2:!SSLv3 in the IMAP/POP Cipher list.

If we do then of course SSL is disabled and all is reported as not vulnerable by poodle.sh

However then any client using an IPhone for example cannot connect to mailboxes on POP/IMAP 993/995 as the IPhone only supports SSL and does not have a TLS option like Android.

Can anyone help on how to make all ports not vulnerable but still allow IPhone to connect on 993/995 POPS/IMAPS?

What version of Plesk are you using? And did you update the TLS_CIPHER_LIST and TLS_PROTOCOL settings as per the updated KB article?

 

[cmaxwell]

Thanks UFHH01 we had a look at this and the other posts but our poodle.sh always reports 993 & 995 as vulnerable unless we have :!SSLv2:!SSLv3 in the IMAP/POP Cipher list.

If we do then of course SSL is disabled and all is reported as not vulnerable by poodle.sh

However then any client using an IPhone for example cannot connect to mailboxes on POP/IMAP 993/995 as the IPhone only supports SSL and does not have a TLS option like Android.

Can anyone help on how to make all ports not vulnerable but still allow IPhone to connect on 993/995 POPS/IMAPS?

I should also add - the iPhone does support TLS. It sounds as if you are using the old TLS_CIPHER_LIST settings which were found not to work properly.

 

[StewartGC]

We are running Plesk v12.0.18 update 5 and we have followed the same Plesk KB article http://kb.odin.com/en/123160 and have also applied the new cipher lists for the courier-imap as below:

************************************
/etc/courier-imap/pop3d-ssl
/etc/courier-imap/imapd-ssl
Add or modify the TLS_PROTOCOL and TLS_CIPHER_LIST directives so they look like:
************************************

************************************
TLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="ECDH+AESGCMH+AESGCM:ECDH+AES256H+AES256:ECDH+AES128H+AES:ECDH+3DESH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"
************************************

 

[cmaxwell]

We are running Plesk v12.0.18 update 5 and we have followed the same Plesk KB article http://kb.odin.com/en/123160 and have also applied the new cipher lists for the courier-imap as below:

************************************
/etc/courier-imap/pop3d-ssl
/etc/courier-imap/imapd-ssl
Add or modify the TLS_PROTOCOL and TLS_CIPHER_LIST directives so they look like:
************************************

************************************
TLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="ECDH+AESGCMH+AESGCM:ECDH+AES256H+AES256:ECDH+AES128H+AES:ECDH+3DESH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"
************************************

So with those settings in place, are you able to connect to the mail server and get mail? And does poodle.sh show your ports are vulnerable/not vulnerable?

 

[StewartGC]

With these settings then yes an IPhone can connect with SSL on IMAP/POP 993/995 and get email.

However poodle.sh reports this.

127.0.0.1:21 - Not vulnerable. Failed to establish SSLv3 connection.
127.0.0.1:25 - Not vulnerable. Failed to establish SSLv3 connection.
127.0.0.1:587 - Not vulnerable. Failed to establish SSLv3 connection.
127.0.0.1:443 - Not vulnerable. Failed to establish SSLv3 connection.
127.0.0.1:465 - Not vulnerable. Failed to establish SSLv3 connection.
127.0.0.1:7081 - Not vulnerable. Failed to establish SSL connection.
127.0.0.1:8443 - Not vulnerable. Failed to establish SSLv3 connection.
127.0.0.1:993 - Vulnerable! SSLv3 connection established using SSLv3/DHE-RSA-AES256-SHA
127.0.0.1:995 - Vulnerable! SSLv3 connection established using SSLv3/DHE-RSA-AES256-SHA

If we add :!SSLv2:!SSLv3 at the end of the cipher list we get "not vulnerable" for all ports.

But then as SSL is then blocked an IPhone cannot connect as it can only use SSL and does not have TLS option.

 

[cmaxwell]

With these settings then yes an IPhone can connect with SSL on IMAP/POP 993/995 and get email.

However poodle.sh reports this.

127.0.0.1:21 - Not vulnerable. Failed to establish SSLv3 connection.
127.0.0.1:25 - Not vulnerable. Failed to establish SSLv3 connection.
127.0.0.1:587 - Not vulnerable. Failed to establish SSLv3 connection.
127.0.0.1:443 - Not vulnerable. Failed to establish SSLv3 connection.
127.0.0.1:465 - Not vulnerable. Failed to establish SSLv3 connection.
127.0.0.1:7081 - Not vulnerable. Failed to establish SSL connection.
127.0.0.1:8443 - Not vulnerable. Failed to establish SSLv3 connection.
127.0.0.1:993 - Vulnerable! SSLv3 connection established using SSLv3/DHE-RSA-AES256-SHA
127.0.0.1:995 - Vulnerable! SSLv3 connection established using SSLv3/DHE-RSA-AES256-SHA

If we add :!SSLv2:!SSLv3 at the end of the cipher list we get "not vulnerable" for all ports.

But then as SSL is then blocked an IPhone cannot connect as it can only use SSL and does not have TLS option.

In imapd-ssl/pop3d-ssl have you made sure there are no other lines that might be overriding your settings? Check the whole file to make sure there are no other TLS_CIPHER_LIST settings in place that may be interfering with your settings. It should not be necessary to add "!SSLv2:!SSLv3" to the cipher list from the KB article.

I don't have a Plesk 12 box to test this on as we're still on 11.5 for all servers so maybe someone else can chime in with their suggestions.

 

[StewartGC]

Yeah there are basically 2 issues:

1. In PLesk 12 why does poodle.sh still show as vulnerable after applying the new cipher list?

2. What workaround is there to secure ports 993/995 but still get email on an IPhone that does not support TLS?

I checked our pop3d-ssl & imapd-ssl and there are no other entries we just have this at the end of the files.

************************POP3D-SSL************************
MAILDIRPATH=Maildir
POPLOCK_TIME=30
MAXDAEMONS=80
MAXPERIP=40
TLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="ECDH+AESGCMH+AESGCM:ECDH+AES256H+AES256:ECDH+AES128H+AES:ECDH+3DESH+3DES:RSA+AESGCM:RSA+AES
:RSA+3DES:!aNULL:!MD5:!DSS"
************************IMAPD-SSL************************
MAILDIRPATH=Maildir
MAXDAEMONS=80
MAXPERIP=40
TLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="ECDH+AESGCMH+AESGCM:ECDH+AES256H+AES256:ECDH+AES128H+AES:ECDH+3DESH+3DES:RSA+AESGCM:RSA+AES
:RSA+3DES:!aNULL:!MD5:!DSS"

Maybe Plesk or someone doing this on Plesk 12 can comment.

 

[UFHH01]

As mentioned before, NOT ALL SSL3 ciphers are vulnerable. Please keep in mind, that the suggested "poodle.sh" just searches for all allowed SSL3 ciphers on your system, as you may see in the code:

host=${1:-127.0.0.1}

port=${2:-443}
protocol=${3:-ssl3}
timeout_bin=`which timeout 2>/dev/null`

Again: Please use the site https://www.ssllabs.com/ssltest/ to test if you are vulnerable.

 

[JCV]

Thanks for letting us know the KB article has been revised - the new ciphers work well for for Courier POP/IMAP.

Only vulnerable port left now is port 465 (Qmail). Do you use Qmail or Postfix? The fix in ssl_v3_disable.sh for Qmail is to add this line to /var/qmail/control/tlsserverciphers:

ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:+HIGH:+MEDIUM

But with that code, no mail clients can send mail. Is there a fix for Qmail that works properly with Plesk 11.5.30?

Hi cmaxwell!

I use postfix.

With main.cf like this:

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3


It works and client can send perfectilly for 465.

 

[Alex_Wilkes]

hi is it possible to just update to openssl 1.0.1j

i tried yum update openssl but it is not updating to j version

i am on plesk 12 centos

thanks
alex

 

[Ultravoné]

So, as I understand it, if you use Plesk 11.5.3 or Plesk 12.0.18 with Postfix, and have run the ssl_v3_disable script (Linux) linked to in the KB article (http://kb.odin.com/en/123160), you are going to have problems with users using SSL in their mail clients, particularly on the iPhone, until such time as someone provides an update or another script which fixes the problem? Correct?

 

[cmaxwell]

@Ultravoné It should work just fine - the ssl_v3_disable.sh script has been updated several times by Parallels in response to the feedback from users in this thread. The current version applies the cipher settings which are compatible with all modern mail clients. However, it's a simple change to revert it if you do indeed experience problems.

 

[Ultravoné]

@Ultravoné It should work just fine - the ssl_v3_disable.sh script has been updated several times by Parallels in response to the feedback from users in this thread. The current version applies the cipher settings which are compatible with all modern mail clients. However, it's a simple change to revert it if you do indeed experience problems.

Oh, I see. So if i'm on 11.5.3, is it worth running the script again? Is there an article that describes how to revert the process? I haven't found one yet.

Thanks a lot for your reply.

 

[cmaxwell]

Oh, I see. So if i'm on 11.5.3, is it worth running the script again? Is there an article that describes how to revert the process? I haven't found one yet.

Thanks a lot for your reply.

Have you already run the script? If so, are you experiencing problems? I wouldn't run the script again if it has already been run as this will just duplicate the same configuration entries.

There isn't an article on how to revert the process, but this would just be a case of working out what was changed by the ssl_v3_disable.sh script and then reversing it (it's fairly simple changes that it makes).

 

[Ultravoné]

Have you already run the script? If so, are you experiencing problems? I wouldn't run the script again if it has already been run as this will just duplicate the same configuration entries.

There isn't an article on how to revert the process, but this would just be a case of working out what was changed by the ssl_v3_disable.sh script and then reversing it (it's fairly simple changes that it makes).

Thanks for the info. Yes, I found that pretty much all of my users had trouble using SSL in their mail clients after I ran the script. This was a couple of days after the KB article was published. At first I assumed they had outdated software, but as things have unfolded, i've come to realise that it's more complicated than that for users trying to use ports like 993/995/465 in a range of mail clients.

 

[cmaxwell]

Thanks for the info. Yes, I found that pretty much all of my users had trouble using SSL in their mail clients after I ran the script. This was a couple of days after the KB article was published. At first I assumed they had outdated software, but as things have unfolded, i've come to realise that it's more complicated than that for users trying to use ports like 993/995/465 in a range of mail clients.

What I suggest doing is review the Courier IMAP and Postfix SMTP sections in the current version of the KB article (http://kb.odin.com/en/123160) and compare the suggested changes with your current files - I suspect the cipher lists will be different as those were updated about a week after the original KB article was published. In which case, update your files accordingly and then restart Courier and Postfix.

 

[Ultravoné]

What I suggest doing is review the Courier IMAP and Postfix SMTP sections in the current version of the KB article (http://kb.odin.com/en/123160) and compare the suggested changes with your current files - I suspect the cipher lists will be different as those were updated about a week after the original KB article was published. In which case, update your files accordingly and then restart Courier and Postfix.

Thank you for the excellent advice. Much appreciated.

 

[UFHH01]

It's not all about outdated software incompatibility but more the fact, that most scripts and tutorials define a work-around for your server like: "!SSLv2 !SSLv3". This is a WRONG solution, because it does exclude as well ciphers, which use TLSv1 and doesn't include TLSv1.1 and TLSv1.2 .


For example:
You have postfix installed and your main.cf has the definition: "smtpd_tls_protocols = SSLv3, TLSv1". A script or tutorial advice a change with "smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3".

To be detailed, your modification says: "accept SSLv3 and TLSv1" ( nothing else! ) and "forbid ALL SSLv2 and SSLv3" protocols. In fact, you are removing all excepted protocols with this modification, because the TLSv1 protocols are not listed as TLSv1, but as SSLv3 - protocols. Control this with the command: openssl ciphers -v 'TLSv1' | sort

The correct way would be to define all acceptable protocols and then forbid the ones, you don not want to use: "smtp_tls_protocols = TLSv1, TLSv1.1, Tlsv1.2, !SSLv2, !SSLv3" and "smtpd_tls_mandatory_protocols = TLSv1, TLSv1.1, Tlsv1.2, !SSLv2, !SSLv3"


Another reason for failures/issues/problems is, that the ciphers definitions are not precise enough:
Some scripts and/or tutorials change the ciphers suites to be "medium", or "high" and don't define explicit WHAT should be exepted and what should be forbidden. Most of them exclude cipher suites, no matter if they are vulnerable or not, just because it is easier to configure, but don't think about that some software and/or clients just don't work with certain cipher suites at all.

Again, I post the "intermediate" solution from mozilla.org ( https://wiki.mozilla.org/Security/Server_Side_TLS ), which defines explizit what you accept and what you forbid on your server:

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

Apart from very few old browsers, this intermediate solution works for most people and their used software. The ones who still experience issues should really update to actual versions of their software and you could provide links to update sites on the web for them, instead of trying to search the issue on your server settings.