■ 1. OpenSSLの品質問題
- OpenSSLの品質や状況に懸念があるという指摘は専門家やエンジニアの間で事実として存在
- 特にOpenSSL 3.0(2021年リリース)以降パフォーマンスの低下やアーキテクチャの複雑化をめぐって厳しい批判
- 主な指摘内容:
- パフォーマンスの大幅な劣化:
- 新しい「プロバイダー・アーキテクチャ」が原因で特定の処理が旧バージョン(1.1.1系)より著しく遅くなった
- マルチスレッド環境でのロック競合によりスループットが劇的に低下
- APIのオーバーヘッドにより証明書の検証や鍵の生成といった基本的な操作のステップ数が増加
- コードの複雑化とテストの不備:
- テストを通過していないコードがマージされる事象が2025年時点でも指摘
- 修正によって別のバグ(デグレード)が発生
- メモリ安全性の欠如(C言語で書かれているためバッファオーバーフローなどの脆弱性が継続的に発見)
- QUICへの対応遅延:
- 次世代通信規格QUIC(HTTP/3)への対応が非常に遅れた
- 多くのプロジェクトがBoringSSLやquictlsなどの別ライブラリへ流出
- 業界の反応(OpenSSL離れの加速):
- BoringSSL: GoogleがOpenSSLをフォーク/不要な機能を削ぎ落としセキュリティとパフォーマンスに特化
- rustls: Rust言語で書かれたTLSライブラリ/メモリ安全性が保証されパフォーマンスも高い
- Goの標準ライブラリ: 独自実装を選択しOpenSSLの混乱の影響を受けない
■ 2. OpenSSLの資金面と組織面の変遷
- Heartbleed以前(2014年以前):
- 世界中のインフラを支えていながら正社員はほぼゼロ
- 寄付金は年間わずか2,000ドル程度という極めて劣悪な環境
- Heartbleed後:
- Linux Foundationの「Core Infrastructure Initiative」などを通じて数億円規模の資金援助
- 組織は急拡大
- 資金拡大の副作用:
- 「商用化」へのシフト: 安定した運営のためサポート契約を販売する法人化を推進/大口顧客が求める「FIPS認証」などの要件が優先
- 官僚化と構造の複雑化: 少数の凄腕エンジニアによる属人的な開発から委員会による合議制へ移行/意思決定の鈍化
- OpenSSL 3.0の問題:
- 過度な抽象化: 将来的な拡張性を求めて内部構造をゼロから作り直す「プロバイダー・アーキテクチャ」を導入/極めて複雑で旧バージョンの数百倍遅い処理が発生
- QUIC対応の失敗: 内部の設計方針が二転三転した結果開発が大幅に遅れた
- 「レガシー」と「新設計」の板挟み:
- 世界中で動いているという責任があるため古いC言語のコード(30年前のものも含む)を維持しながら最新の安全な設計を取り入れる必要
- テストの不足: 膨大なコードベースをカバーする自動テスト体制が追いついていない
- 技術的負債: Rustなどのメモリ安全な言語への移行を求める声もあるがC言語に固執せざるを得ない現状
■ 3. OpenSSLの組織改革(2024年〜)
- 二頭体制への分離(2024年3月〜):
- OpenSSL Corporation(事業会社): 商用ユーザーや大口顧客を対象/サポート契約の販売/FIPS 140認証の取得など
- OpenSSL Foundation(財団): 非営利コミュニティや個人開発者を対象/オープンソースとしての理念を守る
- 旧体制(OMC/OTC)の解散:
- OMC(管理委員会)の解散(2024年3月): 代わりに10名の取締役会が意思決定
- OTC(技術委員会)の解散(2025年4月予定): 代わりにTAC(技術諮問委員会)が新設され技術ロードマップの決定に透明性
- リリースサイクルの「予測可能性」の重視:
- タイムベースのリリース(毎年4月と10月)に移行
- 組織改革の背景にある反省点:
- 「身内感」の払拭: 閉鎖的な構造が外部からの批判を招いていた/新体制では選挙制を導入
- 「商用優先」への批判回避: 組織を分けることでバランスを取る
■ 4. OpenSSL 4.0の野心的変更(2026年4月リリース予定)
- 過去10年以上の負債を一掃するための「大掃除」のリリース
- ENGINE APIの完全削除:
- ハードウェアアクセラレータや独自の暗号モジュールを利用するための仕組み
- 設計が古くメンテナンスの大きな負担
- 「Provider(プロバイダー)」アーキテクチャに一本化
- 独自のハードウェア支援を利用している古いシステムはProvider形式に書き換えない限り4.0に移行不可
- SSLv3のサポート完全終了:
- 2015年に脆弱性(POODLE)によって完全に否定されたがコードとしては残されていた
- 4.0ではSSLv3に関連するコードがライブラリから物理的に削除
- C99標準への移行とツールチェーンの刷新:
- 非常に古いC言語規格(ANSI C/C89)をベースに書かれてきた
- 4.0からはC99以降のコンパイラが必須
- コンパイラの最適化が効きやすくなりパフォーマンス劣化を解消するためのコード整理が進めやすくなる
- スケジュール:
- 2026年2月: コードフリーズ
- 2026年3月: ベータ版リリース
- 2026年4月7日: 正式リリース(予定)
- 4.0でのリセットはOpenSSLが「枯れたが重いライブラリ」から「現代的で筋肉質なライブラリ」へと再生できるかどうかの分水嶺