• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

SSL POODLE / SSLv3 bug

IgorG, in http://kb.odin.com/en/123160 there is no information about securing the Plesk Web Server itself. Why?

I patched it by adding
Code:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
to the /etc/sw-cp-server/conf.d/plesk.conf file and restarting the Plesk Web Server afterwards:
Code:
/etc/init.d/sw-cp-server restart
Is this correct?
 
IgorG, in http://kb.odin.com/en/123160 there is no information about securing the Plesk Web Server itself. Why?

I patched it by adding
Code:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
to the /etc/sw-cp-server/conf.d/plesk.conf file and restarting the Plesk Web Server afterwards:
Code:
/etc/init.d/sw-cp-server restart
Is this correct?
I would also appreciate a little more clarity on implementing this fix, including locations of all the relevant files, so we can be sure that config rebuilds or micro-updates don't overwrite the changes. Also, clarification on how to ensure that Plesk Panel itself is "fixed".
 
Thanks ThomasR the Plesk control panel was not protected and is not covered under any other suggested fixes.. your suggestion successfully protect the latest version of Plesk as of this post. So I thank you, sorry I do not know how to fix for 11.0
 
Update: http://kb.odin.com/en/123160 now (finally) provides a solution for both Plesk 11.0 and 11.5/12 servers:

Plesk 11.5 and later
Edit '/etc/sw-cp-server/config', add
Code:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Restart:
Code:
sudo service sw-cp-server restart
Plesk 11.0
Edit /usr/local/psa/admin/conf/ssl-conf.sh, add the echo 'ssl.use-sslv3 = "disable"' after the echo 'ssl.use-sslv2 = "disable"' directive, so it should looks alike:

Code:
echo 'ssl.engine = "enable"'
echo 'ssl.use-sslv2 = "disable"'`
echo 'ssl.use-sslv3 = "disable"'

Restart:
Code:
sudo service sw-cp-server restart
 
The paths for the NGINX configuration .php files in the KB article are still incorrect (for Plesk 12 anyway).

/usr/local/psa/admin/conf/templates/default/nginxWebmailPartial.php
/usr/local/psa/admin/conf/templates/default/nginxDomainVirtualHost.php
/usr/local/psa/admin/conf/templates/default/nginxVhosts.php​

They are:

/usr/local/psa/admin/conf/templates/default/nginxWebmailPartial.php
/usr/local/psa/admin/conf/templates/default/domain/nginxDomainVirtualHost.php
/usr/local/psa/admin/conf/templates/default/server/nginxVhosts.php​

It's also a little surprising that Parallels are recommending editing the 'default' templates. Is it not possible that a future micro-update that does not include a fix for POODLE might over write these changes?

I have followed the advice given in this thread and copied to a "custom" directory, and edited as suggested.

/usr/local/psa/admin/conf/templates/custom/nginxWebmailPartial.php
/usr/local/psa/admin/conf/templates/custom/domain/nginxDomainVirtualHost.php
/usr/local/psa/admin/conf/templates/custom/server/nginxVhosts.php​

It would be good to get official notification from Parallels when this fix is implemented in the "default" templates, so we can remove the "custom" ones.

Apart from these differences, I have followed the instructions as per KB 123160 and my servers now check out fine and are not vulnerable to POODLE. I've implemented the changes for APACHE, NGINX, POSTFIX and SW-CP-SERVER (I don't run DOVECOT or COURIER).

Thanks to all contributors to this thread, and Parallels for their assistance and guidance.
 
Igor, can we expect to see an upcoming MU to address this in the near future? If it's just a few days away (or in an upcoming MU) it would be great to know.
 
After applying the recommend changes to Courier IMAP/POP files users who access mail via SSL are unable to connect to the server - the following errors occur in the mail client:

Code:
There may be a problem with the mail server or network. Verify the settings for account or try again. The server returned the error: The connection to the server “www.domain.com” on port 993 timed out.

The server shows these errors in the maillog file:

Code:
Oct 18 07:51:02 hostname courier-pop3s: couriertls: accept: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
Oct 18 07:51:12 hostname courier-imaps: couriertls: connect: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

Has anyone else seen this and do you know how to fix this?
 
After applying the recommend changes to Courier IMAP/POP files users who access mail via SSL are unable to connect to the server - the following errors occur in the mail client:

Code:
There may be a problem with the mail server or network. Verify the settings for account or try again. The server returned the error: The connection to the server “www.domain.com” on port 993 timed out.

The server shows these errors in the maillog file:

Code:
Oct 18 07:51:02 hostname courier-pop3s: couriertls: accept: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
Oct 18 07:51:12 hostname courier-imaps: couriertls: connect: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

Has anyone else seen this and do you know how to fix this?

Which e-mail client and version is being used?
 
I'm still having issues after running the scripts to patch everything with NGINX on Port 7081

xxx.xxx.97.234:7081 - Vulnerable! SSLv3 connection established using SSLv3/DHE-RSA-AES256-SHA

I've tried modifying the nginx.conf file but still shows vulnerable.

Anyone have any ideas? Pulling my hair on this one.
 
Back
Top