HTTP/2時代のセキュリティ要件：TLS 1.2の暗号スイート制限と前方秘匿性（PFS）の現場解剖
「おい、ちょっと画面を見てくれ。新規で立ち上げたHTTP/2のAPIエンドポイント、一部の古めのクライアントから謎のコネクションエラーが返ってくるんだ……」
先日、後輩のインフラエンジニアから血相を変えてこんな相談を受けた。ブラウザのモダンな開発者ツールを開かせ、パケットキャプチャを覗き見ると、原因は明白だった。HTTP/2を喋ろうとしたクライアントに対し、サーバー側が「その暗号スイートじゃ話にならない」とばかりに`HANDSHAKE_FAILURE`を突き返していたのだ。
HTTP/2は、Webの高速化においてゲームチェンジャーとなった。1本のTCPコネクション上で複数のストリームを多重化（マルチプレクシング）し、HPACKによるヘッダー圧縮で無駄なトラフィックを削ぎ落とす。しかし、この高速道路を走るための入場チケットとして、ブラウザベンダーやRFC 7540は厳格なセキュリティ要件を課している。特にTLS 1.2をベースにする場合、適当な設定でお茶を濁すことは許されない。
今回は、実務の現場でWeb API設計やインフラ運用に携わる君たちに向けて、HTTP/2が要求するTLS 1.2の最小要件、前方秘匿性（PFS）の死守方法、そして明日からすぐに使える具体的な設定とデバッグ手法を叩き込む。
—
1. なぜHTTP/2はTLSに「厳しい」のか？
HTTP/1.1の時代、暗号化されていない平文（HTTP/1.1 cleartext）での運用はごく当たり前だった。しかし、HTTP/2の標準化にあたり、IETF（Internet Engineering Task Force）は大きな決断を下した。事実上の必須要件として、主要なブラウザ（ChromeやFirefox等）は「暗号化されていないHTTP/2（h2c）には一切接続しない」という実装方針をとったのだ。
つまり、実質的にHTTP/2を使うためにはTLSが必須となる。だが、ただ暗号化されていればいいわけではない。古い脆弱な暗号（RC4やCBCモードのDES、さらには匿名Diffie-Hellmanなど）を排除し、現代のインターネットにふさわしい堅牢性を担保するため、RFC 7540および関連するRFC 7540 Appendix Aでは、HTTP/2で利用してはならない「ブラックリスト暗号スイート（Blacklisted Cipher Suites）」を定めている。
もし、このブラックリストに含まれる暗号スイートをサーバーが提示してしまうと、クライアント（ブラウザ）は接続確立直後にHTTP/2の仕様違反としてコネクションを強制切断（RST_STREAM / PROTOCOL_ERROR）する。これが、冒頭の後輩が直面した悲劇の正体だ。
—
2. 前方秘匿性（PFS: Perfect Forward Secrecy）の絶対死守
HTTP/2の暗号要件を語る上で絶対に外せないキーワードが「前方秘匿性（PFS）」だ。
インフラエンジニアなら耳にタコができるほど聞いている言葉だと思うが、改めてその意味を確認しておこう。PFSとは、仮に将来何者かによって長期的な秘密鍵（プライベートキー）が暴かれたとしても、過去に記録された暗号化通信のパケットが復号されない性質を指す。
静的RSA鍵交換の罠
従来のTLS 1.2設定によく見られた「RSA鍵交換（例: `TLS_RSA_WITH_AES_128_GCM_SHA256`）」では、サーバーの秘密鍵を使ってセッション鍵を直接暗号化してやり取りしていた。これだと、サーバーの秘密鍵が漏洩した瞬間、過去の通信ログ（PCAPファイルなど）がすべて丸裸にされてしまう。
エフェメラルDiffie-Hellman（DHE / ECDHE）の採用
これに対抗するため、HTTP/2のセキュリティ要件では、一時的な（エフェメラルな）鍵をセッションごとに生成するDHEまたはECDHE（楕円曲線Diffie-Hellman）を用いた暗号スイートの使用が事実上の必須となっている。
これにより、通信ごとにまったく異なる使い捨ての暗号鍵が生成されるため、万が一サーバーのマスターキーが将来漏洩しても、過去のセッションは完全に守られるというわけだ。
—
3. HTTP/2 (TLS 1.2) 推奨・必須の暗号スイート一覧
実務において、NginxやApache、あるいはロードバランサー（AWS ALBやCloudflare等）を設定する際、どの暗号スイートを許可すべきか。RFCやMozillaの推奨ガイドライン（Intermediate/Modern compatibility）に基づき、HTTP/2で安全に動作するTLS 1.2の代表的な暗号スイートを厳選して以下に示す。
HTTP/2で安全かつ高速に動作するTLS 1.2暗号スイートの例
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
これらの暗号スイートには共通点がある。すべて、
1. ECDHE（前方秘匿性を担保する楕円曲線Diffie-Hellman）を使っている。
2. AES-GCM または ChaCha20-Poly1305（認証付き暗号: AEAD）を採用し、パフォーマンスと安全性を両立している。
逆に、`AES-CBC` や `3DES` を含むものは、BEAST攻撃やPOODLE攻撃などの脆弱性の温床になるため、容赦なく排除しなければならない。
—
4. 実践：NginxでのセキュアなHTTP/2設定ファイル
百聞は一見にしかず。現場でそのまま使える、TLS 1.2およびTLS 1.3に対応し、HTTP/2の要件を満たすNginxの設定スニペットを公開しよう。
server {
listen 443 ssl http2; # ポート443でSSL有効化、かつHTTP/2を有効にする
server_name api.example.com;
# 証明書と秘密鍵のパス
ssl_certificate /etc/ssl/certs/api_example_com.crt;
ssl_certificate_key /etc/ssl/private/api_example_com.key;
# — TLSプロトコルバージョンの制限 —
# 古いTLS 1.0, 1.1は完全にシャットアウトし、TLS 1.2とTLS 1.3のみを許可
ssl_protocols TLSv1.2 TLSv1.3;
# — 暗号スイートの厳格な指定 (HTTP/2の要件とPFSを死守) —
# ブラウザやクライアントが勝手に弱い暗号を選ばないよう、サーバー側の優先順位を強制する
ssl_prefer_server_ciphers on;
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’;
# — その他のセキュリティチューニング —
# セッションキャッシュの設定（TLSハンドシェイクのオーバーヘッドを軽減）
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
location / {
root /var/www/html;
index index.html index.json;
}
}
この設定のポイントは、`ssl_ciphers` にブラックリスト入りする古い暗号を一切含めず、かつ `ssl_prefer_server_ciphers on;` によってサーバー側から強い暗号を強制している点だ。
—
5. デバッグと動作検証：パケットとツールの手練れ技
設定を投入したら、必ず「本当にHTTP/2で正しくネゴシエーションできているか」を検証する必要がある。インフラエンジニアとしての腕の見せ所だ。
① `curl` を使ったプロトコルと暗号スイートの確認
まずは手元のターミナルから `curl` を叩いて、サーバーがどのプロトコル（h2）で応答し、どの暗号スイートが使われているかを暴いてみよう。
-v で詳細なハンドシェイクの様子を出力し、HTTP/2 (-s –http2) を強制する
curl -v -s –http2 https://api.example.com/healthz 2>&1 | grep -E “Connected to|ALPN|HTTP/2|Cipher”
【実行結果の読み方（成功例）】
- Connected to api.example.com (192.0.2.1) port 443 (#0)
- ALPN, offering h2
- ALPN, offering http/1.1
- SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 <-- PFS対応の暗号スイート！
- ALPN, server accepted h2 <-- HTTP/2のネゴシエーション成功！
< HTTP/2 200 ここで `ALPN, server accepted h2` が返っていれば、TLSのハンドシェイクとHTTP/2のALPN（Application-Layer Protocol Negotiation）は完璧にクリアしている。
② PythonスクリプトによるプログラムからのHTTP/2検証
APIクライアント側の実装でHTTP/2が正しく使われているかを確認するため、Pythonの `httpx` ライブラリ（HTTP/2をネイティブサポートしている優れもの）を使った検証コードを書いておく。
import httpx
HTTP/2を明示的に有効にしたクライアントのインスタンス化
with httpx.Client(http2=True) as client:
try:
response = client.get(“https://api.example.com/healthz”)
print(f”ステータスコード: {response.status_code}”)
print(f”使用されたプロトコル: {response.http_version}”) # ‘HTTP/2’ と表示されるはず
print(f”レスポンスボディ: {response.text}”)
except httpx.HTTPError as e:
print(f”通信エラーが発生しました: {e}”)
もしサーバー側のTLS設定や暗号スイートがHTTP/2の要件を満たしていない場合、このスクリプトは `httpx.ProtocolError` や `RemoteProtocolError` を吐き出してクラッシュする。その場合は、サーバーのログ（Nginxなら `/var/log/nginx/error.log`）を確認し、`peer didn’t support HTTP/2` や `no cipher match` といったエラーが出ていないかチェインを辿ろう。
—
6. まとめ：シニアからの実務アドバイス
HTTP/2におけるTLS 1.2の要件、そして前方秘匿性の重要性について理解してもらえただろうか。
最後に、現場で幾多の障害を踏んできた私から、エンジニアの君たちへいくつかアドバイスを送る。
1. 「動けばいいや」の暗号スイート設定は技術的負債
古いシステムとの互換性を気にするあまり、安全性の低い暗号スイートを許可し続けると、セキュリティ監査で致命的な指摘を受けるか、ある日突然モダンなブラウザからアクセスできなくなる。
2. ALPN（Application-Layer Protocol Negotiation）を過小評価しないこと
ブラウザやクライアントライブラリは、TLSハンドシェイクの「Client Hello」の段階で、自分が話せるプロトコル（`h2` や `http/1.1`）をサーバーに提示する。サーバー側が適切な暗号スイートとALPNの組合せを返せないと、瞬時にフォールバック（または切断）が起きる。デバッグ時は必ずこのハンドシェイクの初動を疑うこと。
3. 将来的にはTLS 1.3への完全移行を見据える
TLS 1.3では、暗号スイートの選択肢が大幅に整理され（脆弱なものが排除され）、デフォルトですべて前方秘匿性が強制される。TLS 1.2の細かい制限に悩まされないためにも、インフラのモダン化を進めていこう。
ネットワークのパケットは嘘をつかない。挙動がおかしいと感じたら、プロトコルの仕様書と通信のログに立ち返り、一歩ずつ紐解いていけば必ず原因にたどり着く。さあ、安全で高速なHTTP/2の世界を、自信を持って構築してくれ。
コメント