3 big lessons to learn from Heartbleed

The devastating OpenSSL vulnerability proves the importance of data center orchestration, the wisdom of running older versions, and the need to give back to the OpenSSL project

Page 2 of 2

Regarding my second point, we have to take into consideration that this vulnerability affected only certain OpenSSL versions. OpenSSL versions prior to 1.0.1 are not vulnerable -- and a massive numbers of active servers using OpenSSL for Web and other services are happily running OpenSSL 0.9.8 through 1.0.0 with no fear of the Heartbleed bug. For those of us not running bleeding-edge production servers, this meant that we had little to worry about. Here's a big takeaway: If you were running RHEL or CentOS prior to version 6.5 -- the latest version released in November -- you were not vulnerable, as versions through 6.4 used OpenSSL v1.0.0 or older versions. Only if you were keeping up with the edge of those distributions did you have to face this issue directly and immediately.

Those of us who stay a release or two behind the curve for this very reason read the announcement with much concern, then breathed a big sigh of relief when we saw the affected versions. Historically, RHEL (and by definition, CentOS) have been somewhat maligned for using older versions of many packages. You'll find that the kernels and many core service packages are usually a year behind current, though many have backported patches for security issues. This is why RHEL 6.4, released over a year ago in February 2013, shipped an OpenSSL version that was even a year older -- and not vulnerable to Heartbleed.

Running behind current versions is sometimes a curse. For example, you may have an app that needs a newer PHP version than the one available from Red Hat, and you have to find custom packages. But when things like this happen, it makes up for that hassle. At least when you need a newer version of PHP, you aren't under the threat of having your SSL private keys lifted while you upgrade. 

Those who are content to sit back a release or two reaped the rewards this week. Those who have to be on the bloody edge of everything were scrambling -- and that's to say nothing of the folks running Debian, Ubuntu, Fedora, or other distributions that move on a much more current package cycle. If you are in charge of a big Web farm running on one of those distros, I can only hope that you had some orchestration solutions in place. Otherwise, I'm sure your office resembled a meteor strike last week.

Of course, all we've talked about so far was the patching and the schadenfreude of not having to worry about it. We haven't talked about all the rekeying that has to happen.

We patched the vulnerability to prevent the private keys from being leaked, but we have absolutely no way of knowing whether they were leaked or not. Now we have to assume that every cert is compromised, and we have to rekey and regen all of our certs. That's not easily scripted at all -- and most of the time will be spent waiting for the certificate authority to redistribute our certs. While we should be able to close the door quickly, it will take a long time to change the locks.

And maybe it's an opportunity for us to actually give some time and money to the OpenSSL project? It's used everywhere, by large multinational companies in every market imaginable, yet its maintenance is the work of a few people. Maybe it's a signal to give back to the project. The least that should happen is that funding should be collected to enable a dedicated team of developers to rewrite OpenSSL and make OpenSSL their core focus. The OpenSSL developers have been taken for granted for far too long.

This story, "3 big lessons to learn from Heartbleed," was originally published at InfoWorld.com. Read more of Paul Venezia's The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

| 1 2 Page 2