Rustls 0.23.45、2024年からのTLS 1.3不具合を修正

0.23.13から0.23.44までのバージョンが、誤った暗号化レベルのTLS 1.3ハンドシェイク（接続確立のやり取り）メッセージを受け入れていました。原因は2024年9月に入った不具合です。

著者 Claire Whitmore

2026年9月14日3 分で読めます

X LinkedIn はてなブックマーク

英語の原文から機械翻訳したものです。原文はClaire Whitmoreが事実確認と編集を行いました。内容に相違がある場合は英語版が優先されます。編集方針

他の言語で読む:原文（英語）Deutsch日本語Français Español Português

握手を交わす2本のロボットの手を描いた線画。片方の手首に、開いた小さな赤い錠が下がっている。

数字で見る

the Rustls release that contains the fix: 0.23.45
the oldest affected version, from September 2024: 0.23.13
the bug sat in released code before the fix: 2 years

Rustls 0.23.45が2026年9月14日に公開され、公開済みのコードに約2年入っていたTLS 1.3ハンドシェイクの不具合が修正されました。0.23.13から0.23.44までのすべてのバージョンが影響を受けます。Rustlsに依存しているなら、自分のビルドが実際にどのバージョンを解決しているか確認してください。Phoronixが公開を報じ、プロジェクトは詳細を勧告GHSA-2mjx-qc3c-rqvcとして登録しました。

RustlsはRustで書かれたTLSライブラリです。TLSはHTTPSの土台にあるプロトコルで、TLSライブラリはプログラムが暗号化接続を確立するために使うものです。OpenSSLを避けたいRust製のサービスでは、Rustlsがよく選ばれます。

この不具合で何が起きるか

TLS 1.3のハンドシェイクの途中で、双方が鍵を切り替えます。その切り替え以降のメッセージは新しい鍵で暗号化されているべきです。Rustlsはそれを常に強制していませんでした。

勧告は条件を具体的に述べています。同じレコードの中で鍵を切り替えるメッセージに続く場合、Rustlsは誤った暗号化レベルのハンドシェイクメッセージを受け入れていました。レコードとはプロトコルが実際に回線へ載せるまとまりで、複数のハンドシェイクメッセージが一緒に流れることがあります。

正直に読めば、最初の印象より範囲は狭いです。「ハンドシェイクの記録（トランスクリプト）は依然として認証されている」と告知は述べています。つまり、通信経路上の攻撃者がこれを使ってハンドシェイクを改変したり、本来成立しないハンドシェイクを成立させたりはできません。実際の影響は、プロトコルが暗号化を要求する内容を相手が平文で送っても、Rustlsが接続を拒否しなかったことです。

したがってこれは厳密さの不具合であり、認証の破れではありません。それでも重要です。仕様が禁じるメッセージを受け入れるライブラリは、その挙動がRFC 8446から外れています。そして、その外れこそが相互運用の不具合や後の攻撃の出どころになります。

メモリ安全性は仕事の全部ではなかった

Phoronixは有用な結論を引き出しており、それは明確に述べる価値があります。Rustlsが存在する理由の一つは、メモリ安全でないTLSコードに深刻な不具合の長い歴史があることで、Rustはその種類の欠陥を取り除きます。今回の不具合はその種類ではありません。

プロトコルの状態機械が、拒否すべきメッセージを受け入れることを、Rustは何も防ぎません。これは論理の誤りであり、論理の誤りはどの言語を選んでも生き残ります。安全な言語での書き直しが買えるのは、バッファオーバーフローや解放後利用からの自由であって、仕様の読み違いからの自由ではありません。

当サイトは同じ点を逆側から示しています。Rustのパッケージがarrayrefへのビルド時サプライチェーン攻撃の運び手になりました。言語は防御の一層であり、一層にすぎません。

確認すべきバージョン

バージョン	状態
0.23.13 から 0.23.44	影響あり
0.23.45	修正済み
0.23.13 より前	勧告によれば、不具合を入れた変更より前

不具合が入ったのは2024年9月です。だから影響範囲は最初からではなく0.23.13から始まります。この問題はGO-2026-4340としても追跡されています。

開発者にとっての意味

更新し、そのうえで自分が実際に何を動かしていたかを確かめてください。これは別々の作業で、省かれるのは後者です。

cargo update -p rustlsを実行し、0.23.45以降に到達したか確認します。次にcargo tree -i rustlsを実行し、何が引き込んでいるかを見ます。Rustlsはたいてい間接的な依存で、HTTPクライアントやサーバーのフレームワーク経由で入ってきます。つまり手に入るバージョンは、それらのクレートが許す範囲で決まります。自分が管理していないライブラリの推移的な固定は、更新したのに何も変わらないように見える典型的な原因です。

サービスではなくバイナリを配布しているなら、今日の手元のものではなく、実際にビルドに使ったロックファイルを確認してください。cargo auditをCIに組み込むのは、この不具合が自分に関係するかどうかとは別に価値があり、データベースに載れば勧告を知らせてくれます。

ただし、この件で午後を障害対応に費やす必要はありません。どちらの情報源にも悪用の証拠はなく、勧告自身が記録は認証されたままだと述べており、最悪の読みは否定されています。緊急事態ではなく、期限のある通常の依存関係の更新として扱ってください。

より広い教訓は、静かなプロトコルの不具合がどれだけ長く生きられるかです。今回のものは出荷済みのリリースに2年とどまりました。しかも安全性のために選ばれるライブラリの中でのことで、見つけたのは事故ではなくレビューでした。それは仕組みが働いた証です。同時に、「Rustで書かれている」とは不具合の一区分についての主張であって、それ以上ではないという念押しでもあります。