Nov 8, 2018

What To Do for the POODLE SSLv3 Vulnerability

On October 14th, 2014, a vulnerability in version 3 of the SSL encryption protocol was disclosed by Google researchers. This vulnerability, dubbed POODLE (Padding Oracle On Downgraded Legacy Encryption), allows an attacker to read information encrypted with this version of the protocol in plain text using a man-in-the-middle attack. The POODLE vulnerability exists because the SSLv3 protocol does not adequately check the padding bytes that are sent with encrypted messages. An attacker can replace these and pass them on to the intended destination. When done in a specific way, the modified payload will potentially be accepted by the recipient without complaint. An average of once out of every 256 requests will accepted at the destination, allowing the attacker to decrypt a single byte. This can be repeated easily in order to progressively decrypt additional bytes. Any attacker able to repeatedly force a participant to resend data using this protocol can break the encryption in a very short amount of time.

A lot of software falls back on SSLv3 if better encryption options are not available. More importantly, it is possible for an attacker to force SSLv3 connections if it is an available alternative for both participants attempting a connection.

The POODLE vulnerability affects any services or clients that make it possible to communicate using SSLv3. Because this is a flaw with the protocol design, and not an implementation issue, every piece of software that uses SSLv3 is vulnerable. Any software that implements a fallback mechanism that includes SSLv3 support is vulnerable and can be exploited. Software that may be affected are web browsers, web servers, VPN servers, mail servers, etc. Because the POODLE vulnerability does not represent an implementation problem and is an inherent issue with the entire protocol, there is no workaround and the only reliable solution is to not use it.

This is an issue that involves both clients and servers. Servers and clients should should take steps to disable SSLv3 support completely. Because a malicious user can force SSLv3 communication if both participants allow it as an acceptable method.

To disable SSLv3 in the Nginx web server, you can use the ssl_protocols directive. This will be located in the server or http blocks in your configuration. On 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. In /etc/nginx/nginx.conf, your ssl_protocols directive should be set like this:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Restart is needed after modification.

To disable SSLv3 on the Apache web server, you will have to adjust the SSLProtocol directive provided by the mod_ssl module. This directive can be set either at the server level or in a virtual host configuration. Depending on your distribution's Apache configuration, the SSL configuration may be located in a separate file that is sourced. On 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 in /etc/apache2/mods-available/ssl.conf. On CentOS, you can can adjust this in the SSL configuration file (if SSL is enabled) in /etc/httpd/conf.d/ssl.conf

SSLProtocol all -SSLv3 -SSLv2

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

To disable SSLv3 in an HAProxy load balancer, you will need to open the haproxy.cfg file located at /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

Restart is needed after modification.

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

Postfix SMTP Server
If your Postfix configuration is set up to require encryption, it will use a directive called smtpd_tls_mandatory_protocols in /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 the service to implement your changes:

Restart is needed after modification.

In order to disable SSLv3 on a Dovecot server, you will need to adjust a directive called ssl_protocols. For most distros, you can adjust this directive in /etc/dovecot/conf.d/10-ssl.conf

ssl_protocols = !SSLv3 !SSLv2

Restart is needed after modification.

Client applications such as web browsers may be vulnerable to this issue because of their step-down protocol negotiation. This may be adjustable in the settings.
For Google Chrome, add --ssl-version-min=tls1 to startup script, such as:

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1

For Firefox, you can set the value security.tls.version.min = 1 in the about:config dialog.

For Internet Explorer, uncheck "Use SSL 3.0" in "Internet Options".