只要你在提供 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 系）會在不提高版本號碼的情況下納入修正（backport）。在作業系統的支援期間內，顯示為 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）