要約

  • Finished は、合意した秘密を用いて現在のハンドシェイク transcript を検証する。再ネゴシエーション前のアプリケーションデータまで証明対象になるわけではない。
  • RFC 5746 は以前の client/server verify_data を新しいハンドシェイクに入れて前の接続へ結び付けた。主体変更、要求境界、認可、commit、外部結果には別の受領証が必要である。

新しい Finished が古いバッファに着地する

接続は既にアプリケーションデータを運んでいる。そこへ新しい ClientHello が入り、サーバーはクライアント証明書を要求し、新しい鍵を合意して Finished を検証する。TLS ライブラリの観点では成功である。

RFC 5246 の verify_data は master secret とハンドシェイクメッセージから計算される。双方が同じ交渉履歴と鍵状態を持つことを強く確かめるが、通常のアプリケーションデータは transcript に含まれない。

当初の再ネゴシエーションには、二度目のハンドシェイクを先行接続へ暗号学的に結ぶ値もなかった。仲介者がサーバーへ接続して要求の先頭を送り、その後へ別の利用者の認証済みハンドシェイクを継ぐと、サーバーが二つを一つの要求として解釈し得た。Finished は真でも、帰属させた会話が真とは限らなかった。

同じファイルディスクリプタは同じ権限ではない

TLS 1.2 は current state と pending state を分ける。ハンドシェイクで次の暗号状態を準備し、ChangeCipherSpec で有効化し、Finished で新状態を確認する。

この状態機械は、以後の record をどの鍵が守るかを決める。認証前に半分だけ届いた命令を、認証後の主体へ帰属させてよいかは決めない。socket が同じなのは転送容器の連続性であり、権限の連続性ではない。

パーサーのバッファは TLS 状態より長生きする。終端装置が最新の principal だけを上流へ渡すと、古いバイトが新しい身元を相続する。暗号処理の成功と認可の失敗が同時に成立する場所である。

前の Finished を持ち帰る修理

RFC 5746 は renegotiation_info と TLS_EMPTY_RENEGOTIATION_INFO_SCSV を導入した。初回ハンドシェイクでは空の renegotiated-connection 値で対応を示す。再ネゴシエーションでは、前回の client Finished と server Finished の verify_data を拡張へ入れる。

新しい交渉は、前の交渉が生成した値を知っていなければならない。端点が保持する接続と一致しなければ拒否できる。同じ socket に並んでいるという推測が、二つのハンドシェイクを結ぶ検証へ変わった。

ただし対応能力は実行結果ではない。ライブラリが拡張を理解しても、ポリシーが再ネゴシエーションを禁止する場合がある。SCSV を見ただけでは二度目の交渉も旧値比較も証明できない。実装、設定、信号、応答、実行、比較結果を別々に記録すべきである。

直った TLS の外に要求境界が残る

Secure Renegotiation はハンドシェイクを結ぶが、アプリケーションのメッセージを区切らない。匿名で始まった命令を、後から得た証明書主体で続行すべきか。破棄するのか、旧主体で完了するのか、新しい完全なメッセージを要求するのか。答えはローカルポリシーにある。

各要求には TLS security generation と principal を付ける必要がある。主体変更時にはバッファをどう扱うか明示する。Finished の成功を理由に、以前の断片へ新しい権限を遡及させてはならない。

RFC 5929 の channel binding も同様である。値を得られることと、上位プロトコルがそれを交換・検証・判断に使用したことは別の証拠である。

Extended Master Secret は別の関係を結ぶ

RFC 7627 の EMS は、ハンドシェイク transcript の hash から master secret を導出し、session hash や triple handshake の問題へ対処する。RFC 5746 の代替ではない。

EMS は秘密とそのハンドシェイクを結ぶ。Secure Renegotiation は新しいハンドシェイクと以前の接続を結ぶ。「TLS 強化済み」という一つのフラグにすると、どちらの関係が検証されたか分からなくなる。

監査は EMS、Secure Renegotiation の信号と実行、旧値、証明書経路、生成した principal を分離する。原因を追える粒度は、項目数を減らした見栄えより重要である。

TLS 1.3 が消した機能と、まだ残る実装

TLS 1.3 は再ネゴシエーションを廃止した。接続内で身元を切り替えるこの経路はなくなる。しかし TLS 1.3 対応は TLS 1.2 廃止の受領証ではない。クライアント側は 1.3、proxy の上流は 1.2 という構成もあり得る。

RFC 9851 による TLS 1.2 の機能凍結も、listener を停止しない。実際の移行には、接続点、読み込まれた設定、観測交渉、依存所有者、同一経路を通るサービス canary が必要である。

再ネゴシエーションが残る間は、初回 Finished、世代ごとのバイト範囲、開始契機、RFC 5746 信号、旧値照合、新しい身元、状態切替、新 Finished、principal mapping、要求境界、認可、commit、外部結果を一つの台帳で関連付ける。

これは BTW の運用分析であって RFC 5246 のログ要件ではない。強い受領証ほど、その証明範囲を越えて使わないことが重要になる。

情報源