How to prevent SSLv2 from being supported on cpanel

[canfone]

Hi There,

I am working with a client to receive PCI Certification and the reporting tool that is being used finds issues with the support of SSLv2 on cpanel SSL ports:

2083/General remote services (tcp)
2087/General remote services (tcp)

and others:

SSL Server Supports Weak Encryption Vulnerability

I have followed the reccomendations and added these lines to the httpd.conf which has taken care of SSL on 443:

SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

Does anyone know how I can disable SSLv2 on cpanel ports?


cPanel ticket: 195603 opened

[shashank]

Hello,

I am not sure how to do this with the new cpanel native ssl support. Until cpanel provides with you with a fix you can do the following.

edit /var/cpanel/cpanel.config and change nativessl=1 to nativessl=0 . This will make cpanel use stunnel again.

The you should edit /usr/local/cpanel/etc/stunnel/default/stunnel.conf and add

options = NO_SSLv2 just below the Authentication stuff and restart cpanel.

SSLv2 support for all cpanel ports will now be disabled. You can test this like :

$ openssl s_client -host serversipadress -port 2083 -verify -debug -ssl2
verify depth is 0
CONNECTED(00000003)
write:errno=104

SSLv3 and TLSv1 will still work, you can test it using :

$ openssl s_client -host serversipaddress -port 2083 -verify -debug -ssl3
verify depth is 0
CONNECTED(00000003)
depth=0 /C=US/ST=Unknown/L=Unknown/O=Unknown/OU=Unknown/CN=server.mydomain.com/emailAddress=ssl.net
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=Unknown/L=Unknown/O=Unknown/OU=Unknown/CN=server.mydomain.com/emailAddress=ssl.net
verify return:1
---
Certificate chain
 0 s:/C=US/ST=Unknown/L=Unknown/O=Unknown/OU=Unknown/CN=server.mydomain.com/emailAddress=ssl.net
   i:/C=US/ST=Unknown/L=Unknown/O=Unknown/OU=Unknown/CN=server.mydomain.com/emailAddress=ssl.net
.....
.....
.....
---
No client certificate CA names sent
---
SSL handshake has read 1065 bytes and written 312 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
SSL-Session:
    Protocol  : SSLv3
    Cipher    : AES256-SHA
    Session-ID: 4D82505199748AEF3D1F5447A87C19C15A8D1B71E41811EC88CB51377BBEAC66
    Session-ID-ctx:
    Master-Key: 7678931110FC624DFA6BE32D41B36940F90F0DB9CB0F757893196342D5BABEB11DD0758E8CE5EDE07A4ED809123A9415
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1188882223
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
---

Please let me know if you have any questions.

[tvcnet]

Hi,
The solution did not work for me:
[/usr/lib/courier-imap/etc]# openssl s_client -host localhost -port 2083 -verify -debug -ssl2
verify depth is 0
CONNECTED(00000003)
depth=0 /C=US/2.5.4.17=91977
<snip>
</snip>
verify error:num=21:unable to verify the first certificate
verify return:1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFUTCCBDmgAwIBAgIRANDQ8hx8wAkj77o4zhjqF4MwDQYJKoZIhvcNAQEFBQAw
<snip>
</snip>
Ciphers common between both SSL endpoints:
RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5
EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5
RC4-64-MD5
---
SSL handshake has read 1501 bytes and written 239 bytes
---
New, SSLv2, Cipher is DES-CBC3-MD5
Server public key is 1024 bit
SSL-Session:
Protocol : SSLv2
Cipher : DES-CBC3-MD5
Session-ID: B7290903DF00B9FF4188F644B0AEDCFD
Session-ID-ctx:
Master-Key: 9F6863869BD2A06EB864B14151844AA517282907FC717466
Key-Arg : A9FE8723537063D9
Krb5 Principal: None
Start Time: 1215032268
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)

Is this still the standard workaround?

[shashank]

I am not sure if there is an official fix out from cpanel yet on this but I have tested this even today and even had a friend test it and it works for us. It seems cpanel restart is needed in your case . Try running /usr/local/cpanel/startup after you have made the change.

[dredding]

I am also curious as to how this can be achieved using nativessl.

[Dathorn_ADT]

I actually just opened a ticket on this very issue yesterday and was told that this can only be changed using the old stunnel implementation. Not a great solution IMO. Perhaps some day they will take PCI compliance seriously.

[rpertiet]

I just went through this on our site and am now PCI DSS compliant.

*** For Apache:

1) Add to HTTPD.CONF

SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite HIGH:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!kEDH

Then run

Code:
/usr/local/apache/bin/apachectl configtest

to ensure you did not break the configuration file. If it says OK then run

Code:
/usr/local/cpanel/bin/apache_conf_distiller --update --main

to save the changes and finally restart Apache

Verify that SSL v2 is disabled by running the following commands (change HOSTNAME.com to your server's correct hostname):

Code:
openssl s_client -ssl2 -connect hostname.com:443
This should fail with an ssl handshake failure message


Code:
wget --spider --secure-protocol=SSLv2 https://hostname.com/
This should fail with an Unable to establish SSL connection message


*** To limit smtps to SSLv3 and TLS, add the following to /etc/exim.conf

Code:
tls_require_ciphers = SSLv3:TLS
And then restart exim.

You can then test with the following command:

Code:
openssl s_client -ssl2 -connect your.hostname.com:465
Try that using each of the following: -ssl2, -ssl3 and -tls1. It should now only work when using -ssl3 or -tls1. It should fail when you use -ssl2; you'll see something like this at the end and it will drop your connection:


Code:
28120:error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list:s2_clnt.c:450:


*** Securing your Courier IMAP:
Locate and open imapd-ssl file (typically found in /usr/lib/courier-imap/etc/). Add the following directives and file locations:

Code:
TLS_PROTOCOL=SSL3

*** Securing your POP3:
Locate and open pop3d-ssl file (typically found in /usr/lib/courier-imap/etc/). Add the following directives:

TLS_PROTOCOL=SSL3

Then restart POP3 and IMAP and that's it for SSLv3.

[tvcnet]

For HTTPS, POP3 and IMAP, I had no problems implementing the fixes. I'm double checking the cpanel configuration right now.

[tvcnet]

Issue almost resolved:

[/usr/lib/courier-imap/etc]# ps auxww | grep stunnel
cpanel 31688 1.2 0.0 4064 1564 ? Ss 09:48 0:00 /usr/sbin/stunnel /usr/local/cpanel/etc/stunnel/mycabundle/stunnel.conf.run

I edited that file and now it seems to work:
root@vs08 [/usr/lib/courier-imap/etc]# openssl s_client -host localhost -port 2083 -verify -debug -ssl2verify depth is 0
CONNECTED(00000003)
write:errno=104

Double checking with ssl3:
[/usr/lib/courier-imap/etc]# openssl s_client -host localhost -port 2083 -verify -debug -ssl3
<snip>
SSL handshake has read 1543 bytes and written 312 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : SSLv3

port 2078:
openssl s_client -host vs08 -port 2078 -verify -debug -ssl2
<snip>
Ciphers common between both SSL endpoints:
RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5
EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5
RC4-64-MD5
---
SSL handshake has read 1501 bytes and written 239 bytes
---
New, SSLv2, Cipher is DES-CBC3-MD5
Server public key is 1024 bit
SSL-Session:
Protocol : SSLv2

Why would port 2078 be the exception?

[carock]

I edited both stunnel.conf files shown in this thread, but my cPanel still accepts SSL V2.

What else can it be using?

Chuck

[carock]

cPanel support fixed me. I missed editing the /var/cpanel/cpanel.config file.

My bad

[carock]

All the changes I made to the stunnel config have reverted back. I guess upcp "fixed" the changes. Now it supports SSL v2 again!!!

Is there a more permanent fix for the stunnel config?

Chuck

[inetbizo]

http://bugzilla.cpanel.net/show_bug.cgi?id=6413 the cpanel bugzilla report

Please vote for bug SSLV2 through cpanel ports the linked forum post for the bug report

stunnel is not the way to go. And I quote:

I do not know of any links that explain how to switch to stunnel. I would recommend that you do not switch to stunnel as well.

Sincerely,

Steven King
Systems Administrator
Help Desk Specialist
CompTIA A+ Certified Professional
CompTIA Linux+ Certified Professional

Liquid Web, Inc.
support@liquidweb.com
800.580.4985
517.322.0434 Int.

[carock]

cPanel support says stunnel is fine, they just are not maintaining it or adding anything special for it like they can and do with their own SSL drive.

With cPanel support help, I have a script that will automatically run after upcp to put the modification back for stunnel config.

The file /scripts/postupcp when it exists will automatically be called by the nightly upcp script.

My postupcp file has this code in it to re-apply the SSLv2 fix to the stunnel.conf.

#!/bin/sh

# backup current stunnel config
cp /usr/local/cpanel/etc/stunnel/mycabundle/stunnel.conf /usr/local/cpanel/etc/stunnel/mycabundle/stunnel.conf-backup

# read in config file and look for option already there
for file in /usr/local/cpanel/etc/stunnel/mycabundle/stunnel.conf
do
        # check for config line already there, if so, skip modification
        grep "options = NO_SSLv2" $1/$file > /dev/null
        if [ $? -ne 0 ]
        then
                echo "stunnel.conf NO_SSLv2 option not found"
                # insert option line under authentication stuff
                cat /usr/local/cpanel/etc/stunnel/mycabundle/stunnel.conf | sed '/# Some debugging stuff/i options = NO_SSLv2' > /usr/local/cpanel/etc/stunnel/mycabundle/stunnel.conf.1
                mv /usr/local/cpanel/etc/stunnel/mycabundle/stunnel.conf.1 /usr/local/cpanel/etc/stunnel/mycabundle/stunnel.conf
                # restart cPanel
                /etc/init.d/cpanel restart
        fi
# if the line already exists in the stunnel config, the do nothing.
done
exit 0

That has been working for several days now and allows my server to pass the SSLv2 security tests after making all the other modifications from the top of this thread.

Thanks,
Chuck

[inetbizo]

Adding the correct Net::SSLeay::ssl_version=3 to /usr/local/cpanel/chksrvd-ssl shouldn't be so hard? If this is the compiled binary to call chksrvd-ssl? They've had PLENTY of time to fix this issue!