Remember Heartbleed?
That was probably the first security hole to enjoy dedicated media promotion under a media-savvy brand name and logo, and it set the trend for, well, for the many trendy vulnerability names that have followed.
It’s thanks to Heartbleed that we ended up with names such as Logjam, Shellshock, FREAK, VENOM, Poodle and HamletPrinceOfDenmark.
→ Actually, we’re kidding about a bug called HamletPrinceOfDenmark, but we’re sure there’s a buffer-full of exploit metaphor just waiting to overflow from Shakespeare’s famous play. If ever there is a security flaw with that name: you read it here first.
Heartbleed was a strange but dangerous sort of bug that reminded us that hackers who break in and then wander around on the inside are not the only risk we need to defend against.
Heartbleed didn’t provide a path for hackers to get inside your edge-facing web servers, and it didn’t require them to do anything more than starting up a connection.
All that an attacker had to do was to abuse a bug in the part of OpenSSL that implemented a feature called “TLS heartbeat”, which is where the name Heartbleed came from.
Buffer overflow
Greatly oversimplified, you could say to a a server, whether you’d actually logged in or not, “To check that you’re still alive at the other end, please send THIS TEXT back to me.”
Of course, you could choose anything in place of THIS TEXT, long or short, so you also had to tell OpenSSL how much text you wanted it to send back.
Sadly, you could deliberately over-exaggerate, and OpenSSL wouldn’t check.
So, instead of saying “9” for THIS TEXT (8 letters and a space), you could give any size up to 65535, which just happens to be 216−1, the largest number you can fit into 16 bits of memory.
And OpenSSL would obligingly copy your test message and send it back, followed by whatever happened to be next door to it in memory.
You could do this over and over again, getting a potentially vast sequence of momentary snapshots of other people’s network data, just like the tantalising glimpses you get through office or apartment windows next to a railway line as your train hurtles past.
The monoculture problem
The real problem with Heartbleed was that an awful lot of the world’s web security infrastructure turned out to be using OpenSSL, magnifying the risk, as any monoculture tends to do.
So, the outcome of Heartbleed, aside from a few frantic days for sysadmins the world over, was a sudden interest in alternative implementations.
Of course, rewriting a cryptographic toolkit from scratch that can slot in where OpenSSL used to be is a huge undertaking, so the immediate efforts took a more pragmatic approach.
The OpenBSD project was the first to get busy, taking the OpenSSL source code and subjecting it to a vigorous cleansing process to make it leaner, meaner and easier to test and audit.
This led to LibreSSL, a plug-and-play alternative to OpenSSL that is significantly smaller than the original.
Google also quickly got on the job, once again starting with the OpenSSL code but developing a derivative project – a fork, in open source language – called BoringSSL that could, and has, developed along its own lines.
This freed Google to push its own security fixes directly into BoringSSL, where anyone could grab them at once, instead of waiting for those fixes to percolate back into the OpenSSL cource code before they became part of an official project distribution.
Amazon to the party
And now, Amazon has joined the SSL/TLS programming party, too, with s2n, a brand new implementation of the SSL/TLS protocol in under 20,000 lines of code all-up.
This compares, says Amazon, with a rather messy 70,000 lines of code (out of about 500,000 in total) in the equivalent parts of OpenSSL.
This is good news for choice, and if you’ve been sucking the whole of OpenSSL into your own software “just because,” you probably want to take a look.
Unfortunately, it’s not quite as simple as taking out all your TLS library code and slotting in s2n instead.
The project only deals with the SSL/TLS protocol parts, not with the underlying cryptography such as RSA (public key cryptography), ECDHE (forward secrecy), AES (enciphering) and SHA (hashing).
Those components come from an open source library called libcrypto, which you build into s2n by compiling a significant chunk…
…of OpenSSL, LibreSSL or BoringSSL.
Nevertheless, the Heartbleed vulnerability wasn’t a problem in any of the cryptographic primitives in libcrypto, so Amazon’s new project is still a welcome breath of fresh air.
What next?
If there were a magic wand I could wave over s2n and have other people code up the needed changes, my first ask would be for an even-more stripped-down default build configuration.
In other words, although the software supports cryptographic algorithms such as RC4, MD5, SHA-1 and SSL 3, I’d love to see those left out altogether by default (perhaps along with 3DES and AES-CBC).
That way, no one could say, “You never told us not to live in the past.”