「OpenSSLの問題が深刻化している」と暗号ライブラリの開発者らが指摘

OpenSSLは暗号通信プロトコル「SSL/TLS」をサポートするオープンソースライブラリであり、世界全体で広く使われています。ところが、そんなOpenSSLの方向性には重大な問題があると、暗号処理用Pythonライブラリ「pyca/cryptography」の開発者兼メンテナであるポール・ケーラー氏らが指摘しました。

The State of OpenSSL for pyca/cryptography — Cryptography 47.0.0.dev1 documentation
https://cryptography.io/en/latest/statements/state-of-openssl/

ケーラー氏らは2014年から12年間にわたってpyca/cryptographyを保守しており、その間はずっとコア暗号アルゴリズムをOpenSSLに依存してきました。しかし、近年のOpenSSL開発には方向性の誤りがみられることから、OpenSSLへの依存度について見直す動きを進めているとのこと。

OpenSSLは長らくメンテナ不足によって低迷した時期が続いていましたが、2014年に「Heartbleed」と名付けられた深刻なバグが見つかったことをきっかけにコミュニティが活性化。本格的なコードレビュープロセスの確立や継続的インテグレーション(CI)でのテスト実行、リリースプロセスの成熟といった大幅な進歩と改善がみられました。

そして2021年にはOpenSSL 3がリリースされました。OpenSSL 3では新しいAPIが導入され、内部的に大規模なリファクタリングが行われましたが、以前のバージョンと比較するとパフォーマンスや複雑さなどの面で後退し、検証プロセスやメモリ安全性といった分野で必要な改善がされなかったとケーラー氏らは指摘しています。

◆パフォーマンスの低下
そもそもOpenSSL 3は、かつてのOpenSSL 1.1.1と比較して解析やキー読み込みなどの領域でパフォーマンスが大幅に低下しています。ケーラー氏らは数年前に、OpenSSL 3の楕円曲線公開鍵の読み込み速度がOpenSSL 1.1.1と比較して5～8倍も遅いというバグを報告しました。後の改善によってパフォーマンスはやや改善されたものの、この問題に対してOpenSSLは、「OpenSSL 3ではパフォーマンスの低下が予想されており、最適化が多少行われるにしてもOpenSSL 1.1.1のレベルに戻ることは期待できない」と回答したとのこと。ケーラー氏らは、ライブラリの他の部分が改善されるならパフォーマンス低下が許容される場合もあるが、OpenSSL 3のパフォーマンス低下はそういうわけではないと指摘しています。

これに対しケーラー氏らは、pyca/cryptographyにおいて証明書の解析をOpenSSLから独自のRustコードに移行したところ、10倍のパフォーマンス向上を実現したと報告しています。さらに公開鍵の解析を独自のRustコードに移行したことで、エンドツーエンドのパス検証が60％高速化したことから、OpenSSLのオーバーヘッドがいかに大きかったのかがよくわかると主張しました。

◆APIの変更と複雑化
OpenSSL 3ではAPIを大幅に変更するプロセスが開始されましたが、これによってパフォーマンスが低下したほかコンパイル時の検証も削減され、冗長性が増し、コードの可読性が低下したとのこと。さらに、OpenSSL 3では「providers(プロバイダ)」という概念も導入されましたが、API設計が不十分だったため無数のパフォーマンス低下の原因になったとケーラー氏らは指摘しています。OpenSSLはこの問題を軽減するためにキャッシュを追加し、最終的にはRCU(Read-Copy-Update)と呼ばれる複雑なメモリ管理戦略を導入しましたが、RCUにはバグの診断が困難という問題がありました。

ケーラー氏らは、「私たちの視点から見ると、これは誤った判断が積み重なる悪循環です。プロバイダAPIの設計が不適切だったためにパフォーマンスの低下を招きました。その結果、キャッシュやRCUといった形でこれらの低下を緩和するための複雑さが増し、結果としてバグの増加につながりました。そしてこれらすべてを経たにもかかわらず、パフォーマンスは当初よりも悪化したのです」と非難しています。また、OpenSSL 3のソースコードには読む人間の理解を阻む要因が驚くほど多く、読むだけでも苦痛な状況になっているとのこと。

◆テスト環境の問題
ケーラー氏らは、OpenSSLのテスト環境は2014年の「Heartbleed」から大幅に改善されたものの、依然として大きな欠陥が存在すると指摘。特にOpenSSL 3の開発サイクルにおいてテストカバレッジの欠陥が顕著に現れ、2025年の時点でもプロジェクトは依然として失敗したテストを含むコードをマージしているとのこと。

◆メモリ安全性の取り組み
OpenSSLが作成された当時はパフォーマンス・埋め込み可能性・メモリ安全性を有意義に提供するプログラミング言語は存在していませんでしたが、記事作成時点ではRustを採用することでメモリ安全性を高めることが可能です。実際にpyca/cryptographyはほとんどの機能でRustを使用し、暗号アルゴリズムの提供にOpenSSLを使用するという仕組みで、パフォーマンスの向上と複数のバグ回避を実現したとケーラー氏らは主張しています。

◆資金や人員不足が原因なのか？
オープンソースプロジェクトに関する問題が提起される際、多くの人々はオープンソースに起因する資金や人員不足が原因だと考えます。しかし、OpenSSLの場合は2014年の「Heartbleed」をきっかけに相当額の資金を手に入れており、OpenSSL CorporationとOpenSSL Foundationが雇用するソフトウェアエンジニアの数は、その他のOpenSSLフォークのフルタイム開発者数を上回っています。そのため、ケーラー氏らはOpenSSLの問題は資金や人員によるものではないと考えています。

◆今後の方向性
ケーラー氏らは「OpenSSLに関する私たちの経験はここ数年にわたり悪化の一途を辿っています」と述べ、今後の新機能ではOpenSSLではなくLibreSSLやBoringSSL、AWS-LCでのみ利用可能な新しいAPIを追加することを発表。また、長期的にはOpenSSL以外の暗号化ライブラリへの切り替えを見据えて、潜在的な代替手段を検討していくとのことです。

最後にケーラー氏らは、「暗号実装の提供に使用するライブラリの変更が、ユーザーに重大な影響を与えることを認識しています。これらの措置を軽率に検討しているわけではなく、急いで実施するつもりもありません。しかしながら、懸念事項の重大性から行動せざるを得ないのです」と述べました。