HTTP/2を支える裏の主役：TLS 1.2/1.3の必須要件と「Black List暗号スイート」の罠
こんにちは。ネットワークインフラの現場を渡り歩いてきたシニアアーキテクトの私だが、今でも後輩からよくこんな質問を受ける。
「先輩、HTTP/2ってマルチプレクシングとかHPACKによるヘッダー圧縮ばかりがクローズアップされますけど、なんでブラウザでHTTP/2（h2）を使うには、実質的に厳格なTLSが強制されるんですか？ 平文（h2c）じゃダメなんですか？」
非常に良い着眼点だ。
HTTP/2の仕様（RFC 7540）自体は、実は平文の「HTTP/2 Cleartext（h2c）」も定義している。しかし、現実のインターネットを見渡してほしい。主要なブラウザ（Chrome、Firefox、Safari、Edge）は、平文でのHTTP/2を完全にサポート外（実装拒否）としている。つまり、現代のWebにおいて、HTTP/2を語ることは、TLS（Transport Layer Security）の要件を語ることと同義なのだ。
今回は、HTTP/2のパフォーマンスを根底から支えつつ、時にインフラエンジニアを悩ませる「TLSのバージョン要件」と「暗号スイート（Cipher Suites）の制約」について、現場のリアルな知見を交えて徹底解説しよう。
—
1. なぜHTTP/2には厳格なTLS要件が課されるのか？
理由は大きく分けて2つある。ひとつは「プロトコルの安全性」、もうひとつは「ミドルボックス（中間機器）の汚染回避」だ。
① 既知の脆弱性とダウングレード攻撃の防止
HTTP/2は1つのTCPコネクション上で複数のリクエスト・レスポンスを並列処理（マルチプレクシング）する。もしこれが平文であれば、中間者攻撃（MITM）によってパケットが改ざんされたり、セキュリティの低いHTTP/1.1へ強制的にダウングレードさせられたりする脆弱性が生まれる。
② プロトコル識別（ALPN）の必須化
HTTP/1.1とHTTP/2は、同じTCPポート（通常は443）で待ち受ける。クライアントがサーバーに接続した瞬間、「このコネクションはHTTP/1.1で話すべきか、HTTP/2で話すべきか」を合意しなければならない。
ここで使われるのが、TLSの拡張機能である ALPN（Application-Layer Protocol Negotiation） だ。TLSのハンドシェイクのプロセスにプロトコル交渉を組み込むことで、追加のラウンドトリップ（往復遅延）なしに、安全かつ確実にHTTP/2へ移行できる。
—
2. HTTP/2で許されるTLSのバージョンと「暗号スイートのブラックリスト」
ここが実務で一番ハマりやすいポイントだ。
「HTTPSにしてTLSで暗号化していれば、HTTP/2が動くんでしょ？」――これは大間違いである。
RFC 7540および関連するセキュリティ要件（RFC 7540 Appendix A）により、HTTP/2で利用するTLSには非常に厳しい制限がある。
利用可能なTLSバージョン
- TLS 1.2（条件付きで許可。ただし特定の暗号スイートは禁止）
- TLS 1.3（強く推奨。HTTP/2との相性は抜群）
- ※ TLS 1.0 や TLS 1.1 は論外。HTTP/2を有効にするサーバーでは無効化が必須。
恐るべき「HTTP/2 ブラックリスト暗号スイート」
TLS 1.2を使う場合、ただ暗号化されていればいいわけではない。RFC 7540では、過去の脆弱な暗号や、前方秘匿性（Forward Secrecy）を持たない暗号スイートを厳格にブラックリスト化している。
例えば、以下のような暗号スイートはHTTP/2では使用が禁止されている。
- `TLS_NULL_` （暗号化なし）
- `TLS_RSA_` （RSA鍵交換。前方秘匿性がないためNG）
- `TLS_ECDH_ECDSA_` / `TLS_ECDH_RSA_` （静的ECDH。同じくNG）
- `RC4` や `3DES` を含むレガシーなスイート
つまり、TLS 1.2でHTTP/2を動かすには、DHE（Diffie-Hellman Ephemeral）またはECDHE（Elliptic Curve DHE）による前方秘匿性が担保された暗号スイートを選ぶ必要がある。
—
3. 実務で直面するトラブル：なぜか「http/1.1」にフォールバックする現象
インフラの構築やAPIサーバーの移行時によくあるトラブルがこれだ。
「Nginxの設定を変えていざブラウザからアクセスしたら、開発者ツールのプロトコル欄が『h2』じゃなくて『http/1.1』になっている……！」
大抵の原因は以下の2つのどちらかだ。
1. サーバー側がブラックリストに含まれる暗号スイート（例: `ECDHE-RSA-AES128-SHA` など、SHA-1ベースのものや古いもの）を優先させている。
2. クライアント（ブラウザ）が「その暗号化じゃHTTP/2の規定に違反するから、HTTP/1.1で通信するね」と判断してダウングレードしている。
この問題を一発で解決するための、Nginxの本番運用向け設定例を見ていこう。
—
4. 実践：Nginxにおける堅牢なHTTP/2 & TLS設定例
以下は、現代のセキュリティ要件（TLS 1.2 / 1.3）を満たし、HTTP/2を完全に安定稼働させるためのNginx設定スニペットだ。コピペしてすぐに実務で使えるよう、各行に詳細なコメントを入れている。
server {
listen 443 ssl http2; # ポート443で待ち受け、SSLとHTTP/2を同時に有効化
server_name api.example.com;
# 証明書と秘密鍵の指定
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
# ==========================================
# TLSバージョンの制御
# ==========================================
# レガシーなTLS 1.0/1.1は完全に排除し、安全なTLS 1.2と1.3のみを許可
ssl_protocols TLSv1.2 TLSv1.3;
# ==========================================
# 暗号スイート（Cipher Suites）の厳格な選定
# ==========================================
# TLS 1.3用の暗号スイートはOpenSSL 1.1.1以降で自動的に最適化されるため指定不要。
# ここではHTTP/2の要件を満たす「前方秘匿性を持つTLS 1.2の暗号スイート」を定義する。
ssl_ciphers ‘ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384’;
# サーバー側の暗号スイート優先順位を強制（古いクライアントの言いなりにならない）
ssl_prefer_server_ciphers on;
# ==========================================
# セッション管理とパフォーマンスチューニング
# ==========================================
# TLSセッションキャッシュを有効化し、ハンドシェイクのオーバーヘッドを削減
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off; # セッションチケットの乱用によるセキュリティリスクを回避
location / {
proxy_pass http://backend_upstream;
proxy_http_version 1.1; # バックエンド側との通信は標準的なHTTP/1.1で十分
proxy_set_header Connection “”;
# クライアントからの元の情報をバックエンドに引き渡す
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
—
5. デバッグと検証：本当にHTTP/2と意図したTLSで通信できているか？
設定を変更したら、必ず「目視」ではなく「ツール」で検証するのがプロのエンジニアだ。現場で使える手元のコマンドやスクリプトを紹介しよう。
① `curl` コマンドによるプロトコルと暗号スイートの確認
手元の端末から、実際にどのようなプロトコルとTLSハンドシェイクが行われているかを暴くには、`curl` のverboseオプションとプロトコル指定が最強だ。
-v で詳細なハンドシェイク過程を出力し、–http2 でHTTP/2での接続を強要する
curl -Iv –http2 https://api.example.com/healthcheck
【実行結果の見方のコツ】
コンソール出力の中に、以下のような記述があれば成功している。
- Connected to api.example.com (192.0.2.1) port 443 (#0)
- ALPN, offering h2
- ALPN, offering http/1.1
- TLSv1.3 (OUT), TLS handshake, Client Hello (1):
- TLSv1.3 (IN), TLS handshake, Server Hello (2):
- ALPN, server accepted to use h2 <-- ここが「h2」になっていればHTTP/2成功！
- SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
もしここで `ALPN, server accepted to use http/1.1` と表示されたら、前述の暗号スイートのミスマッチや設定ミスを疑うべきだ。
② Pythonスクリプトによるプログラムからの検証
APIクライアントなどを開発する際、Pythonの `requests` や `httpx` でHTTP/2が正しく使われているか確認したい場合は、モダンな `httpx` ライブラリを使うのが手っ取り早い。
import httpx
HTTP/2を明示的に有効にしたクライアントを作成
with httpx.Client(http2=True) as client:
try:
response = client.get(“https://api.example.com/healthcheck”)
print(f”ステータスコード: {response.status_code}”)
# 使用されたHTTPのバージョンを出力 (HTTP/2なら ‘HTTP/2’)
print(f”通信プロトコル: {response.http_version}”)
except httpx.HTTPError as e:
print(f”通信エラーが発生しました: {e}”)
—
まとめ：セキュアな基盤の上にこそ、HTTP/2の真価はある
HTTP/2のマルチプレクシングは非常に強力な技術であり、適切に動けばWebアプリケーションの体感速度は劇的に向上する。しかし、その土台にあるのは「厳格なTLSの要件と、ブラックリストを回避した美しい暗号スイートの選択」だ。
「とりあえず動けばいいや」と古い暗号スイートを野放しにしていると、ある日突然、主要ブラウザのアップデートによってサイトが繋がらなくなったり、セキュリティ監査で致命的な指摘を受けたりすることになる。
インフラを預かるエンジニアとして、プロトコルの仕様と暗号技術の裏側にある「なぜ？」をしっかりと押さえ、堅牢で美しいネットワークを設計していこう。
コメント