パケットの隙間に潜む牙を折れ：HTTP/2 DATAフレーム「パディング機能」の深層とセキュリティ・エンジニアリング
Webの高速化とモダナイゼーションの旗手としてHTTP/2が普及して久しい。ひとつのTCPコネクション上で複数のリクエストとレスポンスを同時に多重化（マルチプレクシング）し、バイナリフレームによる効率的なパース、そしてHPACKによる極限のヘッダー圧縮。これらは現代のWebインフラストラクチャを支える美しい偉業だ。
しかし、プロトコルが洗練されればされるほど、攻撃者もまたその洗練された構造の隙間を突いてくる。
今回は、HTTP/2のデータ転送の主役である `DATA` フレームにひっそりと実装されている「パディング（Padding）機能」を取り上げる。一見すると地味なこの仕様が、実はWebアプリケーションをサイドチャネル攻撃、とりわけCRIMEやBREACHといった暗号解析の魔手から守るための防壁であり、同時にパフォーマンスとのシビアなトレードオフを孕んだ玄人向けの機能であることを、パケットレベルの挙動から紐解いていこう。
—
1. なぜパディングが必要なのか？：暗号化された通信路に残された「長さ」の足跡
まず、前提としてHTTP/2は実運用において、事実上TLS（Transport Layer Security）とセットで使われる。TLSは通信の中身を完全に暗号化し、盗聴や改ざんを防ぐ。完璧に見えるこの暗号化レイヤーだが、セキュリティの原則を少しでもかじった者なら知っている通り、「データ長（Length）」は暗号化されても隠せない。
TLSレコード層は、プレーンテキストの長さにわずかなパディング（CBCモード時のブロック長調整など）や認証タグ（AEADのMACなど）のオーバーヘッドを加えるが、アプリケーション層（HTTP/2）のフレームサイズがそのままTCP/IPパケットのサイズ、ひいてはTLSレコードのサイズに大きく反映される。
ここに、巧妙な攻撃者が付け入る隙がある。
サイドチャネル攻撃（BREACH / HTTP/2版CRIME）の脅威
攻撃者が同一ネットワーク上（あるいはブラウザ内の悪意あるJavaScript等を通じて）に位置している場合、彼らはターゲットが取得するレスポンスの「バイト数（サイズ）」を正確に観測できる。
例えば、Webアプリのレスポンスに機密性の高いセッションIDやCSRFトークン、あるいはユーザー固有の秘密情報が含まれており、それがリクエストの内容によって動的に変化するとしよう。攻撃者は既知の文字列を推測しながらリクエストを繰り返し送信し、得られたレスポンスの「サイズの変化」を観測する。もしデータサイズが微妙に変動すれば、自分の推測が当たりに近づいた（あるいは遠ざかった）ことが筒抜けになってしまう。
この「暗号化されているのに、長さ（Length）の揺らぎから情報が漏洩する」という脆弱性を塞ぐために導入されたのが、HTTP/2における `DATA` フレームのパディング機能なのだ。
—
2. HTTP/2 `DATA` フレームにおけるパディングの内部仕様
HTTP/2のフレームは、共通の9バイトのヘッダーを持つ。
その中で、`DATA` フレーム（Type: `0x0`）のペイロード構造は、パディングフラグが有効な場合に独自の進化を遂げる。
フレーム構造の解剖
+———————————————–+
| Length (24) |
+—————+—————+—————+
| Type (8) | Flags (8) |
+-+————-+—————+——————————-+
|R| Stream Identifier (31) |
+=+=================================================+ |
| Pad Length? (8) |—+ |
+————————————————-+ | |
| Data Payload? (…) | | |
+————————————————-+ | |
| Padding? (…) |<--+ |
+-------------------------------------------------+
1. Flags (8-bit): `PADDED` フラグ (`0x8`) が立っている場合、フレームの先頭（データペイロードの直前）に `Pad Length` フィールドが存在することを示す。
2. Pad Length (8-bit): パディング自体の長さを表す1バイトの整数（0〜255）。
3. Data Payload: 実際のアプリケーションデータ（HTML、JSON、画像など）。
4. Padding: 実際に埋め込まれる無意味なバイト列（通常はゼロ埋め）。その長さは `Pad Length` で指定されたバイト数になる。
この仕組みにより、同じコンテンツであっても、意図的にランダムあるいは固定長のパディングを付加することで、外部から観測されるパケットのサイズをカモフラージュ（難読化）できる。
—
3. パフォーマンスへの痛烈な代償：帯域とCPUのジレンマ
セキュリティ向上には常にコストが伴う。パディングも例外ではない。インフラアーキテクトが頭を悩ませるポイントは、この機能がもたらすオーバーヘッドだ。
1. 帯域幅の無駄遣い（Goodputの低下）
パディングは「中身のないダミーデータ」をネットワークに流す行為である。もし動的に大きなパディングを付加し続ければ、実効スループット（Goodput）は低下する。特にモバイル回線や帯域が限られた環境では、この数バイトから数百バイトの積もりが、体感速度の悪化や通信コストの増大に直結する。
2. TCPウィンドウとバッファへの影響
HTTP/2はTCPの上で動く。TCPは輻輳制御アルゴリズムやフロー制御（ウィンドウサイズ）によってパケットを管理しているが、パディングによってフレームサイズが水増しされると、TCPセグメントのパッキング効率が変わり、場合によっては不要なパケット分割（IPフラグメンテーションやMSSの境界問題）を引き起こす可能性がある。
—
4. 実装とチューニング：Nginx / Envoyにおけるパディング制御
現実のWebサーバーやプロキシ（Nginx, Envoy, Apacheなど）では、このパディング機能はどのように扱われているのだろうか。実は、多くの汎用サーバーでは、サイドチャネル攻撃のリスクとパフォーマンスのバランスを取るため、デフォルトでは無駄なパディングを積極的に大量送信することは少ない（あるいは特定のセキュリティ要件を満たすために調整可能である）。
しかし、高度なセキュリティ要件が求められる金融系システムや、機密性の高いAPIゲートウェイを構築する場合、プロキシの設定レベルでパディング挙動を制御する必要がある。
Envoy Proxyでのパディング設定例
モダンなマイクロサービスアーキテクチャの要である Envoy では、HTTP/2の動作を細かくチューニングできる。
static_resources:
listeners:
- name: secure_http2_listener
address:
socket_address: { address: 0.0.0.0, port_value: 443 }
filter_chains:
- transport_socket:
# TLS設定（省略）
filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: http2_sys
http2_protocol_options:
# 最大同時ストリーム数の制御
max_concurrent_streams: 100
# 初期流動制御ウィンドウの最適化 (TCPバッファとの協調)
initial_stream_window_size: 65535
initial_connection_window_size: 1048576
route_config:
# ルート設定（省略）
http_filters:
- name: envoy.filters.http.router
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
アプリケーション層のプロキシにおいて、パディングを厳密に制御したい場合、カスタムC++フィルターを記述するか、アップストリームとの通信におけるTLS層でのパディング（TLS 1.3のRecord Paddingなど）と組み合わせて総合的なサイドチャネル対策を講じるのがアーキテクトの常道だ。
—
5. Linuxカーネルとトランスポート層の最適化：パディングが光る環境づくり
HTTP/2のパディング機能を有効に活用し、かつパフォーマンスの劣化を最小限に抑えるためには、下位レイヤーであるLinuxカーネルのネットワークスタックのチューニングが不可欠となる。パディングによってフレームサイズが微妙に変化するため、TCPのパケット効率を最大化しておかなければならない。
以下のsysctlパラメータチューニングは、高負荷なHTTP/2環境においてパケットのオーバーヘッドを吸収するための定石である。
/etc/sysctl.d/99-http2-network-tuning.conf
TCP窓スケーリングとBBR輻輳制御の有効化 (RTT削減とスループット最大化)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
TCP受信/送信バッファの動的チューニング (マルチプレクシングによる大量ストリームに対応)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
TCP_NODELAY (Nagleアルゴリズムの無効化) の強制
小さな制御フレームやパディング付きフレームの送信遅延を防ぐため、
アプリケーション側 (Nginx/Envoy等) でTCP_NODELAYが確実に有効になるようカーネル側を整える。
net.ipv4.tcp_low_latency = 1
パケットキャプチャ（Wireshark / tcpdump）による検証の眼
インフラエンジニアとして現場に立つ者なら、理論だけでなく「実際にパケットがどう流れているか」を自分の目で確かめる必要がある。
tcpdumpを用いて、HTTP/2の `DATA` フレームにおけるパディングの挙動をキャプチャするコマンドは以下の通りだ。
暗号化されているためTLSの中身（HTTP/2フレーム）はそのままでは見えないが、
パケット長の変化を観測し、パディングの有無によるサイズ変動を追う。
sudo tcpdump -i eth0 -nnvvS “tcp port 443” -w http2_padding_analysis.pcap
Wiresharkでこのpcapを開き、TLSレコード長やTCPセグメントの長さを時系列でグラフ化（IOグラフ）することで、自社のWebアプリケーションがサイドチャネル攻撃に対してどれほど堅牢なサイズ難読化を行えているかを定量的に評価できる。
—
6. まとめ：セキュリティとパフォーマンスの調律師であれ
HTTP/2の `DATA` フレームにおけるパディング機能は、一見すると仕様の隅にあるマニアックなオプションに思えるかもしれない。しかし、その本質は「現代の暗号通信が抱える根本的な弱点（長さの露出）に対する、プロトコル層からの美しきカウンターアタック」である。
すべてのアクセスに対して一律に最大パディングを適用すれば安全性は高まるが、ネットワークは悲鳴を上げる。逆にパフォーマンスを優先してパディングを一切排除すれば、悪意ある攻撃者に機密情報の隙を突かれる。
真に卓越したネットワークアーキテクトやテックリードに求められるのは、このジレンマを正しく理解し、システムの性格（パブリックなメディアサイトか、極秘データを扱う金融・SaaS APIか）に合わせてパディング戦略とトランスポート層のチューニングを精密にコンフィグレーションすることだ。
パケットの隙間に目を凝らし、見えない脅威からシステムを守り抜く。それこそが、インフラストラクチャの美学である。
コメント