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’spublished 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
Disabling via SSLProtocol
Update 10/22: As of cPanel 184.108.40.206, 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'
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:
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:
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:
To do this via CLI, edit /var/cpanel/conf/dovecot/main and change the value of ssl_protocols. Save the file and run:
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'
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:
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:
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