こんにちは！ネットワークの世界へようこそ。インフラ・プロトコルスペシャリストの執筆でお届けする今回の技術ブログです。
私たちが普段何気なく使っているWebブラウザ。アドレスバーにURLを打ち込んでEnterキーを押した瞬間、画面には一瞬で美しい画像やテキストが表示されますよね。「どうやってデータが届いているんだろう？」と、その裏側のドラマに思いを馳せたことはありますか？
前回までのテーマで、HTTP/2が持つ「マルチプレクシング（1本の通信路で同時にいくつもの荷物を運ぶ技術）」の素晴らしさについて触れてきました。今回は、そのHTTP/2が安全に、そして確実に目的地へ荷物を届けるための「大前提」である、TLS（暗号化通信）のバージョン要件と暗号スイートにスポットを当てます。
「TLSって何だか難しそう…」「暗号スイートって呪文みたいに見える…」という方も大丈夫。一歩ずつ、身近な例えから紐解いていきましょう！
—
1. HTTP/2とTLSの切っても切れない関係
まず最初に、ちょっとした秘密（でも業界では常識）をお話しします。
実は、HTTP/2の仕様書（RFC 7540）自体は、必ずしも暗号化（TLS）を強制してはいないんです。理論上は暗号化なしの「HTTP/2（H2C）」も定義されています。
「じゃあ、暗号化しなくてもHTTP/2は動くの？」と思いますよね。
しかし、現実のインターネットの世界では、主要なWebブラウザ（Google ChromeやFirefox、Safariなど）は「暗号化されていないHTTP/2（H2C）には絶対に接続しない」という強硬なポリシーをとっています。
これには明確な理由があります。実務の現場では、次のような「郵便配達」に例えると非常にわかりやすいです。
郵便配達で例える「TLS」の重要性
想像してみてください。あなたは極秘のラブレターや、会社の機密書類を封筒に入れて送ろうとしています。
もし、その封筒が「透明なビニール袋」だったらどうでしょう？ 配達途中の郵便局員にも、すれ違う人にも、中身が丸見えですよね。これが昔ながらのHTTP/1.1や、暗号化なしの通信です。
では、HTTP/2はどうでしょうか。HTTP/2は、1人の配達員が一度に何十通もの手紙を同時に運ぶ「超高速の特急便（マルチプレクシング）」です。
もしこれが透明な袋だったら、一気に大量の機密情報が世間にダダ漏れになってしまいます。危険すぎますよね。
だからこそ、ブラウザたちはこう言いました。
「HTTP/2という超高速便を使うなら、必ず『頑丈で中身が見えないジュラルミンのアタッシュケース（TLS）』に入れて送りなさい。そうでなければ荷物を受け取らないよ」と。
これが、HTTP/2を動かすときにTLSが「実質的な必須要件」となっている背景なんです。
—
2. HTTP/2で許されるTLSのバージョンと「ブラックリスト」
では、どんなTLS（暗号化の仕組み）を使えばいいのでしょうか？ ここに厳しいルールがあります。
HTTP/2を安全に走らせるためには、古いTLSのバージョンをバッサリと切り捨てる必要があります。具体的に見ていきましょう。
NG：古い「TLS 1.0」や「TLS 1.1」
これらは昔の基準で作られた鍵です。現在のサイバー攻撃の技術の前では、まるで「紙の鍵」のように簡単に破られてしまいます。そのため、現代のHTTP/2環境では完全に禁止（または非推奨）されています。
OK：現代の標準「TLS 1.2」と「TLS 1.3」
HTTP/2の安全性を担保するためには、少なくともTLS 1.2、できれば最新かつ最速のTLS 1.3を使用するのが現在の絶対ルールです。
特にTLS 1.3は、通信を始めるための「握手（ハンドシェイク）」の回数が減り、スピードが劇的に向上しています。「安全なのに速い」という、HTTP/2の相棒としてはこれ以上ない組み合わせなんですよ。
—
3. 迷ったらこれ！安全な「暗号スイート」の推奨リスト
「TLSのバージョンは分かったけど、中の暗号化アルゴリズム（暗号スイート）はどう設定すればいいの？」
インフラエンジニアが頭を悩ませるポイントがここですね。暗号スイートとは、いわば「金庫の鍵の組み合わせ」のようなものです。
HTTP/2では、セキュリティ性能が低かったり、脆弱性が発見されたりした古い暗号スイートは「ブラックリスト（使用禁止）」に指定されています。具体的には、暗号にRC4を使ったり、脆弱なRSA鍵交換を使ったりするものは一切使えません。
現代のWebサーバー（NginxやApacheなど）で設定すべき、安全かつ高速な推奨暗号スイートのリストを、実務でそのまま使える設定値としてご紹介します。
Nginxでの設定例（TLS 1.2 / 1.3対応）
実際のサーバー設定ファイル（`nginx.conf`）に記述するパラメーターの例です。日本語のコメントを参考に、安全な要塞を築いてみましょう。
SSL/TLSのプロトコル設定（古いものは容赦なくシャットアウト！）
ssl_protocols TLSv1.2 TLSv1.3;
サーバー側が優先する暗号スイートの順番を強制する（セキュリティ強化の鉄則）
ssl_prefer_server_ciphers on;
推奨されるモダンな暗号スイートのリスト（HTTP/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’;
※補足: TLS 1.3の暗号スイートは、TLS 1.3の仕様書レベルで自動的に安全なものが選ばれるため、
上記の設定（ssl_ciphers）は主にTLS 1.2向けの指定となります。
この設定のポイント
- `ECDHE`: 鍵を交換するときに「前方秘匿性（PFS）」という超重要機能を持つ仕組みです。万が一、将来サーバーのメインの秘密鍵が盗まれたとしても、過去の通信データまで遡って復号（解読）されることを防ぎます。
- `AES128-GCM`: 暗号化と同時に「データが途中で改ざんされていないか」をチェックできる、速くて安全なモードです。
—
4. まとめ：安全とスピードのバランスが生む最高のユーザー体験
今回は、HTTP/2を支える裏の立役者、TLS 1.2/1.3の必須要件と暗号スイートについて解説しました。
1. HTTP/2の裏では必ずTLS（暗号化）がセットで動いている（ブラウザの強いこだわり！）
2. 古いTLS 1.0/1.1は捨て、TLS 1.2とTLS 1.3を採用する
3. ブラックリストを避け、前方秘匿性を持つモダンな暗号スイートを選ぶ
ネットワークやインフラの世界は、一見すると難解な用語の羅列に見えますが、その裏には「どうすればユーザーの大切なデータを、安全に、そして一秒でも早く届けられるか」というエンジニアたちの熱い思いと工夫が詰まっています。
今回の知識をベースに、ぜひご自身のサーバー設定や、パケットキャプチャを通じた通信の観察に挑戦してみてください。「あ、いま安全なジュラルミンケースでマルチプレクシングが動いているぞ！」と実感できた瞬間、ネットワークの勉強がもっと楽しくなりますよ。
それでは、また次回の技術でお会いしましょう！
コメント