要約

  • RFC 9850 の label client_random secret は、TLS がテストデータだけを守る環境向けの三フィールド形式である。Informational RFC であり、実運用システムでは使ってはならない。
  • TLS 1.2 の master secret、TLS 1.3 の方向別 traffic secret、exporter、ECH の secret は権限半径が異なる。単一の「デバッグ鍵」という扱いは危険である。
  • 解析成功は構文上の事実にすぎない。対象ワークロード、有効化者、利用者、パケットとの対応、転送、保存、保持、破棄、未記録状態への復帰には別々の記録が要る。

暗号化通信を診断ツールから読めるようにした瞬間、運用上の主体が増える。TLS の計算が壊れたのではない。エンドポイントが保護を外せる材料を別のプログラムへ渡したのである。RFC 9850 はこの受け渡しを相互運用可能にした。受け渡しを正当化したわけではない。

適用範囲は明確だ。2026年7月に Informational として公開され、Internet Standards Track の仕様ではない。対象は TLS がテストデータのみを保護するシステムで、実運用にこの仕組みを使ってはならない。コンパイルされるソフトウェアでは、配備済みバイナリが後から鍵ログを有効化できないよう、条件付きコンパイルを使うのが最善だとする。これは本番診断の推奨に注意書きを付けた文書ではない。

通常の行は一つの空白で区切る三値からなる。label が材料の種類を示す。client_random は接続を確立した ClientHello の32バイト Randomを64桁の16進表現にし、複数接続を区別する。secret は label に応じた長さの16進値である。ツールは CRLF、CR、LF と16進文字の大小双方を受け入れる。壊れたファイルから利用可能な secret を回収するため、不正な行を無視してよい。

この寛容さは parser の役割を示す。parser は「値を取り出せた」とは言えるが、「収集は承認された」とは言えない。三フィールドには承認者、環境、ワークロード、生成プロセス、チケット、利用者、期限、削除結果がない。ファイルの完全性や保持期間内であることも証明しない。読める形式は、保有者に権限を発生させない。

client_random だけでパケットとの対応も完成しない。RFC 9850 は cipher suite などの接続パラメータが記録されず、secret の利用に handshake 記録が必要な場合があると述べる。packet capture と key log は、同じ案件、時間窓、テスト対象へ明示的に結び付ける必要がある。同じフォルダに置くことは、同じ許可から生じた証明ではない。

TLS 1.3 では label が段階と方向を分ける。client early traffic、両側の handshake traffic、両側の application traffic、exporter は同じ権能ではない。一方向の handshake を読む必要から、全方向・全段階を集める権限を推論してはならない。最小化の単位はファイル容量ではなく label である。

TLS 1.2 の CLIENT_RANDOM は master secret を示し、典型的な TLS 1.3 traffic secret より広い。RFC 9850 によれば、メッセージの読み書きに加え、接続の再開、両端の偽装、再ネゴシエーションを起こす record の挿入、Finished の偽造まで可能になり得る。実装はこの値を記録しないことでリスクを避けられる。方向限定の TLS 1.3 secret と同じ箱に入れるべきではない。

Exporter はアプリケーション側へ半径を広げる。TLS exporter や early exporter は session binding、authentication、その他の派生 secret に使われ得る。そのため RFC 9850 は、悪用され得る文脈では省略するか、記録に別の承認を要求する選択肢を示す。packet を読む担当者が、アプリケーション認証材料まで当然に保有できるわけではない。

ECH は隠された名前の面を持つ。ECH_SECRET は Inner ClientHello を保護する HPKE KEM shared secret で、ECH_CONFIG は構成情報である。ECH_SECRET の取得により Inner ClientHello と SNI が明らかになり得る。ECH 成功時、通常の TLS 1.3 labels は Inner ClientHello Random に結び付く一方、ECH labels は常に Outer Random を使う。単なる「接続ID」では、この内外の意味を失う。

能力は受動的な閲覧に限られない。導出される record key は対称鍵なので、活動中の接続に対して暗号化し、アプリケーションデータを注入・変更できる場合がある。また鍵材料を記録した接続では forward secrecy の保証が成立しない。後からログを得た者が、保存済み record を復号できるためである。影響する接続集合を正確に限定しなければならない。

承認は最初の行より前に始まる。SSLKEYLOGFILE のような環境変数は、アプリケーションの起動コンテキストへのアクセスを有効化能力にする。特殊ファイルへの出力は永続保存を避けられても、別プログラムという消費者を残す。有効化記録には、テスト対象、build または process、許可 label、承認者、開始・終了を含めるべきだ。技術的アクセス可能性は組織的委任ではない。

生成後は保管の連鎖になる。利用者の役割とアクセス方式、転送の送受信者・完全性・保護・期限、保存先の権限と保持期限、capture と secret の共通案件番号が必要だ。ただし capture の全読者へ secret も配る理由にはならない。

パスを一つ消しても閉鎖は証明できない。解析ツール、一時領域、添付、バックアップ、プロセスメモリに複製があり得る。常に存在すると断定するのではなく、候補となる保管点を列挙し処分を記録する。logging 無効化、生成元の停止、消費者の退出、既知コピーの破棄、転送期限切れ、capture 終了を結合して teardown とする。

既に記録された接続の forward secrecy は遡って戻らない。回復を主張できる新しい境界は、以後の接続が新鮮で未記録の材料を使い、生成面が停止し、secret を出さずにアプリケーションが動くことを観測した時点にある。IANA registry は label の共通語彙を保つ。共通語彙は有益だが、利用許可や権限消滅の代わりにはならない。

情報源