Even if you haven’t actually come across the actual codebase, even if you’re not a web developer by any definition of the term, you will at some point have used OpenSSL. It’s quite hard to avoid, in fact: a full two-thirds of the world’s web servers use this free and open implementation of web cryptographic protocols, ensuring safe transmission of data. Since 1998, it’s been doing this job fairly well – in fact, had it not been for the recent Heartbleed scare, most of the world would have gone by their business blissfully unaware of this moat vital of libraries.
Unfortunately (or fortunately, depending on how you look at it), Heartbleed was the straw that broke the camel’s back. In OpenSSL’s case, its spotty record – the RSA timing attack vulnerability, the plaintext recovery attack vulnerability, and even the CSS injection problem that exists to date – all of these were examined and OpenSSL was found wanting. The jury decide – OpenSSL was old, its codebase a mess, and it was time for some alternatives.
Or at least, that’s how the story plays out in a well-ordered universe. In reality, people had been making patches to their OpenSSL libraries over the years – in some cases, these mutated libraries were quite far afield of the official OpenSSL. It wasn’t that hard to pull ahead – OpenSSL, one of the biggest driving forces of the web, was being maintained by just one full-time programmer and ten part-timers running mostly on donations. Additionally, it was drawing a fair amount of flak for poorly planned-out implementations, bad software development practices and poor bug tracking – Heartbleed, for example, was firstly publicly reported in 2010.
So this month, just ahead of I/O, Google announced that they had a whole bunch of patches they kept on applying to each new version of OpenSSL – and from now on, they’d make this a publicly available variant. Thus BoringSSL was formed. The name implies exactly what Google intends BoringSSl to be – a simple, safe set of functions that just works and doesn’t do anything too fancy.
However, Google’s not alone. The OpenBSD folk stepped in the game even earlier with their own fork: LibreSSL. The founder of the OpenBSD group, Theo De Raadt, made it very clear why LibreSSL had to exist:
“Our group removed half of the OpenSSL source tree in a week. It was discarded leftovers,” he told British website Arstechnica in an e-mail. “The Open Source model depends [on] people being able to read the code. It depends on clarity. That is not a clear code base, because their community does not appear to care about clarity.”
Theo and his team removed some 90,000 lines of dead code from the OpenSSL source, incidentally completing work that the OpenSSL devs had been meaning to do for years. Support for ancient standards like FIPS were pruned out, leaving a leaner, meaner library that they can refactor. Unlike Google, LibreSSL plans to stay true to OpenSSL’s interfaces so that developers can shift from one to the other.
Unfortunately, it isn’t entirely OpenSSL’s fault. Despite being used by most of the known Internet, the OpenSSL project constantly struggles to make ends meet. As Steve Marquess, President of the OpenSSL foundation, pointed out in a depressed blog post, they survive on a meagre stipend and commercial work that they complete so they can keep the coffers from running empty. It’s nowhere near enough.
“There has been an outpouring of grassroots support from the OpenSSL user community, roughly two hundred donations this past week. I haven’t finished entering all of them to get an exact total, but all those donations together come to about US$9,000. Even if those donations continue to arrive at the same rate indefinitely …it is nowhere near enough to properly sustain the manpower levels needed to support such a complex and critical software product. The ones who should be contributing real resources are the commercial companies and governments who use OpenSSL extensively and take it for granted…there should be at least a half dozen full time OpenSSL team members, not just one, able to concentrate on the care and feeding of OpenSSL without having to hustle commercial work. If you’re a corporate or government decision maker in a position to do something about it, give it some thought.”
Perhaps it’s too late for the OpenSSL project now – or perhaps not. Either way, we’ve got three players now.