記事概要
WiresharkでHTTPS通信をキャプチャしても「Application Data」と表示されるだけで、HTTPリクエスト/レスポンスの中身は見えない——これはTLSによる暗号化のためです。本記事では、Google ChromeのSSLKEYLOGFILEを使ってTLSの鍵情報を取得し、TLS 1.3 のHTTPS通信をWiresharkで復号する手順を実際のパケットキャプチャ画面付きで解説しています。
なぜTLS 1.3ではServerの秘密鍵だけでは復号できないのか
TLS 1.3では通常、Certificate認証を伴うハンドシェイクで (EC)DHEによるEphemeral（使い捨て）な鍵交換が使われます。
- ClientとServerは鍵交換によって共有Secretを生成
- そこからHandshake Traffic SecretやApplication Traffic Secretなどを導出
- 導出された鍵で実際の通信を暗号化・復号
前方秘匿性（Forward Secrecy）
この仕組みにより、後からServerのCertificate Private Keyが漏洩しても、その鍵だけでは過去にキャプチャしたTLS通信を復号できません。そのためWiresharkでTLS 1.3を解析するには、Client側のTLS実装からTraffic Secretなどの鍵情報を取得するのが有効な手段になります。
この仕組みにより、後からServerのCertificate Private Keyが漏洩しても、その鍵だけでは過去にキャプチャしたTLS通信を復号できません。そのためWiresharkでTLS 1.3を解析するには、Client側のTLS実装からTraffic Secretなどの鍵情報を取得するのが有効な手段になります。
手順①：SSLKEYLOGFILEで鍵情報を取得する
Google Chromeなど一部のアプリケーションは、環境変数SSLKEYLOGFILEを設定して起動すると、TLS復号に使える鍵情報をファイルへ出力できます。
- PowerShellを起動し、環境変数
SSLKEYLOGFILEを設定（例: デスクトップ上のsslkeys.log） - 同じPowerShellからGoogle Chromeを起動（重要：既にChromeが起動していると既存プロセスが再利用されて鍵が出力されないことがある。完全終了してから）
- Wiresharkでパケットキャプチャを開始し、ChromeからWebサイトにアクセス
- TLS通信が発生すると指定パスに
sslkeys.logが出力される
sslkeys.log に記録される主な鍵情報
| エントリ | 役割 |
|---|---|
| CLIENT_HANDSHAKE_TRAFFIC_SECRET | Client→Server方向のTLS Handshakeメッセージの暗号鍵導出用Secret |
| SERVER_HANDSHAKE_TRAFFIC_SECRET | Server→Client方向のTLS Handshakeメッセージの暗号鍵導出用Secret |
| CLIENT_TRAFFIC_SECRET_0 | Handshake完了後のClient→Server方向Application Data（HTTPリクエスト等）のTraffic Key/IV導出用 |
| SERVER_TRAFFIC_SECRET_0 | Handshake完了後のServer→Client方向Application Data（HTTPレスポンス等）のTraffic Key/IV導出用 |
| EXPORTER_SECRET | TLS Exporterでアプリ向け追加Keying Materialを導出するためのSecret |
- TLS 1.3ではKeyUpdateが行われるとApplication Traffic Secretが更新され、
CLIENT_TRAFFIC_SECRET_1等の世代が進んだSecretが追記される - Traffic Secretそのものを暗号アルゴリズムへ直接渡すのではなく、そこからTraffic KeyやIVを導出して使う
手順②：Wiresharkにsslkeys.logを設定する
- Wiresharkメニュー「Edit」→「Preferences」
- 「Protocols」を展開し「TLS」を選択
- 「(Pre)-Master-Secret log filename」に取得した
sslkeys.logを指定（Browseで選択） - 「Apply」を押して完了
設定項目名は「(Pre)-Master-Secret」となっていますが、TLS 1.3の場合も
SSLKEYLOGFILEに記録されたHandshake/Application Traffic Secretなどの情報はこの同じ項目から読み込ませます。
手順③：復号結果の確認
- 復号前：通信の多くが「Application Data」と表示され、HTTP内容は確認不可
- 復号後：「GET /quiz/public HTTP/1.1」のようにHTTPリクエストの中身がそのまま見えるようになる。TLS Recordとして暗号化されていたApplication DataをWiresharkが復号し、上位プロトコル（HTTP）まで解析できる状態になります
復号できない場合の確認ポイント
- Chromeを完全に終了してから起動したか：既存Chromeプロセスが残っているとPowerShellで設定した
SSLKEYLOGFILEが反映されない場合がある - sslkeys.logに鍵情報が出力されているか：ファイルが存在するだけでなく、
CLIENT_TRAFFIC_SECRET_0などの記録を確認 - 正しいsslkeys.logを指定しているか：WiresharkのTLS設定で、実際にChromeが出力しているファイルを指定しているか確認
- 対象通信と鍵情報が対応しているか：キャプチャしたTLSコネクションに対応する鍵が必要。別セッションで取得した鍵では復号できない
まとめ
暗号化されたHTTPS通信も、検証環境などでClient側から適切な鍵情報を取得できれば、WiresharkでHTTPリクエスト/レスポンスまで詳細に解析できます。HTTPSの接続問題やアプリ間通信の調査に役立つ手法です。
⚠ セキュリティ上の注意
Key Log FileにはTLS通信の復号に利用できる重要な情報が含まれます。鍵情報を公開すると通信内容の復号に悪用される可能性があるため、商用環境での利用やファイルの保管・共有には十分注意してください。
Key Log FileにはTLS通信の復号に利用できる重要な情報が含まれます。鍵情報を公開すると通信内容の復号に悪用される可能性があるため、商用環境での利用やファイルの保管・共有には十分注意してください。