The following, written by Rich Salz, deals with Akamai's response to CVE 2015-0204. The vulnerability has been exploited by such exploits as the so-called FREAK attack.
Back in the last century, the United States tried to control the export of strong cryptography. This policy made its way into the SSL/TLS standards in two ways.
The first part was to add several cipher suites that used small, easily breakable keys. These are all identified with the name EXP at the beginning.
For example, EXP-DES-CBC-SHA. DES normally uses a 56-bit key (which is considered laughably weak these days), and EXP-DES is a variant that uses a 40-bit key -- sixty-five thousand times weaker than "laughably weak". (We're using the common OpenSSL names, not the official names from the TLS RFC.)
The second change is more problematic and, for technical purists, very "ugly."
When a client connects to a server, it encrypts part of its initial connection (known as the SSL handshake) using an RSA key from the server. In the export configuration this key is 512 bits. Twenty years ago, this was considered "pretty good" against commercial adversaries. Now it's "pretty weak." An attacker can go to a cloud provider and can decode a key for around $100 and half a day. In the normal course of operation, this is acceptable behavior -- the client and web server have already agreed to use the known-weak export ciphers. That means that at least one of them has no better options -- say, it's a web browser from 1995.
The problem is that, until CVE 2015-0204 was raised -- and fixed -- an OpenSSL client using strong ciphers (anything other than export) could be tricked into accepting such a weak key. An attacker connects to the web server with an export cipher and gets a message signed with the weak RSA key. He then cracks that key. The following day, for future connections from innocent browsers, he can act as a man in the middle (MiTM). The attacker will use the cracked key to connect to clients, who will accept it. The attacker will then have access to all communication between the client and server. A server that does not support the export ciphers will never use the export RSA key and never send it to a client. A client that has the CVE fixed will never accept such a key.
We've already rolled out the fix on our Secure Network, and this ensures that our internal traffic (midgress traffic) is secure, as well as our our communications to any origin websites (forward traffic). There is still a potential exposure when clients connect to us. We can't fix those clients, but we can avoid the problem by disabling export ciphers. Because this is a client side issue, we've reached out to our customers and are working with them to make this change. A very small number of our customers still rely on offering service to export-mode browsers that cannot reasonably be upgraded.
To see if a website is vulnerable to the RSA weak key attack, you can use this OpenSSL command:
% openssl s_client -connect www.akamai.com:443 -cipher EXPORT
61728:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52.10.1/src/ssl/s23_clnt.c:593:
substituting "www.akamai.com" with your hostname. If you see an "alert handshake failure" of this sort, your host is safe.
We would like to thank Karthikeyan Bhargavan of the Prosecco team at INRIA for initially bringing this to our attention. The website will soon be updated with more information once it is released.