Logjam and more SSL Woes

padlockjamOver the past few years we have received continual reports of new attacks on SSL/TLS. Given the importance of this protocol for protecting almost all Internet transactions (and many many others), this cannot be ignored. Logjam (https://weakdh.org) is a new attack, that can also have devastating ramifications. I won’t go into the details of Logjam since you can find this in many other blog posts and on the Logjam website itself. Rather, I want to try to analyze what sort of flaw Logjam is and what the meta-solution to such flaws is.

The researchers who discovered Logjam explain that this is a “protocol flaw” and not an implementation bug. What they mean by this is that the Logjam vulnerability affects implementations that follow the SSL/TLS spec to the letter. This is in contrast to many other flaws in cryptographic solutions that are due to an incorrect implementation of the spec. However, it’s important to understand that Logjam is not a flaw in the cryptographic design of SSL/TLS. Rather, the vulnerability is due to support of legacy modes that are today easily broken (but may have been semi-reasonable back in the day). In particular, prior to the Clinton administration’s easing up of crypto export regulations in the year 2000, cryptographic encryption keys in software exported from the US had to be kept short by law. Thus, the export-controlled version of SSL using Diffie-Hellman key exchange used a 512-bit key which can be easily broken. The researchers did a really good job of showing that not only is it broken but it can be broken in REAL TIME. This is the most interesting part of the attack, at least in my opinion. Since the key can be broken in real time, it is possible to completely bypass the entire SSL/TLS “version rollback” protection mechanisms.

If I lost you in the previous paragraph, it’s not really that important. What is important is that Logjam is due to legacy cryptographic modes being supported forever and not being phased out. Yes, there may be some people running Windows 3.1 out there, and there may be quite a few more running Windows XP. If a web server doesn’t support the crypto that they know how to use, then they can’t go to SSL protected websites. In addition, there may be web servers who can only run pre-2000 export controlled crypto, and so if browsers refuse to support such crypto then these websites will break. However, if supporting them means making the rest of the world vulnerable, then we should just not support them. This is the crux of the problem: supporting ancient crypto doesn’t just mean that old web servers are vulnerable, it makes everyone else vulnerable as well. We have seen this happen multiple times in the past. The real solution to this problem is to stop supporting really old implementations. I know that many people will roll their eyes and say “get real”, but I’m talking really old, and I’m talking about security for everyone versus compatibility for a a small irresponsible minority.

This issue actually arises elsewhere. There are many discussions around using hardware versus hardware for security (to protect keys and so on). There are many security advantages to hardware, but there is also one really big disadvantage. Highly certified hardware is really slow to be updated (if it’s even possible at all). This means that new standards are incorporated late, and known bugs stay around for a long time. In contrast, software can be easily updated and fixed. Of course, this is just one part of the story, and the choice of software versus hardware depends very much on the specific solution and the needs. (For example, storing secret keys in software on the machine using them is a bad idea and is very insecure; always prefer hardware to that. However, with something like Dyadic’s DSM, good security can be achieved in software as well, and this completely changes the equation. This discussion also ignores the biggest issues around hardware versus software which is related to usability, scalability, and so on. However, that’s not relevant to this post.)

In conclusion: the world has to phase out old crypto and it has to do it periodically. In 2011, TLS 1.2 was finally updated so that SSL 2.0 would no longer be supported. Maybe we shouldn’t wait long to do the same to SSL 3.0.

Prof. Yehuda Lindell

Prof. Yehuda Lindell

Yehuda Lindell is a professor of Computer Science at Bar-Ilan University, and a cryptographer with expertise in secure multiparty computation (MPC) that forms the technological core of Unbound’s solutions. Yehuda served as the Chief Scientist of Unbound from its inception until February 2019, when he took over the role as CEO.

Subscribe to BLOG

shares