こんにちは！ネットワークの世界へようこそ。インフラエンジニアの主筆ライターとして、日々飛び交うパケットたちのドラマをお届けしている私です。
さて、私たちが普段何気なく使っているWeb。ブラウザにURLを打ち込めば、一瞬で綺麗なページが表示されますよね。「どうやって通信しているの？」と聞かれたら、多くの人は「HTTPだよ」と答えるでしょう。その通り、Webの共通言語はHTTPです。
そして現代のWebを支える主役といえば、高速化を極めた「HTTP/2」です。一度にたくさんのデータを同時にやり取りする「マルチプレクシング」という魔法のような技術を持っています。
でも、ちょっと待ってください。このHTTP/2、実は「暗号化（TLS）」が事実上の必須条件になっているってご存知でしたか？「えっ、暗号化なら何でもいいの？」いいえ、ここがインフラエンジニアの腕の見せ所。特に古い「TLS 1.2」を使う場合には、絶対に守らなければならない厳しいルール（最小要件）があるんです。
今回は、このHTTP/2とTLS 1.2の切っても切れない関係について、身近な例えを交えながら、一歩ずつ優しく紐解いていきましょう！
—
1. なぜHTTP/2には「セキュリティの厳しい門番」が必要なのか？
HTTP/2の最大の魅力は、1本の通信回線（TCPコネクション）の中で、画像やテキストなどたくさんのデータを同時に、効率よく運ぶマルチプレクシング機能にあります。郵便配達に例えるなら、これまでは1通ずつバイク便を出していたのが、巨大なコンテナトラック1台で一気に大量の荷物を効率よく仕分けて届けるようなものです。
しかし、ここで考えてみてください。
もし、その巨大なトラックの中身が「丸見えのダンボール箱」だったらどうでしょう？ 途中の道路（インターネットの経路）で、誰かに中身を勝手に見られたり、書き換えられたりしたら大惨事ですよね。
だからこそ、HTTP/2の仕様を定めた偉い人たちはこう決めました。
「HTTP/2を使うなら、通信は必ず強力に暗号化しなさい。さもなくば、ブラウザはHTTP/2での通信を拒否します」と。
ここで登場するのが、通信を安全にするための仕組み「TLS（Transport Layer Security）」です。現在主流の「TLS 1.3」を使っていればあまり悩むことはありませんが、互換性の問題などで「TLS 1.2」を使わざるを得ない現場はまだまだたくさんあります。
そして、TLS 1.2を使うときには、「どの暗号の鍵を使うか（暗号スイート）」のチョイスを間違えると、門番に追い返されてしまうのです。
—
2. 前方秘匿性（PFS）という名の「使い捨ての合言葉」
TLS 1.2でHTTP/2を動かすとき、絶対に外せないキーワードが「前方秘匿性（PFS: Perfect Forward Secrecy）」です。
なんだか難しそうな名前ですね。でも、身近な例えで考えてみると一発で理解できます。
スパイ映画の「使い捨てメッセージ」に例えてみよう
想像してください。あなたがスパイ組織のリーダーで、部下に極秘の指令を送るとします。
- ダメな暗号化のやり方：
毎回「合言葉は『リンゴ』ね」と、同じ合言葉を何ヶ月も使い回しています。ある日、敵にその合言葉が書かれたメモ帳が盗まれてしまいました。すると、敵は過去にあなたたちが交わした「過去の秘密の会話」の録音テープを、すべて今のうちに再生して聞いてしまいました……。これでは過去の秘密もすべてバレてしまいますよね。
- 前方秘匿性（PFS）のあるやり方：
あなたと部下は、通信をするたびに「その場限りの使い捨ての鍵（セッションごとに異なる一時的な鍵）」を新しく作ります。会話が終わったら、その鍵は粉々に破壊して二度と使いません。
万が一、何年か経ってから敵に「現在のメイン金庫の鍵」が奪われたとしましょう。でも、過去に使った使い捨ての鍵はもう跡形もなく消滅しているので、敵は過去の会話を絶対に覗き見ることができません。
これが前方秘匿性（PFS）です！「未来でいつか鍵が盗まれたとしても、過去の通信データは絶対に守られる」という、圧倒的な安心感を生み出す仕組みなんですね。
HTTP/2では、この前方秘匿性を保証してくれる暗号方式（具体的には、ECDHEやDHEといった仕組み）を使うことが、厳格なルールとして義務付けられています。
—
3. ブラックリストに載っている「危険な暗号」たち
実は、TLS 1.2には「昔はよく使われていたけれど、今の基準ではセキュリティがフニャフニャで危なっかしい」という暗号方式がたくさんあります。
HTTP/2の仕様（RFC 7540）では、ブラウザが接続してきたときに、次のような「使ってはいけない暗号スイート（Blacklisted Cipher Suites）」が厳しく定められています。
- `RSA` を使った鍵交換（前方秘匿性がないためNG）
- `RC4` という、簡単に解読されてしまう古い暗号
- `CBC` モードと呼ばれる脆弱性を持つ暗号化方式の一部
「難しそうだな…」と思っても大丈夫です。実際の現場では、Webサーバー（NginxやApacheなど）の設定ファイルで、安全なものだけをホワイトリスト形式で許可してあげれば、自動的にこのブラックリストを避けることができます。
—
4. 【実務で使える】Nginxにおける安全なTLS 1.2 & HTTP/2設定例
それでは、実際にインフラの現場で私たちがどのようにサーバーを設定しているのか、具体的なコードを見てみましょう。
今回は、現代のインターネットで標準的に使われている、安全でパフォーマンスも高いNginxの設定例をご紹介します。日本語のコメントを丁寧に添えましたので、そのまま設定ファイルの参考にしてみてください。
server {
listen 443 ssl http2; # ポート443で待ち受けつつ、HTTP/2を有効化する
server_name example.com;
# SSL証明書と秘密鍵のパスを指定
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
# 【重要】安全なTLSのバージョンを指定する（古いTLS 1.0や1.1はシャットアウト）
ssl_protocols TLSv1.2 TLSv1.3;
# 【最重要】HTTP/2の要件を満たし、前方秘匿性(PFS)を持つ暗号スイートだけを厳選して許可
# 古くて危ない暗号や、前方秘匿性のないRSA鍵交換をすべて排除しています
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;
location / {
root /var/www/html;
index index.html index.htm;
}
}
この設定のポイントは、`ssl_ciphers` の部分です。ここに並んでいる `ECDHE` や `GCM` といった文字が含まれる暗号スイートこそが、先ほどお話しした「前方秘匿性（PFS）」をしっかりと担保してくれる、信頼できる精鋭たちです。
—
5. まとめ：安全な土台の上で、HTTP/2の高速な恩恵を受け取ろう
いかがでしたでしょうか？ 今回のポイントを最後にギュッとまとめておきましょう。
1. HTTP/2を使うには、原則としてTLSによる暗号化が必須！
2. TLS 1.2でHTTP/2を動かすときは、「前方秘匿性（PFS）」を確保することが絶対条件。
3. 古い暗号や脆弱な暗号はブラウザから拒絶されるため、サーバー側でしっかりと安全な暗号スイート（ECDHEなど）を選定する必要がある。
インフラの世界は、一見すると呪文のような英単語が並んでいて難しく感じられますよね。でも、今回のように「郵便配達のセキュリティ」や「スパイの使い捨ての鍵」といった身近なストーリーに置き換えてみると、技術がなぜその仕様を求めているのかがスーッと腑に落ちていくはずです。
しっかりと安全な土台（TLS 1.2/1.3の適切な設定）を整えてあげれば、HTTP/2はあなたやユーザーの期待に応え、Webサイトを驚くほど快適に、そして安全に高速表示してくれる最高の相棒になってくれますよ。
それでは、また次回のネットワーク冒険記でお会いしましょう！
コメント