ハクソク

世界を動かす技術を、日本語で。

OpenSSL 4.0.0

49日前原文(github.com)

概要

  • OpenSSL 4.0.0 での代表的な新機能と変更点のまとめ
  • 互換性に影響する変更点 や廃止された機能の詳細
  • 新規追加機能 やセキュリティ強化に関する説明
  • APIの仕様変更 や構成オプションの扱いについて
  • 今後の利用方法や移行時の注意点 を簡潔に整理

OpenSSL 4.0.0の主な変更点

  • OpenSSL 4.0.0 は大規模な新機能追加と機能改善を含むリリース
  • RSAモジュラス等の16進数表示 で、先頭バイトが0x80以上の場合の余分な'00:'を削除
  • 16進数ダンプの幅 を署名は24バイト、他は16バイトに標準化（80文字制限対応）
  • PKCS5_PBKDF2_HMAC API 利用時、FIPSプロバイダーで下限チェックを強化
  • X509_V_FLAG_X509_STRICT 設定時、AKID検証チェックを追加
  • CRL検証プロセス に複数の追加チェックを導入
  • libcrypto によるグローバルデータのatexit()経由クリーンアップを廃止
  • BIO_snprintf() がlibcのsnprintf()を利用
  • OPENSSL_cleanup() がグローバルデストラクタか、デフォルトで未実行に変更
  • ASN1_STRING が不透明型に変更
  • X509関連API関数 の引数・戻り値にconst修飾子を追加し、型安全性を向上
  • X509_cmp_time()等の関数 を非推奨とし、X509_check_certificate_times()に統一
  • SSLv2 Client Hello のサポートを廃止
  • SSLv3 のサポートを完全廃止（2015年から非推奨、1.1.0以降デフォルト無効）
  • エンジン機能 のサポートを廃止し、no-engineビルドオプションとOPENSSL_NO_ENGINEマクロが常時有効
  • RFC 8422準拠の非推奨楕円曲線 のTLSサポートをデフォルトで無効化（有効化にはenable-tls-deprecated-ecオプションが必要）
  • 明示的ECカーブサポート をデフォルトで無効化（有効化にはenable-ec_explicit_curvesオプションが必要）
  • c_rehashスクリプト を廃止し、代わりにopenssl rehashコマンドを使用
  • openssl caコマンドのmsie-hackオプション を廃止
  • BIO_f_reliable() の実装を削除（3.0以降壊れていたが苦情なし）
  • カスタムEVP_CIPHER, EVP_MD, EVP_PKEY, EVP_PKEY_ASN1メソッド の非推奨サポートを削除
  • 固定SSL/TLSバージョンメソッド関数 の非推奨サポートを削除
  • ERR_get_state(), ERR_remove_state(), ERR_remove_thread_state() 等の非推奨関数を削除し、ERR_STATEを常時不透明型に
  • darwin-i386, darwin-ppc等のターゲット を構成から削除

新機能・強化点

  • Encrypted Client Hello (ECH, RFC 9849) のサポート
  • RFC 8998, sm2sig_sm3署名アルゴリズム, curveSM2鍵交換グループ, tls-hybrid-sm2-mlkem（ポスト量子） のサポート
  • cSHAKE関数 （SP 800-185準拠）のサポート
  • ML-DSA-MUダイジェストアルゴリズム のサポート
  • SNMP KDF, SRTP KDF のサポート
  • FIPS自己テスト の遅延実行とfipsinstallコマンドの-defer_testsオプション対応
  • Windows環境 での静的／動的VCランタイムリンク選択サポート
  • TLS 1.2でのFFDHE鍵交換 （RFC 7919準拠）のネゴシエーション対応

利用・移行時の注意点

  • 廃止・非推奨APIや機能の削除 により、既存アプリケーションの移行時はコード修正が必要な場合あり
  • TLS/SSLプロトコルの古いバージョンやエンジン機能 は完全に利用不可
  • 新しい構成オプションやAPI仕様変更 に注意し、ドキュメントやリリースノートの確認が必須
  • セキュリティ強化や標準化対応 のため、古い慣習や非推奨オプションの見直しが推奨

まとめ

  • OpenSSL 4.0.0 は大幅な仕様変更と新機能追加により、より安全で最新の暗号基盤を提供
  • 移行時の互換性チェック や最新ドキュメントの参照が重要
  • 将来的なサポートやセキュリティ対策 のため、積極的なアップデートと対応が推奨

Hackerたちの意見

ついに暗号化されたクライアントハローのサポートが来た！\o/

└

これは「今日」有効にできるものなの？それともブラウザやサーバーがサポートするのに12年かかるの？

└

どんな普通のネットワークでもこれをブロックすることを忘れないでね。

└

それとQUICね。

完全に素人の意見だけど、一方では結構いい感じの整理だね。（確かエンジンは特に惜しまれないはず）でも、互換性を壊すのはいつもリスクがあるし、3.xが…あまり好かれてなかったのを覚えてるよ。

└

だからバージョン4なんだよね。

ちょうど「サッカーピンチ」動画のタイミングだね。

3.xから4.0.0に移行するのってどれくらい大変なんだろう？聞いた話だと、2から3への移行は大変だったらしいけど。

└

それはバージョン2がなかったからだよ…

https://www.haproxy.com/blog/state-of-ssl-stacks これによると、v3は全く使うべきじゃないみたいだね…

└

OpenSSLがついに折れて、開発者がQUICサポートを実装するためのAPIを提供してくれたのはいいことだね - 昨年のことらしい。知らない人のために説明すると、OpenSSL 3.4.1までは、OpenSSLを使ってHTTP/3を実装したい場合、QUICを基盤プロトコルとして使うため、彼らのQUICスタック全体を使わなければならなかった。QUICの実装だけで、暗号化部分にだけOpenSSLを使うことはできなかった。QUICってのは、要するに「UDPの上にTCPの機能を再実装したらどうなるか、でも古いレガシーのクソは全部捨てられる」って感じ。複雑だけど面白い。ただ、OpenSSLの実装が自分の望むように動かなかったり、うまく動かなかったりしたら、我慢するか、他のSSLライブラリを使うしかなかった。だから、例えばcurlをOpenSSLに対してビルドして使ってたら、curlも自動的にOpenSSLのQUIC実装を使わざるを得なかったんだ。もっと良いものがあってもね。CurlのDaniel Stenbergがそのことについてすごく悪いし馬鹿げてるってブログ記事を書いてるから、興味があれば見てみて：https://daniel.haxx.se/blog/2026/01/17/more-http-3-focus-one...

OpenSSL 3に比べて、この移行はすごくスムーズだったよ。唯一の問題は「エンジン」の削除だけで、Fedoraではその依存関係のほとんどが変更されたみたい。

最近のOpenSSLはどうなの？ 以前の大騒ぎ、たしかHeartbleedだったよね？ みんなが恐怖に駆られて、OpenSSLを維持しているのは1人か2人だけだって気づいたやつ。OpenBSDの人たちが人手をかけて、古いバグを片付けてくれたって話だけど。今はもっとしっかりした体制になってるのかな？

└

まだまだひどいよ。Heartbleedの後、しばらくは急速に改善してたけど、OpenSSL 3はパフォーマンスや複雑さ、開発者体験（エルゴノミクス）を気にしてる人にとっては大きな失望だった。OpenSSL 3のコア操作は、OpenSSL 1.1.1よりもずっと遅いままだし。HAProxyの人たちがSSLスタックの状態についてすごく良いブログ記事を書いてるよ：https://www.haproxy.com/blog/state-of-ssl-stacks それに、Pythonの暗号化の人たちがさらに厳しい批判を書いてる：https://cryptography.io/en/latest/statements/state-of-openss... いくつかの興味深い引用を紹介するね：

OpenSSL 3.0では、ライブラリをもっとダイナミックにすることが重要な目標だったらしく、以前は定数だった要素（例えば、アルゴリズム識別子など）が動的になって、コンパイル時に固定されるのではなく、リストで参照しなければならなくなった。新しいデザインでは、誰でもランタイムでそのリストを更新できるから、一貫性を確保するためにリストにアクセスする際にロックが至る所に置かれている。 ありとあらゆることをやった後でも、OpenSSL 3.xのパフォーマンスはOpenSSL 1.1.1に比べてかなり劣っている。比率はワークロードに大きく依存するから予測が難しいけど、10%から99%の損失が報告されている。 OpenSSL 3はAPIを大幅に変更するプロセスを始めた — OSSL_PARAMを導入して、新しいAPIのすべてにそれを使っている（ポスト量子暗号アルゴリズム用のものも含む）。要するに、OSSL_PARAMは関数にキーとバリューのペアの配列を渡すことで動作するから、通常の引数渡しとは違う。これによりパフォーマンスが低下し、コンパイル時の検証が減り、冗長性が増し、コードが読みづらくなる。

└

Heartbleed以降、OpenSSLのセキュリティ面は大きく改善された。これはプロジェクトのメンテナンス慣行にとっての転機だった。OpenSSLが今やインターネットで最も活発に研究されているソフトウェアセキュリティのターゲットの一つになっているのも悪くない。逆に、OpenSSLのソフトウェア品質はHeartbleed以降、パラドックス的に後退したかもしれない。OpenSSL 3.0のデザインがパフォーマンスの面で大きな後退だったというのが大まかな合意で、複数の大きなプロジェクト（特にpyca/cryptography）がOpenSSLから完全に移行することを真剣に検討している。繰り返すけど、セキュリティの懸念はその移行の副次的な問題かもしれないが、核心の問題は今のOpenSSLが使いづらいってことなんだ。

pqサポートのために3.5xにアップデートしたばかりなんだけど、4.0にアップグレードする魅力的なものはある？

└

トップの機能「暗号化されたクライアントハロー（ECH, RFC 9849）のサポート」は、インターネットにアクセス可能なサーバーやクライアントを運営している人にとって非常に重要だね。あなたのPostgresサーバーがそんなのじゃないことを願ってるよ！

ああ、またABIの変更かよ…

constがもっと使われるようになってきて嬉しい。組み込み用のライブラリにそれを追加するのが多すぎるから。デフォルトでconstにしたいと思うけど、今は仕方ないよね。