On Jan. 28, 2016, OpenSSL released a new version of OpenSSL software. This release contains (among others) two potentially important security fixes to which we would like to draw your attention:
- SSLv2 does not block disabled ciphers (CVE-2015-3197) and
- DH small subgroups (CVE-2016-0701)
Akamai would like to inform you that our customers are not vulnerable to these issues on our delivery platform, however, customers should confirm that their origin servers are not exposed to these two issues. Here are some additional details about these two fixes.
CVE-2015-3197 is an issue where a connecting client can force an SSL handshake to complete via SSLv2, even if all SSLv2 ciphers are disabled. It is important to note that simply disabling the SSLv2 ciphers on your OpenSSL server will not mitigate this issue. In order to prevent an SSLv2 connection, support for the actual protocol must be disabled as well. In other words, even if the server configuration only allows strong ciphers (such as AES-GCM) that are not part of SSLv2, it is possible for an attacker to "slip through" these disabled ciphers and complete a handshake using SSLv2. SSLv2 is a weak and broken protocol and should not be used. If that's not possible -- and really, the only reason is having to support very old clients (from the 20th century) -- then this OpenSSL fix becomes even more important.
Akamai recommends that our customers examine their origins (as well as any other outward-facing service such as SSL-based VPN's) and make sure that the SSLv2 protocol is disabled. Although many of you may have done this as part of the POODLE cleanup in Oct 2014, it is worth verifying. Of particular concern are customer origins that support SSLv2. Akamai cannot check whether a particular origin supports SSLv2. While we will always try to use the strongest protocol available, we cannot prevent outside users from connecting to customer origins via SSLv2 if the origin supports it.
All Akamai systems, such as our portal and storage network, have disabled SSLv2 and SSLv3. The use of SSLv2 is disabled on our secure network and the shared certificate network.
Akamai is not vulnerable to the second attack (CVE-2016-0701). This attack requires a combination of weaknesses in order to be exploited: a "bad" ephemeral Diffie-Hellman (DH) key, and software that is trying to minimize CPU cost by re-using that key. An attacker can then make multiple connections and if an "unsafe" key is used, can eventually collect enough information to find the private key.
Ephemeral DH provides forward secrecy, but at the cost of generating a keypair on every new connection. Many systems do not do this, and often re-use a key for a day, or perhaps across multiple virtual origins on the same machine. The proper fix is to not re-use keys, but if they must be used, make sure that a safe (non-bad) keypair is used. The OpenSSL advisory has details on how to do this. Note that only OpenSSL version 1.0.2 is vulnerable. Akamai encourages its customers to look at their source, and upgrade if necessary.
Another solution to CVE-2016-0701 is to use elliptic curve Diffie-Hellman key exchange (ECDHE), and not DHE. This achieves the same benefit (forward secrecy) but at a lower CPU cost while still avoiding the attack vector.