Resolution for POODLE SSLv3.0 vulnerability (CVE-2014-3566) for components that do not allow SSLv3 to be disabled via configuration settings

Solution Unverified - Updated -


  • Red Hat Enterprise Linux 5, 6, 7


  • How do I address CVE-2014-3566 for components that do not allow SSLv3 to be disabled via configuration settings?
  • How do I avoid impact to OpenLDAP from CVE-2014-3566?
  • How do I avoid impact to cups from CVE-2014-3566?
  • For JBOSSEAP 5.2.0, I can't find security advisories of CVE-2014-3566 for Linux platform. Where can I find this CVE for Red Hat linux?


-Some components do not provide configuration parameters that allow SSLv3 to be disabled. Currently, the following components are known to fall into this category:

  • OpenLDAP
  • cups

It is possible to disable SSLv3 for these components by using stunnel. Stunnel provides an encryption wrapper between a remote client and a local (inetd-startable) or remote server, using the OpenSSL library for cryptography.

To disable SSLv3 on stunnel, use the following configuration parameters in the stunnel.conf file:

options = NO_SSLv2
options = NO_SSLv3

Installation and configuration of stunnel is outside the scope of this solution, please consult the man pages and system documentation for more details.

Note: Newer openldap-servers has TLSProtocolMin option. If openldap-servers is openldap-servers-2.4.39-8.el6(for RHEL6), openldap-servers-2.4.39-3.el7(for RHEL7) or later, add "TLSProtocolMin 3.1" in slapd.conf to disable SSLv3. You can refer to man slapd.conf.

Root Cause

A vulnerability was found in the SSLv3.0 protocol. This vulnerability allows a man-in-the-middle attacker to decrypt ciphertext using a padding oracle side-channel attack. For more information about this vulnerability, refer to the following article: POODLE: SSLv3.0 vulnerability (CVE-2014-3566)

Diagnostic Steps

For diagnostic steps, refer to the following article: POODLE: SSLv3.0 vulnerability (CVE-2014-3566)

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.


Using this configuration, the following test now also fails:

openssl s_client -connect $server:636 -tls1

Hi John, can you please provide further details, i.e. exactly what error you get after applying this configuration change?

The script uses openssl s_client to perform the test for ssl3. If that same test is used for tls1

Using the default TLSCipherSuite:

openssl s_client -connect $server:636 -tls1

    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES128-SHA
    Session-ID: XXXXXXXX
    Master-Key: XXXXXXXX
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1413436388
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)

After setting TLSCipherSuite: HIGH:MEDIUM:-SSLv2:-SSLv3

openssl s_client -connect $server:636 -tls1
    Protocol  : TLSv1
    Cipher    : 0000
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1413436499
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)

or on EL5

11420:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:536:

Thanks very much for pointing this out, John. The mitigation suggested by this solution was problematic, as while you can instruct OpenSSL to remove all SSLv3 ciphers (using -SSLv3), there is no cipher left for TLS 1.0/1.1. Analysis has not revealed any configuration mechanism in OpenLDAP that will disable SSLv3 effectively. Therefore this solution has been updated to suggest usage of stunnel as a potential mitigation.

Can you please explain how to force a yum repo to connect using TLS? This 'fix' is breaking all yum repos that are using HTTPS and rejecting SSLv3.

]# yum repolist
Loaded plugins: security, versionlock

Error: Cannot retrieve metalink for repository: epel. Please verify its path and try again

In regards to LDAP, are there any plans for TLS v1.2 support in the near future? (RHEL 6.6) From what I can tell it looks like the OpenLDAP Server doesn't neccessarily have any issues with the Cipher removal of SSLv3, it looks to be more of a client side problem. The NSS/PAM module is what looks like it's choking. It looks like I can still connect to the LDAP port with openssl. Is this a client side problem? I'm really not keen on the idea of using stunnel as a wrapper for the connection.

In an environment with thousands of LDAP clients the stunnel solution just isn't feasible. Will there be a patched released to address OpenLDAP?

My Japanese is not too good but reading between the lines, this seems to work for openldap/slapd.conf
バージョン 2.4.36以降の場合
TLSProtocolMin 3.1
バージョン 2.4.14~2.4.35の場合
TLSProtocolMin 769

I have confirmed that this does indeed work with openldap-2.4.39-8.

Thanks John.

However, setting olcTLSProtocolMin 769 on openldap-2.4.23-34.el6_5.1 still allows a successful SSlv3 handshake. Also, olcTLSProtocolMin is not even documented in the slapd.conf man pages for this version.

I suspect olcTLSProtocolMin is ignored in openldap-2.4.23-34.el6_5.1 because openldap is linked against moz_nss and not openssl.


Referent do CUPS, I've just checked the "" URL, it seems Cups already has a option "SSLOptions" on subversion. Will this be backported to RedHat ?