Today, news broke of Logjam, an attack on TLS connections using Diffie-Hellman ciphersuites. To protect OpenSSL-based clients, we’re increasing the minimum accepted DH key size to 768 bits immediately in the next release, and to 1024 bits soon after. We have also made several other changes to strengthen our cryptographic defaults and have updated our tools and documentation to help servers configure Diffie-Hellman ciphersuites securely - see below for details.

The Logjam attack

A group of top security researchers, including those that brought us bad news about FREAK, have published Logjam, yet another attack on the ageing crypto in TLS. They observe that a man-in-the-middle attacker can downgrade TLS connections to hundreds of thousands of vulnerable servers to 512-bit export Diffie-Hellman. We know that 512-bit Diffie-Hellman is rather weak, and that after a significant one-time computation, new instances of the discrete logarithm can be broken fairly easily. What we didn’t know is the exact cost of this precomputation, and Logjam brings 512-bit Diffie-Hellman down to its knees by completing it for a common 512-bit group in under 100,000 CPU core hours.

What is the impact of Logjam? Well, an adversary that has 100,000 core hours to spare has two avenues for attack.

First, If the server’s DH group is weak, an attacker can launch an active attack to take over the connection, or simply passively eavesdrop on the wire. After succeeding once in the expensive precomputation, they’ll be able to decrypt old sessions established with the same parameters relatively cheaply, too. All notion of forward security is lost if the forward-secure crypto itself is broken! About 1000 trusted HTTPS sites are vulnerable if 512-bit Diffie-Hellman is broken, and 46,700 trusted sites fall with 768-bit Diffie-Hellman, according to the technical report.

Second, connections to servers that support export ciphersuites are still vulnerable even if the server’s regular DH parameters are strong. Passive attacks no longer work but an active man-in-the-middle attacker can initiate an export connection to the server, obtain signed export-grade Diffie-Hellman parameters, break these and take over the connection by replaying these parameters to the client. Due to yet another unfortunate wrinkle of the TLS protocol, the client will accept these even if she does not support export ciphersuites: the protocol simply does not offer the client a way of telling whether ephemeral DH parameters belong to an export ciphersuite or not. FREAK already taught us that export ciphers are dangerous, yet 3.4% of trusted sites (over half a million in total!) are still vulnerable to this attack.

A final twist of the findings is the fact that most servers share common, built-in DH parameters. This means that the attacker can leverage the expensive one-time cryptanalytic computation on all these servers at once. The researchers suspect - though it remains speculation - that nation-scale adversaries may even have broken 1024-bit Diffie-Hellman for a few common groups. According to their estimates, that’s about 45 million core years of computation.

Upcoming changes in OpenSSL

Following these findings, we have started to more aggressively revise the cryptographic defaults in OpenSSL. The following changes are either already released or coming up in the next releases of our supported stable branches.

• Changes affecting OpenSSL 1.0.1 and OpenSSL 1.0.2:
  • 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)]
  • Export cipher suites are disabled by default. [OpenSSL 1.0.2a (current release), OpenSSL 1.0.1m (current release)]
  • The openssl dhparam tool generates 2048-bit DH parameters by default. [OpenSSL 1.0.2 (all releases), OpenSSL 1.0.1n (next release)]. You can use an earlier version of the tool to generate secure parameters as well - just make sure to specify the bitlength explicitly:

    $ openssl dhparam -out dh_2048.pem 2048
    

    If you absolutely must continue to use a 1024-bit group (e.g., for compatibility with older clients - JDK 7-based clients are known to reject groups larger than 1024 bits), avoid the defaults built into your server software and make sure to generate fresh, custom parameters instead.

• Changes affecting OpenSSL 1.0.2 only:
  • Clients will only advertise strong (at least 256-bit) elliptic curves, and OpenSSL servers configured to do ephemeral ECDH automatically with SSL_CTX_set_ecdh_auto will only support strong curves as well. This is a purely precautionary measure: there is no demonstrated attack for even the weakest of curves used in TLS yet - but this time, we don’t want to be caught by surprise. [OpenSSL 1.0.2b (next release)]

A February TLS survey of top Alexa sites discovered 3 sites that prefer 512-bit DH, and 420 sites that prefer 768-bit DH. The 512-bit connections will now break; the 768-bit sites should urgently upgrade. Only 26 surveyed sites prefer an elliptic curve weaker than 256 bits - however, since in ECDH, the client can announce its supported range, OpenSSL client connections to these sites will still work if they also support a stronger curve.

Is my server vulnerable to Logjam?

Here’s how to quickly diagnose a server’s DH configuration with OpenSSL 1.0.2 command-line tools. This is, of course, just a smoke test - failing it is bad but passing it is alone not a guarantee that the configuration is secure.

$ openssl s_client -connect www.example.com:443 -cipher "EDH"

Replace the host and port with your server’s information. In the connection information, look for “Server Temp Key:”:

$ openssl s_client -connect www.example.com:443 -cipher "EDH" | grep "Server Temp Key"

The key should be at least 2048 bits to offer a comfortable security margin comparable to RSA-2048. Connections with keys shorter than 1024 bits may already be in trouble today. (Note: you need OpenSSL 1.0.2. Earlier versions of the client do not display this information.)

If the connection fails, then the server does not support Diffie-Hellman ciphersuites. In this case, you may want to check that it supports ECDH for forward security instead:

$ openssl s_client -connect www.example.com:443 -cipher "ECDHE"

The connection should succeed.

Finally, verify that export ciphers are disabled:

$ openssl s_client -connect www.example:com:443 -cipher "EXP"

The connection should fail.

The OpenSSL team would like to thank Karthikeyan Bhargavan and Antoine Delignat-Lavaud (Prosecco, INRIA) and Adam Langley (Google) for their helpful suggestions and insights.