quality niche 2014

OpenSSL LibreSSL

OpenBSD devs deleted 90k lines of code in the first week after Heartbleed. Shamed OpenSSL into improving. Default on OpenBSD.

What it is

OpenSSL is the dominant open-source implementation of the SSL/TLS protocols, used to encrypt the majority of internet traffic. Heartbleed allowed attackers to read server memory contents (including private keys and user data) from any server running affected OpenSSL versions — roughly 17% of the internet's secure web servers.

The story

On April 7, 2014, the Heartbleed vulnerability (CVE-2014-0160) was publicly disclosed, revealing that a critical bug in OpenSSL's heartbeat extension had been silently exposing the private memory of roughly two-thirds of the internet's web servers for two years. It was one of the worst security vulnerabilities in internet history, and when the OpenBSD developers looked at the OpenSSL code that caused it, they were horrified by what they found.

The OpenBSD team, led by the ever-diplomatic Theo de Raadt, didn't just find Heartbleed — they found a codebase riddled with decades of cruft, dead code paths, custom memory allocators that defeated exploit mitigations, and code that supported platforms nobody had used since the 1990s. Their response was characteristically blunt: fork it and gut it. On April 22, 2014, they announced LibreSSL.

The first week was legendary. The OpenBSD developers deleted over 90,000 lines of C code — roughly half the codebase. They ripped out support for ancient platforms like VMS and OS/2, removed the custom malloc that had masked Heartbleed, eliminated the heartbeat extension entirely, and generally went on a code-deletion rampage that became the stuff of developer folklore. Bob Beck presented the progress at BSDCan in May 2014, documenting the carnage with evident satisfaction.

LibreSSL shipped its first portable release (2.0.0) in July 2014, just three months after Heartbleed. It became the default SSL library on OpenBSD and was adopted by several other BSDs and some Linux distributions. But its broader mission — replacing OpenSSL everywhere — never materialized.

The fork's greatest achievement was arguably not LibreSSL itself, but the shock it delivered to the OpenSSL project. Heartbleed plus the embarrassment of being publicly forked by the OpenBSD team led to the creation of the Core Infrastructure Initiative (CII), which funded two full-time OpenSSL developers and a comprehensive code audit. OpenSSL commits increased by 52.7% in the post-Heartbleed period. LibreSSL scared OpenSSL into becoming better.

Timeline

Heartbleed vulnerability (CVE-2014-0160) publicly disclosed

libressl.org domain registered — fork begins

LibreSSL fork announced at BSDCan 2014

Bob Beck presents 'LibreSSL: The First 30 Days' at BSDCan — 90k+ lines removed

Google announces BoringSSL, promises to exchange fixes with LibreSSL

LibreSSL 2.0.0 — first portable release

LibreSSL becomes default in OpenBSD 5.6

Core Infrastructure Initiative funds OpenSSL audit and full-time developers

Key people

Theo de Raadt
OpenBSD founder who initiated the fork
“Our group removed half of the OpenSSL source tree in a week.”
Bob Beck
LibreSSL developer who presented early progress at BSDCan 2014
Ted Unangst
OpenBSD developer and key LibreSSL contributor
Bodo Moeller
Original author of the heartbeat code that contained the Heartbleed bug

Impact

LibreSSL's most lasting impact was catalytic rather than direct. By publicly humiliating OpenSSL's codebase and demonstrating that half of it was unnecessary dead weight, the fork forced the entire industry to take SSL/TLS library quality seriously. The CII was created, OpenSSL got its first funded developers and security audit, and the broader conversation about critical infrastructure funding began in earnest.

LibreSSL itself remains the default on OpenBSD and is used in some other contexts, but it never displaced OpenSSL in the wider ecosystem. Together with BoringSSL, it created a three-way split in the OpenSSL ecosystem that ultimately improved all three projects through competitive pressure and code sharing.

Lesson: Sometimes the best thing a fork can do is not replace the original, but scare it into becoming better.

Related forks