On May 19th, 2015 a team of researchers (Henninger et. al) published a paper with the title “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice”.
The paper can be divided in two sections: 1) discrete logs on a 512-bit Diffie-Hellman (DH) group, and 2) a new attack against the Transport Layer Security (TLS) protocol. We’ll review both sections.
The discrete logs on a 512-bit Diffie-Hellman group
The researchers implemented a practical attack against the Diffie-Hellman protocol, when used with a key size of 512-bit. They also theorized on the complexity (time and computing power) required for performing the same calculations on 768-bit and 1024-bit DH groups.
This is not a vulnerability on the Diffie-Hellman protocol itself, nor a vulnerability on a specific implementation of the Diffie-Hellman protocol. It is a cryptographic attack against the Diffie-Hellman protocol only when used with small key sizes, also known as “export” keys. Using the Diffie-Hellman protocol with large key sizes is still valid and secure against this attack. These cryptographic attacks can be leveraged across the industry on devices with small key sizes.
Cisco has long recommended the use of large public keys, and encouraged the adoption of more modern and more secure cryptography. See guidance in the document “Next Generation Encryption”, which recommends that Diffie-Hellman with a group size less or equal to 1024-bit to be avoided. A 2048-bit Diffie-Hellman group is acceptable and Elliptic Curve Diffie-Hellman is preferable.
Smaller key sizes are supported in some Cisco products only because of the need for some customers to inter-operate with older devices and deployments for which larger keys and more modern cryptography are not available. While these smaller key sizes are still supported, the ‘Logjam attack’ work of Henninger et. al. dramatically demonstrates the importance of not using smaller key sizes.
Cisco’s recommendation is for customers to reconfigure their Cisco devices to use larger key sizes. Such reconfiguration should happen on any Cisco products using Diffie-Hellman for key derivation – this includes SSH, TLS and IKE (either version 1 or version 2) for IPSec. For example:
- IKE and SSH should avoid Oakley Group 2 and instead use Oakley Group 14, or follow the Next Generation Crypto guidelines referenced above.
- Any TLS client that uses ephemeral Diffie-Hellman is at risk; use RSA ciphersuites instead where possible.
- TLS servers should be configured to disallow any of the DHE_EXPORT ciphersuites.
While Cisco provides recommendations on the Next Generation Crypto guidelines referenced above, each customer should reconfigure their Cisco devices based on their own risk assessment and best practices, and use the Cisco guidelines as a general reference. Customers should refer to the product documentation for each Cisco product in order to find out how to reconfigure a Cisco device to implement larger key sizes for ephemeral Diffie-Hellman when used for SSH, TLS or IKE for IPSec.
For those customers who would prefer to follow US-government guidelines, NIST Special Publication 800-52 revision 1 (Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations) section 3.3.1 (“Cipher Suites“) provides guidance on recommended TLS ciphersuites.
Customers with contracts can open a TAC service request in order to get support on how to reconfigure a Cisco device. Customers with Cisco products that are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers, should contact that organization for assistance with the appropriate course of action.
The protocol downgrade attack against TLS connections
As part of their research, Henninger et. al found a new vulnerability on the TLS protocol. This is not an implementation vulnerability, but a protocol vulnerability, which means any product using TLS, no matter the actual implementation (OpenSSL, GNUTLS, others) is affected.This has been documented as CVE-2015-4000.
This vulnerability allows an ACTIVE attacker performing a man-in-the-middle attack to downgrade a non-DHE_EXPORT TLS connection to a DHE_EXPORT connection. This would then allow an attack against a 512-bit Diffie-Hellman group.
This protocol-downgrade vulnerability can only be exploited against a server supporting a DHE_EXPORT ciphersuite for TLS. The attack will NOT be successful if the Cisco device acting as a TLS server has been reconfigured (according to our previous recommendation) and the DHE_EXPORT ciphersuites have been disabled.
The Logjam attack is a perfect example of an attack that was theoretical, but became a very real threat in the current environment of readily available raw computing power.
Security practitioners should take note and begin incorporating regular reviews of cryptographic protocols in use as part of their existing security policies. This is an example of an opportunity to make use of the advances in cryptography research, and adjust policies to protect networks in advance of a theoretical threat becoming a real attack.
excellent article. I was at RSA for the talk and your post is certainly easier and more to the point.
Great article! However, I find a couple of contradictions here which leaves me a bit confused:
In the 1st part of the article you mention “This is not a vulnerability on the Diffie-Hellman protocol itself, nor a vulnerability on a specific implementation of the Diffie-Hellman protocol.”,
whereas, in the 2nd part you mention that according to researchers
“…found a new vulnerability on the TLS protocol. This is not an implementation vulnerability, but a protocol vulnerability, which means any product using TLS, no matter the actual implementation (OpenSSL, GNUTLS, others) is affected.”
Which one of these should be deemed to be correct statement?
Thanks !
Glad you found this blog post useful, and thanks for taking the time to provide feedback on it !
Both statements are correct. TLS doesn’t define neither key exchange, nor encryption protocols – it relies in existing ones. So TLS, as an example, may use DH and RSA for key exchange, RC-4, AES and DES for encryption, SHA-1, MD5 and others for hashing, etc. Using a car analogy – the mechanic may tell you “We found you were using an air filter too small for your car, and we also found a design problem in the fuel injection system.”. The air filter (DH) is one of the component in your car’s (TLS) injection system (cipher suite negotiation).
Hope this helps ! 🙂
Got it. And the analogy made a lot of sense 🙂
Cheers!