So it seems SSL/TLS has not been having a good time lately, alongside Heartbleed and POODLE we now have the Logjam attack.
It’s somewhat similar to the FREAK attack earlier this year, but that attacked the RSA key exchange and was due to an implementation vulnerability rather than Logjam which attacks the Diffie-Hellman key exchange as is due to a flaw in the TLS protocol.
The Logjam attack allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography. This allows the attacker to read and modify any data passed over the connection. The attack affects any server that supports DHE_EXPORT ciphers, and affects all modern web browsers. 8.4% of the Top 1 Million domains were initially vulnerable.
Source – weakdh.org
The full technical report is here: Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice [PDF]
Who is affected?
Websites, mail servers, and other TLS-dependent services that support DHE_EXPORT ciphers are at risk for the Logjam attack. Websites that use one of a few commonly shared 1024-bit Diffie-Hellman groups may be susceptible to passive eavesdropping from an attacker with nation-state resources.
Millions of HTTPS, SSH, and VPN servers all use the same prime numbers for Diffie-Hellman key exchange. Practitioners believed this was safe as long as new key exchange messages were generated for every connection. However, the first step in the number field sieve—the most efficient algorithm for breaking a Diffie-Hellman connection—is dependent only on this prime. After this first step, an attacker can quickly break individual connections.
The researchers estimate that an academic team can break a 768-bit prime and that a nation-state can break a 1024-bit prime. Breaking the single, most common 1024-bit prime used by web servers would allow passive eavesdropping on connections to 18% of the Top 1 Million HTTPS domains. A second prime would allow passive decryption of connections to 66% of VPN servers and 26% of SSH servers. A close reading of published NSA leaks shows that the agency’s attacks on VPNs are consistent with having achieved such a break.
Are you at risk?
If you update as soon as patches are available on a regular basis, probably not. Microsoft patched it on May 12 with security bulletin MS15-055, Google fixed the issue with the Chrome 42 update, which debuted on April 15 and the Firefox patch is on the way.
If you run servers or are a Sys Admin, there’s full details here on what you can do and a test tool:
Guide to Deploying Diffie-Hellman for TLS
The researchers have 3 recommendations for deploying Diffie-Hellman:
- Disable Export Cipher Suites. Even though modern browsers no longer support export suites, the FREAK and Logjam attacks allow a man-in-the-middle attacker to trick browsers into using export-grade cryptography, after which the TLS connection can be decrypted. Export ciphers are a remnant of 1990s-era policy that prevented strong cryptographic protocols from being exported from United States. No modern clients rely on export suites and there is little downside in disabling them.
- Deploy (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE). Elliptic-Curve Diffie-Hellman (ECDH) key exchange avoids all known feasible cryptanalytic attacks, and modern web browsers now prefer ECDHE over the original, finite field, Diffie-Hellman. The discrete log algorithms we used to attack standard Diffie-Hellman groups do not gain as strong of an advantage from precomputation, and individual servers do not need to generate unique elliptic curves.
- Generate a Strong, Unique Diffie Hellman Group. A few fixed groups are used by millions of servers, which makes them an optimal target for precomputation, and potential eavesdropping. Administrators should generate unique, 2048-bit or stronger Diffie-Hellman groups using “safe” primes for each website or server.
This whole thing does raise some issues with trust, trust in cryptography, in the algorithms, the implementation and the fact that cryptography brings along with it certain promises that should avoid nation state eavesdropping.
I guess we’ll have to wait a little longer to see how dangerous this is in the practical world.
Chris says
Once I’ve created a new 2048 bit DH group using OpenSSL, how do I change it when using IIS on the 2012R2 server?
Darknet says
1. Open the Group Policy Object Editor (i.e. run gpedit.msc in the command prompt).
2. Expand Computer Configuration, Administrative Templates, Network, and then click SSL Configuration Settings.
3. Under SSL Configuration Settings, open the SSL Cipher Suite Order setting.
4. Set up a strong cipher suite order. See this list of Microsoft’s supported ciphers and Mozilla’s TLS configuration instructions.
Chris says
Yeah I’ve followed those instructions and have a cipher set of :
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
SSL_CK_DES_192_EDE3_CBC_WITH_MD5,
TLS_RSA_WITH_NULL_SHA256,
TLS_RSA_WITH_NULL_SHA
And SSLLAbs testing still tops out at a B Grade due to
“This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B. ”
Checking the info from SSLLabs it comes up with
“Uses common DH prime Yes Replace with custom DH parameters if possible (more info)”
However none of the information I have found on Google, including the https://weakdh.org/logjam.html website says anything more than your 4 steps above.
Thanks for you help.
Darknet says
From what I understand IIS uses a static 768-bit Diffie Hellman prime – so there’s not much you can do about that.
You can check this out too – https://www.nartac.com/Products/IISCrypto/
Darknet says
You may find this useful:
https://www.hass.de/content/setup-your-iis-ssl-perfect-forward-secrecy-and-tls-12
Patrick says
Is there a way to do a feature check via webcode so that a visitor could be informed that they are vulnerable?
Im thinking about adding this to my website.
Darknet says
They do it on https://weakdh.org/ so yah definitely, basically they do it by loading https://dhe512.zmap.io in an iframe, if it can load you are vulnerable. Not sure how reliable a test it is though, as I can load it on all my browsers which are updated with the supposed fixed versions.