Thursday, April 10, 2014

A Little Context on the OpenSSL and GnuTLS Bugs

If I'm getting confused, you probably are too, so for a little historical perspective, here's Steven J. Vaughan-Nichols from last month:

According to some reports you'd think the security sky was falling. Yes, GnuTLS, an open-source "secure" communications library that implements \Secure-Socket Layer (SSL) and Transport Layer Security (TLS), has serious flaws. The good news? Almost no one uses it. OpenSSL has long been everyone's favorite open-source security library of choice.

Red Hat discovered the latest in a long-series of GnuTLS bugs .

Latest? Yes, latest.

You see, GnuTLS has long been regarded as being a poor SSL/TLS security library. A 2008 message on the OpenLDAP mailing list had "GnuTLS considered harmful" as its subject — which summed it up nicely. 

In it, Howard Chu, chief architect for the OpenLDAP, the open-source implementation of the Lightweight Directory Access Protocol (LDAP), wrote, "In short, the code is fundamentally broken; most of its external and internal APIs are incapable of passing binary data without mangling it. The code is completely unsafe for handling binary data, and yet the nature of TLS processing is almost entirely dependent on secure handling of binary data. I strongly recommend that GnuTLS not be used. All of its APIs would need to be overhauled to correct its flaws and it's clear that the developers there are too naive and inexperienced to even understand that it's broken." 

With GnuTLS's most recent and perhaps biggest failure to date, Red Hat found that GnuTLS, when shown a specially rigged kind of bogus SSL certificate, would fail to see that the certificate was a fake.

What we learned this week is that OpenSSL had a vastly worse vulnerability, known as Heartbleed.

So... well, one thing is for sure, if two gaping holes in the security backbone of the open source internet architecture had come out six months after The Cathedral and Bazaar was published, we might be living in a completely different, even more proprietary technological world where, say, your Sun Microsystems stock might be worth something. At this point, the overall role of open source processes is well established, and it is clear that switching to proprietary security software isn't going to protect us from prying eyes. Still, what happened to the open source mantra that "with enough eyeballs, all bugs are shallow?" Well, as Timothy B. Lee put it:

The Heartbleed story highlights just how central to online security the OpenSSL library has become. Thousands of organizations use it to protect the privacy of millions of users. Yet the software is developed by a small, volunteer-driven organization. The project lists just 15 developers as responsible for maintaining the software. As one security expert puts it, the team does "a hard job with essentially no pay."

With so many organizations depending on a small, under-resourced project, mistakes were inevitable. It will cost companies and governments millions of dollars to clean up the mess created by Heartbleed. It would be good if some of those deep-pocketed organizations invested resources in helping to improve the OpenSSL code so it's less likely to happen again.

Unfortunately, there's a huge collective action problem. The risk of any specific company or policymaker being blamed for a security breach is low, so everyone assumes that someone else will do something about it.

Right now, we have a "National Security Agency" dedicated to making the internet insecure. We need the opposite.

No comments: