回顧過去的重大事故，只聚焦於對當下你的維運真正有用的教訓。我們不重現攻擊，而是從防禦的視角來解讀。
發生了什麼：回傳資料比請求更多的 bug
TLS（HTTPS 的加密）中有一種用於維持連線的「存活確認（heartbeat）」互動。用戶端傳送一小段資料和一個「把這個回傳給我」的長度，伺服器照樣回傳。本來這只是個簡單的機制。
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日確認。請核對資料中的版本與設定條件。清單優先順序及經驗是本站的整理，不代表全文重新核驗或安全保證。