SSL POODLE / SSLv3 bug

[Ultravoné]

Thanks for the detailed explanation, that's very helpful.

 

[Ultravoné]

I have one more question on this. Hopefully someone can advise.

If i'm running 11.5.3 with the described fixes in place and then I upgrade to Plesk 12, are all of these tweaks going to be overwritten?

i.e: will I need to either run the Poodle script again or manually configure protocols again after the update?

Thanks!

 

[UFHH01]

Well, in case you have some own custom modifications to configurations files, which are not templates ( and not custom templates to be specific ) and which are not changes recommended by Parallels over their knowledge base, well yes... in this case it might be possible that your own custom modifications could be overwritten by Plesk patches/updates/upgrades, I'm afraid. But.... and here comes the good part ... :

Plesk has a so called "Plesk configuration file monitor ( cfgmon )" and stores changed versions at: "/var/lib/plesk/cfgmon" If you would like to restore one of these files, you can use the command:

cp /var/lib/plesk/cfgmon/NAME_OF_THE_FILE_INCLUDING_DATE_AND_TIME /location/of/the/desired/path/NAME_OF_THE_FILE​

 

[Ultravoné]

Ah, thank you for the tip!

 

[gbotica]

I'm running Plesk Linux 12.0.18 Update #27.

I see that the default nginx configuration scripts (/usr/local/psa/admin/conf/templates/default/server/ ... have been updated with:

<?php if (get_param('disablesslv3')): ?>
    ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
<?php else: ?>
    ssl_protocols               SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
<?php endif ?>
    ssl_ciphers                 HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers   on;
<?php   endif ?>
<?php endif ?>

Does this mean we can remove the /usr/local/psa/admin/conf/templates/custom/ ... files as created earlier and rebuild the web config?

I haven't located where the 'disablesslv3' is set.

Thanks for your help.

 

[JanikoG]

The solution is here : http://talk.plesk.com/threads/new-plesk-12-install-has-poodle-unpatched.331094/#post-772948

 

[omexlu12]

Hello Guys,

First sry for my bad english.

I have a similiar Problem i am not able to connect IMAP/POP, ... on Plesk 12 (Debian) with a Mailclient.
In the errorlogs i get the following entry:
"courier-pop3s: couriertls: connect: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher"

I am not so the server specialist can maybe explain me how i can get a connection over mailclient (webmail works for receiving and sending mails)

Thanks

EDIT: Solved

 

[gbotica]

First I would like to thank UFHH01 for the solution provided, our exposure is resolved for now! Hope you don't mind, I have compiled all steps below:

Updated: Be sure you are using the correct directory for the templates.
"/opt/psa/admin/conf/templates/default" is not the same as "/usr/local/psa/admin/conf/templates/custom/" this might be distro specific or a typo on one or ther other...for me I used /usr/local/psa/admin/conf/templates/custom/

Ensure you first run the commands:


Grab a cup of coffee, this will be a while....[elevator music] When it completes you should be back to the shell prompt.

Updated:Make the directory /usr/local/psa/admin/conf/templates/custom/ if it does not already exist. When copying files to custom templates, ensure you are using the same directory structure and only copy over files you will be editing.

Commands:



Make the following code changes to the files below now located in /usr/local/psa/admin/conf/templates/custom/

ssl_session_timeout         5m;
ssl_session_cache shared:SSL:50m;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparam.pem;

After changes have been made be sure to:



# openssl s_client -connect DOMAIN:443 -ssl3

Expand/Collapse Block: Results

CONNECTED(00000003)
140324299970376:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40
140324299970376:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1413404209
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

Also according to the wonderful SSL site link provided by UFHH01: https://www.ssllabs.com/ssltest/

Expand/Collapse Block: Result

Protocols
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 No
SSL 2 No

This is very helpful for hardening server against POODLE and LOGJAM -- thanks!

However, it seems that the need to create custom templates (to add the ssl_ciphers updates and ssl_dhparam parameters) creates another problem ... as Plesk deploys updates that include changes to these web configuration templates, we would need to check if these files are modified and then merge them with our /custom template versions -- hardly a very elegant solution -- in order to patch for one problem, we are blocking our server from receiving future patches.

Is there a better way?

 

[trialotto]

@gbotica,

You stated

However, it seems that the need to create custom templates (to add the ssl_ciphers updates and ssl_dhparam parameters) creates another problem ... as Plesk deploys updates that include changes to these web configuration templates, we would need to check if these files are modified and then merge them with our /custom template versions -- hardly a very elegant solution -- in order to patch for one problem, we are blocking our server from receiving future patches.

Is there a better way?

And yep, there is a simple, better and update-proof way: do not fiddle with templates, (custom) configure Nginx!

Just add a custom .conf file to /etc/nginx/conf.d/, for instance ssl-custom.conf.

Note that the file ssl.conf already exists and that your custom directives have to be somewhat adjusted.

The ssl.conf file contains the following lines by default:

ssl_ciphers HIGH:!aNULL:!MD5;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;

The ssl-custom.conf file should hence include the lines:

ssl_session_timeout 5m;
ssl_session_cache shared:SSL:50m;

ssl_dhparam <location of .pem file>;

and one could also include the cipher suite in this ssl-custom.conf file (uncomment the ssl_ciphers in ssl.conf) or adjust the cipher suite in ssl.conf.

Please be aware of the caveats of the approach to adopt a Ephemeral Diffie-Hellmann (DHE) key exchange process by implementing the ssl_dhparam directive:

a) a potential conflict with standard ssl related nginx directives,

b) a heavy punishment, in terms of performance,

c) a necessity to create an elaborate cipher suite, that has to become even more extensive when wanting to allow for backwards compatibility,

d) some versions of OpenSSL (i.e. the standard versions) do not return the required or some of the required algorithms,

e) certificates and keys have to be perfectly aligned: nginx relies on OpenSSL and the "danger" of the default 1024-bit OpenSSL key for key exchange exists, in the sense that security of a 2048-bit certificate can be comprised, if the default 1024-bit key is used by mistake,

and the above caveats are only the most important ones.

In conclusion, if you really want to implement the ssl_dhparam directive, generate a stronger DHE parameter that is in line with the certificate being used.

And in the current solution proposed, nobody seems to hint to the dangers of using default OpenSSL keys with, for instance, 2048-bit certificates.

In my humble opinion, good ideas and solutions should be implemented well and I am asking openly whether this is the way forward to hardening Nginx SSL/TLS configuration.

Anyway, the idea behind PFS (Perfect Forward Secrecy) is excellent, I am in favour of DHE key exchange.

Regards....