LibreSSL aims to prevent the next Heartbleed

Filed Under: Cryptography, Featured, Security threats, Vulnerability

Stop HeartbleedThe wonderful thing about the internet is that it is full of people who do.

You'd be forgiven for not noticing them - it can sometimes feel like the information superhighway is a gridlock of people yelling, beeping their horns and not listening, but trust me, underneath all that posturing it's crawling with doers.

This legion of achievers creates and maintains a vast mass of occasionally useful and somewhat interlocking pieces of software.

At any one time enough of the individual pieces are able to work successfully with other pieces that, like a whirlpool in a raging torrent, our online universe emerges as a stable structure amidst a boiling froth of software birth, growth, decline, death and rebirth.

Regardless of how any individual project or decision is managed the internet as a whole is an ecosystem organised along Darwinian lines.

There are as many motives for all this doing as there are individuals engaged in it but a vast amount of the really important stuff that's being done, the creation of building blocks that others will arrange and rearrange to create their own projects, is executed by small groups of specialists who work for free and then simply give their software away.

One such team of doers is the OpenSSL team. Their eponymous encryption library, produced by a tiny team with meagre funding, was so useful, so successful and so widely used and integrated that, without any decision being taken that it should, it proliferated until it became a critical piece of internet infrastructure.

That proliferation is what made the Heartbleed bug so devastating. OpenSSL was everywhere and so was its nastiest bug.

The code's primary defenses against bugs and flaws are a) that it's developed by people who know what they're doing and b) their work is open to scrutiny - anyone who wants to can look at it, poke it, test it, suggest changes or take it away and make their own version.

Of course, just because everyone can look it doesn't mean that anyone does. It's easy to assume that somebody else is minding the commons and when it turns out they aren't a tragedy is sure to follow.

Most of the time, people are happy to go about their business without thinking about how the internet's building blocks work or how they're built. Even most of the doers are so busy doing what they're doing that they can't concern themselves with how every little thing they rely upon was done.

One such team were the folks at OpenBSD.

OpenBSDOpenBSD is a robust and well established computer operating system that works a lot like Unix or Linux and aims to be the #1 most secure operating system. The team behind it have reputation for being doers when it comes to security.

The OpenSSL library has been included with the OpenBSD operating system for years and it seems that during that time the OpenBSD team have been happy to trust that the OpenSSL team would make a decent fist of looking after their own.

That was before Heartbleed. That bug, it seems, was the last straw.

The credo of the doers is that when you need a bit of software to do something that it doesn't do, you fix it yourself. What the OpenBSD team need the OpenSSL library to do is to be less broken and they've given up waiting for the current maintainers to fix it.

The Rubicon lay somewhere between the discovery of freelists and the unfixed bug ... That unfixed bug (still unfixed in OpenSSL even now, two weeks later, despite OpenBSD, FreeBSD, and Debian all patching it out of tree) galvanized the team. It was clear that a fork was the only solution and that working with upstream [the OpenSSL team] would be a futile effort.

Of course they can't take the code away from the current maintainers but because the code is open source they are free to either lend a hand, write a better replacement or try to do a better job than the current owners with what's there already.

They've taken the latter course of action, calling their OpenSSL fork LibreSSL. And, being the doers that they are, they've got busy rewriting, refactoring and flensing (and this being the OpenBSD team there's probably been some swearing, eyeball rolling and falling out too).

Scrutiny, vitality and evolution have returned to stagnant but critically important corner of the ecosystem.

, , ,

You might like

11 Responses to LibreSSL aims to prevent the next Heartbleed

  1. Austin Williamson · 531 days ago

    Oh, god. Why. What made them think this is a good idea? Spreading out shallow eyes over more code makes all bugs big.

    • I imagine that they're hoping that LibreSSL will become the de-facto implementation of the OpenSSL library.

      Your concerns are valid but it's not like it can't work. Throwing the toys out of the pram worked wonders for gcc and X.

    • Paul Ducklin · 530 days ago

      Well, this is an OpenBSD rewrite, so it might be a bit harsh to call them "shallow eyes," and I betcha when they have finished there will be less code, not more.

      I'm assuming that their goal is drop-in replacement, which mitigates against starting afresh.

      • Augusto · 529 days ago

        First things first, the OpenSSL team has done an amazing job given the context in which they've been working (as the post mentioned, with little to no funding)

        I hope that LibreSSL provides a drop-in replacement, but that wraps a new, more friendly API. The current OpenSSL API is currently very, very obscure and it's not documented properly.

    • Guy · 530 days ago

      Cool. So we get a well written, secure fork, without even having to wait for Oracle to buy OpenSSL.

      Sweet (-:

  2. 2072 · 531 days ago

    This is the best thing that could happen out of this fiasco. At least they'll make the code readable, respect good coding standards that will make people actually _want_ to review their code. The original OpenSSL looks like it's been written by someone who is in his first years of C programming with no specific aim nor design harmony whatsoever, magic numbers everywhere, code redundancy, you name it...

    • 2072 · 530 days ago

      By the way, if you want to read a good (tragic) comedy, visit where you can read about the ongoing rebuild process commit after commit some of the messages will make you laugh while others will make you shiver...

      • Paul Ducklin · 530 days ago

        Hahahahahaha. I've heard of (probably been involved in a few in my time) puce alerts, even blue and beige alerts. But never of "alert level: fuchsia." (Most Anglophones mispronounce that word, same as they say "dash-hund" instead of "dachshund." I guess your pronunication in this case depends on whether you see it as a colour code or a state of play.)

        • 4caster · 530 days ago

          I think most Anglophones can't bring themselves to pronounce it the Spanish way, i.e. Fooksia. But my English dictionary says it can be pronounced either way.

  3. Jay · 530 days ago

    nice effort by OpenBSD guys.. hope sophos will again start supporting anti virus for them soon :P :D

  4. Don · 530 days ago

    Better funding usually means better code writing. The companies that use (abuse) the open source communities by not providing appropriate funding, then blame them when something goes wrong, should be ashamed.

    At least OpenSSL provided a solution where there was none, but who is going to provide continued support when little or no financial support is given by those who are making millions in profit?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Mark Stockley is an independent web consultant who's interested in literally anything that makes websites better. Follow him on Twitter at @MarkStockley