OpenSSL Heartbeat Vulnerability
The recently reported OpenSSL vulnerability is no joke. Although it was patched quickly, huge portions of the Web were, and in many cases, remain, vulnerable. Among other things, cloud providers must first update to the patched version and then their customers must get new certifications, since the old ones might well have been compromised. Finally, consumers must update their passwords on virtually their Web site accounts, but that’s only really useful once everyone updates their certificates.
But lurking quietly amidst the chaos is the proverbial elephant: should we be using OpenSSL at all?
In our opinion, OpenSSL is a bundle of exploits waiting to happen, some of which may already be known to attackers. The good news is that there are other, potentially superior implementations of TLS/SSL. The bad news is that it could take years for the Web to move away from OpenSSL.
OpenSSL Is Not The Answer
Not to beat a dead horse, but, just as an example, the heartbeat code that caused this problem consists of more than 150 lines of mediocre C code. Keep in mind, the purpose of the heartbeat is just to confirm the existence of a connection. You send a message, which is echoed back. There are few additional complications, such as setting the message type, and so forth, but it’s difficult to understand why this would ever require that much code.
At any rate, the point here is not to excoriate the developers. No one forced Amazon or Heroku, or anyone else, to use OpenSSL. At Panda Strike, we were becoming increasingly concerned about OpenSSL even before this exploit was discovered, partly because of recent exploits discovered in gnuTLS and Apple’s TLS implementations. We weren’t reassured by looking at the code, nor its rather vague provenance.Particularly the following: some sponsors…have requested to remain anonymous (emphasis added). And, then, of course, before we were able to even decide on a course of action—do we switch to a different TLS implementation? if so, which one?—the heartbleed bug hit.
To my mind, this settles this issue. OpenSSL is not a viable implementation for TLS. We all need to move away from it, not merely patch it. Staying on OpenSSL is just asking for trouble. We’ve all had fair warning. No one has any real excuse for having stayed with OpenSSL, should there be another major exploit.Or, really, even a minor one. Any exploit that ends up compromising your application is major, at least to you. The real question is, what are the best alternatives?
Maybe C/C++ Isn’t The Answer, Either
I think we can rule out gnuTLS, since it’s arguably in even worse shape than OpenSSL. There’s Mozilla’s NSS project, which is used not only by Mozilla, but also Google and others, and the code quality looks better. Daniel Bernstein, he of Bernstein v. United States notorietyI use the word notoriety with the utmost respect, just in case that isn’t clear., has written his own library of crypto routines, NaCl (get it?), although these aren’t quite what you need for TLS.
In fact, there are many alternatives that may be worth exploring. What most, if not all of these implementations share, however, is the fact that they’re written in C or C++. And there’s mounting evidence that humans can’t write C or C++ code in a secure fashion, regardless of the quality. In the recent Pwn2Own contest, all four major browsers were compromised, in many cases using memory-related exploits that aren’t any different, in principle, than the heartbleed bug.
In a recent discussion on HackerNews, crypto-analyst Thomas Ptacek makes a similar point:
What security-conscious developer believes C is a good language in which to write complicated, security-critical code? You write code in C because you have to.
Haskell to the Rescue?
Later, in response to a (mistaken) suggestion that test-driven design would have prevented the gnuTLS bug, he goes further (emphasis added):
I have a hard time not being dismissive about TDD’s role in improving systems software security. If you’re going to propose a radical change in the way systems code is written (or, worse, hold systems developers to a nonexistent standard), be intellectually coherent about it: demand that security-critical code be implemented in a rigorous language, like idiomatic Haskell. Don’t propose monumental changes that promise only that the resulting code will be asymptotically secure as Ruby on Rails.
What if the real problem here is that we’re simply using the wrong language? So I checked to see if there was a viable TLS implementation in Haskell, and sure enough, there was. In fact, it’s more widely used, within Haskell packages, than the OpenSSL bindings. So is Haskell TLS a viable option? I asked this of the HackerNews community and was surprised to find a great deal of interest in the topicMore so than, for example, the announcement of Rails 4.1. In fact, for several hours Tuesday night, it was the top post on HN. Perhaps the time is right for this to happen. Coincidently, version 7.8.1 of the Glasgow Haskell Compiler was released this morning. Haskell TLS could be compiled into a shared library and used exactly as we do OpenSSL.
Going Forward
We’l be looking at this option, and others, more closely in the near future. But maybe—in the wake of arguably the biggest security failure in the history of the Internet—it’s time to start thinking out of the box.