要約

  • RFC 9850のSSLKEYLOGFILEは、秘密値のラベル、ClientHelloのランダム値、秘密値という3項目を1行に記録する。キャプチャとハンドシェイクの文脈があればTLS保護を外せるが、行そのものには時刻、エンドポイントの本人性、許可、来歴、保全経路がない。
  • 影響は閲覧にとどまらない。保存トラフィックの復号、稼働中の接続への注入、exporterを使うアプリケーションの侵害、前方秘匿性の喪失が起こり得る。TLS 1.2のマスターシークレットとECHの秘密値はさらに別の危険を持つ。
  • RFCはTLSがテストデータだけを守るシステムに用途を限定し、本番環境での使用を禁止する。復号成功が示すのは秘密値とレコードの技術的対応であり、誰が通信したか、なぜ記録したか、取得が適法だったかではない。

「復号済み」は調査の終点ではない

パケットキャプチャに鍵ログを読み込ませると、暗号化されたレコードがアプリケーションデータへ変わる。結果が再現でき、認証タグも整合するなら、分析には強い根拠がある。ただし、その根拠が答える主語は狭い。

正確には、特定の秘密値、キャプチャ、プロトコル解釈を組み合わせると、特定のレコードを認証・復号できた、と言える。そこから自然人、所有端末、操作意図、業務上の結果へ進むには、別の証跡が要る。

キャプチャにはインターフェース、方向、フィルター、時刻源、欠落率、ハッシュが必要である。鍵ファイルには生成プロセス、バイナリ、起動条件、権限、回収時刻、保管場所、移管履歴が要る。資産台帳の名前が当時のプロセス制御を示すとは限らず、ネットワーク上のエンドポイントが利用者本人を示すとも限らない。分析ツールにも版と設定がある。

秘密値がバイト列を開いたという事実は、これらを自動的に生成しない。強い暗号能力ほど、証拠の主語を丁寧に限定する必要がある。

既存の慣行を共同で記述したRFC

RFC 9850 The SSLKEYLOGFILE Format for TLS は2026年7月に情報提供RFCとして公開された。著者はMartin Thomson、Yaroslav Rosomakho、Hannes Tschofenigである。謝辞には、この形式がNetwork Security Servicesプロジェクトで生まれ、TLSの変化とともに多くの人によって育てられたとある。3人は利用されてきた形式を文書化し、ECH向けの要素を加えた。

2026年9月1日に保存したIETF Datatrackerの人物情報は、ThomsonをMozillaのエンジニアとし、公開された本人情報に45件のRFCと、その時点のHPKE、SPICE、IETF-W3C、レビュー関連の役割を結び付けていた。これは継続的なプロトコル活動の証拠である。単独発明、各製品の検証、導入現場の支配、調査の許可を示すものではない。

IANAはTLS SSLKEYLOGFILE Labelsレジストリーを管理する。共通のラベルがあるから、生成側と解析ツールは同じ秘密値を同じ意味で扱える。一方、RFCは指定専門家によるラベル承認を推奨やお墨付きと解釈してはならないと明記する。登録は互換性を作るが、使用許可を作らない。

3値の外側にあるもの

labelは秘密値の種類を示す。client_randomはClientHelloの32バイトのRandomで、1つのファイルに複数の接続があるときの照合に使える。secretは該当する秘密値である。

次の判断は、この項目定義から導く構造上の推論であり、RFCの直接引用ではない。必須項目にはタイムスタンプ、ホスト名、IPアドレス、ポート、証明書チェーン、プロセスID、利用者、機能の有効化を許可した記録、ファイルのアクセス履歴、キャプチャ参照、保全の連鎖がない。ClientHelloのランダム値は相関キーであって、人の本人性でも資産の所有証明でもない。

RFC自身も技術的な不足を1つ明示する。秘密値には暗号スイートや他の接続パラメーターが付かないため、利用にはTLSハンドシェイクの記録が必要な場合がある。鍵ログは単独で完結する復号報告ではなく、別の観測と組み合わせる入力である。

構文上正しい行をコピーすることも、別の文脈で生成することもできる。だから本物の鍵ログに価値がないのではない。信用の根拠を構文から取得手順、ハッシュ、時刻、相互確認へ移すべきだという意味である。

読む鍵は、書く鍵にもなる

証拠能力を狭く読んでも、安全保障上の影響は小さくならない。RFC 9850によれば、ファイルの内容へアクセスできる者は、対象となる稼働中の接続と保存済み暗号化レコードの機密性および完全性を破れる。

導出鍵は対称鍵である。レコード保護を外せる材料から、稼働中の接続向けのデータを暗号化できる場合があり、アプリケーションデータの注入や改変につながる。したがって調査では、元から取得されていたレコードと、能動的な試験が作ったレコードを区別しなければならない。

Exporterの秘密値はパケット本文より上の層へ影響する。アプリケーションがセッションの結び付け、認証、追加の秘密値の導出にexporterを使っていれば、漏えいはアプリケーション固有の信頼関係を攻撃できる。

前方秘匿性も、対象の鍵素材を記録した時点で成立しない。将来、長期鍵が失われても過去のセッションを守るという性質とは別に、トラフィック秘密値そのものが保管庫へ入る。保存済みキャプチャは後日開ける。

危険度はラベルごとに違う。TLS 1.3はハンドシェイク、アプリケーション、early data、exporterを分ける。TLS 1.2のCLIENT_RANDOMはマスターシークレットであり、RFCは読み書きに加えてセッション再開、双方へのなりすまし、再ネゴシエーション・レコードの挿入、Finishedの偽造を挙げる。ECH_SECRETはInner ClientHelloとそのSNIを露出させ得る。「鍵ログあり」という1項目だけではインシデントの範囲を誤る。

本番環境での禁止は権限設定より手前にある

RFC 9850の適用範囲は、通常の可観測性との引き換え条件を提示していない。TLSがテストデータだけを守るシステムを対象とし、この仕組みを本番環境で使ってはならないとする。コンパイル済みソフトウェアでは条件付きコンパイルを使い、配備したバイナリから有効化できないようにすることを推奨する。

これは制御点をビルドとリリースへ移す。本番用バイナリに機能がなければ、環境変数、誤った運用手順、侵害された起動プログラムも有効化できない。実験環境ではファイル権限と削除が必要だが、本番環境で禁止された能力を残す理由にはならない。

「一時的なデバッグ」は永続化しやすい。ディレクトリーが残り、収集器につながり、バックアップへ入り、別目的で保管されたキャプチャと後から出会う。問題は今日誰がファイルを読めるかだけではない。なぜ稼働中のバイナリが作成できたのかである。

本番環境で発見した場合は、設定不備ではなく封じ込めを要する事案として扱う。生成バイナリと起動時の文脈を特定し、新規出力を止め、ファイルとキャプチャを隔離し、影響する接続を絞り、exporterやECHへの波及を確認する。チケットやチャットへ秘密値を貼る行為は証拠保全ではなく二次拡散である。

ハンドシェイクの認証は別の証跡

RFC 9846はTLS 1.3のハンドシェイクを、パラメーターの交渉、選択した方式による相手の認証、共有鍵素材の確立として説明する。クライアント認証は必須ではなく、証明書やTLS認証の意味はアプリケーションプロトコルがさらに定義する。

鍵ログは鍵スケジュールから一部の値を外へ出す。証明書検証を再実行せず、アプリケーションが期待した参照先の本人性を記録せず、クライアント認証の有無も人の本人性も保証しない。ハンドシェイクのキャプチャに証明書があっても、検証結果と期待名とアプリケーション方針は別に残す必要がある。

復号失敗も狭く読むべきである。別の接続、ハンドシェイクの欠落、鍵更新、方向違い、ECHのInner/Outerランダム値、統合されたプロトコルの追加文脈が原因になり得る。「開かなかった」は「偽物だった」と同義ではない。

RFC 9325は認証、機密性、データ完全性を別々の配備目標として扱う。デバッグ用の成果物が後者2つを外せるからといって、前者の証明書にはならない。

記録は現実を記述しても、現実を作らない

Heng LuのThe Policy Mirrorは、記録が現実を記述しても作り出さないという境界を示す。Running-Code Primacyは共有成果物を稼働システムに必要な決定論的機能へ限定する。On Reality Layersは実行できる力と象徴的な主張を分ける。

SSLKEYLOGFILEの実行力は大きい。正しい秘密値とレコードを合わせれば、保護されたトラフィックを読み、場合によっては変えられる。象徴的な越権は、3項目のファイルをセッション全体、行為者、許可の証明と呼ぶことである。

Thomson、Rosomakho、Tschofenigの貢献はこの境界を含む。既存形式に相互運用性を与えながら、本番環境での禁止を前面に置いた。RFC番号とIANAレジストリーは危険な運用を正当化しない。

著者は文書を、実装者はコードを、リリース責任者はバイナリを、運用者は起動を、調査担当者は取得と解釈を担当する。形式がそれらの決定を引き受けることはない。

鍵ログの周囲に証拠を作る

復号の前に、ビルド、有効化の仕組み、申請者、承認、プロセス、資産、収集区間、権限、ハッシュ、保存場所、保全物の全移管を記録する。

キャプチャ側にはインターフェース、方向、フィルター、時刻源、パケット損失、ハンドシェイクの完全性、トランスポートの組、ハッシュが要る。解析側には使用したラベルとClientHelloのランダム値、復元したパラメーター、ツールと版、認証できたレコード、失敗したレコード、能動的な操作の有無を残す。

最後に解釈を分離する。エンドポイント鍵は利用者本人の証明ではない。復号されたバイト列は画面表示の証明ではない。要求は事業上の結果ではない。許可された試験は一般的な傍受許可ではない。

この分離によって鍵ログの価値は失われない。答えられる問いが明確になり、答えていない問いを隠さなくなる。

参考資料