QUIC通信のパケットキャプチャと復号 (1)

2026/03/04

R.Suzuki

Media over QUIC (MoQ)

QUIC通信のパケットキャプチャ分析の初歩として復号方法をご紹介します。


はじめに

こんにちは。鈴木です。

リアルタイムコミュニケーション(RTC)仕様の標準化と,キャリア網機能を提供するAPIの標準化を担当し,技術調査・仕様提案を行っています。

本記事では,QUIC通信分析の初歩として,QUIC通信のパケットキャプチャを取得し,暗号化されたパケットを復号する方法をご紹介します。

QUIC概要

QUICは,UDP上に構築された新たなトランスポートプロトコルです。もともとGoogleが開発し,その後IETFで標準化が進められ,2021年5月にIETF RFC 90001として発行されました。HTTP/3(IETF RFC 91142)のトランスポート層として広く利用されているほか,WebTransport3など新たなプロトコルの下位層としても採用が進んでいます。

QUICはこれまでのトランスポートプロトコルと以下の点が大きく異なっています。

トランスポート層のHOLB解消

HTTP/2(IETF RFC 91134)ではTCPの単一コネクション上で複数のストリームを多重化することで,コンテンツリクエストの直列処理に伴ってレスポンスが詰まるアプリケーション層のHOLB(Head-of-Line Blocking)を解決しました。

しかしHTTP/2には依然として,TCPに起因するトランスポート層のHOLBが存在します。TCPの順序保証により,ある1つのパケットがロスするとその再送が完了するまで,当該パケットと無関係なストリームを含む全データの配信が滞留します。

QUICは下位のトランスポートプロトコルにUDPを用い,ストリームごとに独立して順序制御・再送制御を行います。これにより,あるストリームのパケットロスが他のストリームの配信をブロックしない設計となっており,トランスポート層のHOLBを解消しています。HTTP/3はトランスポートプロトコルをQUICに取り換えることでこの問題を克服しています。

暗号化の必須化

QUICにはTLS 1.3による暗号化がプロトコルレベルで必須として組み込まれています。HTTP/2の時点で主要ブラウザが実装としてTLSを必須としていましたが,QUICおよびHTTP/3ではプロトコル仕様として暗号化が必須であり,通信の秘匿性がより確実となっています。

また暗号化の範囲はアプリケーションデータやストリーム情報等のQUICフレーム部分にとどまらず,Packet Numberなど一部のヘッダ情報にも及びます。これにより,ミドルボックスからの通信内容の推定をより困難にしています。

パケットキャプチャ解析上の課題

前述のとおり,QUICにはTLS 1.3による暗号化がプロトコルに組み込まれており,アプリケーションデータだけでなく一部のヘッダフィールドも暗号化されます。そのためキャプチャされた暗号化済パケットの復号にはセッション毎のシークレット情報が必要となります。

実験条件

今回は公開されているHTTP/3対応のサーバに対してWebブラウザからアクセスする通信のパケットキャプチャを行いました。

  • OS
    • Windows11 25H2 (26200.7623)
  • Web Browser
    • Google Chrome (145.0.7632.117)
  • 接続先Website
    • google.com (Google)

パケットキャプチャ

パケットキャプチャツール

今回はWindows上で端末外部との通信のパケットキャプチャを行うためWiresharkを利用しました。

Note

端末外部との通信についてはWiresharkで問題なくパケットキャプチャを行うことができます。

一方でWSLを(Network Mode: Mirroredで)利用する場合,Windows側でWiresharkを用いてローカルIFのキャプチャを行っても,Windowsホスト→WSLへのパケットはキャプチャされず,WSL→Windowsホストのパケットのみがキャプチャされます。

WSL上に構成したサーバとの双方向の通信をキャプチャする場合,WSL環境のLinux distribution上でパケットキャプチャが必要となります。(e.g., tcpdump, tshark)

シークレット情報の取得

Chrome・FirefoxなどのWebブラウザや,NSS・OpenSSLなどのライブラリは,NSS Key Log Format5で,TLSハンドシェイク中に生成されるシークレット情報を書き出す機能に対応しています。QUICに統合されたTLS 1.3の鍵交換にも対応しており,QUIC通信を復号するためのシークレット情報をテキストファイルとして書き出すことができます。

Windows上のChromeでシークレット情報を出力するには,下記のように ssl-key-log-file オプションでシークレット情報のテキストファイルを書き出すファイルパスを指定します。(<OUTPUTDIR>は書き込み権限があればどこでも問題ありませんが,マルチバイト文字を含まないパスを指定するのが確実です。)

PowerShellでの実行例:

& "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe" `
>>    --ssl-key-log-file="<OUTPUTDIR>\sslkeys.txt"

上記で起動されたChromeでアクセスを行うことで,アプリケーションがQUIC通信(他TLS通信含む)で利用したシークレット情報が <OUTPUTDIR>\sslkeys.txt に書き込まれます。

キャプチャされたパケットの復号

パケットキャプチャの復号にもWiresharkを利用します。 Wiresharkの 編集>設定>Protocols>TLSに以下のようにシークレット情報のテキストファイルのパスを指定することで,対応するシークレットをルックアップし自動でキャプチャされたパケットの復号が行われます。

暗号化されたQUICパケットのペイロードはProtected Payloadとして不可視となっています。

復号成功後はパケットがWiresharkのHTTP/3 Dissectorによって分析されている様子が確認できます。

まとめ

今回はQUIC通信の解析における初歩として,パケットキャプチャの復号方法についてご紹介しました。

次回以降はQUIC通信の中身や,QUIC上で動作するメディア通信プロトコル等をご紹介いたします。


チーム紹介

本記事は,NTTネットワークサービスシステム研究所 ネットワーク基盤技術研究プロジェクト ノード処理基盤研究グループの RTC (Real-Time Commmunication) チームが執筆しています。 当チームでは,商用サービス開発とは独立した立場から,将来のRTCサービスを支える基盤技術の創出を目的としたコア研究として,RTC関連技術の研究開発および3GPPやCAMARA等における標準化活動に取り組んでいます。

本記事に関するお問い合わせは,下記アドレスまでご連絡ください。

お問い合わせ先メールアドレス