回顾过去的重大事故，只聚焦于对当下你的运维仍然有用的教训。我们不复现攻击，而是从防御的视角来解读。
发生了什么：返回的数据比请求的更多的漏洞
TLS（HTTPS 的加密）中有一种用于维持连接的「存活确认（心跳）」交互。客户端发送一小段数据和一个「把这个返回给我」的长度，服务器照样返回。本来这只是个简单的机制。
OpenSSL 的实现没有校验这个申报的长度。明明实际只发送了几个字节，却申报「返回 64KB」，服务器就会超出收到的数据量，把相邻的内存也一并读取并返回。如果那里恰好存着私钥或会话，它们也会一起泄露。
正常：发送的长度＝返回的长度
「返回 "bird"(4 个字符)・长度 4」→ 服务器「bird」
Heartbleed：短发送＋大申报长度
「返回 "bird"(4 个字符)・长度 64KB」→ 服务器「bird＋相邻的内存 64KB（可能包含私钥、会话等）」
攻击方不需要任何特殊权限。通过反复多次操作，就能 一点点收集到内存的碎片。大量软件所依赖的 TLS 库里的一个小 bug，影响了全世界 HTTPS 通信的安全。
几乎不留痕迹的泄露，无法确定影响范围
Heartbleed 不易在常规的访问日志中留下痕迹，事后很难断定「是否泄露了」「泄露了什么」。一旦难以判断，按最坏情况行动才是正解。
时间线
2014-04-07
漏洞被公开，修复版 OpenSSL 同时发布。公开后不久
全球服务器一齐着手打补丁。影响范围之广引发一片哗然。此后
许多服务按「私钥已泄露」的前提吊销并重新签发证书，并呼吁用户更改密码。
为什么只打补丁还不够
既然私钥有可能已经泄露，那么即便打了补丁，过去泄露的密钥仍然有效。所以应对分两部分：修复漏洞（打补丁），并按已泄露的前提更换密钥、证书和机密。
不充分的应对
- 更新 OpenSSL 后就认为「已经修好了」
- 只更换确认被利用的那一个机密
- 证书继续照常使用
正确的应对
- 在更新之外，还要吊销并重新签发证书（重新生成私钥）
- 彻底更换服务器持有的机密、密钥、密码
- 督促用户更改密码
对当下有用的教训
按『一旦泄露就是全部泄露』处理
不是只换已确认的那一个，而是彻底更换服务器持有的机密、密钥、密码。当泄露几乎不留痕迹时，要按最坏情况行动。
吊销并重新签发证书
既然私钥有可能已经泄露，证书也要重新生成。只要不轮换密钥，过去泄露的密钥就仍然可以使用。
把基础库也纳入监控对象
不只是应用，像 OpenSSL 这样的基础库的 CVE 也要用机器监控来追踪。依赖某个库的软件越多，影响范围越广。
理解内存安全的价值
「读取的比请求的多」这类 bug，可以通过内存安全的设计与语言从结构上减少。在选择构建所用的技术时把它纳入考量。
接下来阅读
- 术语：什么是 CVE
- 术语：什么是 OpenSSL（处于本次事件中心的那个库——以及如何防御它）
- 术语：什么是 Let's Encrypt（免费 TLS 证书＋自动续期——轮换密钥/证书的基础）
- 事故：.env 公开导致全部机密泄露的故事
- 入门：如何守护机密·超入门
来源与确认范围
以下原始资料支持上文的配置、影响范围或应对措施，链接于2026年10月23日确认。请核对资料中的版本和配置条件。清单优先级及经验是本站的整理，不代表全文重新核验或安全保证。