OpenSSL

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

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

OpenSSLは、信頼できないDER形式のデータを読み取るためにBasic Input/Output（BIO）^{[ 73 ]}またはFILEベースの関数を使用する場合に脆弱性があります。この脆弱性は2012年4月19日に発見され、CVE識別子CVE - 2012-2110が割り当てられました。OpenSSLのSSL/TLSコードに直接影響を与えるものではありませんが、ASN.1関数（特にd2i_X509とd2i_PKCS12）を使用していたアプリケーションも影響を受けませんでした。^{[ 74 ]}

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

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

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

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

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

CCSインジェクション脆弱性（CVE - 2014-0224）は、鍵生成に使用されるOpenSSLメソッドの弱点に起因するセキュリティバイパス脆弱性です。^{[ 85 ]}

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

OpenSSLクライアントは、バージョン0.9.8za、1.0.0m、1.0.1hより前のすべてのバージョンのOpenSSLで脆弱性があります。サーバーは、OpenSSL 1.0.1および1.0.2-beta1でのみ脆弱性があることが知られています。1.0.1より前のOpenSSLサーバーのユーザーは、予防措置としてアップグレードすることをお勧めします。^{[ 87 ]}

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

スタンフォード大学のセキュリティ研究者であるデビッド・ラモス氏は、独自に脆弱性を発見し、それをOpenSSLチームに提示したところ、チームはそれに基づいて問題を修正した。

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

この脆弱性（CVE - 2016-0701）は、特定の条件が満たされた場合、OpenSSLサーバーの秘密Diffie-Hellman鍵を復元できるというものです。この脆弱性は、Adobe System Securityの研究者であるAntonio Sanso氏が非公開で報告しました。

OpenSSLはこのバグを重大な問題として分類し、バージョン1.0.2のみが脆弱であることが判明したと指摘した。^{[ 89 ]}

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

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

2014 年 6 月、Google はOpenSSL の独自のフォークである BoringSSL を発表しました。^{[ 94 ]} Google は OpenSSL および LibreSSL の開発者と協力する予定です。^{[ 95 ] [ 96 ] [ 97 ]} Google はその後、BoringSSL をベースにした新しいライブラリ Tink を開発しました。^{[ 98 ]} Microsoft Edgeを含むChromiumベースのブラウザはBoringSSL を実装しています。

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

QuicTLSは、 AkamaiとMicrosoftが共同で開発したフォークで、OpenSSL 3.3リリースに基づいています。一部の機能と修正は、現在のOpenSSLリポジトリから厳選されています。^{[ 100 ]}

開発者コミュニティでは、OpenSSL は新しいメジャー バージョンごとに API の互換性が損なわれることでよく指摘されており、^{[ 101 ] [ 102 ] [ 103 ] [ 104 ]}ソフトウェアの適応が必要となり、新しいバージョンの採用が遅れる傾向があります。^{[ 105 ]}これに加えて、以前のリリースは新しいメジャー バージョンがリリースされてから通常 2 年以内にメンテナンスされるという事実^{[ 28 ]}も相まって、一部のベンダーは、新しいリリースに更新する時間がほとんど残されていないにもかかわらず、ソフトウェアの移行を非常に早い段階で予測せざるを得ず、 ^{[ 106 ]既存のソフトウェアとの互換性の一部を失うリスク[ 107 ] [ 108 ]や、リグレッションのリスク[ 109 ] [ 110 ]}を負うこともあります。

長期サポート(LTS) リリースは 5 年間維持されますが、 ^{[ 12 ]}リリース時期の遅延が累積すると、オペレーティングシステムベンダーは最後にサポートされたリリースをより長く使用せざるを得なくなり、新しいバージョンが利用可能になったときに余裕が少なくなります。たとえば、OpenSSL 3.0 は当初 2019 年第 4 四半期にリリースされる予定でしたが^{[ 50 ]}、最終的に 21 か月後にリリースされました^{[ 28 ]。}これは、以前サポートされていたバージョン 1.1.1 のサポート終了予定日を延長することなく、既存のソフトウェアへの適応を必要とする大幅な変更があったにもかかわらずです。

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

HTTPプロトコルの第 3 バージョンをサポートするためにQUICトランスポート レイヤーが開発されている間、セキュリティを提供するために TLS を使用することが提案され^{[ 120 ]}、TLS ライブラリにいくつかの変更が必要になることが特定されました。このような変更は、当時 QUIC 開発者が主に使用していたライブラリであるBoringSSL ^{[ 121 ]に導入され、後に他のライブラリに移植されました[ 122 ]} 。この作業の移植が OpenSSL にすぐに提案されました^{[ 123 ]} 。同日に議論が開始されましたが、すぐに停滞し、最初はライセンスの考慮事項でブロックされ^{[ 123 ]} 、これらの懸念が解消された後も保留されました。最終的に 10 か月後、OpenSSL 管理委員会はブログ記事で^{[ 124 ]}、API が時間の経過とともに変更される恐れがあるため、このパッチ セットは 3.0 には採用されないと発表しました。最終的に、予定されていた 3.0 のリリースから 1 年以上が経過してもリリースされないままだったため、 AkamaiとMicrosoftのボランティア チームがQuicTLS ^{[ 125 ]}としてプロジェクトをフォークし、QUIC 開発のブロックを解除するために OpenSSL コードの上にこれらのパッチをサポートすることを決定しました。この行動はコミュニティから概ね歓迎されました。最終的に OpenSSL 3.0 がリリースされた後、QUIC パッチ セットは再検討され、却下されました^{[ 126 ]。}これにより、コミュニティの間で数十から数百の失望の反応が起こりました^{[ 123 ]} 。プル リクエストは閉じられ、ユーザーは失望を公に表明する必要性を感じ^{[ 127 ]}、または代替の QuicTLS フォークをサポートするようにオペレーティングシステム ベンダーに懇願したり^{[ 128 ] [ 129 ]}、または代替ソリューションを探したりしました^{[ 130 ]} 。最後に、QuicTLS フォークの共同創設者である Rich Salz は、Apache プロジェクトが QuicTLS からフォークされることに興味があると発表しました^{[ 130 ]}。 2023年2月25日現在、エンドユーザーがソースコードから再構築する必要なく、オペレーティングシステムにデフォルトで搭載されているQUIC互換の長期サポートTLSライブラリはまだ存在しない。