Logjam: TLS vulnerabilities (CVE-2015-4000)

Red Hat Product Security has been made aware of various issues in TLS connections using the Diffie-Hellman (DH) key exchange protocol.

Background Information

TLS connections using the 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 pre-computation of the 512-bit primes given in two popular sets of weak Diffie-Hellman parameters, namely Apache's httpd versions 2.1.5 to 2.4.7, and all versions of OpenSSL.

The Logjam research paper discusses the following issues related to weak DH keys:

  1. The use of DHE_EXPORT cipher suites in the TLS protocol, or DHE keys with export-grade cipher strength: these keys are 512 bits in size and given enough computing power and time, they can be broken. This is especially a problem with perfect-forward secrecy because an attacker could record traffic and later decrypt it.

  2. The use of pre-computed primes that are provided with certain widely-used packages, such as certain versions of Apache httpd and sshd: this weakness allows an attacker to pre-compute such primes once, and use them to decrypt any traffic that uses those primes to establish a TLS connection.

  3. A flaw in the TLS protocol, which can lead to a downgrade from DHE to DHE_EXPORT: this issue has been assigned CVE-2015-4000.

Impact

The following attack scenarios are possible using the issues noted above:

  1. Offline decryption of weak DHE connections
    This attack requires that the server defaults to using a Diffie-Hellman key exchange with 512-bit parameters. This allows a passive network adversary who is able to record the communication between a client and a server to then decrypt this communication.

  2. DHE_EXPORT downgrade and offline decryption of the TLS False Start extension
    This attack requires that a server supports DHE_EXPORT cipher suites or uses 512-bit parameters in non-export DHE ciphers. The client must be using the TLS False Start extension. Under these circumstances, an attacker could record the communication between a client and a server and then decrypt that communication.

  3. DHE_EXPORT downgrade and man-in-the-middle server impersonation
    This is a similar attack to the previous attack, but does not require the TLS False Start extension to be enabled. Instead, the attacker has to rely on the client 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, computing of which takes several minutes.

Resolution

SSL/TLS Servers

In the MITM attack, the attacker tries to connect to the server using DHE_EXPORT cipher suites on behalf of the client. This is achieved by a flaw in the TLS protocol in the way DHE and DHE_EXPORT cipher suites are composed. Using this protocol flaw, an active MITM attack can be conducted provided the server supports DHE_EXPORT cipher suites.

This issue does not affect the current versions of openssl packages as shipped with Red Hat Enterprise Linux 6 and 7 as they do not include DHE_EXPORT cipher suites or any other export-grade cipher suite in its DEFAULT cipher list. (Applications that use the DEFAULT cipher preference will not use export-grade cipher suites. However, application-specific configuration may re-enable the use of export ciphers.) Please note this is only the case when openssl is used by a network server. For information on client issues please see below.

The openssl packages in Red Hat Enterprise Linux 7 excluded export-grade cipher suites from the DEFAULT when used as a server since their initial release. In Red Hat Enterprise Linux 6, the change was made via the RHBA-2014:1525 advisory released as part of Red Hat Enterprise Linux 6.6.

Red Hat Enterprise Linux 5 does support the export-grade cipher suite in its default cipher list. Red Hat does not plan to change the default cipher list in Red Hat Enterprise Linux 5 because this CVE is rated as Moderate Impact. For more information on which Security Advisories are addressed in Production Phase 3, please visit the Red Hat Enterprise Linux Life Cycle page.

SSL/TLS Clients

Since clients do not control the cipher suites controlled by the SSL/TLS server, the only defense is to reject small primes in the DHE handshake. Requiring larger primes can prevent the above mentioned downgrade attacks.

OpenSSL upstream addresses the remaining two issues, by increasing the minimum size of DH parameters which a client can accept to 768 bits. This way even if a MITM attacker downgrades the connection, the client will reject if less than 768 bits are used, which is deemed to be easily breakable.

Currently, all versions of NSS packages as shipped in Red Hat Enterprise Linux accept 512-bit DHE parameters. The following upstream bug and the related commit claim to fix this issue and raise the limit to 1023 bits:

This change is under investigation by Red Hat Product Security and may be backported to relevant NSS packages in Red Hat Enterprise Linux.

Openswan/Libreswan

The Logjam downgrade attack against TLS does not apply to IKE in Openswan and Libreswan. The pluto daemon provided by the openswan and libreswan packages provides the IKEv1 and IKEv2 protocols to establish IPsec VPN tunnels whereas the Logjam attack targets TLS. Openswan and Libreswan also both have default DH groups above MODP1024, and do not support MODP768 and below.

JBoss products

For information on how to mitigate the Logjam vulnerability in affected JBoss products, refer to Logjam: TLS vulnerabilities (CVE-2015-4000) for JBoss products

23 Comments

Great, RHEL6 (as of 6.6) and RHEL7 are not affected sever side... but what about RHEL5?

The article got updated to include, "Red Hat Enterprise Linux 5 does support the export-grade cipher suite in its default cipher list. Red Hat does not plan to change the default cipher list in Red Hat Enterprise Linux 5." Ok. that answers that... but it would nice if you could add a little section on how to disable the feature in common services especially Apache on RHEL5.

To the best of my knowledge the suggested fix by the Logjam info site (https://weakdh.org/sysadmin.html) doesn't work with Apache 2.2.x that is shipped in RHEL5 because Apache 2.2.x lacks the "SSLOpenSSLConfCmd" configuration option... and I believe the only alternative is to disable the feature by adding "!EDH" as a parameter of the SSLCipherSuite configuration option. I'm not a security expert but that seems to be somewhat beneficial (no longer vulnerable) but I'm not sure what if any negative consequences that configuration change might bring with client applications / client location... especially moving forward with pending client applications updates / fixes.

Those who work in the SysAdmin field have tools like QualysGuard foisted on them... and they often contain suggested remediation... but given the handful of SSL and now TLS downgrade bugs that have cropped up over the past year or two... putting them all together for a best practice ssl.conf is a bit challenging. Red Hat's advice (perhaps in a web-based lab tool?) would be great. Ok why am I still running RHEL5? Hey, the vast majority of my systems are RHEL6 and 7 boxes now... but yeah, there are a small amount of lingering RHEL5 boxes in my computer jungle.

OpenSSL packages in Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6 before 6.6 include export ciphers suites in the OpenSSL's DEFAULT cipher suites set. This cipher suites string defines the library default, and is used when application using OpenSSL does not ask the library to use different ciphers.

However, the httpd's mod_ssl actually does override this default. This is what's used in the latest Red Hat Enterprise Linux 5 mod_ssl packages in ssl.conf file:

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

The !EXPORT here means that all export ciphers suites are disabled. Therefore, your server should only be using 1024 bit DH parameters (unless your server key is 512 bit, which should be unlikely).

A practical difference of not removing export ciphers from the DEFAULT is that the following configuration in Red Hat Enterprise Linux 5 makes mod_ssl allow use of export ciphers suites, while they won't be used in current Red Hat Enterprise Linux 6 and 7.

SSLCipherSuite DEFAULT

As per Billy Crook's comment, using 1024 bit DH parameters is insufficient since these are are from the common pool and are easily exploitable. By my understanding, the ability to configure our own DH parameters is still required to close this vulnerability correctly.

In RHEL5 and RHEL6 (httpd 2.2.3 and 2.2.26), what is the recommended method of using a custom generated dhparam.pem (created via openssl dhparam -out dhparam.pem 2048) file?

Appending the pem file to the certificate file as desctibed at weakdh.org does not appear to work.

The httpd packages in Red Hat Enterprise Linux 6 got support for loading DH parameters from the certificate file via RHBA-2014:1386. Note that httpd in Red Hat Enterprise Linux 6 is based on 2.2.15.

The httpd packages in Red Hat Enterprise Linux 5 do not support loading DH parameters from the certificate file.

so, for httpd in RHEL6, then, what action, if any, do we need to take? Do we need to disable cipher suites? Do we need to generate custom DH paramters? (or does it auto generate them based on the RSA key size -- the various tests are showing the DHE bits the same as the RSA key size)?

With Logjam, there are several levels of badness. Following what researches behind this issue cover in their paper, the list can be split as:

  • 512 bit DH parameters are weak. TLS/SSL makes it possible for attacker to force the use of such weak keys even when both client and server support non-export ciphers - it's sufficient to have export ciphers enabled on the server side. Action here is to ensure your httpd configuration does not enable export ciphers, and disable them if it does. They are disabled in the default configuration.

  • 768 bit DH parameters may be broken with resources available to academic groups. No httpd action, as it did not use 768 bit parameters.

  • 1024 bit DH parameters. Researches speculate that breaking this may now be within the reach of state-level attackers. The use of fixed parameters hard-coded in httpd rather than separate ones for each system make the attack more likely by spreading the cost across multiple systems that can be attacked using single broken parameters. Options here are to generate customer parameters of the same size, or use parameters of lager size. For Red Hat Enterprise Linux 6, the httpd packages from RHBA-2014:1386 (or later) are needed for both of these options.

As noted above, httpd packages in RHBA-2014:1386 support reading of DH parameters from the certificate file, making it possible to generate custom parameters (e.g. using openssl dhparam). They also automatically use larger parameters based on / matching server key size. These are still hard-coded parameters, of the following sizes: 1024 (RFC 2409), 2048, 3072, 4096, 6144, and 8192 (RFC 3526). It seems you're using one of these. Option here is to move to use of custom parameters.

So is the DH keysize always going to match the RSA keysize (unless a downgrade to export cipher attack takes place)? Or can the DH keysize be bigger?

The problem with most articles is that they seem to talk about RSA keysize and DH keysize interchangably (ie they say the problem is a small DH keysize and that one should fix this by increasing the RSA keysize... ok).

In my case, I'm using an RSA keysize of 4096, so, I was surprised that a test told me DHE of 4096 as well (when all the articles were talking about fixed 1024 bit DHE keys). Again, didn't make sense.

Can the DHE keysize be LARGER than the RSA keysize?

Note that I'm concerned with more than just a webserver (which, again 99% of the tests out there seem to be focused on, which doesn't help with things such as... email).

Thanks.

DH parameters size does not have to match RSA key size.

Older httpd versions only allowed the use of 2 hard coded DH parameters - 1024 bit one with non-export ciphers, and 512 bit one with export ciphers. So even if you had 4096 bit RSA key, only 1024 bit DH parameters were used.

Newer httpd versions, such as the one from the mentioned RHBA-2014:1386, use additional hard coded parameters with larger size, and use key size to determine which DH parameters to use. If your server key size is in the rage 0..1024, httpd will use 1024 bit DH parameters; if it's in the range 1025..2048 -> 2048 bit DH params; 2049..3072 -> 3072 bit DH params; etc. For commonly used RSA key sizes as 2048 or 4096, DH params will have the same size. For non-standard key sizes, the above can lead to the use of larger DH parameters than RSA key size.

Or course, when setting custom DH parameters via SSLCertificateFile, you can have them smaller or larger than RSA keys size.

The above is specific to httpd, as it describes what httpd does and can not be generalized to other programs.

I have simply disabled DH entirely on RHEL 5.

Basically I use the recommended cypher list from weakdh.org (which is way to long for rhel5, as it does not support most cyphers on the list, but it does not complain) and added :!EDH to the end of it. Works for me, and according to the SSLLabs test it did not lock out any relevant platform. Besides, 2048 bit DH groups lock out Java 6 (should not be relevant anymore).

Can someone confirm the following:
On RHEL 6.6 with apache httpd-2.2.15-39.el6.centos.x86_64 and a private key of 2048 bits with !EXPORTS but DHE enabled

Personal tests show that mod_ssl wil use a 2048 DH parameters in this case since https://bugzilla.redhat.com/show_bug.cgi?id=1071883

Why still the need to explicitly specify a custom dhparm group. Doesn't this already stop the Logjam attack?

We have disabled the EDH Ciphers at Apache Config.
Now there is another issue that the server does not support Forward Secrecy (as openssl version is openssl-0.9.8e-32.el5_11 and does not support ECDHE).
The Server is RHEL 5.11 . So the OpenSSL version on it does not Support TLS 1.1 or 1.2.
[rsiwal]$ egrep '^SSLCipher|^SSLProtocol' /etc/httpd/conf.d/ssl.conf
SSLCipherSuite ALL:!ADH:!EDH:!EXPORT:!SSLv2:!RC4:+HIGH:+MEDIUM:-LOW
SSLProtocol All -SSLv2 -SSLv3
Please suggest

Disabling EDH ciphers removes Forward Secrecy (PFS) support. Disabling EXPORT ciphers should be sufficient. Disabling EDH on RHEL 5 clients is good but not on the servers.

The advice from weakdh assumes that you are running the latest version of OpenSSL which is not what is supported in RHEL 5.

Setting the ciphers in Apache Tomcat to the one specified in https://weakdh.org/sysadmin.html , mkes it support only TLSv1.2:
ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_SHA256,TLS_ECDHE_RSA_WITH_AES_128_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_SHA,TLS_ECDHE_RSA_WITH_AES_256_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_SHA384,TLS_ECDHE_RSA_WITH_AES_256_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_SHA,TLS_DHE_RSA_WITH_AES_128_SHA256,TLS_DHE_RSA_WITH_AES_128_SHA,TLS_DHE_DSS_WITH_AES_128_SHA256,TLS_DHE_RSA_WITH_AES_256_SHA256,TLS_DHE_DSS_WITH_AES_256_SHA,TLS_DHE_RSA_WITH_AES_256_SHA"
/>

I know RHEL 4 is living death already, however we have some customers running our products on it and still refusing upgrade. What's the recommended SSLCipherSuite list after the Logjam and previous SSL/TLS related threats?

Hello: I am a Linux Admin "newbie" and learning what I can since a colleague retired but not much information was handed down to me when he left, but I digress.
So, we have RHEL 4, 5. and 6 (many versions), and it appears that the RHEL 4 and 5 versions will not receive an update, correct? If so, is there a remediation/fix for those versions (other than the canned "migrate to the latest" but is not a reasonable demand due to our environment)?
I am not afraid to admit that I am struggling with this and am extending out to the good people for assistance, and thank you in advance.

A handy command to verify what ciphers your Apache config is allowing, where X is the IP address:

nmap --script ssl-enum-ciphers -p 443  X.X.X.X

The following Knowledge Solution was written to better clarify that OpenSSH in RHEL 5 is NOT impacted by LogJam:
Diffie-Hellman key exchange algorithm with sshd in Red Hat Enterprise Linux

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

RHEL5 version of the patch was released.

Disabling the export ciphers is easy. What I am trying to figure out is how to specify my own DH key. Following this article (https://weakdh.org/sysadmin.html) tells us to use an option that doesn't work in 2.2.x. Could someone from RH actually answer how to specify our own custom DH keys so we don't use the awful 512 sized default.

The httpd version in Red Hat Enterprise Linux 5 does not allow you to specify your own DH parameters. If you're using Red Hat Enterprise Linux 6, update to httpd packages from RHBA-2014:1386 (or later).

If using older httpd version, 1024 bit parameters are used when using non-export ciphers. 512 bit parameters are only offered by httpd when using export ciphers. Updated httpd from RHBA-2014:1386 uses DH parameters with sizes above 1024 bit and chooses them based on the server key size (see also my earlier comment above). It also accepts custom DH parameters set via SSLCertificateFile file.

I'm wondering if adding the DH to the SSLCertificateFile would break other software?