Bug 1152789 (CVE-2014-3566, POODLE)

Knowledgebase article:

https://access.redhat.com/articles/1232123

To mitigate this vulnerability, it is recommended that you explicitly disable SSLv3.0 in all affected packages. Additional instructions to do this for each affected package, as well as updates that disable SSLv3.0 by default, are being developed by Red Hat as a high priority.

Upstream patch:

master:
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=cf6da05304d554aaa885151451aa4ecaa977e601

OpenSSL-1.0.1
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6bfe55380abbf7528e04e59f18921bd6c896af1c

OpenSSL-0.9.8:
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=c6a876473cbff0fd323c8abcaace98ee2d21863d
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=dc5dfe431cffbc1fa8eeead0853bd03395e52e71

NSS 3.17 already has a patch for this at:

https://hg.mozilla.org/projects/nss/rev/45cb71fd7bca
https://bugzilla.mozilla.org/show_bug.cgi?id=1036735

This introduces the SSL_ENABLE_FALLBACK_SCSV and resolves the downgrade issue.

This issue went into 3.17.1 beta

Created openssl tracking bugs for this issue:

Affects: fedora-all [bug 1152850]

Created mingw-openssl tracking bugs for this issue:

Affects: fedora-all [bug 1152851]

(In reply to Huzaifa S. Sidhpurwala from comment #7)
> (In reply to Huzaifa S. Sidhpurwala from comment #3)
> 
> > GNUTLS:
> > Looks like gnutls already has support for SCSV. Need to figure out where
> 
> It appears like the following commit introduced SCSV in gnutls:
> 
> https://gitorious.org/gnutls/gnutls/commit/
> 1a338cbaaeec11d958de8da4d1ae036979fccf3e
> 
> Though i am confused why 0xff is used instead of 0x56. All rhels have this.

This is the TLS renegotiation SCSV which is different than the TLS fallback SCSV. However, the attack as I understand it does not apply on clients that rely on the TLS protocol negotiation. It applies to clients that do the "browser"-like negotiation which is to connect using TLS1.2, if that doesn't work, discard everything, and retry TLS 1.1... and so on until you do SSL 3.0.

GnuTLS does not provide an API to do that trickery, and does not even discuss that as an option. I think that this attack affects mostly browsers rather than applications that properly use TLS/SSL.

Statement:

This issue affects the version of openssl as shipped with Red Hat Enterprise Linux 5, 6 and 7, Red Hat JBoss Enterprise Application Platform 5 and 6, and Red Hat JBoss Web Server 1 and 2, Red Hat Enterprise Virtualization Hypervisor 6.5, and Red Hat Storage 2.1.

This issue affects the version of nss as shipped with Red Hat Enterprise Linux 5, 6 and 7.

Additional information can be found in the Red Hat Knowledgebase article: 
https://access.redhat.com/articles/1232123

IssueDescription:

A flaw was found in the way SSL 3.0 handled padding bytes when decrypting messages encrypted using block ciphers in cipher block chaining (CBC) mode. This flaw allows a man-in-the-middle (MITM) attacker to decrypt a selected byte of a cipher text in as few as 256 tries if they are able to force a victim application to repeatedly send the same data over newly created SSL 3.0 connections.

Note that there are two problems outlined in the paper linked in comment 0:

- efficient padding oracle attack against SSL 3.0 CBC cipher suites
- lack of ways to avoid MITM forced fallback in applications that implement re-connect SSL/TLS version fallback mechanism


The SSL 3.0 problem is yet another attack against the "authenticate-then-encrypt" constructions used by block ciphers in the cipher block chaining (CBC) mode, as used in SSL and TLS.  Previous attacks included BEAST / CVE-2011-3389 (bug 737506) or Lucky13 / CVE-2013-0169 (bug 907589).  The paper describes that when using SSL 3.0, only as little as 256 connections may be required to reliably decrypt one byte of cipher text.

The attack is similar to the BEAST attack - it requires that a man-in-the-middle (MITM) attacker can make victim SSL client to repeatedly send the same secret information over SSL connection, mixed with attacker provided data.  Web browser is an example of such use case.  Attacker's script can make victim's browser send repeated requests to a target server.  Each request containing attacker controlled data (such as target path and GET/POST data) as well as secret information attacker wants to recover (such as authentication cookie).  A more detailed description of the browser attack can be found in the Adam Langley's blog post:

https://www.imperialviolet.org/2014/10/14/poodle.html

SSL 3.0 protocol issues that allow this attack are addressed, to some degree, in TLS - TLS 1.0 specifies format of message padding bytes, newer TLS versions define cipher suites using different modes.

Implementations of SSL 3.0 protocols should be expected to get any fix to address this protocol problem.  Patches linked in comment 2 and comment 3 do not fix this issue, see below for more information on what they do.  One alternative may be to restrict use of CBC block ciphers with SSL 3.0, which leaves stream cipher RC4 as the only alternative.  RC4 has other known issues (see CVE-2013-2566 / bug 921947) and its use is discouraged.  It seems the only option will be to abandon the use of SSL 3.0.  See the Red Hat Knowledgebase article linked in comment 1 for instructions on how to disable the use of SSL 3.0 in various applications shipped as part of Red Hat products.

As SSL/TLS libraries used today usually support at least TLS version 1.0 (which is newer protocol version than SSL 3.0 despite having lower version number), often up to the currently latest TLS version 1.2, TLS 1.0 or newer is usually negotiated when SSL/TLS connection is created.  SSL/TLS protocols include a fallback mechanism which allows client and server to communicate even if the highest SSL/TLS version they support is not the same.  Client indicates the highest version it supports in its ClientHello handshake message, and server picks the highest version supported by both peers and communicates it back to client in its ServerHello handshake message.  SSL/TLS protocols implement protections to prevent MITM attacker from being able to tamper with handshake messages to force the use of the protocol version lower than the highest version supported by both client and server.  Which leads us to the second problem...


Certain applications, most notably web browsers such as Mozilla Firefox or Google Chrome, implement different fallback mechanism for compatibility reasons.  Some SSL/TLS implementation do not correctly handle cases when connecting client supports newer TLS protocol version than supported by the client, or when certain TLS extensions are used.  Instead of negotiating the highest TLS version supported by server, connection attempt may fail.  As a workaround, a web browser may attempt to re-connect with certain protocol versions disabled.  For example, browser may initially connect claiming TLS 1.2 as the highest supported version, and subsequently reconnect claiming only TLS 1.1, TLS 1.0 or eventually SSL 3.0 as the highest supported version until connection attempt succeeds.

This fallback mechanism makes it trivial for MITM attacker to force browser to use specific SSL/TLS version when talking to a web server.  Even if both client and server support TLS 1.2, they can be forced to use SSL 3.0 if both allow that protocol version, which makes it possible to mount a padding oracle attack as described above.

Patches in comment 2 and comment 3, which implement the TLS_FALLBACK_SCSV protection defined in the following RFC draft:

https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00

aims to make this fallback mechanism safer by making it possible for applications to indicate if they are doing version fallback and that they can speak newer SSL/TLS protocol version.  Note that those fixes are insufficient if only applied to SSL/TLS libraries, client applications need to be modified to take advantage of the new feature.  The following conditions must be met to make TLS_FALLBACK_SCSV protection work:

- SSL/TLS library used by an application doing re-connect fallback needs to implement TLS_FALLBACK_SCSV
- application must be modified to instruct the SSL/TLS library to send TLS_FALLBACK_SCSV when doing fallback to older protocol version
- SSL/TLS library used by the server must support TLS_FALLBACK_SCSV, no change to the server application is required

If server sees a connection attempt using SSL/TLS version lower than the highest protocol version it supports and that also includes TLS_FALLBACK_SCSV, it rejects the connection.

Note that is re-connect version fallback commonly found in web browsers is uncommon in other applications or SSL/TLS libraries (i.e. it is not done by OpenSSL, NSS or GnuTLS).

Regarding the CVE, Mitre CVE project currently describes CVE-2014-3566 as:

  The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products,
  uses nondeterministic CBC padding, which makes it easier for man-in-the-
  middle attackers to obtain cleartext data via a padding-oracle attack, aka
  the "POODLE" issue.

This description pins the CVE to the first, SSL 3.0 protocol issue.  However, it seems to have been used for both problems, and as part of fixes adding TLS_FALLBACK_SCSV support, which is likely to create confusion.

OpenSSL upstream versions 0.9.8zc, 1.0.0o and 1.0.1j add support for TLS Fallback Signaling Cipher Suite Value (TLS_FALLBACK_SCSV) as a mitigation against CVE-2014-3566 / POODLE attack.

https://www.openssl.org/news/secadv_20141015.txt

Jenkins is adding a code fix to disable SSLv3:

https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2014-10-15

script is:

#!/bin/bash
#
#  Copyright (C) 2014 by Dan Varga
#  dvarga
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 3 of the License, or
#  (at your option) any later version.


host=$1
port=$2

if [ "$2" == "" ]
then
        port=443
fi


out="`echo x | openssl s_client -ssl3 -connect ${host}:${port} 2>/dev/null`"
ret=$?

if [ $ret -eq 0 ]
then
        echo "VULNERABLE! SSLv3 detected."
        exit
elif [ $ret -eq 1 ]
then
        out=`echo $out | perl -pe 's|.*Cipher is (.*?) .*|$1|'`
        if [ "$out" == "0000" ] || [ "$out" == "(NONE)" ]
        then
                echo "Not Vulnerable. We detected that this server does not support SSLv3"
                exit
        else
                echo "just passing through..."
        fi
elif [ $ret -eq 124 ]
then
        echo "error: timeout connecting to host $host:$port"
        exit
fi
echo "error: Unable to connect to host $host:$port"

now results:

client runs openssl 0.9.8e-12.el5_4.6 on RHEL 5
server is jboss 4.2.2.GA with openssl 0.9.8e-12.el5_5.7 => VULNERABLE! SSLv3 detected.
server is jboss 5.1.0.GA with openssl 0.9.8e-26.el5_9.1 => VULNERABLE! SSLv3 detected.
server is jboss EAP6.1.0.GA with openssl 1.0.1e-16.el6_5.4 => VULNERABLE! SSLv3 detected.

client runs openssl 1.0.1e-16.el6_5.4 on RHEL 6(.5)
server is jboss 4.2.2.GA with openssl 0.9.8e-12.el5_5.7 => just passing through...
error: Unable to connect to host c0164673.prod.bfa:9443
server is jboss 5.1.0.GA with openssl 0.9.8e-26.el5_9.1 => just passing through...
error: Unable to connect to host c0164530.prod.bfa:9443
server is jboss EAP6.1.0.GA with openssl 1.0.1e-16.el6_5.4 => just passing through...
error: Unable to connect to host c0164530.prod.bfa:9443

however, this is yielded inside the script

# out=`echo x | openssl s_client -ssl3 -connect c0164529.prod.bfa:9443 2>/dev/null`;echo $out | perl -pe 's|.*Cipher is (.*?) .*|$1|'
ECDHE-RSA-AES256-SHA

and shorter:

# echo x | openssl s_client -ssl3 -connect c0164529.prod.bfa:9443 2>/dev/null;echo $?
CONNECTED(00000003)
(...certificate chain here...)
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 543FA546602F970772A05828E981C983BB6058CA9127E9FB43EE6FB515734ADC
    Session-ID-ctx:
    Master-Key: 5FB4F48FEEA29FE469A7A4CAC52B6F90A91FA87EEBA6B5FDC560089FEF8CD56A0E2A835DAC4E97084DE02B8BD62A34F4
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1413457222
    Timeout   : 7200 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
1


Is this fine? I am puzzled, the checker-script tells it is "unable to connect", yet there clearly "connected" is stated...

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 5

Via RHSA-2014:1653 https://rhn.redhat.com/errata/RHSA-2014-1653.html

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 7

Via RHSA-2014:1652 https://rhn.redhat.com/errata/RHSA-2014-1652.html

The openssl packages errata linked in comment 40 and comment 41 do not address the SSL 3.0 protocol issue, to which the CVE-2014-3566 was assigned.  They add support for the TLS_FALLBACK_SCSV, which enables TLS servers to detect forced protocol downgrades against clients that do re-connect protocol version fallback.  Both server and client need to implement this feature, and clients have to actively use it for the protection to work (see comment 14 for details).

Tomas, we rely on the official releases by Red Hat and not on bugzilla comments by anyone..

(In reply to Tomas Hoger from comment #43)
> The openssl packages errata linked in comment 40 and comment 41 do not
> address the SSL 3.0 protocol issue, to which the CVE-2014-3566 was assigned.
> They add support for the TLS_FALLBACK_SCSV, which enables TLS servers to
> detect forced protocol downgrades against clients that do re-connect
> protocol version fallback.  Both server and client need to implement this
> feature, and clients have to actively use it for the protection to work (see
> comment 14 for details).


Tomas, we rely on the official releases by Red Hat and not on bugzilla comments by anyone..btw, are you from redhat ?

Tomas Hoger is in Red Hat Product Security.

John, you are from oracle, how do you know that ? :-)

A bit messy POODLE :)

At https://access.redhat.com/solutions/120383
in "Red Hat Enterprise Linux 5 (postfix-2.3.x)"
these setting are implemented in postfix 2.5, correct legacy syntax is:

smtpd_tls_mandatory_protocols = TLSv1
smtp_tls_mandatory_protocols = TLSv1

(In reply to errata-xmlrpc from comment #41)

There are no RHEL6 packages linked in RHSA-2014:1652
https://rhn.redhat.com/errata/RHSA-2014-1652.html

I guess RHEL6 was mentioned by mistake ?

(In reply to Dex from comment #48)
> There are no RHEL6 packages linked in RHSA-2014:1652
> https://rhn.redhat.com/errata/RHSA-2014-1652.html

The erratum lists openssl-1.0.1e-30.el6_6.2 as updated package for various Red Hat Enterprise Linux 6 variants.  Red Hat Enterprise Linux 6 is also in the list of Affected Products near the top of the page.

Note that upstream python is disabling SSLv3 by default:

http://bugs.python.org/issue22638

(In reply to Tomas Hoger from comment #49)
> (In reply to Dex from comment #48)
> > There are no RHEL6 packages linked in RHSA-2014:1652
> > https://rhn.redhat.com/errata/RHSA-2014-1652.html
> 
> The erratum lists openssl-1.0.1e-30.el6_6.2 as updated package for various
> Red Hat Enterprise Linux 6 variants.  Red Hat Enterprise Linux 6 is also in
> the list of Affected Products near the top of the page.

Both issues resolved .. thanks.

With Asterisk AST-2014-011 advisory, SSLv3 is no longer used for res_jabber/res_xmpp, and when no encryption method is specified, it is no longer possible to fall back to SSLv3 or SSLv2:

http://downloads.asterisk.org/pub/security/AST-2014-011.html

(Fedora and EPEL bugs: bug 1154894, bug 1154895)

libserf 1.3.8 disables SSLv2 and SSLv3:

https://serf.googlecode.com/svn/tags/1.3.8/CHANGES

(Fedora and EPEL bugs: bug 1155392, bug 1155393)

This issue has been addressed in the following products:

  Red Hat Storage 2.1

Via RHSA-2014:1692 https://rhn.redhat.com/errata/RHSA-2014-1692.html

Asterisk is susceptible to this as well, as per upstream advisory http://downloads.asterisk.org/pub/security/AST-2014-011.html (it includes patches for Asterisk 11 (Fedora) and Asterisk 1.8 (EPEL 6)

Created asterisk tracking bugs for this issue:

Affects: fedora-all [bug 1160852]
Affects: epel-6 [bug 1160853]

(In reply to Huzaifa S. Sidhpurwala from comment #3)
> NSS 3.17 already has a patch for this at:
> 
> https://hg.mozilla.org/projects/nss/rev/45cb71fd7bca
> https://bugzilla.mozilla.org/show_bug.cgi?id=1036735

Backport to 3.16:

https://hg.mozilla.org/projects/nss/rev/53506619e81a

Additional bug tracking addition of the TLS_FALLBACK_SCSV support to NSS utilities:

https://bugzilla.mozilla.org/show_bug.cgi?id=1083360
https://hg.mozilla.org/projects/nss/rev/34baf87d485d

IBM Java SE updates 5.0 SR16-FP8, 6 SR16-FP2, 6R1 SR8-FP2, 7 SR8, and 7R1 SR2 address this issue by disabling SSL 3.0 by default.  Those updates also implement the following changes:

- Add new system property com.ibm.jsse2.disableSSLv3 that can be used to re-enable SSL 3.0 by setting its value to false.
- Change semantics of the SSLContext.getInstance("SSL") call - prior to this update, only SSL 3.0 was enabled.  In updated versions, TLS 1.0 and possibly 1.1 and 1.2 are enabled instead.

Details of the changes can be found in the following IBM article:

http://www-01.ibm.com/support/docview.wss?uid=swg21688165

Puppet advisory:

http://puppetlabs.com/blog/impact-assessment-sslv3-vulnerability-poodle-attack

This issue has been addressed in the following products:

  Supplementary for Red Hat Enterprise Linux 5
  Supplementary for Red Hat Enterprise Linux 6

Via RHSA-2014:1877 https://rhn.redhat.com/errata/RHSA-2014-1877.html

This issue has been addressed in the following products:

  Supplementary for Red Hat Enterprise Linux 5

Via RHSA-2014:1876 https://rhn.redhat.com/errata/RHSA-2014-1876.html

This issue has been addressed in the following products:

  Supplementary for Red Hat Enterprise Linux 6

Via RHSA-2014:1882 https://rhn.redhat.com/errata/RHSA-2014-1882.html

This issue has been addressed in the following products:

  Supplementary for Red Hat Enterprise Linux 6
  Supplementary for Red Hat Enterprise Linux 7

Via RHSA-2014:1880 https://rhn.redhat.com/errata/RHSA-2014-1880.html

This issue has been addressed in the following products:

  Supplementary for Red Hat Enterprise Linux 5
  Supplementary for Red Hat Enterprise Linux 6

Via RHSA-2014:1881 https://rhn.redhat.com/errata/RHSA-2014-1881.html

This issue has been addressed in the following products:

  JBoss Web Server 2.1.0

Via RHSA-2014:1920 https://rhn.redhat.com/errata/RHSA-2014-1920.html

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7
  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 5

Via RHSA-2014:1948 https://rhn.redhat.com/errata/RHSA-2014-1948.html

nodejs-0.10.33-1.el7, libuv-0.10.29-1.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.

nodejs-0.10.33-1.el6, libuv-0.10.29-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

nodejs-0.10.33-1.fc21, libuv-0.10.29-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

nodejs-0.10.33-1.fc20, libuv-0.10.29-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

nodejs-0.10.33-1.fc19, libuv-0.10.29-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

This issue has been addressed in the following products:

  JBoss Enterprise Application Platform 6.3

Via RHSA-2015:0012 https://rhn.redhat.com/errata/RHSA-2015-0012.html

This issue has been addressed in the following products:

  JBoss Enterprise Web Platform 5.2.0

Via RHSA-2015:0011 https://rhn.redhat.com/errata/RHSA-2015-0011.html

This issue has been addressed in the following products:

  JBoss Enterprise Application Platform 5.2.0

Via RHSA-2015:0010 https://rhn.redhat.com/errata/RHSA-2015-0010.html

The OpenJDK (IT6 1.13.6, IT7 2.5.4, and 8u31-b13) and Oracle JDK (5.0u81, 6u91, 7u75 and 8u31) updates address this issue by disabling SSL 3.0 protocol support by default.  Updates add support for disabling specific SSL/TLS protocol versions using the jdk.tls.disabledAlgorithms security property, and they also update the master security properties file, java.security, to add SSLv3 to the list of algorithms that are disabled by default.

Users who need to re-enable SSL 3.0 protocol support in OpenJDK or Oracle JDK can do so using one of the following ways:

* Change the master security properties file to not include SSLv3 in the list of disabled algorithms.  The java.security files for each JDK can be found at the following path:

  /usr/lib/jvm/*/jre/lib/security/java.security

The sub-directory under /usr/lib/jvm contains package name (such as java-1.7.0-openjdk or java-1.7.0-oracle) possibly followed by package version or architecture (depending on the JDK and its version).

Note that the change to the file will affect all applications using given JDK.  Local changes to the file will also cause new java.security versions to be installed as java.security.rpmnew if future updates change packaged version, requiring manual merge of changes.

* Re-enable SSLv3 support only for specific application or applications that require it.  Create a new security properties file that will override the default jdk.tls.disabledAlgorithms setting from the master java.security, and use the java.security.properties system property to make Java read the file in addition to the master security properties file.  Example:

  $ cat enable-ssl3.security 
  jdk.tls.disabledAlgorithms=

  $ java -Djava.security.properties=/path/to/enable-ssl3.security ...

Note that this only works if the master security properties file sets the security.overridePropertiesFile security property to true.  That is the default setting in all OpenJDK and Oracle JDK packages shipped in Red Hat Enterprise Linux.

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 5

Via RHSA-2015:0068 https://rhn.redhat.com/errata/RHSA-2015-0068.html

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2015:0069 https://rhn.redhat.com/errata/RHSA-2015-0069.html

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 7

Via RHSA-2015:0067 https://rhn.redhat.com/errata/RHSA-2015-0067.html

OpenJDK upstream fixes, as described in comment 82:

http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/0a1fe04693dd
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/1c0cc3bbe07d


Oracle Java SE 7u75 and 8u31 release notes, which also mention the change:

http://www.oracle.com/technetwork/java/javase/7u75-relnotes-2389086.html
http://www.oracle.com/technetwork/java/javase/8u31-relnotes-2389094.html

This issue has been addressed in the following products:

  Oracle Java for Red Hat Enterprise Linux 6

Via RHSA-2015:0080 https://rhn.redhat.com/errata/RHSA-2015-0080.html

This issue has been addressed in the following products:

  Oracle Java for Red Hat Enterprise Linux 7
  Oracle Java for Red Hat Enterprise Linux 5
  Oracle Java for Red Hat Enterprise Linux 6

Via RHSA-2015:0079 https://rhn.redhat.com/errata/RHSA-2015-0079.html

This issue was fixed in IcedTea6 1.13.6 and IcedTea7 2.5.4:

http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2015-January/030488.html
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2015-January/030469.html

This issue has been addressed in the following products:

  Oracle Java for Red Hat Enterprise Linux 7
  Oracle Java for Red Hat Enterprise Linux 6
  Oracle Java for Red Hat Enterprise Linux 5

Via RHSA-2015:0086 https://rhn.redhat.com/errata/RHSA-2015-0086.html

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 7

Via RHSA-2015:0085 https://rhn.redhat.com/errata/RHSA-2015-0085.html

This issue has been addressed in the following products:

  Red Hat Satellite Server v 5.6

Via RHSA-2015:0264 https://rhn.redhat.com/errata/RHSA-2015-0264.html

Official workaround for the issue has been published by IETF as RFC 7507 "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks".

https://tools.ietf.org/html/rfc7507

This issue has been addressed in the following products:

  RHEL 6 Version of OpenShift Enterprise 2.0

Via RHSA-2015:1546 https://rhn.redhat.com/errata/RHSA-2015-1546.html

This issue has been addressed in the following products:

  RHEL 6 Version of OpenShift Enterprise 2.1

Via RHSA-2015:1545 https://rhn.redhat.com/errata/RHSA-2015-1545.html

GnuTLS got support for RFC 7507 in upstream version 3.4.4:

http://lists.gnutls.org/pipermail/gnutls-devel/2015-August/007707.html

Related upstream commits:

https://gitlab.com/gnutls/gnutls/commit/db9a7d810f9ee4c9cc49731f5fd9bdeae68d7eaa
https://gitlab.com/gnutls/gnutls/commit/21f89efad7014a5ee0debd4cd3d59e27774b29e6
https://gitlab.com/gnutls/gnutls/commit/7c5f1955a73778c067786a88a419f337d5d9e5c0
https://gitlab.com/gnutls/gnutls/commit/20a98e817713764b9df5306286091df1b61190d9
https://gitlab.com/gnutls/gnutls/commit/1cca0461d28cb74646f9443d547e5d0ed325d7fc