How To Protect your Server Against the POODLE SSLv3 Vulnerability

Verified and Tested 02/05/2015

Introduction

On October 14th, 2014, a vulnerability was established in version 3 of the SSL encryption protocol. This vulnerability, known as POODLE (Padding Oracle On Downgraded Legacy Encryption), allows an attacker to read otherwise encrypted information with this version of the protocol in plain text using a man-in-the-middle attack.

Although SSLv3 is an older version of the protocol, many pieces of software will still revert to SSLv3 if better encryption options are not available at the time. Also, It is important to keep in mind that an attacker can force SSLv3 connections if it is an available alternative for both participants attempting to connect.

The POODLE vulnerability affects any services or clients that make it possible to communicate using SSLv3. As this is a flaw with the protocol design, every piece of software that utilizes SSLv3 is vulnerable.

The POODLE vulnerability exists because the SSLv3 protocol does not properly check the padding bytes that are sent along with encrypted messages. An attacker can replace these and pass them on to the intended destination. When done, the modified payload will potentially be accepted by the recipient without complaint.

Protecting Yourself from the POODLE SSLv3 Vulnerability

There are actions that can be taken in order to ensure protection from this type of vulnerability. Since encryption is negotiated between clients and servers, this is an issue that effects both parties. Clients should take steps to disable SSLv3 support completely. Many of the applications today use better encryption by default, but even these applications use SSLv3 as a fallback option if none are available. This should be disabled, as an attacker can force SSLv3 communication if both parties allow it as an acceptable method of encryption.

Apache Web Server

To disable SSLv3 on the Apache Web server you will have to adjust the SSLProtocol directive provided by the mod_ssl module.

This can be set either at the server level or in a virtual host configuration. Depending on your distributions Apache configuration, the SSL configuration maybe located in a separate file that is sourced.

In Ubuntu, the server-wide specification for servers can be adjusted by editing the /etc/apache2/mods-available/ssl.conf file. If mod_ssl is enabled, a symbolic link will connect this file to the mods-enabled subdirectory:

sudo nano /etc/apache2/mods-available/ssl.confIn

CentOs, you can adjust this in the SSL configuration file located here (If SSL is enabled):

sudo nano /etc/httpd/conf.d/ssl.conf

Inside you can find the SSLProtocol directive. If it is not available, create it. Modify this to remove support for SSLv3:

SSLProtocol all -SSLv3 -SSLv2

Save and close the file. Restart to enable the changes.

On Ubuntu, you can type:

sudo service apache2 restart

On CentOS, this would be:

sudo service httpd restart

Nginx Web Server

To disable SSLv3 on a Nginx web server, you can use the ssl_protocols directive. This will be located in the server or http blocks in your configuration.

For example, in Ubuntu, you can either add this globally to /etc/nginx/nginx.conf inside of the http block, or to each server block in the /etc/nginx/sites-enabled directory.

sudo nano /etc/nginx/nginx.conf

To disable SSLv3, your ssl_protocols directive should be set like this:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

You should restart the server after the above modification has been made:

sudo service nginx restart

HAProxy Load Balancer

To disable SSLv3 in an HAProxy load balancer, you will need to open the haproxy.cfg file.This is located at /etc/haproxy/haproxy.cfg:

sudo nano /etc/haproxy/haproxy.cfg

In your front end configuration, if you have SSL enabled, your bind directive will specify the public IP address and port. If you are using SSL, you will want to add no-sslv3 to the end of this line:

frontend name

bind public_ip:443 ssl crt /path/to/certs no-sslv3

Save and close the file. Restart to implement the changes:

sudo service haproxy restart

OpenVPN VPN Server

Recent versions of OpenVPN don’t allow SSLv3. The service is not vulnerable to this specific problem, so you will need to adjust your configuration.

Postfix SMTP Server

If your Postfix configuration is set up to require encryption, it will use a directive calledsmtpd_tls_mandatory_protocols. You can find this in the main Postfix configuration file:

sudo nano /etc/postfix/main.cf

For a Postfix server set up to use encryption at all times, you can ensure that SSLv3 and SSLv2 are not accepted by setting this parameter. If you do not force encryption, you do not have to do anything:

smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3

Save your configuration. Restart to implement changes:

sudo service postfix restart

Dovecot IMAP and POP3 Server

In order to disable SSLv3 on a Dovecot server, you will need to adjust a directive called ssl_protocols. Depending on your distributions packaging methods, SSL configurations may be kept in an alternate configuration file.

For most Distros, you can adjust this directive by opening this file:

sudo nano /etc/dovecot/conf.d/10-ssl.conf

If you are using Dovecot 2.1 or higher, set the ssl_protocols directive to disable SSLv2 and SSLv3:

ssl_protocols = !SSLv3 !SSLv2

If you are using a version of Dovecot lower than 2.1, you can set the ssl_cipher_list to disallow SSLv3 like this:

ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL:!SSLv3

Save and close the file. Restart in order to save changes:

sudo service dovecot restart

Additional Steps You Can Take

You should always update any client applications. Most importantly, web browsers may be vulnerable to this issue because of their step down protocol negotiation. Ensure that your browsers do not allow SSLv3 as an acceptable encryption method. This may be adjustable in the settings or in the installation of an additional plugin.

Learn more about Atlantic.Net’s hosting solutions, including HIPAA compliant disaster recovery services.