OpenSSL

OpenSSL是一個開放原始碼的軟體函式庫套件，應用程式可以使用這個套件來在-{zh-tw:電腦網路;zh-cn:计算机网络}-上進行安全通訊，避免竊聽，同時確認另一端連線者的身份。這個套件廣泛被應用在網際網路的網頁伺服器上。

其主要函式庫是以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人組成，有13個開發人員具有提交權限（其中許多人也是OpenSSL管理委員會的一部分）。只有兩名全職員工（研究員），其餘的是志願者。

該項目每年的預算不到100萬美元，主要依靠捐款。 TLS 1.3的開發由Akamai贊助。

 主要版本发布 

+ OpenSSL版本历史 版本  初始版本日期  备注  最近更新版本  1998年12月23日 OpenSSL项目的正式开启 0.9.1c（1998年12月23日）  1999年3月22日 取代0.9.1c 0.9.2b（1999年4月6日）  1999年5月25日 取代0.9.2b 0.9.3a（1999年5月27日）  1999年8月9日 取代0.9.3a 0.9.4（1999年4月9日）  2000年2月28日 取代0.9.4 0.9.5a（2000年4月1日）  2000年9月24日 取代0.9.5a 0.9.6m（2004年3月17日）  2002年12月31日 取代0.9.6m 0.9.7m（2007年2月23日）  2005年7月5日 取代0.9.7m 0.9.8zh（2015年12月3日）  2010年3月29日 取代0.9.8n 1.0.0t（2015年12月3日）  2012年3月14日 取代1.0.0
 维护至2016年12月31日
 支持RFC 6520 TLS/DTLS心跳
 支持SCTP
 RFC 5705 TLS key material exporter
 RFC 5764 DTLS-SRTP协商
 Next Protocol Negotiation
 PSS signatures in certificates, requests and 证书吊销列表
 Support for password based recipient info for CMS
 支持TLS v1.2以及TLS v1.1
 Preliminary FIPS capability for unvalidated 2.0 FIPS module
 支持（SRP） 1.0.1u（2016年9月22日）  2015年1月22日 取代1.0.1
 维护至2019年12月31日（长期维护）
 Suite B支持TLS 1.2和DTLS 1.2
 支持DTLS 1.2
 TLS自动选择椭圆曲线（EC）
 用於設置TLS支持的簽名算法和曲線的API
 SSL_CONF配置API
 支持TLS 
 支持应用层协议协商
 CMS支持、RSA-OAEP、ECDH及X9.42 DH 1.0.2u（）   取代1.0.2h
 維護到2019年9月
 支持BLAKE (RFC 7693)
 支持ChaCha20-Poly1305（RFC 7539）
 支持X25519（RFC 7748）
 支持和证书透明度
 支持扩CCM模式密碼套件
 支持扩展主密钥
 移除SSLv2
 移除对Kerberos密码包的支持
 将RC4和3DES從libssl从DEFAULT密碼套件中移除
 将DSS、SEED、IDEA、CAMELLIA以及AES-CCM从DEFAULT密碼套件中移除
 将40和56位密码从libssl中移除 1.1.0l（）   長期支援版本（維護至2023年9月11日）
 支持TLS1.3
 支持SHA-3
 支持以及（RFC 7748）
 支持
 支持
 支持多素數RSA（RFC 8017）
 支持SM2、SM3以及SM4
 移除Heartbleed
 移除对QNX支持的支持 1.1.1w（）   重新授權至Apache License 2.0
 重新支援 3.0.10 (）   合規
 效能改善 3.1.2 (）  客戶端支援 QUIC
TLS 證書壓縮
ECDSA 的確定性使用
TLS 原始公鑰支援 持續開發中   持續開發中   持續開發中 

算法
OpenSSL支持许多不同的加密算法：
 加密
 AES、Blowfish、Camellia、Chacha20、Poly1305、、、DES、IDEA、、RC4、RC5、TDES、、SM4

 密碼雜湊函數
 MD5、MD4、MD2、SHA-1、SHA-2、SHA-3、RIPEMD-160、、、BLAKE2、、SM3

 公开密钥加密
 RSA、DSA、ECDSA、ECDHE、迪菲-赫爾曼密鑰交換、椭圆曲线密码学、X25519、、、、GOST R 34.10-2001、SM2
（从1.0版开始，橢圓曲線迪菲-赫爾曼金鑰交換用于支持前向安全性）)

 授權條款(Licensing) 
OpenSSL 根據 OpenSSL 許可證和 SSLeay 許可證獲得雙重許可，這意味著可以使用任一許可證的條款。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授權不相容。

一些 GPL 開發者為了允許他們的系統與 OpenSSL 一起使用，特別在他們的授權條款中加入了"OpenSSL例外"。例如，GNU Wget 和 climm 採用了這樣的例外條款。某些套件（如 Deluge）在 GPL 授權條款的開頭添加額外部分，記錄此例外。而其他套件則選擇使用具有不同授權的替代品，例如採用 GNU-LGPL 的 GnuTLS、BSD 授權的 Botan、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 正式發布。

發生過的重大漏洞

 拒絕服務(DoS): ASN.1 解析 
在OpenSSL 0.9.6k，某些特定的ASN.1序列會在 Windows 電腦上觸發大量遞迴。該錯誤於 2003 年 11 月 4 日被發現。能夠發送任意大量的 ASN.1 序列將導致 OpenSSL 崩潰。

 "可預測私鑰"漏洞（僅限Debian） 
OpenSSL 的偽亂數產生器使用複雜的程式方法來取得熵。為了防止Valgrind分析工具發出相關警告， Debian發行版的維護者對 Debian 的 OpenSSL 套件變體應用了補丁，該補丁將其可生成的私鑰總數限制為32,768，無意中破壞了其隨機數生成器。損壞的版本包含在 2006 年 9 月 17 日發布的 Debian 版本中（版本 0.9.8c-1），這也影響了其他基於Debian的系統，例如Ubuntu。

該錯誤於 2008 年 5 月 13 日由 Debian 報告。在 Debian 4.0 發行版（代號 etch）中，這些問題已在版本 0.9.8c-4etch3 中修復，而針對 Debian 5.0 發行版（代號 lenny）的修復則包含在版本 0.9.8g-9 中。

 OCSP 裝訂漏洞 
在連線建立的握手階段時，用戶端可能會傳送格式不正確的ClientHello訊息 ，導致 OpenSSL 解析的內容超出訊息末端。CVE 專案分配了識別碼CVE -2011-0014  ，這影響了所有 OpenSSL 版本 0.9.8h 至 0.9.8q 以及 OpenSSL 1.0.0 至 1.0.0c。由於解析可能會導致讀取不正確的記憶體位址，因此攻擊者有可能引發DoS。某些應用程式也可能會暴露已解析的OCSP擴充的內容，從而導致攻擊者能夠讀取ClientHello之後的記憶體內容。

 ASN.1 BIO 漏洞 
當使用基本輸入/輸出 (BIO) 或基於 FILE 的函數讀取不受信任的DER格式資料時，OpenSSL 容易受到攻擊。但該漏洞不會直接影響 OpenSSL 的 SSL/TLS 程式碼，或者任何使用 ASN.1 函數（特別是 d2i_X509 和 d2i_PKCS12）的應用程式。

該漏洞於 2012 年 4 月 19 日發現，並分配了 CVE 識別碼CVE -2012-2110 。

 SSL、TLS 和 DTLS 明文恢復攻擊 
在處理 SSL、TLS 和 DTLS 中的 CBC 密碼套件時，發現 OpenSSL 在 MAC 處理期間容易受到定時攻擊。 Nadhem Alfardan 和 Kenny Paterson 發現了這個問題，並於 2013 年 2 月 5 日發布了他們的發現。CVE 識別碼為CVE -2013-0169 

 心臟出血漏洞 

OpenSSL 1.0.1至1.0.1f 版本在其 TLS心跳擴展（Heartbeat Extension）的實現中存在一個嚴重的內存處理漏洞，該漏洞可被利用在每次心跳中洩露最多 64 KB 的應用程序內存。（CVE -2014-0160 ）。通過讀取 Web 伺服器的內存，攻擊者可能訪問敏感數據，包括伺服器的私鑰。

這可能使攻擊者能夠解碼之前竊聽的通信內容，特別是在加密協議未確保完美前向保密（Perfect Forward Secrecy, PFS）的情況下。掌握私鑰還可能讓攻擊者對未來的通信進行中間人攻擊（MITM attack）。

該漏洞還可能洩露其他用戶敏感請求與響應的未加密部分，包括會話Cookie 和密碼，這可能讓攻擊者冒充其他用戶的身份進行服務操作。

該漏洞於 2014 年 4 月 7 日披露時，估計大約 17%（約 50 萬台）由受數位憑證認證機構 (CA) 認證的安全 Web 伺服器可能受到了此攻擊的影響。並且，Heartbleed 漏洞可能同時影響伺服器和客戶端。

 CCS注入漏洞 
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 之前版本伺服器的用戶升級作為預防措施。

 ClientHello 為內容的 DoS 攻擊 
此漏洞（CVE -2015-0291 ）允許任何人讀取證書的內容並準確地修改它，從而利用該漏洞使客戶端或伺服器崩潰。如果客戶端連接到一個使用 OpenSSL 1.0.2 的伺服器並在重新協商時提供無效的簽名算法擴展，將會發生空指標引用。這可能導致針對伺服器的拒絕服務（DoS）攻擊。

斯坦福大學的安全研究員 David Ramos 持有一個私有的漏洞利用程序，並將其提交給 OpenSSL 團隊，隨後該問題被修補。

OpenSSL 將此漏洞分類為高嚴重性問題，指出版本 1.0.2 受到影響。

 對 Diffie–Hellman 小型子group的 密鑰恢復攻擊 
此漏洞（CVE-2016-0701 ）在滿足某些特定條件時，允許恢復 OpenSSL 伺服器的 Diffie–Hellman 私鑰。

該漏洞由 Adobe 系統安全研究員 Antonio Sanso 私下報告，OpenSSL 將此漏洞分類為高嚴重性問題，並指出僅版本 1.0.2 受到影響。

 分支 
 Agglomerated SSL 

在2009年，OpenSSL API受挫之后，当时的OpenBSD开发人员Marco Peereboom创建了分支Agglomerated SSL（assl），它重新使用OpenSSL API，但提供了更简单的外部接口。

 LibreSSL 

2014年4月的心脏出血漏洞事件之后，OpenBSD项目成员以OpenSSL 1.0.1g作为分支，创建一个名为LibreSSL的项目。在缩减OpenSSL的代码库的第一周，将超过90,000行的C语言代码从分支中删除。

 BoringSSL 

2014年6月，Google发布了自己的OpenSSL分支BoringSSLhttps://boringssl.googlesource.com/boringssl/  BoringSSL，计划与OpenSSL和LibreSSL的开发者合作。

 GmSSL 
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上开源，并由北京大学信息安全实验室开发和维护。此项目获得2015年度中国Linux软件大赛二等奖（一等奖空缺）。

 受到的批評 

 舊版本兼容問題 
在開發者社群中，經常提及OpenSSL每次推出新的主要版本時引入 API 相容性破壞的案例，此時就會需要對軟體進行調整，從而往往延遲新版本的採用。

此外，由於舊版本通常在新主要版本發布後的維護期不超過兩年，這種情況往往迫使某些供應商必須非常早地開始準備軟體遷移。 因此在更新到新版本時，有時可能面臨失去與現有軟體的某些相容性風險， ，或導致軟體回歸(Software regression)的風險。

 發行版本間隔時間太長 
雖然長期支援版本（LTS)會維護長達 5 年，但發行時間間的間隔往往迫使作業系統供應商不得不長時間地停留在最後一個支援的版本上，從而在新版本發布時較沒有緩衝時間。

例如，OpenSSL 3.0 原本預計在 2019 年第 4 季發布， 但最終拖延了 21 個月才發行，且沒有延長對先前支援的版本 1.1.1 的預期支援結束日期，儘管存在需要對現有軟體進行適配的重要變更。

 顯著的性能下降 
上述提到的 1.1.1 版本較短的支援延遲引發了對對性能敏感的使用者更多的擔憂。在 OpenSSL 3.0 正式發布後不久，一些使用者開始報告該版本在多執行緒環境下出現嚴重的性能下降問題，許多人指出頻繁的底層操作中鎖的使用效率較低，導致速度降低達到 80 到 400 倍。OpenSSL 團隊已建立一個綜合性問題來試圖集中收集這些大規模性能回歸的報告。

大約一半的回報者表示，無法從早期版本升級到 3.0 ，這進一步加劇了由於先前版本 1.1.1 版本支援時間有限而帶來的困擾。

 對用戶需求的考量 
在開發 QUIC 傳輸以支援 HTTP 3.0時，提出使用 TLS 來提供安全性，並發現需要對 TLS 庫進行一些適配修改。這些修改最初引入到了 BoringSSL， 成為當時 QUIC 開發者主要使用的版本，後來也被移植到其他版本中。 這項工作的移植很快被提議給 OpenSSL。

雖然當天就開始討論，但進展迅速受阻，最初是由於授權考量而受阻，然後在這些問題解決後仍被擱置。最終，10 個月後，OpenSSL 管理委員會在一篇博客文章中宣布，由於擔心 API 會隨時間變更，這些補丁集將不會被納入 3.0 版本。

在預計發布 3.0 版本超過一年後，該版本仍遙遙無期，一支來自 Akamai 和 Microsoft 的志願者團隊決定 fork 該項目為 QuicTLS，並在 OpenSSL 代碼上支援這些補丁，以促進 QUIC 開發進展。這一行動得到了社群的普遍歡迎。

最終，在 OpenSSL 3.0 正式發布後，QUIC 補丁集再次被考慮，但最終被否決，該 pull 請求被關閉，在社群中引發了數十到數百條失望反應。也有使用者向作業系統供應商請求支援替代的 QuicTLS 分叉，或尋找其他解決方案。

最後，QuicTLS 項目的聯合創始人 Rich Salz，宣布希望從 QuicTLS 分叉出一個 Apache 項目。但截止到 2023 年 2 月 25 日，仍然沒有一個預設在作業系統中提供長期支援且兼容 QUIC 的 TLS 庫，而這要求終端使用者需要自行從源碼重新構建。

 參見 
 加密
 OpenSSH
 TLS的应用对比
 WolfSSL

 註記 

 参考 

 外部連結 
 OpenSSL官方網站
 SSLeay文件庫
 OpenSSL License vs GPL
 wget's 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:加密软件
Category:C函式庫
Category:自由安全软件
Category:傳輸層安全協議