!!! Overview[1]
[{$pagename}] [exploit] is against the [TLS] protocol.

[{$pagename}] allows a downgrade in [TLS] to [Export-grade] [Cryptography] which then allows [decryption]

[Diffie-Hellman key-exchange] is a popular [cryptographic] [algorithm] that allows Internet [protocols] to agree on a shared key and negotiate a [secure connection]. 

[{$pagename}] is fundamental to many protocols including [HTTPS], [SSH], [IPsec], [SMTPS], and [protocols] that rely on [TLS].

We have uncovered several weaknesses in __how [Diffie-Hellman] key exchange has been deployed__:

[{$pagename}] 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] is reminiscent of the [FREAK] attack, but is due to a flaw in the [TLS] protocol rather than an implementation [vulnerability], and attacks a [Diffie-Hellman key-exchange] rather than an [RSA key-exchange]. 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.

Threats from state-level adversaries. 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.

We carried out this computation against the most common 512-[bit] prime used for [TLS] and demonstrate that the [{$pagename}] [attack] can be used to downgrade connections to 80% of [TLS] servers supporting DHE_EXPORT. We further 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.

[{$pagename}] [exploit] demonstrated that the security of [Diffie-Hellman] is lower than expected, notably when the prime is shared by many servers as this is usually the case. When the "prime" is shared an attack against the "prime" can be precomputed and used to efficiently break connections using the same prime. Ensure that the DH parameter matches the size of the associated RSA key (at least 2048 bits).[2]

!! What Should I Do?[3]
We have three recommendations for correctly deploying Diffie-Hellman for TLS:
* Disable [Export-grade] [Cipher Suites]. Even though modern browsers no longer support [export-grade] 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. No modern [TLS] clients rely on [export-grade] 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.
* Use a Strong, [Diffie-Hellman] Group. A few 1024-bit groups are used by millions of servers, which makes them an optimal target for precomputation, and potential eavesdropping. Administrators should use __2048-bit or stronger__ [Diffie-Hellman] groups with __"safe"__ primes.
* Implement [TLS Fallback Signaling Cipher Suite Value (SCSV)]

!! [Understanding Logjam and making WSO2 servers safe|http://blog.facilelogin.com/2015/07/understanding-logjam-and-making-wso2.html|target='_blank'][4]
The blog [Understanding Logjam and making WSO2 servers safe|http://blog.facilelogin.com/2015/07/understanding-logjam-and-making-wso2.html|target='_blank'] has a great explaination and shows a use case for the [exploit]. He further points out that some of the reasons for [{$pagename}] was:

"''During the crypto wars happened in 90's it was decided to make ciphers weaker when its being used to communicate outside USA and these weaker ciphers are known as EXPORT ciphers. This law was out-turned later, but unfortunately TLS was designed before that and it has the support for EXPORT ciphers. According to the EXPORT ciphers the DH prime numbers cannot be longer than 512 bits. If the client wants to use DH EXPORT ciphers with 512 bit prime number, then during the Client Hello message of the TLS handshake its has to send DH_EXPORT cipher suite.
''"


!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Weak Diffie-Hellman and the Logjam Attack|https://weakdh.org/|target='_blank'] - based on information obtained 2015-10-25
* [#2] - [SSL/TLS & Perfect Forward Secrecy|http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html|target='_blank'] - based on information obtained 2013-04-10
* [#3] - [Guide to Deploying Diffie-Hellman for TLS|https://weakdh.org/sysadmin.html|target='_blank'] - based on information obtained 2015-10-25 
* [#4] - [Understanding Logjam and making WSO2 servers safe|http://blog.facilelogin.com/2015/07/understanding-logjam-and-making-wso2.html/|target='_blank'] - based on information obtained 2016-01-05-