Glossary
What is OpenSSL — the library under HTTPS, and how to defend it
OpenSSL is the open-source library that powers HTTPS (TLS/SSL) and cryptography. Most servers use it indirectly — inherited via the web server or OS — so one flaw ripples worldwide (Heartbleed). Why its blast radius is huge, and how to defend: know your version, avoid EOL releases, monitor CVEs, patch fast.
If you serve HTTPS, your server is almost certainly running on OpenSSL (or a compatible implementation). You never touch it directly, yet its flaws reach everyone — here's what that foundational library is and how to defend it.
Where it sits — a foundation you "inherit"
The tricky thing about OpenSSL is that you're using it without ever having chosen it. Your app delegates TLS to the web server, the web server delegates crypto to OpenSSL, and that OpenSSL is shipped by the OS — a nested stack.
Normally this is a blessing — crypto is left to a shared implementation written by experts. But when that shared foundation has a hole, everyone sitting on top of it is affected at once. That's what "a foundational-library flaw has a huge blast radius" means.
Why it's scary: one bug threatened keys worldwide
2014's Heartbleed (CVE-2014-0160) came from a small OpenSSL implementation mistake (trusting a claimed length without validating it) that let an outsider read server memory — which could include private keys and session data — a little at a time. Because OpenSSL was so widely used, a vast number of servers worldwide became targets simultaneously (full story → Heartbleed).
The lesson is blunt: the more foundational the dependency, the wider the blast radius. So it's not just the dependencies your app imports directly — foundational libraries like OpenSSL running underneath deserve the same seriousness in monitoring and patching.
How to defend: avoid EOL, monitor the foundation
Know which OpenSSL your stack uses
You can't defend what you can't see. Inventory which OpenSSL (release line and version) your servers, container base images, and language runtimes each depend on.
Don't run end-of-life (EOL) versions
Once a release line is past support, new vulnerabilities found in it get no fix. Running EOL is leaving a door that won't be closed even after a hole is found. Plan upgrades onto a supported line.
Include the foundation in CVE monitoring
App dependencies are easy to track with osv-scanner and the like, but the OS-shipped OpenSSL is easy to overlook. Make sure new CVEs in foundational libraries surface too (→ the CVE remediation playbook).
Patch promptly when it's serious
Heartbleed-class bugs are attacked the moment they're disclosed. Keep your update path light enough that foundational patches can ship same-day when the severity calls for it — not "at the next scheduled update."
Our take: watch the foundation with machines
You can't track foundational-library flaws on human memory. This site puts its own dependencies and foundations under machine CVE monitoring. The certificates you serve via Let's Encrypt still run their crypto through an OpenSSL-family implementation underneath — so inventorying the "invisible foundation" and putting it under watch is the shortest path to preventing high-blast-radius incidents.
Read next
- Learn from an incident: Heartbleed (an OpenSSL flaw that threatened keys worldwide)
- Related: What is Let's Encrypt (free TLS certs + auto-renewal) / Glossary: What is a CVE
- In practice: the CVE remediation playbook / monitor dependencies with osv-scanner
FAQ
QI never installed OpenSSL — could I still be using it?
Almost certainly yes. OpenSSL is a foundational library used internally by web servers (Nginx/Apache), operating systems, and language runtimes. Even if you never reference it in your code, if you're serving HTTPS then OpenSSL (or a compatible implementation) is very likely running underneath. Assuming 'I don't use it' is exactly how foundational vulnerabilities get missed.
QHow is it different from LibreSSL or BoringSSL?
Both are forks of OpenSSL. LibreSSL was created by the OpenBSD project after Heartbleed to clean up the codebase; BoringSSL is Google's variant for its own use. Most users don't need to choose between them — what matters far more is keeping whichever implementation your platform ships on a supported, up-to-date version.
QHow do I check the version or update it?
On many systems `openssl version` shows it, and you update it through your OS package manager or by rebuilding your container's base image. The key point is not to keep running an end-of-life (EOL) release: once a release line is EOL, new vulnerabilities found in it get no fix. Track your foundational dependencies the same way you track your app's dependencies.