要約

  • 旧来のTLSでは、既存接続上の再ネゴシエーションと、その前のハンドシェイクとの間に暗号学的な結合がなかった。
  • RFC 5746は、初回ハンドシェイク時の対応通知と、前回ハンドシェイクの検証データを用いる結合を導入した。TLS 1.3は再ネゴシエーションを廃止したが、全ての旧来経路が消えたことを示すものではない。

問題は「別のハンドシェイク」が同じ接続に入れることだった

RFC 5246は、既存のTLS接続上で再ネゴシエーションを行うTLS 1.2を定義した。後続のRFC 5746が扱った問題は、同じトランスポート接続上の前後のハンドシェイクが、暗号学的に結び付けられていなかったことである。RFC 5246 RFC 5746

攻撃の流れは、任意の通信を復号するというものではない。まず攻撃者がサーバーとのTLS接続を確立する。次に、対象となるアプリケーションプロトコルの先頭に置かれるデータを送る。その後、被害者のハンドシェイクを、攻撃者が確立した接続上の再ネゴシエーションとしてサーバーに中継する。サーバーが新しいハンドシェイクで被害者を認証しても、攻撃者が先に置いたバイト列が同じアプリケーションストリームの前部に残る可能性がある。RFC 5746 RFC 7457

この影響は、アプリケーションプロトコルがその先頭部分をどう解釈するかによって決まる。RFC 7457が記録したのは、境界を越えた限定的なプレフィックス注入であって、攻撃者が被害者の暗号化通信を復号できることでも、後続の全バイトを自由に書き換えられることでもない。RFC 7457

RFC 5746は通知と結合を分けて修復した

RFC 5746の修復には、役割の異なる二つの要素がある。初回ハンドシェイクでは、renegotiation_info拡張またはTLS_EMPTY_RENEGOTIATION_INFO_SCSVによって、安全な再ネゴシエーションを実装できることを通知する。再ネゴシエーションでは、前回ハンドシェイクのFinished検証データを持ち込み、新しいハンドシェイクがどの接続に属するかを暗号学的に結び付ける。RFC 5746

この区別は運用上重要である。対応機能が存在するという通知は、特定の経路が実際に安全な結合を検証していることと同じではない。RFC 7525は旧バージョンのTLSについて安全な再ネゴシエーションの扱いを運用上の推奨に組み込み、後のRFC 9325もTLS 1.3と旧バージョンをまたぐ安全な利用の指針を維持した。RFC 7525 RFC 9325

TLS 1.3は機能を運ぶのではなく、再ネゴシエーションをなくした

RFC 8446で定義されたTLS 1.3には、TLS 1.2型の再ネゴシエーションがない。TLS 1.3は、KeyUpdateやポストハンドシェイク認証のような、より限定された目的の仕組みを残している。RFC 8446 RFC 9325も、TLS 1.3が再ネゴシエーションを廃止したことを確認しつつ、旧バージョンに対する管理を扱っている。RFC 9325

したがって、TLS 1.3の仕様上の安全性と、あるサービスの全経路がTLS 1.3だけで動いているという主張は別である。公開エンドポイントがTLS 1.3を使っていても、内部サービス間のホップ、TLS終端装置、ライブラリ、製品設定、アプリケーション経路に旧来の挙動が残っている可能性は、これらのRFCだけからは判断できない。

仕様公開から展開証拠へ

この修復で、責任の所在も分かれる。IETFの標準化プロセスは、ワイヤ上の結合、通知、移行時の挙動を定義する。実装者は拡張を実装し、検証を強制し、安全なポリシー選択肢を提供する。サービス運用者は、配備済みコンポーネントを更新し、旧来の再ネゴシエーションを許容するか、制限するか、拒否するかを決める。アプリケーション所有者は、注入されたプレフィックスが認可やリクエスト解釈に影響するかを確認する。

この資料群が示すのは、プロトコルの仕組みと推奨である。RFCは、RFC 5746の実装が世界中で完了したこと、名前のある事業者の現在の設定、脆弱な挙動の完全な廃止を証明しない。修復の耐久性を示すには、公開エンドポイント、内部ホップ、ライブラリまたは製品、終端装置、アプリケーション経路を別々に調べ、例外の所有者と期限、廃止の証拠を記録する必要がある。

結論は限定的だが明確である。RFC 5746は、同じ接続上のハンドシェイクを結び付ける欠落した暗号境界を修復した。TLS 1.3はその再ネゴシエーションという設計上の入口を取り除いた。しかし、仕様の公開日は、現場の修復完了日ではない。未解決の問いは、旧来の経路が実際に消えたことを、どの観測可能な証拠が示すのかである。