HTTP/2を支える暗号の鉄則：TLS 1.2/1.3の要件とブラックリスト暗号スイートの全貌
ネットワークエンジニアとして数多くのトラフィックを解析していると、HTTP/2の高速化（マルチプレクシング）にばかり目がいきがちですが、その土台を支えるトランスポート層、そして何よりTLS（Transport Layer Security）層の設計が疎かになっている現場をあまりにも多く見かけます。
「HTTP/2は平文（H2C）でも動くはずだ」――仕様上はその通りです。しかし、現代の主要なブラウザ（Chrome, Firefox, Safari等）は、セキュリティとプライバシーの観点から実質的に「TLS暗号化（HTTPS）が必須」という硬いポリシーを敷いています。つまり、HTTP/2を語る上で、TLSのハンドシェイク最適化と厳格な暗号スイートの選定は避けて通れない実務の核心なのです。
今回は、パケットレベルの挙動、TLS 1.3によるレイテンシ削減、そして現場で絶対に避けるべきブラックリスト暗号スイートの現実まで、インフラアーキテクトの視点から深く掘り下げていきます。
—
1. HTTP/2におけるTLSバージョンの選択と「ブラックリスト」の現実
HTTP/2を実装するにあたり、RFC 7540および関連するセキュリティ仕様（RFC 9113）では、利用可能なTLSのバージョンと暗号スイートに対して極めて厳しい制限を設けています。
非推奨から禁止へ：TLS 1.2とTLS 1.3の境界線
現代のWebインフラストラクチャにおいて、選択肢はTLS 1.2とTLS 1.3の二択です。TLS 1.0および1.1は、すでに主要ブラウザおよび主要なセキュリティ標準（PCI DSSなど）において完全に廃止されています。
HTTP/2でTLS 1.2を使用する場合、最大のボトルネックとなるのは「脆弱な暗号スイート（Cipher Suites）の排除」です。HTTP/2の仕様では、プレーンテキストのTCPコネクションと同様に、盗聴や改ざんのリスクがある古い暗号化アルゴリズムを厳格に拒否するため、「HTTP/2ブラックリスト（TLS Cipher Suite Blacklist）」が定義されています。
以下のような暗号スイートは、完全なレガシーとして即座に排除しなければなりません。
- `RC4` を含むすべてのスイート（RC4-SHA等）
- `CBC` モードを持つ古い対称暗号（`AES-CBC`など。BEAST攻撃やLucky 13攻撃の標的となるため）
- `DES` や `3DES`
- 完全前方秘匿性（PFS: Perfect Forward Se secrecy）を提供しないRSA鍵交換スイート（`RSA-AES128-SHA`など）
HTTP/2で許可される強固な暗号スイート（推奨リスト）
安全なセッションを確立しつつ、ハードウェア支援（AES-NIなど）を最大限に活かすための推奨暗号スイートは以下の通りです。特にTLS 1.3ではアルゴリズムが整理され、設定ミスが起きにくくなっています。
TLS 1.3用 暗号スイート（TLS 1.3はこれらのみで動作）
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS 1.2用 推奨暗号スイート（前方秘匿性を担保するAEAD暗号のみ許可）
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
—
2. パケットキャプチャで見る：TLSハンドシェイクとHTTP/2 Upgrade/ALPNの連動
HTTP/2の通信がどのように確立されるか、その舞台裏をパケットの視点から覗いてみましょう。
通常のHTTPS通信では、TCP 3-wayハンドシェイクの完了後、すぐにTLSハンドシェイクが始まります。HTTP/2を効率よく（オーバーヘッドなく）開始するために極めて重要な役割を果たすのが、TLSの拡張機能であるALPN（Application-Layer Protocol Negotiation: RFC 7301）です。
ALPNによるラウンドトリップ削減
もしALPNが存在しなかったらどうなるでしょうか？ クライアントはまずHTTP/1.1で接続し、サーバーとの間で「HTTP/2にアップグレードできますか？」というネゴシエーション（`Upgrade: h2c` ヘッダー等）を追加で行う必要があり、致命的なRTT（Round Trip Time）の増加を招きます。
ALPNを使用すると、TLSのハンドシェイク（Client Hello / Server Hello）のフェーズで、どのアプリケーション層プロトコル（`h2` または `http/1.1`）を使うかを同時に合意してしまいます。
Client Server
| —– [1] TCP SYN ———————————–> |
| <---- [2] TCP SYN-ACK -------------------------------- |
| ----- [3] TCP ACK ------------------------------------ |
| |
| ----- [4] TLS Client Hello (+ ALPN: "h2") -----------> |
| <---- [5] TLS Server Hello (+ ALPN: "h2") ------------ |
| <---- [6] TLS Certificate / Key Exchange / Finished -- |
| ----- [7] TLS Finished / CCS ------------------------> |
| |
| ===== [8] 暗号化されたTCPストリーム上でHTTP/2開始 ===== |
このように、TLSハンドシェイクの完了と同時にHTTP/2のバイナリフレーミングのやり取り（SETTINGSフレームの交換など）に移行できるため、レイテンシを極限まで削ぎ落とすことができるのです。
—
3. 実務で直面するパフォーマンスの罠：TLS 1.2 vs TLS 1.3 と TCPバッファ
テックリードやインフラエンジニアとして実運用サーバー（NginxやEnvoyなど）をチューニングする際、セキュリティとパフォーマンスのバランスは常に頭を悩ませるポイントです。
TLS 1.3による「0-RTT」の魅力とリスク
TLS 1.3の最大の目玉機能の一つが0-RTT（Zero Round Trip Time Resumption）です。過去に接続したことのあるサーバーに対して、再接続時にハンドシェイクを待たずに暗号化されたアプリケーションデータを1回目のパケット（Client Helloと同時）で送信できるという画期的な仕組みです。
しかし、実運用においてはリプレイ攻撃（Replay Attack）のリスクを慎重に評価しなければなりません。特に、冪等性（Idempotency）が保証されていないPOSTリクエストなどが0-RTTで送信された場合、悪意ある第三者がパケットを傍受・再送することで、サーバー側で意図しない重複処理が走る危険性があります。
インフラ設計の現場では、「GETリクエストなどの安全なトラフィックに限定して0-RTTを許可する」、あるいはセキュリティを最優先して「あえて0-RTTは無効化し、1-RTT（通常のTLS 1.3ハンドシェイク）の高速性を活かす」という判断が一般的です。
LinuxカーネルパラメータとTCP/TLSのチューニング実例
Nginxをフロントエンドに据えた高負荷環境において、HTTP/2のマルチプレクシング（1つのTCPコネクション上で数百のストリームを多重化する構造）を最大限に活かすためには、Linuxカーネル側のトランスポート層のチューニングが不可欠です。
特に、HTTP/2では「ヘッド・オブ・ライン・ブロッキング（TCP層でのパケットロスによる全ストリームの停止）」の影響を受けやすいため、BBR混雑制御アルゴリズムの採用やバッファサイズの最適化が効果を発揮します。
以下に、実戦投入に耐えうるNginxのSSL/TLS設定スニペットを提示します。
server {
listen 443 ssl http2;
server_name api.example.com;
# — 証明書と鍵の設定 —
ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
# — TLSバージョンの厳格な指定 (レガシーを完全排除) —
ssl_protocols TLSv1.2 TLSv1.3;
# — HTTP/2セキュリティ要件に適合する堅牢な暗号スイート —
# TLS 1.3のスイートはNginx/OpenSSL側で自動的に最優先されます
ssl_ciphers ‘ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305’;
# サーバー側の暗号スイート選択順序を強制する（クライアント側の言いなりにならない）
ssl_prefer_server_ciphers on;
# — セッションキャッシュとタイムアウトの最適化 —
# ハンドシェイクの負荷を軽減し、再接続を高速化
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off; # セッションチケットのローテーションを安全に行うため通常はoffか適切に管理
# — OCSP Staplingの設定（クライアント側の証明書検証レイテンシを削減） —
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 1.1.1.1 valid=300s;
resolver_timeout 5s;
location / {
proxy_pass http://backend_cluster;
proxy_http_version 1.1; # バックエンドとの通信は必要に応じて調整
# ヘッダーの転送設定など
}
}
さらに、OSレベル（`/etc/sysctl.conf`）では、以下のようなTCPバッファのチューニングを加えることで、多数の並行ストリームを捌くHTTP/2のパフォーマンスを底上げできます。
カーネルのソケット送受信バッファの最大値を拡張（高スループット化）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
TCPの送受信バッファのデフォルト値と上限値（動的チューニング）
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
混雑制御アルゴリズムにBBRを採用（パケットロスに強いネットワークへ）
※カーネルが対応している場合
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
—
4. まとめ：セキュリティとパフォーマンスの妥協なき融合を目指して
HTTP/2におけるTLSの要件と暗号スイートの選定は、単に「セキュリティスキャナーの警告を消すための作業」ではありません。パケットがどのような暗号化アルゴリズムで処理され、ALPNによってどれだけ無駄な往復を削ぎ落とし、マルチプレクシングされたストリームがカーネルバッファの上でどう流れていくか――そのすべてを俯瞰して初めて、真に堅牢で爆速なWebインフラストラクチャが完成します。
古いCBCモードの暗号やTLS 1.0/1.1といった遺物は今すぐ完全に葬り去り、TLS 1.3と洗練されたAES-GCM / ChaCha20-Poly1305の世界へ移行しましょう。あなたのネットワークを駆け巡るパケットたちは、きっとその洗練された設計に応えて最高のパフォーマンスを発揮してくれるはずです。
コメント