在 zhtw 電腦網路；zhcn 計算機網路 上，OpenSSL 是一個開放原始碼的軟體函式庫套件，應用程式可以使用這個套件來進行安全通訊，避免竊聽，同時確認另一端連線者的身份。這個套件廣泛被應用在網際網路的網頁伺服器上。 其主要函式庫是以 C 語言所寫成，實作了基本的加密功能，實作了 SSL 與 TLS 協定。OpenSSL 可以執行在 OpenVMS、 Microsoft Windows 以及絕大多數類 Unix 作業系統上（包括 Solaris，Linux，Mac OS X 與各種版本的開放原始碼 BSD 作業系統）。 雖然此軟體是開放原始碼的，但其 30 以前版本的授權條款與 GPL 有衝突之處，故 GPL 軟體使用 OpenSSL 時（如 Wget）必須對 OpenSSL 給予例外。 歷史 OpenSSL 計劃在 1998 年開始，其目標是發明一套自由的加密工具，在網際網路上使用。OpenSSL 以 Eric Young 以及 Tim Hudson 兩人開發的 SSLeay 為基礎，隨著兩人前往 RSA 公司任職，SSLeay 在 1998 年 12 月停止開發。因此在 1998 年 12 月，社群另外分支出 OpenSSL，繼續開發下去。 OpenSSL 管理委員會目前由 7 人組成，有 13 個開發人員具有提交許可權（其中許多人也是 OpenSSL 管理委員會的一部分）。只有兩名全職員工（研究員），其餘的是志願者。 該專案每年的預算不到 100 萬美元，主要依靠捐款。 TLS 13 的開發由 Akamai 贊助。 主要版本釋出 OpenSSL 版本歷史 版本 初始版本日期 備註 最近更新版本 1998 年 12 月 23 日 OpenSSL 專案的正式開啟 091c（1998 年 12 月 23 日） 1999 年 3 月 22 日 取代 091c 092b（1999 年 4 月 6 日） 1999 年 5 月 25 日 取代 092b 093a（1999 年 5 月 27 日） 1999 年 8 月 9 日 取代 093a 094（1999 年 4 月 9 日） 2000 年 2 月 28 日 取代 094 095a（2000 年 4 月 1 日） 2000 年 9 月 24 日 取代 095a 096m（2004 年 3 月 17 日） 2002 年 12 月 31 日 取代 096m 097m（2007 年 2 月 23 日） 2005 年 7 月 5 日 取代 097m 098zh（2015 年 12 月 3 日） 2010 年 3 月 29 日 取代 098n 100t（2015 年 12 月 3 日） 2012 年 3 月 14 日 取代 100 維護至 2016 年 12 月 31 日 支援 RFC 6520 TLSDTLS 心跳 支援 SCTP RFC 5705 TLS key material exporter RFC 5764 DTLSSRTP 協商 Next Protocol Negotiation PSS signatures in certificates requests and 證書吊銷列表 Support for password based recipient info for CMS 支援 TLS v12 以及 TLS v11 Preliminary FIPS capability for unvalidated 20 FIPS module 支援（SRP） 101u（2016 年 9 月 22 日） 2015 年 1 月 22 日 取代 101 維護至 2019 年 12 月 31 日（長期維護） Suite B 支援 TLS 12 和 DTLS 12 支援 DTLS 12 TLS 自動選擇橢圓曲線（EC） 用於設定 TLS 支援的簽名演算法和曲線的 API SSL_CONF 配置 API 支援 TLS 支援應用層協議協商 CMS 支援、RSAOAEP、ECDH 及 X942 DH 102u 取代 102h 維護到 2019 年 9 月 支援 BLAKE RFC 7693 支援 ChaCha20Poly1305（RFC 7539） 支援 X25519（RFC 7748） 支援和證書透明度 支援擴 CCM 模式密碼套件 支援擴充套件主金鑰 移除 SSLv2 移除對 Kerberos 密碼包的支援 將 RC4 和 3DES 從 libssl 從 DEFAULT 密碼套件中移除 將 DSS、SEED、IDEA、CAMELLIA 以及 AESCCM 從 DEFAULT 密碼套件中移除 將 40 和 56 位密碼從 libssl 中移除 110l 長期支援版本（維護至 2023 年 9 月 11 日） 支援 TLS13 支援 SHA3 支援以及（RFC 7748） 支援 支援 支援多素數 RSA（RFC 8017） 支援 SM2、SM3 以及 SM4 移除 Heartbleed 移除對 QNX 支援的支援 111w 重新授權至 Apache License 20 重新支援 3010 ） 合規 效能改善 312 ） 客戶端支援 QUIC TLS 證書壓縮 ECDSA 的確定性使用 TLS 原始公鑰支援 持續開發中 持續開發中 持續開發中 演算法 OpenSSL 支援許多不同的加密演算法： 加密 AES、Blowfish、Camellia、Chacha20、Poly1305、、、DES、IDEA、、RC4、RC5、TDES、、SM4 密碼雜湊函式 MD5、MD4、MD2、SHA1、SHA2、SHA3、RIPEMD160、、、BLAKE2、、SM3 公開金鑰加密 RSA、DSA、ECDSA、ECDHE、迪菲 赫爾曼金鑰交換、橢圓曲線密碼學、X25519、、、、GOST R 34102001、SM2 （從 10 版開始，橢圓曲線迪菲 赫爾曼金鑰交換用於支援前向安全性） 授權條款 Licensing OpenSSL 根據 OpenSSL 許可證和 SSLeay 許可證獲得雙重許可，這意味著可以使用任一許可證的條款。OpenSSL 授權實際上是 Apache 授權條款 10，而 SSLeay 授權則與四條款 BSD 授權條款有些相似。 由於 OpenSSL 授權是 Apache 授權條款 10（而非 Apache 授權條款 20），因此被要求在宣傳資料和任何 redistributions 中明確標出：「本產品包含由 OpenSSL Project 開發，用於 OpenSSL 工具包的軟體」（根據 OpenSSL 授權第 3 和第 6 條規定）。由於此限制，OpenSSL 授權和 Apache 授權條款 10 這兩個授權與 GNU GPL 授權不相容。 一些 GPL 開發者為了允許他們的系統與 OpenSSL 一起使用，特別在他們的授權條款中加入了 OpenSSL 例外。例如，GNU Wget 和 climm 採用了這樣的例外條款。某些套件（如 Deluge）在 GPL 授權條款的開頭新增額外部分，記錄此例外。而其他套件則選擇使用具有不同授權的替代品，例如採用 GNULGPL 的 GnuTLS、BSD 授權的 Botan、MPL 授權的 NSS，這些工具具備相同的功能。 2015 年 8 月，OpenSSL 宣佈將要求大多數貢獻者簽署貢獻者授權協議（Contributor License Agreement CLA），並計劃將 OpenSSL 的授權最終變更為 Apache 授權條款 20。此過程於 2017 年 3 月展開，並於 2018 年完成。 2021 年 9 月 7 日，採用 Apache 授權條款 20 授權的 OpenSSL 300 正式發布。 發生過的重大漏洞 拒絕服務 DoS ASN1 解析 在 OpenSSL 096k，某些特定的 ASN1 序列會在 Windows 電腦上觸發大量遞迴。該錯誤於 2003 年 11 月 4 日被發現。能夠傳送任意大量的 ASN1 序列將導致 OpenSSL 崩潰。 可預測私鑰 漏洞（僅限 Debian） OpenSSL 的偽亂數產生器使用複雜的程式方法來取得熵。為了防止 Valgrind 分析工具發出相關警告， Debian 發行版的維護者對 Debian 的 OpenSSL 套件變體應用了補丁，該補丁將其可生成的私鑰總數限制為 32768，無意中破壞了其隨機數生成器。損壞的版本包含在 2006 年 9 月 17 日發布的 Debian 版本中（版本 098c1），這也影響了其他基於 Debian 的系統，例如 Ubuntu。 該錯誤於 2008 年 5 月 13 日由 Debian 報告。在 Debian 40 發行版（代號 etch）中，這些問題已在版本 098c4etch3 中修復，而針對 Debian 50 發行版（代號 lenny）的修復則包含在版本 098g9 中。 OCSP 裝訂漏洞 在連線建立的握手階段時，，使用者端可能會傳送格式不正確的 ClientHello 訊息，導致 OpenSSL 解析的內容超出訊息末端。CVE 專案分配了識別碼 CVE 20110014 ，這影響了所有 OpenSSL 版本 098h 至 098q 以及 OpenSSL 100 至 100c。由於解析可能會導致讀取不正確的記憶體位址，因此攻擊者有可能引發 DoS。某些應用程式也可能會暴露已解析的 OCSP 擴充的內容，從而導致攻擊者能夠讀取 ClientHello 之後的記憶體內容。 ASN1 BIO 漏洞 當使用基本輸入 輸出 BIO 或基於 FILE 的函式讀取不受信任的 DER 格式資料時，OpenSSL 容易受到攻擊。但該漏洞不會直接影響 OpenSSL 的 SSLTLS 程式碼，或者任何使用 ASN1 函式（特別是 d2i_X509 和 d2i_PKCS12）的應用程式。 該漏洞於 2012 年 4 月 19 日發現，並分配了 CVE 識別碼 CVE 20122110。 SSL、TLS 和 DTLS 明文恢復攻擊 在處理 SSL、TLS 和 DTLS 中的 CBC 密碼套件時，發現 OpenSSL 在 MAC 處理期間容易受到定時攻擊。 Nadhem Alfardan 和 Kenny Paterson 發現了這個問題，並於 2013 年 2 月 5 日發布了他們的發現。CVE 識別碼為 CVE 20130169 心臟出血漏洞 OpenSSL 101 至 101f 版本在其 TLS 心跳擴充套件（Heartbeat Extension）的實現中存在一個嚴重的記憶體處理漏洞，該漏洞可被利用在每次心跳中洩露最多 64 KB 的應用程式記憶體。（CVE 20140160）。透過讀取 Web 伺服器的記憶體，攻擊者可能訪問敏感資料，包括伺服器的私鑰。 這可能使攻擊者能夠解碼之前竊聽的通訊內容，特別是在加密協議未確保完美前向保密（Perfect Forward Secrecy PFS）的情況下。掌握私鑰還可能讓攻擊者對未來的通訊進行中間人攻擊（MITM attack）。 該漏洞還可能洩露其他使用者敏感請求與響應的未加密部分，包括會話 Cookie 和密碼，這可能讓攻擊者冒充其他使用者的身份進行服務操作。 該漏洞於 2014 年 4 月 7 日披露時，估計大約 17（約 50 萬臺）由受數位憑證認證機構 CA 認證的安全 Web 伺服器可能受到了此攻擊的影響。並且，Heartbleed 漏洞可能同時影響伺服器和客戶端。 CCS 注入漏洞 CCS 注入漏洞 CVE 20140224 是一個安全繞過漏洞，是由 OpenSSL 中處理金鑰材料的方法存在的弱點引起。 此漏洞可以透過中間人攻擊（MITM）被利用。攻擊者可以解密和修改傳輸中的流量。一名遠端未經身份驗證的攻擊者可以透過特製的握手過程迫使通訊雙方使用弱金鑰材料。成功的攻擊可能導致安全繞過，使攻擊者能夠訪問潛在的敏感資訊。該攻擊僅能在易受攻擊的客戶端與伺服器之間執行。 OpenSSL 使用者端在版本 098za、100m 和 101h 之前的所有 OpenSSL 版本中都存在漏洞。僅已知 OpenSSL 101 和 102beta1 中的伺服器容易受到攻擊。建議使用 101 之前版本伺服器的使用者升級作為預防措施。 ClientHello 為內容的 DoS 攻擊 此漏洞（CVE 20150291）允許任何人讀取證書的內容並準確地修改它，從而利用該漏洞使客戶端或伺服器崩潰。如果客戶端連線到一個使用 OpenSSL 102 的伺服器並在重新協商時提供無效的簽名演算法擴充套件，將會發生空指標引用。這可能導致針對伺服器的拒絕服務（DoS）攻擊。 斯坦福大學的安全研究員 David Ramos 持有一個私有的漏洞利用程式，並將其提交給 OpenSSL 團隊，隨後該問題被修補。 OpenSSL 將此漏洞分類為高嚴重性問題，指出版本 102 受到影響。 對 DiffieHellman 小型子 group 的 金鑰恢復攻擊 此漏洞（CVE20160701）在滿足某些特定條件時，允許恢復 OpenSSL 伺服器的 DiffieHellman 私鑰。 該漏洞由 Adobe 系統安全研究員 Antonio Sanso 私下報告，OpenSSL 將此漏洞分類為高嚴重性問題，並指出僅版本 102 受到影響。 分支 Agglomerated SSL 在 2009 年，OpenSSL API 受挫之後，當時的 OpenBSD 開發人員 Marco Peereboom 建立了分支 Agglomerated SSL（assl），它重新使用 OpenSSL API，但提供了更簡單的外部介面。 LibreSSL 2014 年 4 月的心臟出血漏洞事件之後，OpenBSD 專案成員以 OpenSSL 101g 作為分支，建立一個名為 LibreSSL 的專案。在縮減 OpenSSL 的程式碼庫的第一週，將超過 90000 行的 C 語言程式碼從分支中刪除。 BoringSSL 2014 年 6 月，Google 釋出了自己的 OpenSSL 分支 BoringSSLhttpsboringsslgooglesourcecomboringssl BoringSSL，計劃與 OpenSSL 和 LibreSSL 的開發者合作。 GmSSL GmSSL 支援 SM2SM3SM4SM9ZUC 等商用密碼，主要使用 SM2 替代 RSADiffieHellmanECDSAECDH，SM3 替代 MD5SHA1SHA256，SM4 替代 DESAES，SM9 替代 PKICA 體系，所有程式碼在 GitHub 上開源，並由北京大學資訊安全實驗室開發和維護。此專案獲得 2015 年度中國 Linux 軟體大賽二等獎（一等獎空缺）。 受到的批評 舊版本相容問題 在開發者社群中，經常提及 OpenSSL 每次推出新的主要版本時引入 API 相容性破壞的案例，此時就會需要對軟體進行調整，從而往往延遲新版本的採用。 此外，由於舊版本通常在新主要版本發布後的維護期不超過兩年，這種情況往往迫使某些供應商必須非常早地開始準備軟體遷移。 因此在更新到新版本時，有時可能面臨失去與現有軟體的某些相容性風險， ，或導致軟體回歸 Software regression 的風險。 發行版本間隔時間太長 雖然長期支援版本（LTS 會維護長達 5 年，但發行時間間的間隔往往迫使作業系統供應商不得不長時間地停留在最後一個支援的版本上，從而在新版本發布時較沒有緩衝時間。 例如，OpenSSL 30 原本預計在 2019 年第 4 季發布， 但最終拖延了 21 個月才發行，且沒有延長對先前支援的版本 111 的預期支援結束日期，儘管存在需要對現有軟體進行適配的重要變更。 顯著的效能下降 上述提到的 111 版本較短的支援延遲引發了對對效能敏感的使用者更多的擔憂。在 OpenSSL 30 正式發布後不久，一些使用者開始報告該版本在多執行緒環境下出現嚴重的效能下降問題，許多人指出頻繁的底層操作中鎖的使用效率較低，導致速度降低達到 80 到 400 倍。OpenSSL 團隊已建立一個綜合性問題來試圖集中收集這些大規模效能回歸的報告。 大約一半的回報者表示，無法從早期版本升級到 30 ，這進一步加劇了由於先前版本 111 版本支援時間有限而帶來的困擾。 對使用者需求的考量 在開發 QUIC 傳輸以支援 HTTP 30 時，提出使用 TLS 來提供安全性，並發現需要對 TLS 庫進行一些適配修改。這些修改最初引入到了 BoringSSL， 成為當時 QUIC 開發者主要使用的版本，後來也被移植到其他版本中。 這項工作的移植很快被提議給 OpenSSL。 雖然當天就開始討論，但進展迅速受阻，最初是由於授權考量而受阻，然後在這些問題解決後仍被擱置。最終，10 個月後，OpenSSL 管理委員會在一篇部落格文章中宣佈，由於擔心 API 會隨時間變更，這些補丁集將不會被納入 30 版本。 在預計發布 30 版本超過一年後，該版本仍遙遙無期，一支來自 Akamai 和 Microsoft 的志願者團隊決定 fork 該專案為 QuicTLS，並在 OpenSSL 程式碼上支援這些補丁，以促進 QUIC 開發進展。這一行動得到了社群的普遍歡迎。 最終，在 OpenSSL 30 正式發布後，QUIC 補丁集再次被考慮，但最終被否決，該 pull 請求被關閉，在社群中引發了數十到數百條失望反應。也有使用者向作業系統供應商請求支援替代的 QuicTLS 分叉，或尋找其他解決方案。 最後，QuicTLS 專案的聯合創始人 Rich Salz，宣佈希望從 QuicTLS 分叉出一個 Apache 專案。但截止到 2023 年 2 月 25 日，仍然沒有一個預設在作業系統中提供長期支援且相容 QUIC 的 TLS 庫，而這要求終端使用者需要自行從原始碼重新構建。 參見 加密 OpenSSH TLS 的應用對比 WolfSSL 註記 參考 外部連結 OpenSSL 官方網站 SSLeay 檔案庫 OpenSSL License vs GPL wgets readme file，including the GPL with exception mICQ COPYING file，citing the GPL and including the exception OpenSSL FAQ entry on interaction between the OpenSSL and GNU licenses OpenSSL Quick Reference Guide OpenSSL Cookbook A Short Guide to the Most Frequently Used OpenSSL Features and Commands By Ivan Ristić Category 加密軟體 CategoryC 函式庫 Category 自由安全軟體 Category 傳輸層安全協議