OpenSSLは、コンピュータネットワーク上で盗聴を防止し、通信相手を識別するためのアプリケーション用ソフトウェアライブラリです。HTTPSウェブサイトの大部分を含むインターネットサーバーで広く利用されています。

OpenSSLには、SSLおよびTLSプロトコルのオープンソース実装が含まれています。Cプログラミング言語で記述されたコアライブラリは、基本的な暗号化機能を実装し、様々なユーティリティ関数を提供しています。OpenSSLライブラリを様々なコンピュータ言語で使用できるようにするラッパーも利用可能です。

OpenSSL Software Foundation (OSF) は、貢献者ライセンス契約、寄付の管理など、ほとんどの法的立場において OpenSSL プロジェクトを代表しています。また、OpenSSL Software Services (OSS) は、サポート契約に関しても OpenSSL プロジェクトを代表しています。

OpenSSL は、ほとんどのUnix 系 オペレーティング システム( Linux、macOS、BSDを含む)、Microsoft Windows、OpenVMSで利用できます。

プロジェクトの履歴

OpenSSLプロジェクトは、インターネットで使用されるコード向けの無料の暗号化ツールセットを提供するために1998年に設立されました。これは、エリック・アンドリュー・ヤングとティム・ハドソンによるSSLeayのフォークに基づいていますが、1998年12月17日にヤングとハドソンがRSA Securityに移籍したため、非公式に開発が終了しました。初期の創設メンバーは、マーク・コックス、ラルフ・エンゲルシャル、スティーブン・ヘンソン、ベン・ローリー、ポール・サットンでした。[4]

2018年、OpenSSLのバージョン番号は1.1.1から3.0.0に変更され、OpenSSLのモジュールとの競合を避けるため、メジャーバージョン番号の2が省略されました。バージョン3.0.0は、Apacheライセンスを採用した最初のバージョンです。

2019年5月現在、[5] OpenSSL管理委員会は7名[6]で構成されており、コミット権限を持つ開発者は17名[7] （その多くがOpenSSL管理委員会のメンバーでもある）である。フルタイムの従業員（フェロー）はわずか2名で、残りはボランティアである。

2024年までに従業員は14人になりました。

このプロジェクトは2024年に550万米ドルの総収入があった。[8] TLS 1.3の開発はAkamaiによって後援された。[9]

メジャーバージョンリリース

アルゴリズム

OpenSSL はさまざまな暗号化アルゴリズムをサポートしています。

暗号
AES、Blowfish、Camellia、ChaCha20、Poly1305、 SEED、CAST-128、DES、IDEA、RC2、RC4、RC5、トリプルDES、GOST 28147-89、[41] SM4
暗号ハッシュ関数
MD5、MD4、MD2、SHA-1、SHA-2、SHA-3、RIPEMD-160、MDC-2、GOST R 34.11-94、[41] BLAKE2、ワールプール、[42] SM3
公開鍵暗号
RSA、DSA、ディフィー・ヘルマン鍵交換、 楕円曲線、X25519、Ed25519、X448、Ed448、 GOST R 34.10-2001、[41] SM2

（完全順方向秘密はバージョン1.0以降、楕円曲線ディフィー・ヘルマン暗号を使用してサポートされている。 [43]）

FIPS 140 検証

FIPS 140は、暗号モジュールの試験および認証のための米国連邦政府のプログラムです。OpenSSLのFOM 1.0に対する初期のFIPS 140-1認証は、2006年7月に「認証済みモジュールと外部ソフトウェアとの相互作用について疑問が生じたため」失効しました。このモジュールは2007年2月に再認証され、その後FIPS 140-2に取って代わられました。[44] OpenSSL 1.0.2は、FIPS 140-2認証環境でFIPS承認アルゴリズムを提供するために構築されたOpenSSL FIPSオブジェクトモジュール（FOM）の使用をサポートしていました。[45] [46] OpenSSLは、現在FIPSモードをサポートしている唯一のOpenSSLバージョンであるという反対意見にもかかわらず、2019年12月31日をもって1.0.2アーキテクチャを「サポート終了」または「EOL」に分類することを決定しました。[47] EOLの結果、FOM自体はさらに8か月間検証されたままであったものの、多くのユーザーはFOM 2.0を適切に展開できず、1.0.2アーキテクチャの延長サポートを確保できなかったためコンプライアンス違反となりました。

FIPS オブジェクト モジュール 2.0 は、2020 年 9 月 1 日に NIST がデジタル署名標準としての FIPS 186-2 の使用を非推奨とし、非準拠のモジュールをすべて「履歴」に指定するまで、いくつかの形式で FIPS 140-2 検証済みのままでした。この指定には、連邦政府機関に対して、モジュールを新規調達に含めないようにという警告も含まれています。この非推奨には、OpenSSL 検証の 3 つすべてが含まれていました – OpenSSL FIPS オブジェクト モジュール (証明書 #1747) [48 ] 、OpenSSL FIPS オブジェクト モジュール SE (証明書 #2398) [49]、および OpenSSL FIPS オブジェクト モジュール RE (証明書 #2473) [50] 。コンサルタントによって作成された多くの「プライベート ラベル」の OpenSSL ベースの検証とクローンも履歴リストに移動されましたが、[52]

OpenSSL 管理委員会は、バージョン管理スキームの変更を発表しました。

この変更により、OpenSSL FIPSモジュールが既にこの番号を占有していたため、次期メジャーバージョンのメジャー番号が2倍になるはずでした。そのため、OpenSSL 2.0のバージョン番号をスキップし、OpenSSL 3.0を継続することが決定されました。

OpenSSL 3.0はFIPSモードを復元し、FIPS 140-2テストを受けましたが、大幅な遅延がありました。この取り組みは、SafeLogic [53] [54] [55]の支援を受けて2016年に開始され、2017年にはOracleからのサポートも受けましたが、[56] [57]プロセスは困難を極めていました。[58]

2020年10月20日、OpenSSL FIPSプロバイダー3.0がCMVPテスト中実装リストに追加されました。これは、FIPS 140-2の検証を進めるためにテストラボと正式に契約したことを反映しています。これにより、その後数か月間に多数の認証が取得されました。[59]

ライセンス

OpenSSLはOpenSSLライセンスとSSLeayライセンスのデュアルライセンスであり、どちらのライセンスの条項も使用できます。[60] OpenSSLライセンスはApacheライセンス1.0であり、SSLeayライセンスは4条項BSDライセンスと類似点があります。OpenSSLライセンスはApacheライセンス1.0であり、Apacheライセンス2.0ではないため、広告資料および再配布物には「本製品には、OpenSSLプロジェクトがOpenSSLツールキットで使用するために開発したソフトウェアが含まれています」という文言を記載する必要があります（OpenSSLライセンスの第3条および第6条）。この制限により、OpenSSLライセンスとApacheライセンス1.0はGNU GPLと互換性がありません。[61]一部のGPL開発者は、自社のシステムでOpenSSLを使用することを明確に許可するOpenSSL例外をライセンスに 追加しています。GNU Wgetとclimmはどちらもこのような例外を使用しています。[62] [63]一部のパッケージ（Delugeなど）は、ライセンスの冒頭に例外を記述したセクションを追加することで、GPLライセンスを明示的に変更しています。[64]その他のパッケージは、 LGPLライセンスのGnuTLS、BSDライセンスのBotan、またはMPLライセンスのNSSを使用しており、これらも同様の機能を果たします。

OpenSSLは2015年8月に、ほとんどの貢献者に貢献者ライセンス契約（CLA）への署名を義務付け、OpenSSLは最終的にApache License 2.0の条件に基づいて再ライセンスされることを発表しました。[65]このプロセスは2017年3月に開始され、[66] 2018年に完了しました。[67]

2021年9月7日、OpenSSL 3.0.0がApache License 2.0の下でリリースされました。[68]

注目すべき脆弱性

サービス拒否（DOS）：ASN.1解析

OpenSSL 0.9.6kには、特定のASN.1シーケンスがWindowsマシン上で大量の再帰処理を引き起こすバグがあり、2003年11月4日に発見されました。Windowsは大量の再帰処理を正しく処理できず、その結果OpenSSLがクラッシュしていました。また、任意の数のASN.1シーケンスを送信できるため、結果としてOpenSSLがクラッシュしていました。

OCSP ステープルの脆弱性

ハンドシェイクの作成時に、クライアントが誤った形式のClientHelloメッセージを送信し、OpenSSLがメッセージの末尾以降を解析してしまう可能性がありました。CVEプロジェクトによって識別子CVE - 2011-0014が割り当てられたこの問題は、OpenSSLバージョン0.9.8hから0.9.8q、およびOpenSSL 1.0.0から1.0.0cの全バージョンに影響を及ぼしました。解析によって誤ったメモリアドレスが読み取られる可能性があるため、攻撃者によるDoS攻撃が発生する可能性があります。また、一部のアプリケーションでは、解析されたOCSP拡張の内容が公開されるため、攻撃者がClientHello以降のメモリ内容を読み取ることができる可能性がありました。 [69]

ASN.1 BIOの脆弱性

OpenSSLは、基本入出力（BIO）[70]またはFILEベースの関数を用いて信頼できないDER形式のデータを読み取る際に脆弱です。この脆弱性は2012年4月19日に発見され、CVE識別子CVE - 2012-2110が付与されました。OpenSSLのSSL/TLSコードには直接影響しませんが、ASN.1関数（特にd2i_X509とd2i_PKCS12）を使用しているアプリケーションにも影響はありません。[71]

SSL、TLS、DTLS 平文回復攻撃

OpenSSLは、SSL、TLS、DTLSにおけるCBC暗号スイートの処理において、MAC処理中のタイミング攻撃に対して脆弱であることが判明しました。この問題を発見したのはNadhem Alfardan氏とKenny Paterson氏で、2013年2月5日にその調査結果を公表しました[72] 。この脆弱性にはCVE識別子CVE - 2013-0169が割り当てられました。

予測可能な秘密鍵（Debian 固有）

OpenSSLの疑似乱数生成器は、複雑なプログラミング手法を用いてエントロピーを獲得します。Valgrind解析ツールが関連する警告を出さないようにするため、DebianディストリビューションのメンテナーはOpenSSLスイートのDebianバリアントにパッチを適用しました。このパッチは、生成可能な秘密鍵の総数を32,768個に制限することで、乱数生成器を意図せず破壊してしまいました。[73] [74]この破壊されたバージョンは、2006年9月17日のDebianリリース（バージョン0.9.8c-1）に含まれており、 Ubuntuなどの他のDebianベースのディストリビューションにも悪影響を及ぼしました。すぐに使用できるエクスプロイトは容易に入手可能です。[75]

このエラーは2008年5月13日にDebianによって報告されました。Debian 4.0ディストリビューション（etch）では、これらの問題はバージョン0.9.8c-4etch3で修正され、Debian 5.0ディストリビューション（lenny）ではバージョン0.9.8g-9で修正されました。[76]

ハートブリード

Heartbleedバグを表すロゴ

OpenSSLバージョン1.0.1から1.0.1fには、 TLSハートビート拡張機能の実装に重大なメモリ処理バグがあり、ハートビートごとに最大64KBのアプリケーションメモリが漏洩する可能性があります [ 77 ] [78]（CVE - 2014-0160）。攻撃者はWebサーバーのメモリを読み取ることで、サーバーの秘密鍵などの機密データにアクセスできる可能性があります[79]。これにより、使用されている暗号化プロトコルが完全な前方秘匿性を保証していない場合、攻撃者は以前に盗聴された通信を解読できる可能性があります。また、秘密鍵が漏洩した場合、攻撃者は将来の通信に対して中間者攻撃を仕掛けることもできます[要出典] 。この脆弱性により、セッションCookieやパスワードなど、他のユーザーの機密リクエストや応答の暗号化されていない部分が漏洩する可能性があり、攻撃者がサービスの他のユーザーのIDを乗っ取る可能性があります[80] 。

2014年4月7日の発表時点では、信頼できる機関によって認定されたインターネットの安全なウェブサーバーのうち、約17％、つまり50万台が攻撃に対して脆弱であると考えられていました。[81]しかし、Heartbleedはサーバーとクライアントの両方に影響を及ぼす可能性があります。

CCS注入の脆弱性

CCSインジェクション脆弱性（CVE - 2014-0224）は、OpenSSLの鍵生成方法の弱点に起因するセキュリティバイパスの脆弱性です。[82]

この脆弱性は、中間者攻撃[83]によって悪用される可能性があり、攻撃者は転送中のトラフィックを復号化および変更できる可能性があります。認証されていないリモートの攻撃者は、特別に細工されたハンドシェイクを使用して脆弱な鍵素材の使用を強制することで、この脆弱性を悪用する可能性があります。この脆弱性の悪用に成功すると、セキュリティバイパス状態が発生し、攻撃者が機密情報にアクセスできる可能性があります。この攻撃は、脆弱なクライアントとサーバー間でのみ実行可能です。

OpenSSLクライアントは、OpenSSLバージョン0.9.8za、1.0.0m、1.0.1hより前のすべてのバージョンで脆弱性が存在します。サーバーはOpenSSL 1.0.1および1.0.2-beta1でのみ脆弱性が確認されています。1.0.1より前のバージョンのOpenSSLサーバーをご利用の方は、予防措置としてアップグレードすることをお勧めします。[84]

ClientHello sigalgs DoS

この脆弱性（CVE - 2015-0291）により、誰でも証明書を取得し、その内容を読み取り、正確に改変することで、クライアントまたはサーバーをクラッシュさせることが可能です。クライアントがOpenSSL 1.0.2サーバーに接続し、無効な署名アルゴリズム拡張で再ネゴシエートすると、ヌルポインタ参照が発生します。これにより、サーバーに対するDoS攻撃が発生する可能性があります。

スタンフォード大学のセキュリティ研究者、David Ramos 氏は、非公開の脆弱性を発見し、それを OpenSSL チームに提示して、OpenSSL チームにより問題が修正されました。

OpenSSLはこのバグを重大度の高い問題として分類し、バージョン1.0.2に脆弱性が見つかったと指摘した。[85]

ディフィー・ヘルマン小部分群に対する鍵回復攻撃

この脆弱性（CVE - 2016-0701）は、特定の状況下でOpenSSLサーバーの秘密Diffie-Hellman鍵を復元できる可能性があります。Adobe System Securityの研究者であるAntonio Sanso氏が、この脆弱性を非公開で報告しました。

OpenSSLはこのバグを重大度の高い問題に分類し、バージョン1.0.2のみが脆弱であることが判明したと指摘した。[86]

フォーク

集約型SSL

2009年、オリジナルのOpenSSL APIに対する不満から、当時OpenBSD開発者であったMarco PeereboomはオリジナルのAPIをフォークしてAgglomerated SSL (assl) [87]を作成しました。これは内部的にはOpenSSL APIを再利用していますが、はるかにシンプルな外部インターフェースを提供しています。[88]その後、2015年頃のLibreSSLフォーク を受けて非推奨となりました。

リブレSSL

2014年4月、 Heartbleed事件を受けて、 OpenBSDプロジェクトのメンバーはOpenSSLを1.0.1gブランチからフォークし、 LibreSSLというプロジェクトを立ち上げました。[89] OpenSSLのコードベースを整理した最初の1週間で、9万行以上のCコードがフォークから削除されました。[90]

退屈なSSL

2014年6月、GoogleはOpenSSLの独自のフォークであるBoringSSLを発表しました。[91] GoogleはOpenSSLとLibreSSLの開発者と協力する予定です。[92] [93] [94] Googleはその後、BoringSSLをベースにした新しいライブラリTinkを開発しました。[95]

AWS-LC

2020年9月、 Amazon Web Services暗号化チームによって管理され、AWSクラウドコンピューティングプラットフォームで使用される汎用暗号ライブラリとしてリリースされました。OpenSSLおよびBoringSSLプロジェクトのコードに基づいています。 [96]

クイックTLS

QuicTLSは、OpenSSL 3.3リリースをベースにした、 AkamaiとMicrosoftの共同フォークです。一部の機能と修正は、現在のOpenSSLリポジトリから厳選されています。[97]

批判

下位互換性

開発者コミュニティでは、OpenSSLはメジャーバージョンアップごとにAPIの互換性が失われるという問題がよく指摘されており[98] [99] [100] [101]、ソフトウェアの適応が必要となり、新バージョンの導入が遅れる傾向がある。[102]これに加えて、メジャーバージョンアップ後、以前のリリースは通常2年以内にメンテナンスされるという事実[28]もあって、一部のベンダーは、新リリースへのアップデートにほとんど時間が残されていないにもかかわらず[103] 、ソフトウェアの移行を早期に予測せざるを得なくなり、既存のソフトウェアとの互換性が失われるリスク[104 ]や、リグレッションのリスク[106]を負うことになる。[ 107]

リリース間の遅延

長期サポート（LTS）リリースは5年間維持されますが[12] 、リリース期間の遅延が蓄積されると、オペレーティングシステムベンダーは前回のサポートリリースに長期間留まらざるを得なくなり、新バージョンがリリースされた際に余裕がなくなる傾向があります。例えば、OpenSSL 3.0は当初2019年第4四半期にリリースされる予定でしたが[47]、最終的には21ヶ月後にリリースされました[28]。これは、既存ソフトウェアへの適応を必要とする大幅な変更があったにもかかわらず、以前サポートされていたバージョン1.1.1のサポート終了を延長することなく行われました。

パフォーマンスの大幅な低下

上述のバージョン 1.1.1 のサポート遅延の短縮は、パフォーマンスに敏感なワークロードを持つユーザーにさらなる懸念を引き起こします。3.0 の一般提供からしばらくして、一部のユーザーから、マルチスレッド環境でこのバージョンに影響を与える深刻なパフォーマンスの低下が報告され始めました。多くは、頻繁な低レベル操作でのロックの非効率的な使用を挙げ、80 倍から 400 倍の速度低下を挙げています。[108] [109] [ 110] [111] [112] [113] [114] [115] OpenSSL チームは、このような大規模なパフォーマンスの低下の報告を一元化するために、メタ問題を作成しました。[116]これらの報告者の約半数は、以前のバージョンから 3.0 にアップグレードすることは不可能であると指摘しており、以前のバージョン 1.1.1 に残されたサポート期間が限られていることによって引き起こされる問題にさらに拍車をかけています。

ユーザーの要件への配慮

QUICトランスポート層がHTTPプロトコルの第3バージョンをサポートするために開発されていた際、セキュリティを提供するためにTLSを使用することが提案され、[117] TLSライブラリにいくつかの適応が必要であることが判明しました。そのような変更は、当時QUIC開発者が主に使用していたライブラリであるBoringSSL [118]に持ち込まれ、後に他のライブラリに移植されました。 [119]この作業の移植はすぐにOpenSSLに提案されました。[120]同じ日にいくつかの議論が開始されましたが、すぐに行き詰まり、最初はライセンスを考慮してブロックされ、[120]これらの懸念が解消された後も保留されました。最終的に10か月後、OpenSSL管理委員会はブログ投稿で[121]このパッチセットはAPIが時間の経過とともに変更される恐れがあるため、3.0には採用されないことを発表しました。 3.0 のリリースが予定されていたものの 1 年以上経ってから、まだリリースされていないAkamaiとMicrosoftのボランティア チームがプロジェクトを QuicTLS [122]としてフォークし、OpenSSL コード上でこれらのパッチをサポートして QUIC 開発の妨げにならないようにすることを決定しました。 この行動はコミュニティで概ね歓迎されました。 OpenSSL 3.0 がようやくリリースされた後、QUIC パッチ セットは再検討され、採用しないことが決定されました。 [123]コミュニティの間で数十から数百の失望の反応を引き起こしました。[120]プル リクエストはクローズされましたが、ユーザーは失望を公に表明するか、[124]オペレーティング システム ベンダーに代わりの QuicTLS フォークをサポートするように懇願するか、[125] [126]別の解決策を探す必要があると感じました。 [ 127 ]最後に、QuicTLS フォークの共同創設者である Rich Salz が、Apache プロジェクトが QuicTLS からフォークすることに興味があることを発表しました。 2023 年 2 月 25 日現在、エンドユーザーがソースから自分で再構築する必要なく、オペレーティング システムでデフォルトで利用できる、QUIC 互換の長期サポート TLS ライブラリはまだありません。

参照

注記

  1. ^ メジャーバージョン2.0.0は、OpenSSL FIPSモジュールで以前使用されていたためスキップされました。[30]

参考文献

  1. ^ “OpenSSL 3.6.0”. 2025年10月1日. 2025年10月1日閲覧。
  2. ^ “/source/license.html”. www.openssl.org . 2019年1月18日時点のオリジナルよりアーカイブ。2021年3月3日閲覧。
  3. ^ 「OpenSSLライセンス | ソフトウェアパッケージデータ交換（SPDX）」。spdx.org。
  4. ^ Laurie, Ben (1999年1月6日). "Announce: OpenSSL (Take 2)". ssl-users (メーリングリスト). 2019年3月23日時点のオリジナルよりアーカイブ。 2018年10月29日閲覧。
  5. ^ “New Committers”. OpenSSL Software Foundation. 2019年5月20日. 2024年10月14日時点のオリジナルよりアーカイブ。2024年10月11日閲覧。
  6. ^ “OpenSSL Management Committee”. OpenSSL Software Foundation. 2018年7月22日時点のオリジナルよりアーカイブ。 2019年11月3日閲覧。
  7. ^ “OpenSSL Committers”. OpenSSL Software Foundation. 2018年7月22日時点のオリジナルよりアーカイブ。 2019年11月3日閲覧。
  8. ^ 「OpenSSL 年次レポート 2024」(PDF)。
  9. ^ Marquess, Steve (2017年1月19日). 「AkamaiがTLS 1.3をスポンサー」. openssl-announce (メーリングリスト). 2017年2月1日時点のオリジナルよりアーカイブ。 2018年11月9日閲覧。
  10. ^ “OpenSSL – Changelog”. OpenSSL Software Foundation. 2016年9月13日時点のオリジナルよりアーカイブ。 2016年9月26日閲覧。
  11. ^ “OpenSSL Releases”. GitHub . 2022年12月6日閲覧。
  12. ^ ab 「OpenSSLライブラリ – リリース戦略」。OpenSSLソフトウェア財団。2024年12月9日時点のオリジナルよりアーカイブ。 2024年8月1日閲覧。
  13. ^ abcdefgh 「OpenSSL 0.9.xシリーズのノート」GitHub 。 2022年12月6日閲覧。
  14. ^ “OpenSSL 1.0.0 シリーズノート”. GitHub . 2022年12月6日閲覧。
  15. ^ “OpenSSL 1.0.1 シリーズノート”. GitHub . 2022年12月6日閲覧。
  16. ^ R. Seggelmann; M. Tuexen; M. Williams (2012年2月). トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）ハートビート拡張.インターネット技術特別調査委員会. doi : 10.17487/RFC6520 . ISSN  2070-1721. RFC 6520. 提案された標準。RFC 8447 によって更新されました。
  17. ^ E. Rescorla (2010年1月). トランスポート層セキュリティ（TLS）のための鍵マテリアルエクスポーター.インターネット技術タスクフォース. doi : 10.17487/RFC5705 . ISSN  2070-1721. RFC 5705. 提案された標準。RFC 8446 および 8447 によって更新されました。
  18. ^ D. McGrew; E. Rescorla (2010年5月). セキュアリアルタイムトランスポートプロトコル (SRTP) の鍵を確立するためのデータグラムトランスポート層セキュリティ (DTLS) 拡張.インターネット技術タスクフォース. doi : 10.17487/RFC5764 . ISSN  2070-1721. RFC 5764. 提案された標準。RFC 7983 および 9443 によって更新されました。
  19. ^ “OpenSSL 1.0.2 シリーズノート”. GitHub . 2022年12月6日閲覧。
  20. ^ “OpenSSL 1.1.0 シリーズノート”. GitHub . 2022年12月6日閲覧。
  21. ^ JP. Aumasson (2015年10月). MJ. Saarinen (編). BLAKE2暗号ハッシュおよびメッセージ認証コード (MAC). 独立投稿. doi : 10.17487/RFC7693 . ISSN  2070-1721. RFC 7693. 情報提供。
  22. ^ Y. Nir; A. Langley (2018年6月). IETFプロトコルのためのChaCha20とPoly1305. Internet Research Task Force . doi : 10.17487/RFC8439 . ISSN  2070-1721. RFC 8439. 情報提供。RFC 7539 を廃止します。
  23. ^ ab A. Langley; M. Hamburg; S. Turner (2016年1月). セキュリティのための楕円曲線.インターネット技術タスクフォース. doi : 10.17487/RFC7748 . ISSN  2070-1721. RFC 7748. 情報提供。
  24. ^ ab Caswell, Matt (2018年9月11日). 「OpenSSL 1.1.1 がリリースされました」. OpenSSL ブログ. OpenSSL Foundation . 2024年10月11日閲覧.
  25. ^ 「OpenSSL 1.1.1シリーズノート」GitHub . 2022年12月6日閲覧。
  26. ^ Caswell, Matt (2018年2月8日). 「OpenSSLでTLS1.3を使用する」. OpenSSLブログ. OpenSSL Foundation . 2024年10月11日閲覧.
  27. ^ B. Kaliski; A. Rusch; J. Johnsson; A. Rusch (2016年11月). K. Moriarty (編). PKCS #1: RSA暗号仕様バージョン2.2.インターネット技術タスクフォース. doi : 10.17487/RFC8017 . ISSN  2070-1721. RFC 8017. 情報提供。RFC 3447 を廃止します。
  28. ^ abc 「OpenSSL 3.0がリリースされました！」OpenSSLブログ. 2021年9月7日. 2024年10月11日閲覧。
  29. ^ 「OpenSSL 3.0シリーズノート」. GitHub . 2022年12月6日閲覧。
  30. ^ Matt Caswell (2018年11月28日). 「アンティオキアの聖なる手榴弾」. OpenSSLブログ. 2024年10月11日閲覧。
  31. ^ 「OpenSSL 3.1 最終リリース」。OpenSSLブログ。2023年3月7日。 2024年10月11日閲覧。
  32. ^ 「OpenSSL 3.1シリーズノート」. GitHub . 2023年3月15日閲覧。
  33. ^ “OpenSSL 3.2.0 Final Release”. OpenSSL Blog . 2023年11月23日. 2024年12月7日時点のオリジナルよりアーカイブ。 2024年10月11日閲覧。
  34. ^ 「OpenSSL 3.2シリーズノート」. GitHub . 2023年11月24日閲覧。
  35. ^ A. Ghedini; V. Vasiliev (2020年12月). TLS証明書の圧縮.インターネット技術タスクフォース. doi : 10.17487/RFC8879 . ISSN  2070-1721. RFC 8879. 提案された標準。
  36. ^ T. Pornin (2013年8月). デジタル署名アルゴリズム（DSA）と楕円曲線デジタル署名アルゴリズム（ECDSA）の決定論的使用法. 独立提出. doi : 10.17487/RFC6979 . ISSN  2070-1721. RFC 6979. 情報提供。
  37. ^ J. Gilmore; S. Weiler; T. Kivinen (2014年6月). P. Wouters; H. Tschofenig (編). トランスポート層セキュリティ (TLS) およびデータグラムトランスポート層セキュリティ (DTLS) における生の公開鍵の使用.インターネット技術タスクフォース. doi : 10.17487/RFC7250 . ISSN  2070-1721. RFC 7250. 提案された標準。
  38. ^ 「OpenSSL 3.3 最終リリース」。OpenSSLブログ。2024年4月10日。 2024年10月11日閲覧。
  39. ^ “OpenSSL 3.4 Final Release”. OpenSSL Blog . 2024年10月22日. 2024年12月8日時点のオリジナルよりアーカイブ。 2024年11月22日閲覧。
  40. ^ “OpenSSL 3.5 Final Release”. OpenSSL Blog . 2025年4月8日. 2025年4月25日時点のオリジナルよりアーカイブ。 2025年4月28日閲覧。
  41. ^ abc "GOST エンジン OpenSSL 1.0.0 README". cvs.openssl.org. 2013年4月15日時点のオリジナルよりアーカイブ。
  42. ^ “OpenSSL ソースコード、ディレクトリ crypto/whrlpool”. GitHub . 2019年2月17日時点のオリジナルよりアーカイブ。2017年8月29日閲覧。
  43. ^ 「前方秘匿性による長期的なデータ保護」。2016年3月4日時点のオリジナルよりアーカイブ。2012年11月5日閲覧。
  44. ^ 「NIST、オープンソース暗号化モジュールを再認証」gcn.com。2007年10月10日時点のオリジナルよりアーカイブ。
  45. ^ "FIPS-140". openssl.org . 2019年11月12日閲覧。
  46. ^ 「OpenSSL FIPSオブジェクトモジュールv2.0のOpenSSLユーザーガイド」（PDF） openssl.org. 2017年3月14日. 2020年6月9日時点のオリジナルよりアーカイブ（PDF） 。 2019年11月12日閲覧。
  47. ^ ab 「3.0開発、FIPS、および1.0.2 EOLに関する最新情報」OpenSSLブログ、2019年11月7日。 2024年10月11日閲覧。
  48. ^ 「暗号モジュール検証プログラム証明書 #1747」。コンピュータセキュリティリソースセンター。2016年10月11日。
  49. ^ 「暗号モジュール検証プログラム証明書 #2398」。コンピュータセキュリティリソースセンター。2016年10月11日。2020年10月26日時点のオリジナルよりアーカイブ。2020年10月29日閲覧。
  50. ^ 「暗号モジュール検証プログラム証明書 #2473」。コンピュータセキュリティリソースセンター。2016年10月11日。
  51. ^ 「暗号モジュール検証プログラムの検索結果」。コンピュータセキュリティリソースセンター。2016年10月11日。
  52. ^ 「暗号モジュール検証プログラムの検索結果」。コンピュータセキュリティリソースセンター。2016年10月11日。
  53. ^ Schneider, Troy K. (2016年7月20日). 「より安全なOpenSSLの政府承認取得」. GCN: 公共部門ITのためのテクノロジー、ツール、戦術. 2021年5月9日時点のオリジナルよりアーカイブ。 2020年10月29日閲覧。
  54. ^ Waterman, Shaun (2016年7月21日). 「SafeLogicが連邦政府のOpenSSL利用を救済」FedScoop .
  55. ^ Rashid, Fahmida Y. (2016年7月26日). 「改良されたOpenSSL、政府認証に向けて順調に進捗」InfoWorld .
  56. ^ Wells, Joyce (2017年8月3日). 「Oracle、SafeLogic、OpenSSLがFIPSモジュールのアップデートで協力」. Database Trends and Applications .
  57. ^ Kerner, Sean Michael (2017年8月4日). 「Oracle、SafeLogicと提携しOpenSSLセキュリティ向けFIPSモジュールを開発」eWeek .
  58. ^ “OpenSSL 3.0 Alpha7 Release”. OpenSSL Blog . 2020年10月20日. 2024年10月14日時点のオリジナルよりアーカイブ。2024年10月11日閲覧。
  59. ^ 「暗号化モジュール検証プログラム：OpenSSL」.コンピュータセキュリティリソースセンター. 2016年10月11日. 2021年4月14日時点のオリジナルよりアーカイブ。 2021年9月24日閲覧。
  60. ^ “OpenSSL: Source, License”. openssl.org. 2019年1月18日時点のオリジナルよりアーカイブ。2015年2月5日閲覧。
  61. ^ 「ライセンス – フリーソフトウェア財団」. fsf.org. 2008年1月24日時点のオリジナルよりアーカイブ。 2008年1月4日閲覧。
  62. ^ “WGET 1.10.2 for Windows (win32)”. users.ugent.be. 2008年1月2日時点のオリジナルよりアーカイブ。
  63. ^ 「ソースコードとバイナリのリリース」climm.org. 2011年2月12日時点のオリジナルよりアーカイブ。 2010年11月30日閲覧。
  64. ^ “Deluge LICENSE file”. deluge-torrent.org. 2013年12月3日時点のオリジナルよりアーカイブ。 2013年1月24日閲覧。
  65. ^ Salz, Rich (2015年8月1日). 「ライセンス契約と変更が近づいています」. openssl.org . 2024年10月11日閲覧。
  66. ^ “OpenSSL、Apacheライセンスv. 2.0へのライセンス変更で他のFOSSプロジェクトや製品とのより広範な利用を促進”. 2017年3月23日. 2017年7月18日時点のオリジナルよりアーカイブ。 2018年8月6日閲覧。
  67. ^ Lee, Victoria; Radcliffe, Mark; Stevenson, Chris (2019年2月5日). 「2018年のFOSS法務動向トップ10」Opensource.com、Red Hat . 2019年2月5日時点のオリジナルよりアーカイブ。 2019年9月28日閲覧。OpenSSLプロジェクトは、OpenSSL/SSLeayライセンスからApacheソフトウェアライセンスバージョン2（ASLv2）への移行を完了したことを発表しました。
  68. ^ “OpenSSL 3.0 License Change”. 2021年9月22日. 2025年1月17日時点のオリジナルよりアーカイブ。 2021年9月24日閲覧。
  69. ^ 「OpenSSLのアップデートで重大なセキュリティ脆弱性が修正」2014年8月9日。2014年8月26日時点のオリジナルよりアーカイブ。2014年8月25日閲覧。
  70. ^ 「OpenSSL ASN.1 asn1_d2i_read_bio() ヒープオーバーフロー脆弱性」. Cisco. 2016年6月10日時点のオリジナルよりアーカイブ。2016年5月9日閲覧。
  71. ^ 「ASN1 BIO 脆弱性」OpenSSL. 2015年3月2日時点のオリジナルよりアーカイブ。 2015年2月5日閲覧。
  72. ^ 「TLSにおけるRC4のセキュリティについて」ロイヤル・ホロウェイ情報セキュリティ学部。2013年3月15日時点のオリジナルよりアーカイブ。 2014年4月29日閲覧。
  73. ^ 「research!rsc: Debian/OpenSSLの大失敗から学ぶこと」research.swtch.com . 2015年8月12日閲覧。
  74. ^ "SSLkeys". Debian Wiki . 2015年6月19日閲覧。
  75. ^ 「Debian OpenSSL – 予測可能なPRNGブルートフォースSSHエクスプロイトPython」Exploits Database . 2008年6月1日. 2025年2月6日時点のオリジナルよりアーカイブ。2015年8月12日閲覧。
  76. ^ 「DSA-1571-1 openssl – 予測可能な乱数ジェネレータ」Debianプロジェクト、2008年5月13日。2011年3月9日時点のオリジナルよりアーカイブ。2012年8月5日閲覧。
  77. ^ OpenSSL.org (2014年4月7日). “OpenSSL Security Advisory [07 Apr 2014]”. 2014年4月8日時点のオリジナルよりアーカイブ。2014年4月9日閲覧。
  78. ^ OpenSSL (2014年4月7日). 「TLSハートビート読み取りオーバーラン (CVE-2014-0160)」. 2014年4月8日時点のオリジナルよりアーカイブ。2014年4月8日閲覧。
  79. ^ Codenomicon Ltd (2014年4月8日). 「Heartbleed Bug」. 2014年4月7日時点のオリジナルよりアーカイブ。2014年4月8日閲覧。
  80. ^ 「Heartbleedはなぜ危険なのか？ CVE-2014-0160の悪用」IPSec.pl. 2014年。2014年4月8日時点のオリジナルよりアーカイブ。2014年4月8日閲覧。
  81. ^ マトン、ポール（2014年4月8日）「広く信頼されている50万のウェブサイトがHeartbleedバグの脆弱性」Netcraft Ltd. 2014年11月19日時点のオリジナルよりアーカイブ。2014年4月8日閲覧。
  82. ^ 「OpenSSL、さらなる欠陥を次々と発見 ― より重大な脆弱性が発見される」サイバーオアム脅威研究所、2014年。2014年6月19日時点のオリジナルよりアーカイブ。 2014年6月13日閲覧。
  83. ^ “CVE-2014-0224”. CVE. 2014. 2014年8月1日時点のオリジナルよりアーカイブ。2014年6月13日閲覧。
  84. ^ “OpenSSL Security Advisory”. OpenSSL. 2014年6月5日. 2024年4月30日時点のオリジナルよりアーカイブ。2014年6月13日閲覧。
  85. ^ 「OpenSSL、深刻なサービス拒否脆弱性を修正」Brandon Stosh、2015年3月20日。2015年4月2日時点のオリジナルよりアーカイブ。2015年3月20日閲覧。
  86. ^ Goodlin, Dan (2016年1月28日). 「OpenSSLの重大なバグにより、攻撃者がHTTPSトラフィックを解読できる」Ars Technica . 2016年11月20日時点のオリジナルよりアーカイブ。 2017年6月14日閲覧。
  87. ^ “Agglomerated SSL”. GitHub . 2010年9月7日. 2024年12月9日時点のオリジナルよりアーカイブ。2024年12月9日閲覧。
  88. ^ "security/assl: assl-1.5.0p0v0 – ひどいSSL APIをまともなインターフェースで隠す". OpenBSD ports . 2014年5月22日. 2015年2月10日時点のオリジナルよりアーカイブ。2015年2月10日閲覧。
  89. ^ 「OpenBSDはOpenSSLの大規模なストリップダウンとクリーンアップを開始した」OpenBSD journal . 2014年4月15日. 2014年7月1日時点のオリジナルよりアーカイブ。2014年4月21日閲覧。
  90. ^ 「OpenBSDがOpenSSLをフォーク、プルーン、修正」ZDNet、2014年4月21日。2014年4月21日時点のオリジナルよりアーカイブ。2014年4月21日閲覧。
  91. ^ “BoringSSL”. Git at Google . 2018年2月17日時点のオリジナルよりアーカイブ。2015年12月28日閲覧。
  92. ^ 「Google、OpenSSLの独立したフォーク「BoringSSL」を発表」Ars Technica、2014年6月21日。2014年6月23日時点のオリジナルよりアーカイブ。2017年6月14日閲覧。
  93. ^ “BoringSSL”. Adam Langley's Weblog . 2014年6月20日. 2018年6月1日時点のオリジナルよりアーカイブ。 2015年9月22日閲覧。
  94. ^ 「BoringSSLはHeartbleedにつながった騒動を鎮めたい」Sophos. 2014年6月24日. 2018年2月14日時点のオリジナルよりアーカイブ。2016年10月24日閲覧。
  95. ^ Buchanan, Bill (2018年8月30日). 「OpenSSLに別れを告げ、Google Tinkにようこそ」. Medium . 2019年4月4日閲覧。
  96. ^ 「AWS-LCは汎用暗号ライブラリです」。GitHub 。 2020年9月4日。 2024年12月8日閲覧。
  97. ^ 「QuicTLSプロジェクトの公式リポジトリ」GitHub . 2025年5月7日. 2025年5月7日閲覧。
  98. ^ “OpenSSL 3 breaks webpack build · Issue #22305 · brave/brave-browser”. GitHub . 2024年12月8日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  99. ^ “openssl version 3.0 in arch? / Newbie Corner / Arch Linux Forums”. bbs.archlinux.org . 2024年5月16日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  100. ^ “OpenSSL 3.0 transition plans”. Ubuntu Community Hub . 2022年4月6日. 2024年12月25日時点のオリジナルよりアーカイブ。 2023年2月25日閲覧。
  101. ^ “OpenSSL 3.0 Compatibility · Issue #597 · nginx/unit”. GitHub . 2024年12月8日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  102. ^ “Our future with OpenSSL”. Python.org のディスカッション. 2022年11月28日. 2023年2月25日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  103. ^ 「OpenSSL 3.0 を Red Hat Enterprise Linux および Fedora に導入した経験」www.redhat.com。
  104. ^ “OpenSSL 3.X に対してコンパイル”. groups.google.com . 2024年12月8日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  105. ^ “ESET Management Agent (RHEL 9.x, OpenSSL 3.0.x)”. ESETセキュリティフォーラム. 2022年6月6日. 2024年12月9日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  106. ^ “Issue 46313: SSLObject が OpenSSL 3 で SSLEOFError を発生させない - Python トラッカー”. bugs.python.org . 2024年12月8日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  107. ^ “RHEL 9 : openssl (RHSA-2022:6224)”. www.tenable.com . 2024年12月8日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  108. ^ 「OpenSsl 3.0 を重いマルチスレッドサーバーアプリケーションで使用するとパフォーマンスが大幅に低下する · Issue #17064 · openssl/openssl」。GitHub 。 2024年12月8日時点のオリジナルよりアーカイブ。 2023年2月25日閲覧。
  109. ^ “d2i_x509 使用時のマルチスレッドアプリケーションにおける Openssl 3.0 のパフォーマンス問題 · Issue #17950 · openssl/openssl”. GitHub . 2024年12月8日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  110. ^ “1.1.1と比較して、資格情報の読み込み効率が大幅に低下 · Issue #18814 · openssl/openssl”. GitHub . 2024年12月7日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  111. ^ 「3.0 ロックによりパフォーマンスが低下する · Issue #20286 · openssl/openssl」。GitHub。
  112. ^ “v16.15.0からv18.1.0にアップグレード後、アウトバウンドSSLリクエストのCPU使用率が高くなる · Issue #43128 · nodejs/node”. GitHub . 2024年12月8日時点のオリジナルよりアーカイブ。 2023年2月25日閲覧。
  113. ^ “OpenSsl 3.0 FIPSプロバイダーにおける大幅なパフォーマンス低下 · Issue #18472 · openssl/openssl”. GitHub . 2024年12月8日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  114. ^ “パフォーマンス測定 · Issue #16791 · openssl/openssl”. GitHub . 2024年12月8日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  115. ^ “PEM/DER デコードによる PKCS8 RSA 秘密鍵の速度が 3.0 では 80 倍遅い · Issue #15199 · openssl/openssl”. GitHub . 2024年12月8日時点のオリジナルよりアーカイブ。 2023年2月25日閲覧。
  116. ^ “3.0 パフォーマンスの問題 · Issue #17627 · openssl/openssl”. GitHub . 2024年12月8日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  117. ^ Thomson, Martin; Turner, Sean (2017年1月14日). 「TLS（トランスポート層セキュリティ）を使用したQUICのセキュリティ確保」。2024年12月8日時点のオリジナルよりアーカイブ。 2023年11月27日閲覧– IETF経由。
  118. ^ 「221 - boringssl - Google のニーズを満たすように設計された OpenSSL のフォーク - Monorail」。bugs.chromium.org。
  119. ^ “Support QUIC TLS API (#826) · Issues · gnutls / GnuTLS · GitLab”. GitLab . 2019年9月4日. 2024年12月8日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  120. ^ abc “WIP: master QUIC support by tmshort · Pull Request #8797 · openssl/openssl”. GitHub . 2025年1月21日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  121. ^ 「QUICとOpenSSL」。OpenSSLブログ。2020年2月17日。 2024年10月11日閲覧。
  122. ^ 「quictlsがTwitterで発表」。
  123. ^ “OMCリリース要件”. www.mail-archive.com . 2025年1月21日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  124. ^ “The QUIC API OpenSSL will not provide | daniel.haxx.se”. 2021年10月25日. 2025年1月21日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  125. ^ Tarreau, Willy (2021年10月27日). 「[Pkg-openssl-devel] quictls を維持する意図はありますか？」. 2024年12月7日時点のオリジナルよりアーカイブ。 2023年2月25日閲覧。
  126. ^ “Bug#1011391: openssl: please support quictls patchset”. groups.google.com . 2024年12月8日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
  127. ^ ab “HTTP/3 support · Issue #680 · haproxy/haproxy”. GitHub . 2024年12月7日時点のオリジナルよりアーカイブ。2023年2月25日閲覧。
Wikimedia Commons にはOpenSSLに関連するメディアがあります。
  • 公式サイト
  • OpenSSL マニュアルページ
  • OpenSSL プログラミング ガイド (アーカイブ)
  • OpenSSLライセンスとGPL 2014年7月23日アーカイブ、Wayback Machineマーク・マクローリン
  • 「OpenSSLプログラミングチュートリアル」。2018年8月16日。2021年5月10日時点のオリジナルよりアーカイブ。
  • OpenSSL コミュニティ Wiki