名詞解釋
什麼是 OpenSSL——HTTPS 底下的底層函式庫，以及如何防禦它
OpenSSL 是支撐 HTTPS（TLS/SSL）與加密的開源函式庫。多數伺服器是間接使用它——透過 Web 伺服器或作業系統繼承而來——所以一個瑕疵就會波及全球（Heartbleed）。為何它的影響範圍如此巨大，以及如何防禦：掌握自己的版本、避開 EOL 版本、監控 CVE、快速修補。
只要你在提供 HTTPS，你的伺服器底下幾乎可以肯定正執行著 OpenSSL（或相容的實作）。你從不直接碰它，它的瑕疵卻會波及每一個人——以下說明這個底層函式庫是什麼，以及如何防禦它。
它所處的位置——一個你「繼承而來」的根基
OpenSSL 棘手之處在於，你明明從未選擇它，卻一直在使用它。你的應用程式把 TLS 委派給 Web 伺服器，Web 伺服器把加密委派給 OpenSSL，而那個 OpenSSL 又是由作業系統所附帶——層層堆疊。
通常這是一件好事——加密被交給由專家撰寫的共用實作。但當那個共用的根基出現破口時，坐在它上面的每一個人都會同時受到影響。這正是「底層函式庫的瑕疵影響範圍巨大」的真正含意。
為何可怕：一個 bug 威脅了全球的金鑰
2014 年的 Heartbleed（CVE-2014-0160）源自 OpenSSL 一個小小的實作失誤（沒有驗證就信任了對方申報的長度），它讓外部人士能一點一點地讀取伺服器的記憶體——其中可能包含私鑰與工作階段資料。由於 OpenSSL 被廣泛使用，全球大量伺服器同時成為了攻擊目標（完整來龍去脈 → Heartbleed）。
教訓直白得很：相依套件越是底層，影響範圍就越廣。 所以需要重視的不只是你的應用程式直接引用的相依套件——像 OpenSSL 這樣在底下執行的底層函式庫，在監控與修補上同樣值得認真對待。
如何防禦：避開 EOL、監控根基
掌握你的技術棧使用的是哪個 OpenSSL
你無法防禦你看不見的東西。請盤點你的伺服器、容器基礎映像與語言執行階段，各自依賴的是哪個 OpenSSL（版本線與版本）。
不要執行已終止支援（EOL）的版本
一旦某個版本線過了支援期，它新發現的漏洞就會沒有修正。執行 EOL 版本，就等於留著一扇即便發現破口也不會被關上的門。請規劃升級到受支援的版本線。
把根基也納入 CVE 監控
應用程式的相依套件用 osv-scanner 之類的工具就很容易追蹤，但作業系統所附帶的 OpenSSL 卻很容易被忽略。請確保底層函式庫的新 CVE 也能浮上檯面（→ CVE 應對劇本）。
情況嚴重時及時修補
Heartbleed 等級的 bug，往往在揭露的那一刻就遭到攻擊。請讓你的更新路徑保持輕量，好讓底層修補在嚴重程度有需要時能當天上線——而不是「等下一次排程更新」。
本站觀點：用機器盯住根基
你無法靠人腦記憶去追蹤底層函式庫的瑕疵。本站把自己的相依套件與根基都納入了機器化的 CVE 監控。你透過 Let's Encrypt 所提供的憑證，底下仍然是透過 OpenSSL 家族的實作來執行加密——所以盤點那個「看不見的根基」並把它納入監控，正是防止高影響範圍事件最短的路徑。
接下來閱讀
- 從事件中學習：Heartbleed（一個威脅了全球金鑰的 OpenSSL 瑕疵）
- 相關：什麼是 Let's Encrypt（免費 TLS 憑證＋自動續期）／ 術語：什麼是 CVE
- 實務上：CVE 應對劇本／用 osv-scanner 監控相依套件
FAQ
Q我從沒安裝過 OpenSSL——還是有可能在使用它嗎？
幾乎可以肯定是的。OpenSSL 是一個底層函式庫，被 Web 伺服器（Nginx/Apache）、作業系統與語言執行階段在內部使用。即便你的程式碼從未引用它，只要你在提供 HTTPS，那麼底下極有可能正在執行 OpenSSL（或相容的實作）。認為『我沒有用它』，正是底層漏洞被漏掉的典型原因。
Q它和 LibreSSL 或 BoringSSL 有何不同？
兩者都是 OpenSSL 的分支（fork）。LibreSSL 是 OpenBSD 專案在 Heartbleed 之後為了整理程式碼而建立的；BoringSSL 則是 Google 為自家用途打造的版本。多數使用者並不需要在它們之間做選擇——更重要的是，讓你的平台所附帶的那個實作，維持在受支援且最新的版本。
Q我該如何檢查版本或更新它？
在許多系統上 `openssl version` 會顯示版本，而你可以透過作業系統的套件管理員、或重建容器的基礎映像來更新它。關鍵在於別繼續執行已終止支援（EOL）的版本：一旦某個版本線進入 EOL，它新發現的漏洞就不會再有修正。請用追蹤應用程式相依套件的同樣方式，去追蹤你的底層相依套件。