こんにちは！日々のネットワーク運用の現場、本当にお疲れ様です。世界中を行き交うパケットの海を眺めていると、たまには誰もが「中身はどうなっているんだ…！」と頭を抱えたくなる夜がありますよね。
私たちが普段何気なく使っているWebブラウザ。その裏側では、目にも留まらぬ速さでデータがやり取りされています。特に最新の「HTTP/3」という規格は、これまでの常識を覆すスピードと快適さを私たちにもたらしてくれました。
でも、インフラエンジニアやプロトコルを愛する者にとって、新しい技術の登場は「デバッグの難易度が跳ね上がる」という試練の始まりでもあります。
今回は、HTTP/3の心臓部である「QUIC（クイック）」パケットのキャプチャと、暗号化のベールを剥ぎ取るための秘伝の技――`SSLKEYLOGFILE`を使ったWiresharkでの復号手順について、身近な例えを交えながら一歩ずつ紐解いていきましょう！
—
1. なぜHTTP/3（QUIC）のパケット解析はこんなにも難しいのか？
これまでのHTTP/2やHTTP/1.1では、パケットキャプチャツール（例えばみんな大好きWireshark）を開いてパケットを覗き見ると、通信の様子がかなりクリアに見えていました。TCPという信頼できる連絡網の上で通信が行われていたため、「あ、いま接続の手続きをしているな」「お、画像データが流れてきたな」というのが、パケットの見た目からなんとなく分かったんです。
しかし、HTTP/3の底を支えるQUICというプロトコルは、世界が全く違います。
郵便配達に例えるなら……「完全密閉の二重金庫」
これまでの通信を「頑丈なダンボール箱に荷物を詰めて送る状態」とするならば、QUICは「中身が見えないどころか、外側から鍵のかかったジュラルミンの二重金庫」に入れて運ぶようなものです。
しかも、QUICはTCPではなくUDPという、どちらかといえば「手紙をポストに放り込んだら、あとは野となれ山となれ」的なライトな配送網を使っています。UDPを使っているのに、その上で独自の強力な暗号化と信頼性制御を行っているのがQUICのすごいところなのですが……。
セキュリティが強固になったおかげで、私たちエンジニアが「あれ、なんでこのAPI通信が失敗しているんだ？」とトラブルシューティングしようとWiresharkを開いても、画面に並ぶのは意味不明な暗号化された文字列（モザイクの嵐）だけ。これでは、まるで暗闇の中で黒猫を探すようなものです。
「じゃあ、HTTP/3のトラブルシューティングは諦めるしかないの？」
いいえ、そんなことはありません！ちゃんと秘密のマスターキーを取り出す方法があるんです。それが今回主役となる `SSLKEYLOGFILE` です。
—
2. 秘密の合鍵を手に入れろ！「SSLKEYLOGFILE」の仕組み
ブラウザとサーバーが通信するとき、盗聴を防ぐために「今だけの秘密の暗号鍵（セッションキー）」をこっそりお互いに作り出します。この鍵は通信が終わると消えてしまうので、後からパケットをキャプチャしても中身は見えません。
そこで、「ブラウザがサーバーと握手して鍵を作った瞬間、そのこっそり作った合鍵を、こっそりファイルに書き留めておいて！」 とブラウザにお願いする機能が用意されています。これが `SSLKEYLOGFILE` という環境変数です。
一連の流れをイメージしてみましょう。
1. あなたがパソコンの環境変数に「合鍵はこのファイルに書き出してね」と設定する。
2. ブラウザ（Google ChromeやFirefoxなど）を起動して、お目当てのWebサイトにアクセスする。
3. ブラウザが通信のたびに、生成された暗号鍵をこっそり指定のファイルにメモしていく。
4. Wiresharkでキャプチャしたパケットファイルと、その「合鍵メモ」を一緒にWiresharkに読み込ませる。
5. あら不思議！モザイクが外れて、HTTP/3の中身（リクエストやレスポンス）が丸見えに！
すごくワクワクしませんか？さあ、実際に手を動かしてこの魔法を体験してみましょう！
—
3. 実践！WiresharkでQUICパケットを復号する手順
それでは、実際に環境を整えてデバッグを行ってみます。今回は一番手軽に試せる、ご自身のPC（ローカル環境）での手順を解説しますね。
ステップ1：環境変数「SSLKEYLOGFILE」を設定する
まずは、ブラウザに「合鍵をここにメモしてね」と指示を出します。お使いのOSに合わせて設定を行いましょう。
- Windows（PowerShell）の場合
一時的にセッション変数として設定する場合は、PowerShellで次のように実行してからブラウザを起動します。
# 合鍵の保存先パスを指定します（例: デスクトップのkey.logというファイル）
$env:SSLKEYLOGFILE = “$env:USERPROFILE\Desktop\key.log”
# そのまま同じPowerShellの窓から、Chromeを起動します
& “C:\Program Files\Google\Chrome\Application\chrome.exe”
- macOS / Linux（ターミナル）の場合
ターミナルから環境変数を渡してブラウザを起動します。
# 合鍵の保存先をホームディレクトリ等に指定してChromeを起動
export SSLKEYLOGFILE=”$HOME/Desktop/key.log”
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
💡 ポイント： 必ず環境変数を設定した「そのプロセスから起動したブラウザ」を使ってくださいね。普段から開きっぱなしのブラウザだと、設定が反映されず鍵がファイルに書き出されません！
ブラウザが起動したら、試しにデスクトップの `key.log` ファイルの中身をテキストエディタで覗いてみてください。`CLIENT_RANDOM …` のような文字列がズラリと書き込まれていれば、合鍵の収集は大成功です！
—
ステップ2：Wiresharkでパケットをキャプチャする
次に、Wiresharkを起動してキャプチャを開始します。
1. ご自身の通信インターフェース（Wi-FiやEthernetなど）を選んでキャプチャをスタートします。
2. 先ほど起動したブラウザで、HTTP/3（QUIC）に対応しているWebサイト（例: `https://quic.w3.org/` や Googleなど）にアクセスします。
3. ページが無事に表示されたら、Wiresharkのキャプチャを停止します。
この時点では、画面上のQUICパケット（UDPポート443番あたりで行き来しているパケット）はまだ暗号化されたままで、HTTP/3の美しいリクエストヘッダーなどは見えないはずです。
—
ステップ3：Wiresharkに「合鍵ファイル」を読み込ませる
いよいよ最後の仕上げです。先ほどブラウザがこっそり書き溜めてくれた合鍵ファイル（`key.log`）を、Wiresharkに教えてあげましょう。
1. Wiresharkの上部メニューから [編集 (Edit)] ＞ [設定 (Preferences)] を開きます。
2. 左側のツリーから [Protocols (プロトコル)] を選択し、スクロールして [TLS] を見つけてクリックします。
3. 設定項目の中に “(Pre)-Master-Secret log filename” という欄があります。
4. ここで、先ほど指定した `key.log` ファイルのパス（例: `C:\Users\ユーザー名\Desktop\key.log`）を参照して設定し、[OK] をクリックします。
—
ステップ4：パケットフィルターで中身を確認する
設定が完了すると、Wiresharkが瞬時に暗号鍵を使ってパケットを復号してくれます！
パケット一覧の上部にあるフィルターバーに、次のように入力して絞り込んでみましょう。
HTTP/3やQUICのトラフィック、かつ復号されたHTTP層のデータに絞り込むフィルター
http3
お疲れ様でした！パケットの詳細ウィンドウに、これまで見えなかった `:method: GET` や `:path: /` といったHTTP/3のヘッダー情報、そしてブラウザとサーバーの間で行われたやり取りがクリアに表示されているのが確認できたでしょうか？
—
4. トラブルシューティングの現場で活かす知見
無事にパケットが読めるようになると、現場でのトラブルシューティングの精度が劇的に上がります。
例えば、
- 「なぜか特定のCDNとの間でQUICのハンドシェイク（接続確立）が無限ループしている（フォールバックが起きている）」
- 「マルチプレクシング（ひとつのコネクション上で複数のストリームを同時にさばく仕組み）において、どのストリームIDでパケットロスや再送が発生しているのか」
といった、目に見えなかったネットワークの健康状態を生々しく観察できるようになります。
HTTP/3やQUICは、これからのWebインフラストラクチャの主役です。「暗号化されていて中身が見えないから分からない」と諦めてしまう前に、今回ご紹介した `SSLKEYLOGFILE` のテクニックを思い出してみてくださいね。
一歩ずつ、パケットの声を聴けるエンジニアになっていきましょう。それでは、また次回の技術探訪でお会いしましょう！
コメント