de-POODLE-ing: How to Disable Support for SSLv3 on a cPanel Server

4.8/5 - (52 votes)

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:

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, 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": 'All -SSLv2 -SSLv3'

Then run:


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:


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:


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



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:


Then run:




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:

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:


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.



Go to WHM -> FTP Server Configuration and add !SSLv3 to the TLS Cipher Suite value, ie:


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:


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


  1. karim Reply

    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.

  2. Lucas R Reply

    Hi Nessa,

    Great Post – I’ll remember to share it! 😀

    Minor question – was there a specific reason for leaving out FTP(S)?

  3. Manuk Reply

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

    1. Vanessa Vasile Reply

      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:

    1. Mark Reply

      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.

    2. Vanessa Vasile Reply

      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.

  4. Manuel Reply

    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.

    1. Mark Reply

      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!

  5. Manuk Reply

    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
    in the worst situation only a byte unencrypted (even if no bug in SSLv3 email has been demonstrated as of now)


    1. Roy Reply

      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.

  6. jwalker Reply

    It seems there is a mistake with Exim.
    It seems that it should be: ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-SSLv3:-EXP

    1. Mark Reply

      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.

  7. Frank Reply

    This causes 30% of emails to not receive:
    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

  8. Manuk Reply

    exactly Frank! SSLv3 has nothing to do with smtp, if you deny sslv3 to email functionality in email you will lose email !

    1. Vanessa Vasile Reply

      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.

  9. Pingback: SSLv3 Vulnerability (Poodle) - GeekDecoder

  10. Jestep Reply

    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.

  11. Host Prairie Reply

    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.

  12. Pingback: Dovecot Cpanel | Free Favi Icons

  13. Pingback: Beliefs That Make Most Security “Experts” Idiots –

  14. Pingback: Cpanel Webmail Require Ssl | Cloud Email Services

Leave a Reply

Your email address will not be published. Required fields are marked *

Log in