Run ldd on almost any network-facing binary on our server, and libssl and libcrypto show up in the output. That's OpenSSL.
SSH in and download a file, and it's almost certainly curl, or libcurl linked into whatever you're using.
We decided to notice that quiet, mostly invisible work these projects put into keeping every server running. So is*hosting is now a sponsor of curl and OpenSSL, as part of the Hosting for Good initiative.
curl is the utility (and the library, libcurl) that moves data over the network. HTTP, HTTPS, FTP, and a couple dozen other protocols. It's in nearly every Linux distribution, in macOS, Windows, cars, TVs, routers — by some estimates, more than ten billion installations worldwide.
When your application makes an outbound request, chances are libcurl is doing the work. And most of it has been maintained since 1998 largely by one person — Daniel Stenberg.
OpenSSL is the library behind the cryptography under TLS. Every https:// handshake, every encrypted connection between your server and a client, most likely runs through its code. The padlock in the browser means something precisely because of OpenSSL.
Until recently, though, these projects only got noticed when they broke. And part of the internet broke with them.
In April 2014, researchers disclosed a bug in the TLS heartbeat mechanism in OpenSSL. The vulnerability in versions 1.0.1 through 1.0.1f let a remote attacker read chunks of a server's private memory — up to 64KB per request — with no privileges required. Worse, the request could be repeated as many times as needed, pulling fresh 64KB slices of memory each time. In practice, an attacker could potentially pull private keys, passwords, and session cookies.
By one estimate, around 17% of secure web servers were exposed, and companies like Yahoo, Google, and Facebook had to patch immediately.
At the time, OpenSSL was maintained by a tiny group of volunteers on a negligible budget. The gap between how critical the code was and how little its maintainers were supported proved too wide.
The industry's answer was the Core Infrastructure Initiative — an attempt to fund, on the fly, the projects everyone relied on and no one maintained.
We'd rather not wait for the next incident, so we're sponsoring projects like these now.
Our reasoning is fairly practical.
We use this code ourselves. Provisioning, monitoring, our API endpoints — curl and OpenSSL have been in the dependency graph for a long time.
Our customers use this code. Both libraries are on every VPS. As long as they're well maintained, servers and our clients are more secure by default.
The internet runs on this code. The systems your business talks to — payment gateways, APIs, websites — lean on the same libraries.
For us, this is maintaining the infrastructure we all depend on.
Hosting for Good rests on the idea that infrastructure shouldn't be a barrier. Not for a startup bringing up its first node in a new region, and not for a solo maintainer keeping a critical library alive on donations and stubbornness.
The open source under us is that same infrastructure, held together mostly by underfunded volunteers. For hosting providers, it's the rent we should have been paying from the start.
If you deploy your own hosting and put anything at all on it, you depend on curl, OpenSSL, and projects like them. Supporting them is cheaper and easier than it seems. It can be the price of one coffee a month.
Two obvious places to start — the two projects from this post:
Take a look at your requirements.txt, package.json, or ldd output, pick the project you use most, and support it.