A new attack against the Diffie Hellman protocol has been made public. This weakness allows an attacker (a man in the middle (MITM)) to downgrade the key exchange protocol Diffie Hellman to 512-bit export-grade cryptography. When the TLS (Transport Layer Security) connection is secured using this few bits, it becomes vulnerable to being broken (i.e. obtaining the session key) meaning that the connection can then be eavesdropped upon.
Why is this important?
The Diffie Hellman protocol is used to secure many everyday websites using HTTPS (this makes the lock icon appear or for your browser address bar to display green). Samples of what Extended Validation certificates look like within your web browser are shown on this page. EV certificates are less common than standard single domain name certificates but these images should assist in conveying how widely used HTTPS really is. More information on TLS/SSL is available in this podcast.
Diffie Hellman is also frequently used when accessing servers remotely using SSH and within VPNs (including IPSec VPNs). VPNs are commonly used to access servers in your workplace from outside of your workplace or when using a public internet connection e.g. a coffee shop’s free WiFi.
As detailed in a technical report on this attack (see Page 3: Table 1) since a large number of devices use the same prime number (upon which the most efficient algorithm namely number field sieve for breaking a Diffie Hellman secured connection is based) this means that the time needed to break the connection is significantly reduced. Using this attack (see Page 7: Table 2), the times for breaking common Diffie Hellman secured connections are shown below:
512 bit: Linear Algebra Stage: 7.7 years; Descent Time: 10 minutes
768 bit: Linear Algebra Stage: 28,500 years; Descent Time: 2 days (within reach of academic researchers)
1024 bit: Linear Algebra Stage: 35 million years; Descent Time: 30 days (within reach of a nation state)
I refer you to the section titled “What should I do?” within this page for advice on next steps.
Today I tested Mozilla Firefox (v38.0.1), Google Chrome (v43.0.2357.73, 64 bit, Beta Channel) and Internet Explorer (v11.0.19) to check if they were vulnerable to this attack.
You can check your browser by the visiting this page (also mentioned above). The result will be shown at the top of the page for you.
Both Firefox and Chrome at the time of writing were vulnerable, this is likely to be resolved very soon by both browser vendors.
IE 11 was not vulnerable to this attack (most likely since Microsoft issued MS15-055 as part of its May security updates). However since Microsoft Research is credited as a contributor along with many other computer scientists of the above mentioned report its plausible that this gave them advance notice of the issue to resolve it sooner.
If you use WinSCP, you should ensure you have the latest version installed so that you are no longer vulnerable to Logjam and other more recent OpenSSL vulnerabilities.
Update: 20th May 2015: A ComputerWorld blog post provides a table showing which browsers are currently patched against this flaw.
Update: 7th February 2016:
VideoLAN have updated their VLC media player to version 2.2.2 which addresses the Logjam security issues within their product. Further details are available in a more recent blog post.
Update: 21st May 2015: OpenSSL has published a blog post with a discussion of the Logjam attack, upcoming changes in OpenSSL in response to this attack and provides a means to check if your OpenSSL server installation is vulnerable.
Update: 31st January 2016: To further protect against the Logjam attack the OpenSSL project have now increased the length of the Diffie-Hellman handshake parameters to 1024 bits. Further details are available in this security advisory.
Update: 11th June 2015:
OpenSSL released a security advisory today to resolve 7 CVEs one of which was a workaround for the Logjam security flaw. The change made to resolve this flaw was to reject Diffie-Hellman handshake requests for parameters shorter than 768 bits. A later release of OpenSSL will extend this to 1024 bits. I would advice updating your OpenSSL installations as soon as possible to mitigate these vulnerabilities (usually by using your Linux package manager to install the applicable updates).
Update: 10th July 2015: I have verified that the Opera web browser is not vulnerable to Logjam since version 30.0.1835.52 released on the 9th of June 2015.
In addition, at the time of writing (10th July 2015), Google Chrome v43.0.2357.132 (Stable, 64 bit) and Google Chrome v44.0.2403.81 (Beta, 64 bit) remain vulnerable to Logjam.
Update: 24th July 2015: At the time of writing (24th July 2015), Google Chrome v44.0.2403.107 (Stable, 64 bit) and Google Chrome v44.0.2403.89 (Beta, 64 bit) remain vulnerable to Logjam.
Update: 28th July 2015: Google Chrome v44.0.2403.125 (Stable, 64 bit) remains vulnerable to Logjam. However Google Chrome v45.0.2454.15 (Beta, 64 bit) includes a fix for Logjam. I have verified it is no longer vulnerable.
Update: 12th August 2015: Google Chrome v44.0.2403.155 (Stable, 64 bit) remains vulnerable to Logjam.
Update: 13th August 2015: OpenSSH has released v7.0 which addresses the Logjam issue within it’s implementation.
Update: 25th August 2015: VideoLAN, the creators of VLC have closed the ticket that I mentioned above (see update: 2nd June 2015) since they have resolved the Logjam issue within their code for the upcoming version 2.2.2 of VLC. A related ticket involving a regression (an unintentional introduced software bug/error) caused by the changes they made was also resolved.
I hope that the above advice assists you in securing your servers and computer systems from this new attack. I will update this article when more information concerning updates for web browsers becomes available.