【実務・中級編】QUICのパケット保護と暗号化(AEAD) – HTTPプロトコル・通信規格実践ガイド

お疲れ様！今日もWebアプリケーションのパフォーマンスチューニングやインフラの運用、トラブルシューティング対応、本当にお苦労様。

さて、最近「HTTP/3の導入を検討したいのですが、UDPベースになると中間者攻撃やパケット改ざんのリスクはどうなるんですか？」という相談を後輩から受けることが増えてきた。TCPからUDPへの移行と聞くと、往年のインフラエンジニアほど「信頼性のないプロトコルでセキュリティは大丈夫か？」と身構えてしまうのも無理はない。

だが、結論から言おう。QUICはTCP+TLS 1.3の組み合わせよりも遥かに強固で、徹底的な暗号化主義に基づいている。

今回は、HTTP/3の足回りであるQUICプロトコルにおいて、どのようにパケットが保護され、AEAD（Authenticated Encryption with Associated Data：関連データ付き認証付き暗号）がどの範囲にどう適用されているのか、その泥臭いメカニズムと現場でのデバッグ手法までを1から徹底解説しよう。

—

1. なぜQUICは「ヘッダーまで暗号化」するのか？（ミドルボックス固着化問題）

TCP時代、我々はWiresharkを開けばTCPヘッダーのACK番号やウィンドウサイズ、SYN/FINフラグを当たり前のように平文で確認できた。ネットワーク上のファイアウォールやルーター（いわゆるミドルボックス）も同様に、これらのヘッダー情報を勝手に覗き見し、最適化と称して改ざんしたり、未知のTCPオプションを落としたりしていたんだ。

これが有名な「ミドルボックスの固着化（Middlebox Ossification）」問題だ。プロトコルを拡張しようとしても、途中のネットワーク機器が邪魔をして通信が通らない。

RFC 9000およびRFC 9001で標準化されたQUICは、この教訓から恐ろしいほど徹底した決定を下した。

> 「ネットワークのルーティングに必要な最小限の領域（プレーンテキスト）を除き、ヘッダーのフラグやパケット番号、ペイロードのすべてを暗号化・保護する」

これにより、ミドルボックスによる勝手なパケット改ざんを防ぎ、プロトコルの将来的な進化の自由度を確保したんだ。そして、この「改ざん防止」と「機密性確保」を同時に実現するキーテクノロジーこそがAEADだ。

—

2. AEAD（認証付き暗号）の基本とQUICにおける適用範囲

まずは「AEADとは何か」を整理しておこう。

従来の暗号化（CBCモードなど）は「データを隠す（機密性）」だけだったため、暗号文の一部を改ざんされても復号側に気づかれないリスクがあった。そこで登場したのがAEADだ。AEADは「暗号化（機密性）」と「メッセージ認証コード（完全性・真正性）」を同時に提供する。

AEADへの入力は以下の4つだ。

1. Secret Key（暗号化鍵）
2. Nonce（暗号用使い捨てランダム値）
3. Plaintext（暗号化したいデータ：ペイロード）
4. Associated Data（AAD：暗号化はしないが、改ざん検出の対象にしたい平文データ）

そして出力として、「Ciphertext（暗号文）」と「Authentication Tag（認証タグ）」が得られる。

QUICパケットの構造とAEADの適用範囲

QUICのパケット構造を概念図で見てみよう。1つずつのフィールドがどう扱われているかが極めて重要だ。

+———————————————————————–+
| QUIC Header (Associated Data) |
| +——————-+——————–+————————+ |
| | Header Form / Flags| Connection IDs (DCID/SCID)| Version / etc. | |
| +——————-+——————–+————————+ |
+———————————————————————–+
| Protected Header (Header Protection) |
| +—————————————————————–+ |
| | Packet Number (マスク処理により暗号化・難読化) | |
| +—————————————————————–+ |
+———————————————————————–+
| Encrypted Payload (Ciphertext) |
| +—————————————————————–+ |
| | QUIC Frames (STREAM, ACK, CRYPTO, PING etc.) | |
| +—————————————————————–+ |
+———————————————————————–+
| Auth Tag (16 Bytes) |
| +—————————————————————–+ |
| | AEADにより生成された改ざん検証用タグ | |
+———————————————————————–+

この図からわかる通り、適用範囲は以下の3つに明確に分かれている。

① AAD（Associated Data）として保護される領域

接続ID（Connection ID）やバージョン（Version）などのヘッダー情報。
これらはルーターがパケットを正しく転送するために平文（Plaintext）でなければならない。
しかし、途中のミドルボックスがConnection IDを勝手に書き換えたら通信が崩壊する。そのため、AEADのAAD（関連データ）として入力され、改ざんされた瞬間に受信側でAuth Tagの検証が失敗してパケットが破棄される仕組みになっている。

② Ciphertext（暗号文）として完全に暗号化される領域

HTTP/3のデータを含むQUICフレーム群（STREAMフレーム、ACKフレームなど）。
TCPでは平文だった「ACKパケット（どこまで受信したか）」すらも、QUICでは完全に暗号化される。外部の盗聴者は、クラスタリングやトラフィック解析を行わない限り、通信相手がどのデータを再送しているかすら分からない。

③ ヘッダー保護（Header Protection）が適用される領域

パケット番号（Packet Number）および一部のフラグビット。
実は、パケット番号はAEAD本体による暗号化の外側にある。なぜなら、復号に必要な「Nonce」の生成にパケット番号自体が使われるというデッドロック問題があるからだ。
そこでQUICでは、AEADとは別に「Header Protection（HP）」という別の軽量暗号メカニズム（AES-ECBやChaCha20）を使って、パケット番号をマスク（難読化）している。

—

3. 鍵の進化シーケンスと4つの暗号化レベル

QUICではハンドシェイクの進行に応じて、使用する暗号鍵（暗号レベル）が目まぐるしく変化する。ここを理解していないと、Wiresharkのパケット解析で確実に詰まるぞ。

Client Server
| |
|—— 1. Initial Packet (Initial Secret) ————>|
|<----- 2. Initial / Handshake Packet (Handshake Key) --| | | | [ TLS 1.3 Handshake Finished via CRYPTO Frames ] | | | |------ 3. 1-RTT Packet (Application Key) ------------->|
|<----- 4. 1-RTT Packet (Application Key) ------------->|

各階層の鍵の導出と用途は以下の通りだ。

現場でよくある勘違いが、「Initialパケットも暗号化されているから安全」という思い込みだ。
Initialパケットの暗号鍵は、クライアントが送信した`Destination Connection ID`とRFCで規定された公開ソルトから誰でも生成できる。つまりInitialパケットは実質的に「平文」だ。目的は秘密保持ではなく、パケット構造の統一と偶発的なパケット破損の検知（DOS攻撃の軽減）にある。本物の機密性が保たれるのはHandshake以降だ。

—

4. 現場でのデバッグ：SSLKEYLOGFILEを使ったQUICの解読手順

Web API開発やインフラ運用中、「HTTP/3の通信がタイムアウトする」「APIヘッダーが正しく渡っていないようだ」という障害にぶつかった時、暗号化されたQUICパケットを指をくわえて見ているわけにはいかない。

TLS 1.3と同様に、QUICでも`SSLKEYLOGFILE`を出力させてWiresharkで復号するのが鉄板のデバッグ手法だ。

手順1: `curl`コマンドでQUIC通信と秘密鍵のログを保存する

最新の`curl`（HTTP/3対応ビルド）を使用して、接続時の鍵情報をファイルに書き出す。

環境変数 SSLKEYLOGFILE を指定して HTTP/3 通信を実行
export SSLKEYLOGFILE=$HOME/quic_keys.log

–http3-only フラグで QUIC 通信を強制
curl -v –http3-only https://curl.se/ -o /dev/null

生成された `quic_keys.log` の中身を見ると、普通のTLS 1.3とは異なるQUIC固有のラベルが出力されているのがわかるはずだ。

TLS 1.3 / QUIC Secrets log
CLIENT_EARLY_TRAFFIC_SECRET …
QUIC_CLIENT_HANDSHAKE_TRAFFIC_SECRET 4679a…
QUIC_SERVER_HANDSHAKE_TRAFFIC_SECRET 89abf…
QUIC_CLIENT_TRAFFIC_SECRET_0 cdef1…
QUIC_SERVER_TRAFFIC_SECRET_0 23456…

これらの `QUIC__TRAFFIC_SECRET` が、WiresharkがQUICのAEAD復号およびヘッダー保護（パケット番号のマスク解除）を行うための鍵となる。

手順2: Wiresharkで復号設定を行う

1. Wiresharkを起動し、対象のインターフェースでキャプチャを開始（フィルタ: `udp.port == 443`）。
2. 設定画面を開く: `Preferences` -> `Protocols` -> `TLS`
3. `(Pre)-Master-Secret log filename)` の項目に、先ほど出力した `quic_keys.log` のパスを指定する。

これで、通常は「Protected Payload」としか表示されなかった暗号化領域が復号され、中身の `STREAM Frame` や `HTTP/3 HEADERS`、`DATA Frame` がクリアに表示されるようになる。

—

5. PythonによるQUIC鍵導出とAEAD構造の可視化コード

仕組みをさらに深く理解するために、QUICのInitialパケットから「どのように暗号鍵とAEADのIV（初期化ベクトル）が導出されるか」を追体験するPythonコードを書いた。HKDF（HMACベースの鍵導出関数）の動きが手に取るように理解できるはずだ。

以下のコードを実行してみよう（`cryptography` ライブラリが必要: `pip install cryptography`）。

import hkdf
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from cryptography.hazmat.primitives import hashes

RFC 9001 (QUIC v1) で定義されている Initial Salt (固定値)
QUIC_V1_INITIAL_SALT = bytes.fromhex(
“38762cf7f55934b34d179ae6a4c80cadccbb7f0a”
)

def hkdf_expand_label(secret: bytes, label: bytes, length: int) -> bytes:
“””RFC 8446 / RFC 9001 に準拠した HKDF-Expand-Label の実装”””
# “tlsv13 ” プレフィックスを自動付与
full_label = b”tlsv13 ” + label
label_len = len(full_label)

# Struct 構築: Length(2bytes) + Label Length(1byte) + Label + Context Length(1byte)
info = length.to_bytes(2, byteorder=”big”) + \
label_len.to_bytes(1, byteorder=”big”) + \
full_label + \
(0).to_bytes(1, byteorder=”big”)

hkdf_obj = hkdf.HKDF(secret, length, salt=None, hash=hashes.SHA256())
# 簡易的にHKDF-Expandを実施
return hkdf.hkdf_expand(secret, info, length, hash=hashes.SHA256())

def derive_initial_keys(client_dst_cid: bytes):
“””
クライアントの Destination Connection ID (DCID) から
Initial レベルの AEAD 鍵と IV、Header Protection 鍵を導出する
“””
# 1. Initial Secret の導出
initial_secret = hkdf.hkdf_extract(QUIC_V1_INITIAL_SALT, client_dst_cid, hash=hashes.SHA256())

# 2. Client Initial Secret の導出
client_initial_secret = hkdf_expand_label(initial_secret, b”client in”, 32)

# 3. AEAD Key, IV, Header Protection Key の導出 (AES-128-GCM の場合)
client_key = hkdf_expand_label(client_initial_secret, b”quic key”, 16)
client_iv = hkdf_expand_label(client_initial_secret, b”quic iv”, 12)
client_hp = hkdf_expand_label(client_initial_secret, b”quic hp”, 16)

return {
“client_key”: client_key.hex(),
“client_iv”: client_iv.hex(),
“client_hp”: client_hp.hex()
}

if __name__ == “__main__”:
# Wireshark などで確認したクライアントの Connection ID (サンプル値)
sample_dcid = bytes.fromhex(“8394c8f03e515708”)

keys = derive_initial_keys(sample_dcid)
print(“=== QUIC Initial Packet Cryptographic Keys ===”)
print(f”DCID : {sample_dcid.hex()}”)
print(f”AEAD Key (128bit): {keys[‘client_key’]}”)
print(f”AEAD IV (96bit) : {keys[‘client_iv’]}”)
print(f”HP Key (128bit): {keys[‘client_hp’]}”)
print(“==============================================”)

このスクリプトがやっているのは、まさにQUICスタック（Nginx, Envoy, lsquicなど）がパケットを受信した瞬間に一番最初に行う鍵計算そのものだ。ここからAEAD（AES-GCM等）に渡され、平文の暗号化や改ざん検証が行われる。

—

6. シニアエンジニアからのアドバイス：インフラ運用での注意点

最後に、HTTP/3およびQUICを本番環境へ投入・運用するWebエンジニア／インフラエンジニアに、現場視点での重要なポイントを3つ残しておく。

1. 「UDPだからIPフラグメンテーション」を死守せよ
QUICパケットは暗号化されているため、途中のルーターでIPフラグメンテーション（パケット分割）が発生すると、復号時にパケット全体が破損しAEAD認証タグの検証が全滅する。必ずPath MTU Discovery (PMTUD)を適切に機能させ、QUICの最小PMTUである`1200バイト`を下回らないインフラ設計を行おう。

2. ミドルボックスの監視とeBPFの活用
従来のネットワーク監視ツール（NTA/IDS）は、TCPヘッダーの平文情報に依存していた。QUIC導入後はヘッダーが暗号化されるため、ネットワーク境界での監視が難しくなる。今後はホスト側（サーバー内部）でeBPFを用いて、QUICスタックが復号した後のソケットイベントを捉える監視アーキテクチャへのシフトが必要だ。

3. 0-RTTにおけるReplay Attack（リプレイ攻撃）への警戒
QUICの目玉機能である0-RTT接続だが、0-RTTで送信される暗号化データ（0-RTT Keys）はリプレイ攻撃に対して脆弱だ。攻撃者が0-RTTパケットをキャプチャし、そのままサーバーに再送すると、サーバー側で2回処理されてしまう可能性がある。そのため、Web APIの設計では「0-RTTでは副作用のあるリクエスト（POSTやPUT、決済処理等）を絶対に許可せず、安全なGETリクエストのみに制限する」というアプリケーション層での防衛が必須だ。

QUICとAEADによるパケット保護は、一見するとデバッグを困難にする悪魔の仕様に見えるかもしれない。しかし、その内部構造とHKDFによる鍵導出のロジック、そして解読ツールを正しく理解すれば、これほど強固で洗練されたプロトコルはないと実感できるはずだ。

しっかり仕様を腹に落とし込んで、自信を持ってHTTP/3時代のアークテクチャを構築していこう！応援しているぞ。