Another day, another codename for a security vulnerability. This time it's "LogJam". Doesn't have quite the ring of BEAST or FREAK but similar in some ways to the latter.
In short, a RHEL6 appliance with an OSU later than October 2014 is not susceptible to the downgrade to export-grade ciphers and uses 2048-bit DH parameters. RHEL5 appliance UIs do not allow the downgrade to export-grade ciphers and use 1024-bit DH parameters. Communication between appliances and proxies (prior to 10.2) is susceptible to downgrading and uses 512-bit DH parameters.
I discuss in more detail below but inter-communication between proxies and appliances is vulnerable. However, the complexity of the attack and the fact it would have to occur inside of a (hopefully) protected network limit the possibility of the vulnerability being exploited. The vulnerability poses a much more serious threat to public facing applications or sites.
Adrian et al, published their findings and materials on https://weakdh.org/. The WeakDH.org site and OpenSSL blog (https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/) provide excellent detail on the vulnerabilities and how to test for them and the paper itself is available if you fancy the technical detail (https://weakdh.org/imperfect-forward-secrecy.pdf).
The attack is a man-in-the-middle (MiTM) attack. A connection is "downgraded" to a weaker Diffie-Hellman (DH) group. Without going into implementation details - a higher-bit group is regarded stronger for the DH key-exchange. Pre-computing the weak groups allows the MitM to compromise a connection quickly when intercepting the initial key exchange. According to the paper, a 512-bit group was pre-computed in a week by the team and nation-states could (and probably have) compute 1024-bit groups in a time to make them useful. This is an issue because a large number of servers employing DH key-exchange use a "small number of fixed or standardized groups".
The WeakDH.org team have 3 recommendations for correctly deploying Diffie-Hellman for TLS (https://weakdh.org/sysadmin.html) which involves disabling the export-grade cipher suites, deploying Elliptic-Curve DH ciphers and generating strong (more importantly - unique) DH groups. Red Hat's article on LogJam (https://access.redhat.com/articles/1456263) focusses on stopping export-downgrade and information on how to stop clients accepting smaller DH parameters. OpenSSL is used by the ADDM appliance (httpd - part of the RHEL distribution) as well as for communication (omniORB) between appliances and proxies. The WeakDH.org team also recommend OpenSSH configuration changes to mitigate the fact OpenSSH also uses DH groups and this affects the appliance only.
Red Hat excluded export-grade ciphers in a patch to OpenSSL packages shipped in RHEL 6 from 6.6 (https://rhn.redhat.com/errata/RHBA-2014-1525.html). These packages were included in the October 2014 OSU. This means the UI on the appliance (you are using HTTPS, right? ;D) is not vulnerable to downgrade assuming an October OSU, or later, has been applied. For those customers that have followed the steps to implement mod_nss, the upstream change is currently “under investigation by Red Hat and may be backported to the relevant NSS packages”. The DH parameters are 2048-bit.
Unfortunately, because the CVE has been rated “Moderate Impact”, Red Hat will not be patching the OpenSSL packages on RHEL 5. That said, running the OpenSSL suggested tests for vulnerability (with suitable warning that it’s just a smoke test) shows a RHEL 5 ADDM appliance does not allow exporting ciphers and uses 1024-bit DH parameters. I suspect this is due to the SSLCipherSuite configuration.
Running the OpenSSL tests against the externally visible omniORB ports on an up-to-date RHEL6 appliance shows that it does not allow export-grade ciphers (it uses openssl shipped with RHEL) and uses 512-bit DH parameters. Running the same tests on the proxy side shows the proxy will allow downgrading and uses a 512-bit DH parameters. Unlike the appliance, the proxy is built against a specific version of OpenSSL (can't rely on it existing in the OS) and carries the required files to allow communication. We update the OpenSSL version as often as is feasible (latest available before release) but the fix in OpenSSL (upstream, not RH) was not available in any of the current releases at the time we built the proxies. From 10.2, the proxy does not support downgrade of the ciphers due to a tightening of the list of ciphers but earlier versions are susceptible. There are no onsite configurations that can be used to stop downgrade or increase the DH parameters.
In the short term, we're going to ship proxies in an upcoming OSU - making them available by the UI - that will stop downgrading to export-grade ciphers. However, increasing the size of the DH parameters will introduce a lot of upgrade and compatibility complications and further planning and testing needs to be done before we consider exactly what to do. While deploying elliptic-curve ciphers and generating additional groups is recommended by the WeakDH team it's more relevant to publicly facing applications and sites than an application inside the network. Regardless of the complexity of the attack, and the limited scope, the ADDM team are looking at ways we can help limit susceptibility further. As Schneier, the Chuck Norris of the security world (http://www.schneierfacts.com/), states; "One of the problems with patching the vulnerability is that it breaks things" (https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html), and we want to avoid that
*UPDATE (5th June 2015): Of course Red Hat chose to back port a patch to the OpenSSL packages today (Red Hat Customer Portal) that enforces DH parameters >=768-bits. Essentially, this patch, once applied, will affect communication between appliance<->appliance and appliance<->proxy because the appliance relies on OpenSSL shipped with RHEL. The patch is marked Moderate severity so this will be rolled into a monthly OSU rather than an immediate patch and we will do our best to make sure the updates to the required bits of ADDM are as seamless as possible.
*UPDATE (15th June 2015): To clarify my above update. Red Hat's update will be included in a future OSU and that this affects only disabling cipher downgrade on the appliance - it does not increase parameters. We're looking at how best to allow for this patch and how it will work and affect ADDM - as well as how best to upgrade the appliance and proxies with as little disruption to customers as possible. We'll have an update on how we're going to do this ASAP.
*UPDATE (10th July 2015): We have added the following message to the OSU June documentation.
The openssl-1.0.1e-cve-2015-4000.patch has been excluded from the openssl-1.0.1e-30.el6_6.11 RPM to prevent compatibility issues in existing BMC Atrium Discovery deployments.
The patch prevents OpenSSL allowing connections with DH parameters fewer than 768 bits. OpenSSL is used in BMC Atrium Discovery for communication between appliances for consolidation and clustering, and between appliances and Windows proxies. All these channels currently use 512 bit DH parameters. If the patch was included, no communication between appliances and proxies would be possible until all were upgraded.
Future releases of BMC Atrium Discovery will increase the DH parameters to 2048 bits. Excluding the patch at present allows planned roll-out of updates rather than a forced immediate upgrade of all systems.
*UPDATE (17th September): As of 10.2.0.1 both the appliance and proxies are using 2048 bit DH parameters (Defects resolved in this version - BMC Atrium Discovery 10.2 - BMC Documentation - ADDM-16279). We will continue to remove the openssl-1.0.1e-cve-2015-4000.patch from the openssl RPM shipped in the OSU for backwards compatibility with older proxies and appliances.