Remove ads
提示：此条目的主题不是OpenSSH。在计算机网络上，OpenSSL是一個開放原始碼的軟體函式庫套件，應用程式可以使用這個套件來進行安全通訊，避免竊聽，同時確認另一端連線者的身份。這個套件廣泛被應用在網際網路的網頁伺服器上。
 | 此条目或章节需要時常更新。有關事物或許會隨著時間而有所變化。 |
其主要函式庫是以C語言所寫成，實作了基本的加密功能，實作了SSL與TLS協定。OpenSSL可以運行在OpenVMS、 Microsoft Windows以及絕大多數類Unix作業系統上（包括Solaris，Linux，Mac OS X與各種版本的開放原始碼BSD作業系統）。
雖然此軟體是開放原始碼的，但其3.0以前版本的授權條款與GPL有衝突之處，故GPL軟體使用OpenSSL時（如Wget）必須對OpenSSL給予例外。
OpenSSL計劃在1998年開始，其目標是發明一套自由的加密工具，在網際網路上使用。OpenSSL以Eric Young以及Tim Hudson兩人開發的SSLeay為基礎，隨著兩人前往RSA公司任職，SSLeay在1998年12月停止開發。因此在1998年12月，社群另外分支出OpenSSL，繼續開發下去。
OpenSSL管理委員會目前由7人組成[2]，有13個開發人員[3]具有提交權限（其中許多人也是OpenSSL管理委員會的一部分）。只有兩名全職員工（研究員），其餘的是志願者。
| 版本 | 初始版本日期 | 备注 | 最近更新版本 |
|---|---|---|---|
| 0.9.1 | 1998年12月23日 |
|
0.9.1c（1998年12月23日） |
| 0.9.2 | 1999年3月22日 |
|
0.9.2b（1999年4月6日） |
| 0.9.3 | 1999年5月25日 |
|
0.9.3a（1999年5月27日） |
| 0.9.4 | 1999年8月9日 |
|
0.9.4（1999年4月9日） |
| 0.9.5 | 2000年2月28日 |
|
0.9.5a（2000年4月1日） |
| 0.9.6 | 2000年9月24日 |
|
0.9.6m（2004年3月17日） |
| 0.9.7 | 2002年12月31日 |
|
0.9.7m（2007年2月23日） |
| 0.9.8 | 2005年7月5日 |
|
0.9.8zh（2015年12月3日） |
| 1.0.0 | 2010年3月29日 |
|
1.0.0t（2015年12月3日） |
| 1.0.1[7] | 2012年3月14日 |
|
1.0.1u（2016年9月22日） |
| 1.0.2[8] | 2015年1月22日 | 1.0.2u（2019年12月20日） | |
| 1.1.0[9] | 2016年8月25日 | 1.1.0l（2019年9月10日） | |
| 1.1.1[11] | 2018年9月11日 | 1.1.1w（2023年9月11日） | |
| 3.0[note 1] | 2021年9月7日 |
|
3.0.10 (2023年8月1日） |
| 3.1 | 2023年3月14日 |
|
3.1.2 (2023年8月1日） |
| 3.2[15][16] | 2023年11月23日 | 持續開發中 | |
| 3.3[17] | 2024年4月9日 | 持續開發中 | |
| 3.4[18] | 2024年10月22日 | 持續開發中 | |
格式： 舊版本 舊版本，仍被支援 当前版本 最新的预览版 未来版本 | |||
Remove ads
OpenSSL支持许多不同的加密算法：
- 加密
- AES、Blowfish、Camellia、Chacha20、Poly1305、SEED、CAST-128、DES、IDEA、RC2、RC4、RC5、TDES、GOST 28147-89[19]、SM4
- 密碼雜湊函數
- MD5、MD4、MD2、SHA-1、SHA-2、SHA-3、RIPEMD-160、MDC-2、GOST R 34.11-94[19]、BLAKE2、Whirlpool[20]、SM3
- 公开密钥加密
- RSA、DSA、ECDSA、ECDHE、迪菲-赫爾曼密鑰交換、椭圆曲线密码学、X25519、Ed25519、X448、Ed448、GOST R 34.10-2001[19]、SM2
（从1.0版开始，橢圓曲線迪菲-赫爾曼金鑰交換用于支持前向安全性）[21])
OpenSSL 根據 OpenSSL 許可證和 SSLeay 許可證獲得雙重許可，這意味著可以使用任一許可證的條款。[22]OpenSSL 授權實際上是 Apache授權條款1.0，而 SSLeay 授權則與四條款 BSD授權條款有些相似。
由於OpenSSL 授權是Apache授權條款1.0（而非Apache授權條款2.0），因此被要求在宣傳資料和任何redistributions中明確標出：「本產品包含由 OpenSSL Project 開發，用於 OpenSSL 工具包的軟體」（根據 OpenSSL 授權第 3 和第 6 條規定）。由於此限制，OpenSSL授權和Apache授權條款1.0這兩個授權與GNU GPL授權[23]不相容。
一些 GPL 開發者為了允許他們的系統與 OpenSSL 一起使用，特別在他們的授權條款中加入了"OpenSSL例外"。例如，GNU Wget[24] 和 climm [25]採用了這樣的例外條款。某些套件（如 Deluge）在 GPL 授權條款的開頭添加額外部分，記錄此例外[26]。而其他套件則選擇使用具有不同授權的替代品，例如採用 GNU-LGPL 的 GnuTLS、BSD 授權的 Botan[27]、MPL 授權的 NSS，這些工具具備相同的功能。
2015 年 8 月，OpenSSL 宣布將要求大多數貢獻者簽署貢獻者授權協議（Contributor License Agreement, CLA），並計劃將 OpenSSL 的授權最終變更為Apache授權條款 2.0。此過程於 2017 年 3 月展開，並於 2018 年完成。
2021 年 9 月 7 日，採用Apache授權條款 2.0 授權的OpenSSL 3.0.0 正式發布。[28]
Remove ads
在OpenSSL 0.9.6k，某些特定的ASN.1序列會在 Windows 電腦上觸發大量遞迴。該錯誤於 2003 年 11 月 4 日被發現。能夠發送任意大量的 ASN.1 序列將導致 OpenSSL 崩潰。
OpenSSL 的偽亂數產生器使用複雜的程式方法來取得熵。為了防止Valgrind分析工具發出相關警告， Debian發行版的維護者對 Debian 的 OpenSSL 套件變體應用了補丁，該補丁將其可生成的私鑰總數限制為32,768，無意中破壞了其隨機數生成器。損壞的版本包含在 2006 年 9 月 17 日發布的 Debian 版本中（版本 0.9.8c-1），這也影響了其他基於Debian的系統，例如Ubuntu。[29]
該錯誤於 2008 年 5 月 13 日由 Debian 報告。在 Debian 4.0 發行版（代號 etch）中，這些問題已在版本 0.9.8c-4etch3 中修復，而針對 Debian 5.0 發行版（代號 lenny）的修復則包含在版本 0.9.8g-9 中[30]。
在連線建立的握手階段時，，用戶端可能會傳送格式不正確的ClientHello訊息，導致 OpenSSL 解析的內容超出訊息末端。CVE 專案分配了識別碼CVE -2011-0014 ，這影響了所有 OpenSSL 版本 0.9.8h 至 0.9.8q 以及 OpenSSL 1.0.0 至 1.0.0c。由於解析可能會導致讀取不正確的記憶體位址，因此攻擊者有可能引發DoS。某些應用程式也可能會暴露已解析的OCSP擴充的內容，從而導致攻擊者能夠讀取ClientHello之後的記憶體內容。[31]
當使用基本輸入/輸出 (BIO) 或基於 FILE 的函數讀取不受信任的DER格式資料時，OpenSSL 容易受到攻擊。但該漏洞不會直接影響 OpenSSL 的 SSL/TLS 程式碼，或者任何使用 ASN.1 函數（特別是 d2i_X509 和 d2i_PKCS12）的應用程式。
在處理 SSL、TLS 和 DTLS 中的 CBC 密碼套件時，發現 OpenSSL 在 MAC 處理期間容易受到定時攻擊。 Nadhem Alfardan 和 Kenny Paterson 發現了這個問題，並於 2013 年 2 月 5 日發布了他們的發現[32]。CVE 識別碼為CVE -2013-0169
OpenSSL 1.0.1至1.0.1f 版本在其 TLS心跳擴展（Heartbeat Extension）的實現中存在一個嚴重的內存處理漏洞，該漏洞可被利用在每次心跳中洩露最多 64 KB 的應用程序內存。[33][34]（CVE -2014-0160）。通過讀取 Web 伺服器的內存，攻擊者可能訪問敏感數據，包括伺服器的私鑰。[35]
這可能使攻擊者能夠解碼之前竊聽的通信內容，特別是在加密協議未確保完美前向保密（Perfect Forward Secrecy, PFS）的情況下。掌握私鑰還可能讓攻擊者對未來的通信進行中間人攻擊（MITM attack）。
該漏洞還可能洩露其他用戶敏感請求與響應的未加密部分，包括會話Cookie 和密碼，這可能讓攻擊者冒充其他用戶的身份進行服務操作。[36]
該漏洞於 2014 年 4 月 7 日披露時，估計大約 17%（約 50 萬台）由受數位憑證認證機構 (CA) 認證的安全 Web 伺服器可能受到了此攻擊的影響[37]。並且，Heartbleed 漏洞可能同時影響伺服器和客戶端。
CCS 注入漏洞 (CVE -2014-0224) 是一個安全繞過漏洞，是由 OpenSSL 中處理密鑰材料的方法存在的弱點引起。
此漏洞可以通過中間人攻擊（MITM）被利用。攻擊者可以解密和修改傳輸中的流量。一名遠程未經身份驗證的攻擊者可以通過特製的握手過程迫使通信雙方使用弱密鑰材料。成功的攻擊可能導致安全繞過，使攻擊者能夠訪問潛在的敏感信息。該攻擊僅能在易受攻擊的客戶端與伺服器之間執行。
OpenSSL 用戶端在版本 0.9.8za、1.0.0m 和 1.0.1h 之前的所有 OpenSSL 版本中都存在漏洞。僅已知 OpenSSL 1.0.1 和 1.0.2-beta1 中的伺服器容易受到攻擊。建議使用 1.0.1 之前版本伺服器的用戶升級作為預防措施。[38]
此漏洞（CVE -2015-0291）允許任何人讀取證書的內容並準確地修改它，從而利用該漏洞使客戶端或伺服器崩潰。如果客戶端連接到一個使用 OpenSSL 1.0.2 的伺服器並在重新協商時提供無效的簽名算法擴展，將會發生空指標引用。這可能導致針對伺服器的拒絕服務（DoS）攻擊。
斯坦福大學的安全研究員 David Ramos 持有一個私有的漏洞利用程序，並將其提交給 OpenSSL 團隊，隨後該問題被修補。
OpenSSL 將此漏洞分類為高嚴重性問題，指出版本 1.0.2 受到影響。[39]
此漏洞（CVE-2016-0701）在滿足某些特定條件時，允許恢復 OpenSSL 伺服器的 Diffie–Hellman 私鑰。
該漏洞由 Adobe 系統安全研究員 Antonio Sanso 私下報告，OpenSSL 將此漏洞分類為高嚴重性問題，並指出僅版本 1.0.2 受到影響。[40]
在2009年，OpenSSL API受挫之后，当时的OpenBSD开发人员Marco Peereboom创建了分支Agglomerated SSL（assl），它重新使用OpenSSL API，但提供了更简单的外部接口。[41]
2014年4月的心脏出血漏洞事件之后，OpenBSD项目成员以OpenSSL 1.0.1g作为分支，创建一个名为LibreSSL的项目。[42]在缩减OpenSSL的代码库的第一周，将超过90,000行的C语言代码从分支中删除。[43]
2014年6月，Google发布了自己的OpenSSL分支BoringSSL[44]，计划与OpenSSL和LibreSSL的开发者合作。[45][46][47]
GmSSL支持SM2/SM3/SM4/SM9/ZUC等商用密码，主要使用SM2替代RSA/Diffie-Hellman/ECDSA/ECDH，SM3替代MD5/SHA-1/SHA-256，SM4替代DES/AES，SM9替代PKI/CA体系，所有代码在GitHub上开源[48]，并由北京大学信息安全实验室开发和维护[49]。此项目获得2015年度中国Linux软件大赛二等奖（一等奖空缺）[50]。
在開發者社群中，經常提及OpenSSL每次推出新的主要版本時引入 API 相容性破壞的案例[51][52][53][54]，此時就會需要對軟體進行調整，從而往往延遲新版本的採用。
此外，由於舊版本通常在新主要版本發布後的維護期不超過兩年，這種情況往往迫使某些供應商必須非常早地開始準備軟體遷移。 因此在更新到新版本時，有時可能面臨失去與現有軟體的某些相容性風險， [55][56]，或導致軟體回歸(Software regression)的風險。[57][58]
雖然長期支援版本（LTS)會維護長達 5 年[59]，但發行時間間的間隔往往迫使作業系統供應商不得不長時間地停留在最後一個支援的版本上，從而在新版本發布時較沒有緩衝時間。
例如，OpenSSL 3.0 原本預計在 2019 年第 4 季發布， 但最終拖延了 21 個月才發行，且沒有延長對先前支援的版本 1.1.1 的預期支援結束日期，儘管存在需要對現有軟體進行適配的重要變更。
上述提到的 1.1.1 版本較短的支援延遲引發了對對性能敏感的使用者更多的擔憂。在 OpenSSL 3.0 正式發布後不久，一些使用者開始報告該版本在多執行緒環境下出現嚴重的性能下降問題，許多人指出頻繁的底層操作中鎖的使用效率較低，導致速度降低達到 80 到 400 倍[60][61][62][63][64][65][66][67]。OpenSSL 團隊已建立一個綜合性問題來試圖集中收集這些大規模性能回歸的報告。[68]
大約一半的回報者表示，無法從早期版本升級到 3.0 ，這進一步加劇了由於先前版本 1.1.1 版本支援時間有限而帶來的困擾。
在開發 QUIC 傳輸以支援 HTTP 3.0時，提出使用 TLS 來提供安全性[69]，並發現需要對 TLS 庫進行一些適配修改。這些修改最初引入到了 BoringSSL[70]， 成為當時 QUIC 開發者主要使用的版本，後來也被移植到其他版本中[71]。 這項工作的移植很快被提議給 OpenSSL[72]。
雖然當天就開始討論，但進展迅速受阻，最初是由於授權考量而受阻，然後在這些問題解決後仍被擱置。最終，10 個月後，OpenSSL 管理委員會在一篇博客文章中宣布[73]，由於擔心 API 會隨時間變更，這些補丁集將不會被納入 3.0 版本。
在預計發布 3.0 版本超過一年後，該版本仍遙遙無期，一支來自 Akamai 和 Microsoft 的志願者團隊決定 fork 該項目為 QuicTLS，並在 OpenSSL 代碼上支援這些補丁，以促進 QUIC 開發進展。這一行動得到了社群的普遍歡迎。
最終，在 OpenSSL 3.0 正式發布後，QUIC 補丁集再次被考慮，但最終被否決[74]，該 pull 請求被關閉，在社群中引發了數十到數百條失望反應[75]。也有使用者向作業系統供應商請求支援替代的 QuicTLS 分叉[76][77]，或尋找其他解決方案[78]。
最後，QuicTLS 項目的聯合創始人 Rich Salz，宣布希望從 QuicTLS 分叉出一個 Apache 項目[78]。但截止到 2023 年 2 月 25 日，仍然沒有一個預設在作業系統中提供長期支援且兼容 QUIC 的 TLS 庫，而這要求終端使用者需要自行從源碼重新構建。
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
Remove ads