只要你在提供 HTTPS 服务，你的服务器几乎可以肯定就跑在 OpenSSL（或兼容实现）之上。你从不直接接触它，但一旦发现缺陷，就会有大量服务器受到影响。下面讲清楚这个库的作用，以及如何防御它。
它在哪里被使用
OpenSSL 棘手的地方在于，你在使用它，却从未亲自选择过它。你的应用把 TLS 委托给 Web 服务器，Web 服务器把加密委托给 OpenSSL，而那个 OpenSSL 又由操作系统附带提供，形成一层套一层的技术栈。
通常这很方便：加密被交给了由专家编写的共享实现。但当这个共享库出现漏洞时，使用它的每一个人都会同时受到影响。这正是「底层库的缺陷影响广泛」的含义。
OpenSSL、SSL/TLS 与证书的区别
这几个名称听起来相似，所以常被混淆，但各自的作用不同。
| 术语 | 是什么 | 例子 |
|---|---|---|
| SSL / TLS | 加密连接的规则（协议）。SSL 是旧版本；如今使用的是 TLS 1.2 / 1.3 | HTTPS 就是用 TLS 包裹的 HTTP |
| OpenSSL | 实际执行 TLS 和加密运算的程序（库），附带一个命令行工具 | Nginx 和 Apache 在内部调用它 |
| 证书 | 由证书颁发机构担保你拥有某个域名的数据。其中包含公钥 | Let's Encrypt 免费签发 |
也就是说，OpenSSL 是实现 TLS 规则的一种工具，证书是这个工具在连接时使用的数据。实现 TLS 的库还有其他几种（LibreSSL、BoringSSL、Windows Schannel 等），用哪一种取决于操作系统和软件。
影响为何如此广泛：一个 bug 曾让大量服务器的密钥面临风险
2014 年的 Heartbleed（CVE-2014-0160）源于 OpenSSL 一个很小的实现错误（未经校验就信任了对方申报的长度），它让外部人员能一点点读取服务器内存——其中可能包含私钥与会话数据。由于 OpenSSL 使用得如此广泛，全球大量服务器在同一时刻成了攻击目标（完整故事 → Heartbleed）。
教训很清楚：依赖在技术栈中越靠下，影响就越广。 所以需要关注的不只是应用直接引入的依赖——像 OpenSSL 这样运行在底层的库，在监控与打补丁上同样值得认真对待。
如何防御：避开 EOL，监控底层库
弄清你的技术栈使用的是哪个 OpenSSL
看不见的东西无法防御。盘点一下你的服务器、容器基础镜像以及语言运行时各自依赖的是哪个 OpenSSL（发行版本线与具体版本）。
不要运行已停止支持（EOL）的版本
一旦某个发行版本线过了支持期，在其中新发现的漏洞就不会再有修复。如果继续运行 EOL 版本，漏洞即使被发现也会一直得不到修复。请规划升级到受支持的版本线上。
把底层库一并纳入 CVE 监控
应用依赖用 osv-scanner 之类的工具很容易追踪，但操作系统附带的 OpenSSL 却很容易被忽视。请确保底层库中的新 CVE 也能浮现出来（→ CVE 修复实操手册）。
一旦严重就尽快打补丁
Heartbleed 这一类的 bug，往往在披露的那一刻就遭到攻击。请让你的更新链路足够轻便，使得在严重程度需要时，底层补丁能够当天就发布上线——而不是「等到下一次例行更新」。
受支持的版本（截至 2026 年 10 月）
OpenSSL 项目在奇数年的 4 月发布长期支持（LTS）版本，并至少支持五年。3.5 之后发布的非 LTS 版本，自发布起支持 13 个月。
| 版本线 | 类型 | 支持结束 |
|---|---|---|
| 4.0 | 常规 | 2027 年 5 月 14 日 |
| 3.6 | 常规 | 2026 年 11 月 1 日 |
| 3.5 | LTS | 2030 年 4 月 8 日 |
| 3.4 | 常规 | 2026 年 10 月 22 日 |
| 3.0 / 1.1.1 / 1.0.2 | — | 已结束（仅有 OpenSSL Corporation 的付费扩展支持） |
操作系统附带的 OpenSSL 则是另一回事。许多 Linux 发行版（包括 Red Hat 系）会在不提升版本号的情况下引入修复（向后移植）。在操作系统的支持期内，一个仍显示为 3.0 的软件包可能会继续从操作系统厂商那里收到修复。不要仅凭版本号判断「旧就有漏洞」或「新就安全」，请查看操作系统厂商的安全公告。
如何检查自己的环境
检查操作系统的 OpenSSL
openssl version -a 查看版本。要查看软件包版本，Debian/Ubuntu 用 dpkg -l 'libssl*' openssl，Red Hat 系用 rpm -q openssl。把这个软件包版本与操作系统厂商的安全公告对照，看是否已包含修复。检查应用实际使用的是哪个
nginx -V，Python 用 python3 -c "import ssl; print(ssl.OPENSSL_VERSION)"，Node.js 用 node -p process.versions.openssl，可以看到内置的版本。容器镜像也要检查
订阅 OpenSSL 的安全公告
如何解读漏洞的严重程度
OpenSSL 项目把自身的漏洞分为四个等级，并据此改变修复的发布方式。
| 严重程度 | 大致含义 | 修复的发布方式 |
|---|---|---|
| Critical | 影响常见配置且容易被利用（服务器内存大量泄露、私钥被盗等） | 立即为所有受支持版本发布修复 |
| High | 风险低于 Critical 但仍然严重（不太常见的配置、仅影响客户端等） | 私下准备，然后为所有受支持版本发布 |
| Moderate | 仅限于拒绝服务、不常用的协议等 | 并入下一次例行发布 |
| Low | 仅限命令行工具、不太可能出现的条件组合等 | 并入下一次例行发布 |
像 Heartbleed 这样能从外部读取服务器内存的缺陷，符合 Critical 的定义。对于 Critical 和 High，看到预告就开始准备更新。
本站的看法：用机器监控底层库
底层库的缺陷无法靠人脑记忆来追踪。本站把自身的依赖与底层都置于机器化的 CVE 监控之下。你通过 Let's Encrypt 签发的证书，其加密在底层依然是经由 OpenSSL 家族的实现来运行的，所以把平时不会想到的底层库列出来并加以监控，是预防影响广泛的事件最直接的方法。
接下来阅读
- 从事件中学习：Heartbleed（一个让大量服务器的私钥面临风险的 OpenSSL 缺陷）
- 相关：什么是 Let's Encrypt（免费 TLS 证书＋自动续期）／ 术语：什么是 CVE
- 实战：CVE 修复实操手册／用 osv-scanner 监控依赖
出处（一手资料）
- OpenSSL Library，“Release Strategy” — openssl-library.org（LTS 方针、各版本线的支持结束日期）
- OpenSSL Library，“Security Policy” — openssl-library.org（四个严重程度等级、事先预告）
- Red Hat，“Backporting Security Fixes” — access.redhat.com（为什么仅凭版本号无法判断是否有漏洞）
- NIST NVD，“CVE-2014-0160” — nvd.nist.gov（Heartbleed）