Hide Forgot
TLS connections using Diffie-Hellman key exchange protocol were found to be vulnerable to an attack, in which a man-in-the-middle attacker could downgrade vulnerable TLS connections to 512-bit export-grade cryptography. The attack affects any server that supports DHE_EXPORT ciphers. This attack can be conduted by precomputation on the 512 bit primes given in two popular sets of weak Diffie-Hellman parameters, namely Apache 2.1.5 - 2.4.7 and OpenSSL. The following attack scenarios are possible: 1. Offline Decryption of Weak DHE Connections: This attack requires that the server default to using a Diffie-Hellman key exchange with 512-bit parameters. In this attack, there is a passive network adversary able to eavesdrop, who can obtain a transcript of the communication between the client and server. 2. DHE_EXPORT Downgrade and Offline Decryption of TLS False Start: This attack only requires that a server support 512-bit parameters, but has a greater requirement of the client and attacker. The server, in this case, only needs to support DHE_EXPORT cipher suites or use 512-bit parameters in non-export DHE ciphers. The client must be using the TLS False Start extension. 3. DHE_EXPORT Downgrade and Man-In-The-Middle Server Impersonation: This is similar to the second attack, but does not need TLS False Start extension to be enabled. We instead require the client be willing to wait a significant amount of time for the handshake to complete. This is because the attacker must compute the connection key during the handshake process, but computing the key takes several minutes. External Reference: https://weakdh.org/ https://access.redhat.com/articles/1456263
Upstream OpenSSL planned changes: https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ in few words: * 1.0.1 and 1.0.2: update to require at least 768 bit DH now * 1.0.1 and 1.0.2 (next release): require at least 1024 bit DH * export grade ciphers disabled by default
CVE-2015-4000 has been assigned to: "a flaw in the way TLS composes DHE and DHE_EXPORT. When a server selects DHE_EXPORT for a handshake, it proceeds by issuing a signed ServerKeyExchange message containing a 512-bit p512, but the structure of this message is identical to the message sent during standard DHE ciphersuites. Critically, the signed portion of the server's message fails to include any indication of the specific ciphersuite that the server has chosen." (This is the TLS protocol problem associated with the Logjam attack.) Reference: http://www.openwall.com/lists/oss-security/2015/05/20/8
Explanation about the CVE assignment: LOGJAM research paper[1] discusses various issues related to weak DH keys. 1. One of the issue is use of DHE_EXPORT ciphersuites in TLS protocol or DHE keys with export cipher strength. These keys are 512 bits in size and given enough computing power and time, they can be broken. This is specially a problem with perfect-forward secrecy, ie enough traffic and be recorded and later decrypted. 2. Another issue is about pre-computed primes, which are stored along with certain critical packages such as certain versions of apache and sshd. This can lead to pre-computation and offer attacker an advantage of compute once, use many to decrypt traffic. 3. The third problem is an issue with the TLS protocol, which can lead to a downgrade from DHE to DHE_EXPORT. This issue has been assigned CVE-2015-4000
Fixes and Proposals for OpenSSL: =============================== The current versions of openssl packages as shipped with Red Hat Enterprise Linux 6 and 7 do not include DHE_EXPORT or any other export grade cipher suite in its DEFAULT cipher list. Applications that use the DEFAULT cipher preference will not use export cipher suites. However, application specific configuration may re-enable the use of export ciphers. The openssl packages in Red Hat Enterprise Linux 7 excluded export cipher suites from the DEFAULT since their initial release. In Red Hat Enterprise Linux 6, the change was made via the following advisory released as part of Red Hat Enterprise Linux 6.6: https://rhn.redhat.com/errata/RHBA-2014-1525.html This should address the first problem from the above. Secondly as per: https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ "OpenSSL clients will reject connections with DH parameters shorter than 768 bits. As an unfortunately large number of servers use 768-bit parameters still, we’ll be giving them a short grace period to upgrade, with a keen eye out to raising the limit to 1024 bits soon. [OpenSSL 1.0.2b (next release), OpenSSL 1.0.1n (next release)]" This should address the the other two issues listed in comment #4 Fixes and Proposals for NSS: =========================== Currently all versions of NSS packages as shipped in Red Hat Enterprise Linux, accept 512 bit DHE parameters. The following upstream bug and related commit claim to fix this issue and raise the limit to 1023 bits. https://bugzilla.mozilla.org/show_bug.cgi?id=1138554 https://hg.mozilla.org/projects/nss/rev/ae72d76f8d24
Statement: This issue affects the version of openssl and nss libraries as shipped with Red Hat Enterprise Linux 4, 5, 6 and 7. More information about this flaw is available at: https://bugzilla.redhat.com/show_bug.cgi?id=1223211#c4 and https://bugzilla.redhat.com/show_bug.cgi?id=1223211#c5. Red Hat Enterprise Linux 4 is in Extended Life Cycle phase of the support and maintenance life cycle. This issue is not currently planned to be addressed in future updates of Red Hat Enterprise Linux 4.
The following openssl patches increase the limit of the DH parameters to 768 bits. It rejects handshakes with lower sizes: openssl-1.0.1: https://github.com/openssl/openssl/commit/63830384e90d9b36d2793d4891501ec024827433 openssl-1.0.2: https://github.com/openssl/openssl/commit/10a70da729948bb573d27cef4459077c49f3eb46
Created nss tracking bugs for this issue: Affects: fedora-all [bug 1224448]
Created openssl tracking bugs for this issue: Affects: fedora-all [bug 1224447]
GnuTLS: ====== In the versions of GnuTLS shipped with Red Hat Enterprise Linux 5 and 6, the default value of DHE parameter is set to 727 bits. In Red Hat Enterprise Linux 7 (GnuTLS > 3.1) cipher parameters (security level) can be controlled by using priority strings. GnuTLS defaults to priority string "Weak", thereby setting DHE parameter size as 1008 bits. However GnuTLS allows client applications compiled against it, to change the value of the minimum size of DHE parameters which can be accepted from the server, (post initialization to the above mentioned safe values) by using the gnutls_dh_set_prime_bits() function. A client application can use this function to change the DHE parameter size to any value it desires. In Red Hat Enterprise Linux 7 (GnuTLS > 3.1) when client applications attempt to set DHE parameter size to a value lower than the one specified by the security level, it results in a warning message in the log files.
Mozilla released a nss-3.19.1 to fix this flaw: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.19.1_release_notes " The minimum strength of keys that libssl will accept for finite field algorithms (RSA, Diffie-Hellman, and DSA) have been increased to 1023 bits (bug 1138554)."
nss-3.19.1-1.0.fc21, nss-softokn-3.19.1-1.0.fc21, nss-util-3.19.1-1.0.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
nss-3.19.1-1.0.fc22, nss-softokn-3.19.1-1.0.fc22, nss-util-3.19.1-1.0.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 6 Via RHSA-2015:1072 https://rhn.redhat.com/errata/RHSA-2015-1072.html
nss-util-3.19.1-1.0.fc20, nss-3.19.1-1.0.fc20, nss-softokn-3.19.1-1.0.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 6 Via RHSA-2015:1185 https://rhn.redhat.com/errata/RHSA-2015-1185.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 5 Via RHSA-2015:1197 https://rhn.redhat.com/errata/RHSA-2015-1197.html
Java JDKs previously enforced the following lower limit for the DH parameters size accepted by the TLS/SSL client implementation in the JSSE component: - OpenJDK 6, 7 and 8 - 512 bits - Oracle JDK 6, 7, and 8 - 512 bits - IBM JDK 5.0, 6 and 7 - 256 bits Updates released for IBM JDKs in June 2015 (5.0 SR16-FP11, 6 SR16-FP5, 7 SR9-FP1 and 7R1 SR3-FP1): http://www.ibm.com/developerworks/java/jdk/alerts/#IBM_Security_Update_June_2015 for Oracle JDKs in July 2015 (6u101, 7u85, and 8u51): http://www.oracle.com/technetwork/topics/security/cpujul2015-2367936.html#AppendixJAVA and OpenJDK updates matching the above Oracle JDK updates increase the limit to 768 bits. This limit is defined using the jdk.tls.disabledAlgorithms security property set in the java.security file. The specification "DH keySize < 768" defines that the use of DH algorithm with keys smaller than 768 bits is not allowed. The new jdk.tls.disabledAlgorithms default value is: jdk.tls.disabledAlgorithms=SSLv3, DH keySize < 768 In certain IBM JDK versions, RC4 is disabled too, hence the default value is: jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768 Note that older JDK versions prior to the listed updates do not correctly handle the "DH keySize < 768" specification and allow use of smaller DH keys with this setting. They only allow disabling the use of DH completely, using "DH" specification added to the jdk.tls.disabledAlgorithms. Such configuration can be used in OpenJDK 6 and later, Oracle JDK 7 and later, and IBM JDK 7 and later, but is ineffective in Oracle JDK 6 and IBM JDKs 6 and 5.0.
This issue has been addressed in the following products: Red Hat Enterprise Linux 5 Via RHSA-2015:1230 https://rhn.redhat.com/errata/RHSA-2015-1230.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 6 Via RHSA-2015:1229 https://rhn.redhat.com/errata/RHSA-2015-1229.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Via RHSA-2015:1228 https://rhn.redhat.com/errata/RHSA-2015-1228.html
This issue has been addressed in the following products: Oracle Java for Red Hat Enterprise Linux 5 Oracle Java for Red Hat Enterprise Linux 7 Oracle Java for Red Hat Enterprise Linux 6 Via RHSA-2015:1243 https://rhn.redhat.com/errata/RHSA-2015-1243.html
This issue has been addressed in the following products: Oracle Java for Red Hat Enterprise Linux 6 Oracle Java for Red Hat Enterprise Linux 7 Oracle Java for Red Hat Enterprise Linux 5 Via RHSA-2015:1242 https://rhn.redhat.com/errata/RHSA-2015-1242.html
This issue has been addressed in the following products: Oracle Java for Red Hat Enterprise Linux 6 Oracle Java for Red Hat Enterprise Linux 7 Via RHSA-2015:1241 https://rhn.redhat.com/errata/RHSA-2015-1241.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-2015:1486 https://rhn.redhat.com/errata/RHSA-2015-1486.html
This issue has been addressed in the following products: Supplementary for Red Hat Enterprise Linux 7 Supplementary for Red Hat Enterprise Linux 6 Via RHSA-2015:1485 https://rhn.redhat.com/errata/RHSA-2015-1485.html
This issue has been addressed in the following products: Supplementary for Red Hat Enterprise Linux 5 Via RHSA-2015:1488 https://rhn.redhat.com/errata/RHSA-2015-1488.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:1526 https://rhn.redhat.com/errata/RHSA-2015-1526.html
This issue has been addressed in the following products: Supplementary for Red Hat Enterprise Linux 6 Supplementary for Red Hat Enterprise Linux 5 Via RHSA-2015:1544 https://rhn.redhat.com/errata/RHSA-2015-1544.html
This issue has been addressed in the following products: Red Hat Satellite Server v 5.7 Red Hat Satellite Server v 5.6 Via RHSA-2015:1604 https://rhn.redhat.com/errata/RHSA-2015-1604.html
(In reply to Huzaifa S. Sidhpurwala from comment #5) > https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ > > "OpenSSL clients will reject connections with DH parameters shorter than 768 > bits. As an unfortunately large number of servers use 768-bit parameters > still, we’ll be giving them a short grace period to upgrade, with a keen eye > out to raising the limit to 1024 bits soon. [OpenSSL 1.0.2b (next release), > OpenSSL 1.0.1n (next release)]" OpenSSL introduced the DH parameters size requirement of 768 bits in versions 1.0.1n and 1.0.2b: https://www.openssl.org/news/secadv/20150611.txt As previously announced, the limit has now been raised to 1024 bits in versions 1.0.1r and 1.0.2f: https://www.openssl.org/news/secadv/20160128.txt
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 6.4.10 Via RHSA-2016:2056 https://rhn.redhat.com/errata/RHSA-2016-2056.html
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 7 Via RHSA-2016:2054 https://rhn.redhat.com/errata/RHSA-2016-2054.html
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 6 Via RHSA-2016:2055 https://rhn.redhat.com/errata/RHSA-2016-2055.html