OpenSSL 4.1.0がもたらすDTLS 1.3とGREASE：アップグレード前に検証すべきこと

OpenSSLの新しいリリースは、一見すると単なるライブラリの置き換えのように思えるかもしれません。しかしOpenSSL 4.1.0はそれ以上の注意を払う価値があります。目玉機能であるDTLS 1.3には、ネットワークで問題が発生したときにのみ表面化する4つの既知の問題が存在するためです。

2026年11月2日現在、OpenSSL 4.1.0は、インターネットの暗号化接続の大部分を保護するツールキットの最新機能リリースです。DTLS 1.3、GREASE、高速化された耐量子およびAESコードパス、そしていくつかのビルド変更が追加されています。OpenSSLを使用してソフトウェアを出荷している開発チームにとって、現時点での課題は極めて実用的なものです。すなわち、この新リリースは採用する価値があるのか、そして文書化された制限事項がある中でアプリケーションは正しく動作するのか、という点です。

DTLS 1.3の概要をわかりやすく解説

暗号化されたWebトラフィックの大部分は、TCP上で動作するTLSを使用しています。TCPは信頼性の高いトランスポートであり、失われたパケットを再送し、順序通りに配信します。

DTLS（Datagram Transport Layer Security）は、そのような保証を一切行わないトランスポートであるUDP上で同様の保護機能を提供します。パケットは遅れて到着したり、順不同で届いたり、まったく届かないこともあります。ビデオ通話、VPN、ゲームのトラフィック、多くのIoTデバイスは、その高速性からUDPに依存しており、プライバシーを保護するためにDTLSが使用されています。

DTLS 1.3はRFC 9147で定義されており、TLS 1.3をベースに構築されています。UDPのデータグラム動作を維持しながら、盗聴、改ざん、メッセージの偽造から保護します。仕様では、保証内容がTLSと異なる点、特に順序保証やリプレイ保護の違いについて慎重に言及されています。そのため、アプリケーション側で対処しなければならない点も残されています。

重要な教訓として、クリーンな実験用ネットワークで機能するDTLS接続は、ほとんど何の証明にもなりません。パケット損失、応答の遅延、再送、そして対向側にある異なる実装との通信こそが、真に対処が難しいケースです。

4つの既知のDTLSの問題

リリースノートには4つの既知の問題が記載されています。これらは接続の動作や信頼性に影響を与えます。アナウンスではこれらを重大な脆弱性とは位置づけておらず、活発な悪用も報告されていません。それでも、それぞれがそのままテストケースとして活用できます。

キー更新によってセッションチケットの再送が停止する可能性（Issue #32878）

DTLS 1.3のハンドシェイク後、サーバーはセッションチケットを送信する場合があります。これにより、クライアントは後で迅速に再接続できるようになります。キー更新が発生した時点でピアがまだそれらのチケットを確認応答（ACK）していない場合、OpenSSLはそれらをクリアし、再送タイマーを停止してしまうことがあります。

キー更新は個別のやり取りです。チケットが届いたことを証明するものではありません。チケットが失われた場合、二度と再送されない可能性があります。Issueレポートには、確認応答なしにチケットが削除される様子を示す再現コードが含まれています。

恒久的な受信エラーが一時的なエラーに見える可能性（Issue #33277）

OpenSSLのDTLSリスナーを通じて作成された接続では、恒久的な受信エラーが SSL_ERROR_WANT_READとして報告されることがあります。通常、このコードは「データがまだありません。再試行してください」を意味します。これを信じたアプリケーションは、切断された接続に対して永久に待機し続ける可能性があります。ポーリングやその後のaccept呼び出しによっても、失敗した状態が隠れてしまうことがあります。

再現コードにはDTLS 1.2も含まれているため、これはDTLS 1.3のユーザーだけでなく、リスナーを使用するすべての人に関係します。

一時的な書き込みエラーが致命的なエラーに見える可能性（Issue #33278）

これはその裏返しの問題です。リスナーを通じて受け入れられたノンブロッキング接続において、単に再試行すべき書き込みが SSL_ERROR_SYSCALL を返し、本来の SSL_ERROR_WANT_WRITEとはならないことがあります。これを致命的として扱うアプリケーションは、まだ正常な接続を閉じてしまう可能性があります。

報告によると、別のAPIパスで構築されたDTLSサーバーは正しい再試行コードを返しました。この問題はリスナーベースの接続に関連しており、DTLS 1.3に限定されません。

有効な確認応答によってハンドシェイクが中断される可能性（Issue #33242）

クライアントがサーバーの最初のハンドシェイクメッセージ群の一部のみを受信した場合、到着したレコードに対して確認応答（ACK）を送信することがあります。サーバーとしてのOpenSSL 4.1.0は、その確認応答に対して unexpected_message アラートで応答し、ハンドシェイクを終了してしまうことがあります。

ここに落とし穴があります。OpenSSLクライアントがこれらの確認応答を処理する方法のため、OpenSSL同士のテストではこの問題は発生しません。そのため、社内テストをすべてパスしたシステムであっても、パケット損失のあるネットワーク上で別のクライアントライブラリを使用すると失敗する可能性があります。

GREASE：プロトコルの柔軟性を維持する

GREASEは「Generate Random Extensions And Sustain Extensibility」（ランダムな拡張を生成して拡張性を維持する）の略であり、RFC 8701で説明されています。

TLSでは、双方が自身がサポートしている内容を通知し、相手側が理解できるオプションを選択します。これが機能するのは、ソフトウェアが認識できない値を無視する場合に限られます。一部の実装では未知の値を拒否してしまい、その結果、将来プロトコルに新しい機能を追加することが困難になります。

GREASEは意図的に予約された無意味な値を送信します。正しいピアはそれらを無視します。問題のあるピアは、何年も後に実際の新しい拡張機能がその許容性に依存したときではなく、テストの段階で早期に失敗します。運用担当者にとって重要なのは、長期的な互換性です。エンドポイント、ロードバランサー、トラフィック検査機器、特に古い機器がこれに対応できるか確認してください。

暗号処理の高速化とビルドの変更点

本リリースには、以下のようなパフォーマンス向上の取り組みも含まれています：

• ppc64leにおけるML-DSAおよびML-KEMの最適化（これらは耐量子署名および鍵交換アルゴリズムです）。
• AVX-512で高速化されたSHAKEを含む、x86_64におけるML-DSAの改善。
• AES-CBC復号におけるAVX-512およびVAESの最適化。
• 新しいIKEv2鍵導出関数と、Elbrus2000アーキテクチャの初期サポート。

注目すべきビルドの変更点：

• 新しいMSVC 2013ターゲットの追加。
• Windows-on-ItaniumおよびWindows CEターゲットの削除。
• オプション no-ecdsa および no-ecdh が削除されました。プロジェクトの説明によると、これらのオプションは実際にはそれらの実装を無効化していませんでした。楕円曲線暗号のサポートを無効化するには、次を使用してください： no-ec.
• ユーティリティ tsget は、以下に依存するようになりました： Net::Curl::Easy.

プリミティブの高速化が、必ずしもアプリケーション全体の高速化を意味するわけではありません。マイクロベンチマークだけでなく、現実的な接続パターンとワークロードで測定してください。

サポート期間が判断の基準となる

OpenSSLプロジェクトは、以下のアップストリームサポート期間を提示しています：

シリーズ	サポート期限
OpenSSL 4.1	2027年11月
OpenSSL 4.0	2027年5月14日
OpenSSL 3.6	2026年11月1日
OpenSSL 3.5 LTS	2030年4月8日

このように、最新リリースの保守期間は3.5 LTSよりもはるかに短くなっています。なお、3.6のサポートはちょうど今頃終了することに注意してください。また、パッケージ化されたOpenSSLはアップストリームではなくベンダーのスケジュールに従うことが多いため、OSや製品ベンダーがサポートする期間も確認してください。

OpenSSL 4.1.0を安全に評価する方法

ステップ1：本当に必要かどうかを判断する

DTLS 1.3を使用するアプリケーション、DTLSリスナーを使用するアプリケーション、および長期的なサポートが必要なアプリケーションをリストアップします。新機能が必要ない場合は、3.5 LTSを使い続けるのが賢明な選択です。

ステップ2：テスト対象のビルドを確認する

本番環境に直接導入することは絶対に避け、隔離された環境でテストビルドを実行し、そのバージョンとビルドオプションを確認します：

openssl version -a

ステップ3：クリーンなネットワークだけでなく、パケット損失環境下でもテストする

Linuxテストマシンでは、ループバックインターフェースに次のツールで意図的なパケット損失や遅延を追加できます： netem。これに対してDTLSクライアントとサーバーを実行し、テスト後にルールを削除します：

sudo tc qdisc add dev lo root netem loss 5% delay 50ms
# run your DTLS client/server tests here
sudo tc qdisc del dev lo root

初回の接続だけでなく、ハンドシェイク後の動作（セッションチケット、キー更新）も注意深く監視してください。

ステップ4：他の実装と接続テストを行う

Issue #33242はOpenSSL同士のテストでは発生しないため、パケット損失環境下で少なくとも1つの非OpenSSL DTLSクライアントをサーバーに接続してテストしてください。

ステップ5：エラー処理を確認する

DTLSリスナーを使用している場合は、コードが次のようなエラーにどう反応するか確認してください： SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE および SSL_ERROR_SYSCALL。成功しない「再試行」によって接続が永久にハングアップしないよう、タイムアウトを追加してください。

ステップ6：実際の条件でベンチマークを実施し再ビルドする

実機環境で実際のワークロードを用いてベンチマークを実施します。ビルドパイプラインを再実行し、オプション（ no-ec ）が期待通りの構成を生成していることを確認してください。

まとめ

OpenSSL 4.1.0は意義のある機能リリースです。DTLS 1.3とGREASEはデータグラムのセキュリティと将来の互換性を強化し、新たな最適化によりサポート対象ハードウェア上での耐量子計算およびAES処理が高速化される可能性があります。しかし、採用にあたっては単に新しいライブラリを導入してアプリが起動することを確認するだけでは不十分です。4つの既知のDTLS問題は具体的なテストケースを提供しており、サポート期間は短く、真の検証は相互運用性、障害復旧、およびワークロードのテストを通じて行われます。

メリット

• DTLS 1.3により、UDPトラフィックにTLS 1.3世代の保護機能がもたらされます。
• GREASEにより、将来の拡張機能を破損させる前に、脆弱なピアを早期に検出できます。
• サポートされているCPUにおけるML-DSA、ML-KEM、AES-CBCコードパスの高速化。
• よりクリーンなビルドオプション：誤解を招く no-ecdsa および no-ecdh フラグが削除されました。
• 既知の問題は、再現コードとともにオープンに文書化されています。

デメリット

• サポートが2027年11月に終了し、3.5 LTSよりもはるかに早期です。
• 4つの既知のDTLS問題が、再送、エラー報告、ハンドシェイクに影響を与えます。
• リスナーに関する2つの問題は、DTLS 1.2のユーザーにも影響します。
• ビルドの変更により、既存のスクリプトやビルドターゲットが破損する可能性があります。
• パフォーマンスの向上は特定のハードウェアに依存し、アプリケーション層にまで及ばない可能性があります。

注意事項

本記事は教育目的で作成されており、公開されているOpenSSL 4.1.0リリース情報を要約したものです。公式のOpenSSLドキュメントではありません。記載されているコマンドは隔離されたテストマシン向けの例であり、ご自身の環境、インターフェース名、テストプログラムに合わせて調整する必要があります。問題の詳細やサポート期間は変更される可能性があるため、信頼する前に公式のOpenSSLリリースノート、イシュートラッカー、およびベンダーのアドバイザリで各項目を必ず確認してください。

よくある質問（FAQ）

• OpenSSL 4.1.0の新機能は何ですか？ — DTLS 1.3、GREASE、ML-DSA、ML-KEM、AES-CBCの最適化、IKEv2鍵導出関数、およびいくつかのビルド変更が追加されています。
• DTLS 1.3とは何ですか？ — RFC 9147で定義されているTLS 1.3のデータグラム版であり、UDP経由のトラフィックを暗号化して保護します。
• 4つのDTLSの既知の問題はセキュリティ上の脆弱性ですか？ — アナウンスでは、これらは重大な脆弱性ではなく接続動作および信頼性の問題と説明されており、活発な悪用も報告されていません。
• 既知の問題はDTLS 1.2にも影響しますか？ — はい、リスナーのエラー報告に関する2つの問題（#33277および#33278）はDTLS 1.3に限定されません。
• TLSにおいてGREASEは何をしますか？ — 未知の拡張機能を誤って拒否するピアを早期に発見できるよう、予約されたランダムな値を送信することで、プロトコルの拡張性を維持します。
• OpenSSL 4.1のサポート期間はどのくらいですか？ — アップストリームのサポートは2027年11月までですが、OpenSSL 3.5 LTSは2030年4月8日までサポートされます。
• OpenSSL 3.5 LTSから4.1にアップグレードすべきですか？ — 新機能が必要であり、十分なテストを実施できる場合にのみアップグレードしてください。それ以外の場合は、3.5 LTSの方がはるかに長いサポート期間を提供します。
• OpenSSLビルドで楕円曲線暗号のサポートを無効にするにはどうすればよいですか？ — オプション no-ec を使用してください。削除された no-ecdsa および no-ecdh オプションは、実際にはそれらの実装を無効化していませんでした。

タグ

#OpenSSL #DTLS13 #TLS #Cryptography #PostQuantum #NetworkSecurity #CyberSecurity #DevSecOps #UDP #InfoSec