みなさんこんにちは！日々のWebブラウジング、快適に楽しんでいますよね。リンクをクリックした瞬間、パッとページが表示されるあのスピード感。私たちは普段、あまり意識せずにWebサイトを行き来していますが、その裏側ではネットワークの技術者たちが、通信をより速く、そしてより安全にするために日夜奮闘しています。
さて、Webの通信規格といえば、長年「HTTP/1.1」が主役でした。しかし、時代はより高速な「HTTP/2」へとシフトしています。HTTP/2の大きな魅力は、1本の通信路（コネクション）でいくつものデータを同時にやり取りできる「マルチプレクシング」という機能です。
ここで、インフラエンジニアを目指すみなさんや初学者の方が、最初に「おっ？」と身構えてしまうポイントがあります。それが「HTTP/2を動かすためには、原則としてTLS（暗号化通信）が必須である」というルールです。
「あれ？ 通信を速くする話なのに、なんでわざわざ暗号化の重い処理を挟むの？」
「TLSのバージョンや暗号スイート（暗号化の組み合わせ）って、なんだか厳しそうなルールがたくさんありそう……」
そんな疑問や不安を抱えていませんか？ 大丈夫です！難しい数式や暗号理論をいきなり覚える必要はありません。今回は、郵便配達のストーリーに例えながら、HTTP/2のTLS要件とセキュリティの秘密を一緒に優しく紐解いていきましょう。一歩ずつ理解していけば、実務でNginxやApacheの設定ファイルを書くときも怖くなくなりますよ！
—
1. なぜHTTP/2には「TLS（暗号化）」が必須なのか？
まず最初に、なぜHTTP/2を使うためにTLSが必須級なのか、その理由を身近な例えで考えてみましょう。
HTTP/1.1の時代、通信は基本的に「中身が見えやすいハガキ」のようなものでした。誰でも途中の郵便ポストや配達の途中で、ハガキの文字を覗き見ることができました（これを「平文（ひらぶん）通信」と呼びます）。
しかし、HTTP/2は1本の道路（コネクション）の上を、画像やテキストなど大量の荷物を乗せたバイク（ストリーム）がものすごいスピードで同時に何台もビュンビュン往来する、いわば「超高速の専用バイパス」です。
もし、この高速道路を通る荷物が丸見えだったらどうでしょう？ 悪意ある第三者に通信を盗み見られたり、勝手に中身を書き換えられたりする危険性が跳ね上がりますよね。ブラウザ（Google ChromeやFirefoxなど）の開発チームは、「これからの高速なWeb通信は、セキュリティが完全に守られている場所（HTTPS）でしか動かさない！」という強い意思決定をしました。
そのため、主要なブラウザは「HTTP/2を使うなら、必ずTLSによる暗号化を使いなさい」というルール（仕様）にしているのです。つまり、HTTP/2の圧倒的な速さは、「頑丈なカギをかけた金庫（TLS）」があって初めて手に入るものなんですね。
—
2. TLSのバージョン要件：古いカギはもう使えない？
TLS（Transport Layer Security）には、いくつかの「世代（バージョン）」があります。
歴史を振り返ると、TLS 1.0、TLS 1.1、TLS 1.2、そして最新のTLS 1.3へと進化してきました。
ここでインフラの現場で必ず知っておかなければならない重要ルールがあります。それは、「HTTP/2では、古い世代のTLS（TLS 1.0や1.1）は事実上お断り、あるいは厳しく制限されている」ということです。
なぜ古いバージョンがダメなの？
古い世代の鍵（暗号アルゴリズム）は、長い年月を経るうちに「ピッキングの方法（脆弱性）」がハッカーたちに見つかってしまっています。ボロボロの古い鍵穴のままだと、どんなに頑丈なHTTP/2のシステムを作っても、泥棒に入られてしまいますよね。
そのため、HTTP/2を安全に走らせるためには、以下のバージョンをメインに据える必要があります。
- TLS 1.2：現在、多くのサーバーで主力として使われている堅実なバージョン。ただし、後述する「安全な暗号スイート」の組み合わせを守る必要があります。
- TLS 1.3：現在利用できる最も新しく、かつ安全でスピードも速い最新バージョン。無駄な通信の往復（ハンドシェイク）を削ぎ落としているため、HTTP/2との相性は抜群です！
—
3. ブラックリスト化された「危ない暗号スイート」たち
TLSの中身を覗くと、「暗号スイート（Cipher Suites）」という、鍵の種類や暗号化のアルゴリズムを組み合わせた「レシピ名」のような設定項目が存在します。
インフラの世界では、このレシピの中に「絶対に選んではいけない（ブラックリスト化された）もの」が明確に定められています。
たとえば、以下のような古い・危ないとされる技術は、HTTP/2の通信において厳しく排除されています。
1. RC4：昔はよく使われましたが、暗号としてのパターンが見破られやすいことが発覚し、即座に追放されました。
2. CBCモードの古い暗号（DES, 3DESなど）：ブロック暗号の仕組みに隙があり、通信のデータを盗み見られるリスクがあります。
3. NULL暗号（暗号化しない設定）：「名前の通り、暗号化しません」という本末転送な設定。もちろん論外です。
4. 輸出規制用などの弱い暗号（Export用暗号）：昔、アメリカの法律で海外に強い暗号を持ち出すことが禁じられていた名残で、わざと弱く作られた暗号です。現代においては危険でしかないため当然NGです。
HTTP/2を実装するサーバー（NginxやApacheなど）は、接続してきたブラウザに対して「私たち、この危ない暗号スイートは一切受け付けませんからね！」と拒否できるリストを持っておく必要があります。
—
4. 実務で役立つ！NginxでのHTTP/2 & TLS設定例
「理屈は分かったけれど、実際にサーバーの設定ファイル（Nginx）ではどう書けばいいの？」
そんな疑問に答えるべく、安全なTLSとHTTP/2を有効にする具体的な設定サンプルを見てみましょう。実務ですぐにコピー＆ペーストして調整できるように、日本語のコメントを丁寧に添えておきますね。
server {
listen 443 ssl http2; # ポート443で待ち受け、SSLを有効にしつつ、HTTP/2をONにする
server_name example.com;
# 証明書と秘密鍵のパス（Let’s Encryptなどのパスを指定）
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# 【重要】HTTP/2で許可するTLSのバージョンを制限する（古い1.0や1.1は排除！）
ssl_protocols TLSv1.2 TLSv1.3;
# 【重要】ブラックリストを避け、安全性が高くモダンな暗号スイートだけを指定する
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:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256’;
# サーバー側の暗号スイートの優先順位を強制する（クライアント側の言いなりにならない）
ssl_prefer_server_ciphers on;
location / {
root /var/www/html;
index index.html index.htm;
}
}
設定のポイント解説
- `listen 443 ssl http2;`: この1行で「HTTPS通信」と「HTTP/2」が同時に有効になります。とてもシンプルですね。
- `ssl_protocols TLSv1.2 TLSv1.3;`: 安全な最新の2つのバージョンだけに絞ることで、脆弱性のある古い通信をシャットアウトしています。
- `ssl_ciphers …`: ガードマンが厳選した「安全で強力な暗号の組み合わせ」だけを許可しています。これによって、ブラックリスト入りの危険な暗号は完全に弾かれます。
—
5. おわりに：安全な土台の上でこそ、HTTP/2は輝く
今回は、HTTP/2におけるTLS要件と暗号スイートについて、郵便配達の例えや具体的な設定ファイルを交えて解説しました。
「HTTP/2は速い！」というメリットの裏側には、「安全な暗号化（TLS 1.2/1.3）という頑丈な土台がしっかり作られていること」という絶対条件があります。
最初は、専門用語や暗号の文字列を見て「難しそう……」と感じるかもしれません。でも、パケットが通る道筋や、セキュリティを担保する理由をひとつずつ紐解いていけば、インフラの仕組みはもっと身近で面白いものに変わっていきます。
ぜひ今回の記事を参考に、ご自身の開発環境や検証サーバーで設定を見直し、安全で爆速なWebの仕組みを体感してみてくださいね！ それではまた次回の技術解説でお会いしましょう。
コメント