de-POODLE-ing: How to Disable Support for SSLv3 on a cPanel Server
- Written by Vanessa Vasile
- Published in Apache, Fixes, Howto, Linux, News, Security
- 35 Comments
- Permalink
The latest security buzz this month is about the SSLv3 POODLE vulnerability, and how SSL version 3.0 is now officially designated as insecure, joining its predecessors versions 1.0 (unreleased) and 2.0. This effectively concludes the life cycle of the SSL protocol in favor of TLS. This post will give you a brief overview of what POODLE is, and how to protect against it on a cPanel system.
Unlike Heartbleed though, the problem is actually [mostly] on the client side. When a browser, or really any client that connects to an encrypted service, connects to a website over https, it’ll use the newest protocol that it can (at present, that is TLS 1.2, soon to be replaced with 1.3). If it’s unable to connect, the present behavior for most is to re-negotiate using older protocols. This in itself is not the actual vulnerability, only the behavior that causes the exploit to be successful. The actual problem behind the POODLE vulnerability is that information accessed via an SSLv3-encrypted connection is not actually secure, as we found out. An attacker can use the browser’s “fallback” capabilities to essentially persuade the browser to use SSLv3, then execute a man-in-the-middle attack to read transmitted data in plain text. We won’t go over the details here, but you can read a full explanation of the vulnerability in Google’s published security advisory.
While the burden of this exploit is on the client end, server administrators should take action to disable SSLv3 on their servers. While any modern browser supports TLS 1.0/1.1/1.2, it’s a known fact that some people just don’t update their software. Companies such as Google and Mozilla are working to disable fallback support in Chrome and Firefox, respectively, but if someone hasn’t updated their browser since 2008, they probably can’t be expected to do it now. There’s are also web servers that are not configured to allow TLS, thus forcing the browser to negotiate with an older protocol. So there are indeed two sides to this problem, and the disabling of older protocols on either the client or server end can cause compatibility problems. The end result is, everyone has some updating to do.
Note: OpenSSL did release a patch to help prevent client-side protocol fallbacks, but this does not fully address the problem.
Services not affected:
- OpenSSH (does not utilize OpenSSL)
Disabling SSLv3 for Apache
At present, cPanel does not yet support disabling SSL protocols through their interfaces, so you’ll need to do it manually via command line. I’ll try to remember to update this post when they change this, as I hear they have an open case for it right now.
Disabling via SSLProtocol
Update 10/22: As of cPanel 11.44.1.19, you can now change the cipher list via WHM -> Apache Configuration -> Global Configuration -> SSL/TLS Cipher Suite:
All -SSLv2 -SSLv3
To do this via CLI, edit /var/cpanel/conf/apache/local and edit this line (it may not exist by default, so you can just add it under sslciphersuite:
"sslprotocol":
"item":
"sslprotocol": 'All -SSLv2 -SSLv3'
Then run:
/scripts/rebuildhttpdconf
service httpd restart
If the change does not take effect, see if /var/cpanel/templates/apache/main.local exists. If it does, you need to make sure this line exists in the SSL part of the config:
[% IF main.sslprotocol.item.sslprotocol.length %]SSLProtocol [% main.sslprotocol.item.sslprotocol %][% END %]
Disabling SSLv3 for cPanel, WHM, and Webmail
This is specifically referring to cPanel services, accessed via ports 2083, 2096, and 2087. Go to WHM -> Service Configuration -> cPanel Web Services Configuration, and change TLS/SSL Protocols to:
SSLv23:!SSLv2:!SSLv3
To do this via CLI, edit /var/cpanel/conf/cpsrvd/ssl_socket_args and change the value of SSL_version to the same as above. Save the file and run:
/usr/local/cpanel/whostmgr/bin/whostmgr2 docpsrvdconfiguration
Disabling SSLv3 for WebDisk
Go to WHM -> cPanel Web Disk Configuration and change the value of TLS/SSL Protocols to:
SSLv23:!SSLv2:!SSLv3
To do this via CLI, edit the file /var/cpanel/conf/cpdavd/ssl_socket_args and change the value of SSL_version to the same as above. Then run:
/usr/local/cpanel/whostmgr/bin/whostmgr2 docpdavdconfiguration
Disabling SSLv3 for Dovecot
If you are using Dovecot for POP/IMAP, go to WHM -> Mailserver Configuration and edit the value for SSL Protocols exclude SSLv3:
!SSLv2 !SSLv3
To do this via CLI, edit /var/cpanel/conf/dovecot/main and change the value of ssl_protocols. Save the file and run:
/usr/local/cpanel/whostmgr/bin/whostmgr2 savedovecotsetup
DISABLING SSLV3 FOR Courier
Go to WHM -> Mailserver Configuration and change the value of TLS/SSL Protocol for both POP and IMAP to “Only permit TLSv1.0 connections”.
To do this via CLI, edit the following valuesfor both IMAP and POP3 SSL in /var/cpanel/courierconfig.yaml:
"TLS_PROTOCOL": 'TLSv1' "TLS_STARTTLS_PROTOCOL": 'TLSv1'
Then run:
/usr/local/cpanel/bin/build_courier_conf
DISABLING SSLV3 FOR Exim
At present there is no way to disable SSLv3 via WHM. You can go to WHM -> Exim Configuration Manager and disable the option for “Allow weak SSL/TLS ciphers”, but at ths time of this writing, this does not include disabling SSLv3. To do this via CLI, create/edit a file called /etc/exim.conf.local, and add the following:
@CONFIG@ tls_require_ciphers = ALL:-SSLv3:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
If the file already exists, just add this to the existing @CONFIG@ section. Then run:
/scripts/buildeximconf
service exim restart
Note: There are numerous reports of this causing issues for mail servers trying to send email to your server. Proceed with caution here.
DISABLING SSLV3 FOR Pure-FTPd/ProFTPd
Go to WHM -> FTP Server Configuration and add !SSLv3 to the TLS Cipher Suite value, ie:
HIGH:MEDIUM:+TLSv1:!SSLv2:!SSLv3
To do this via CLI, edit /var/cpanel/conf/pureftpd/main (/var/cpanel/conf/proftpd if you run ProFTP) and change the value of TLSCipherSuite. Then run:
/usr/local/cpanel/bin/build_ftp_conf
service pure-ftpd restart
Testing for SSLv3 Support
To make sure services on your server are not accepting SSLv3 connections, you can run the openssl client on your server against the SSL ports. This command is run as follows:
openssl s_client -connect localhost:port -ssl3
If it fails (which is what you want), you should see something like this at the top of the output:
140575449110344:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
For the port value, you’d use the following to test:
- 443: https (Apache)
- 995: POP3 SSL
- 993: IMAP SSL
- 465: SMTPS (Exim)
- 2083: cPanel SSL
- 2078: WebDisk SSL
- 2087: WHM SSL
- 2096: Webmail SSL
35 Comments
i did try this. but seems like after changing the cipher list. i cannot access my cpanel and whm. revert back to default setting and it works again.
Do you have this issue when disabling SSLv3 for Apache and trying to access websites on your server too? What is your OS and browser + version?
Thanks but you waste my time by showing a wrong info.
This port is really a SSL Port? :2086
It says 2096. Chill out.
Hi Nessa,
Great Post – I’ll remember to share it! 😀
Minor question – was there a specific reason for leaving out FTP(S)?
Hi Lucas,
I updated the post to include FTP.
Thanks! You’re the best Nessa
Attackers can then exploit the bug by carrying out a man-in-the-middle (MITM) attack to decrypt secure HTTP cookies, which could let them steal information or take control of the victim’s online account
==================
can you explain me why you are disabling SSL3 for email services since the problem is related with HTTP cookies ?!?
Please read the link to the whitepaper that is posted in the article before negating the content of the post with nonfactual information. The issue is that the SSLv3 protocol is no longer considered secure because data sent over it can be decrypted (ref: “This leaves us with no secure SSL 3.0 cipher suites at all: to achieve secure encryption, SSL 3.0 must be avoided entirely.”) The PoC using HTTP cookies was only an example of how the exploit can by used, not the full scope. All the information you need is in the whitepaper posted by Google. Here’s the link again, in case you’d like to bother to read it this time: https://www.openssl.org/~bodo/ssl-poodle.pdf
You rock! Thank you for this article (and ignore the haters).
indeed I read the google doc word by word , and there is no risk for email .
https://www.openssl.org/~bodo/ssl-poodle.pdf
The problem is only related with http cookies and stop.
This post took several hours of time to research and put together, and you are benefiting from the information for free. If it’s such a waste of your time to read articles we put together, feel free to not read them.
I’m sorry, but you are incorrect. Again, the PoC is only siting HTTP cookies as an non-exclusive example. The SSLv3 protocol is no longer secure. Just about every website that discusses this in detail concedes. You are completely misinterpreting the whitepaper.
As an option for Apache you could also change the cipher suite at Apache Configuration -> Global Configuration. This is similar to what you did for CPanel.
In my experience this option has a lower maintenance overhead than keeping local templates in sync with Cpanel changes after upgrades.
This is indeed true, but do note that the post indicates you can use an include instead. For reference, updating this via command line involves editing /var/cpanel/conf/apache/local. I’ve updated Vanessa’s post to include this. Thanks for your feedback!
If you disable SSL3 in email , ALL connections (clients) that want negotiate SSL using SSLv3 are processed completely
UNencrypted , now what is better …
fully unencrypted
or
in the worst situation only a byte unencrypted (even if no bug in SSLv3 email has been demonstrated as of now)
?!?
If you disable SSLV3 for email it wont send anything at all, your clients will just fail to send or receive email. It’s not going to fall back and send your email unencrypted. You have to setup TLS for your email clients and use that instead. SSLv3 is basically unsecured and needs to be disabled.
It seems there is a mistake with Exim.
It seems that it should be: ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-SSLv3:-EXP
The instructions for cPanel, WHM, and Webmail doesn’t work on RHEL5. only on 6.
Any other solution?
Can you be more specific about the problem you are having? Note that the version of OpenSSL backported on CentOS 5 has limited TLS support.
I get SSL connection error only on RHEL 5. on 6 it’s fine.
What can I do if the support is limited?
Upgrade to CentOS 6?
EXIM
This causes 30% of emails to not receive:
@CONFIG@
tls_require_ciphers = ALL:-SSLv3:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
I deleted and now everything seams to be working.
—-
Cpanels latest update might fix this: WHM>> Service Configuration>> Exim Configuration Manger>> Advanced Editor>> openssl_options = +no_sslv2 +no_sslv3
This is indeed true, and is specifically noted in the original post, indicating that changing this could cause deliverability issues for clients that dont speak TLS.
exactly Frank! SSLv3 has nothing to do with smtp, if you deny sslv3 to email functionality in email you will lose email !
Because SMTP does in fact accept SSLv3 connections, it is relevant. The security vulnerablity lies within the SSLv3 protocol itself, so anything that uses SSLv3 can be affected. This is why email providers are disabling SSLv3 support for their own services. Please check your facts.
Thanks for the info Vanessa, this dude clearly does not understand how encryption works.
Pingback: SSLv3 Vulnerability (Poodle) - GeekDecoder
I would like to know how to resolve poodle vulnerability in rhel6 server. port number 11090 is vulnerable.
What service is listening on port 11090?
Several ASV’s are now considering TLSv1 a failing condition. We tried disabling RC4-SHA which is listed as a weak cipher but end up breaking ssl as a result. Not sure how to get around this on a cpanel server.
Thank you so much for this wonderful article. Many of the things have already been taken care of in subsequent CPanel/WHM updates since the article was written but still it was good information to have as there were some services that needed changes.
Pingback: Dovecot Cpanel | Free Favi Icons
Pingback: Beliefs That Make Most Security “Experts” Idiots – v-nessa.net
Pingback: Cpanel Webmail Require Ssl | Cloud Email Services