【入門編】 TLS 1.3における暗号スイートの簡素化と前方秘匿性(PFS) – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

こんにちは！セキュリティチームで日々インフラやコードの守りを固めているエンジニアです。

皆さんは、Webサイトを作ったり、APIを叩いたりするときに https:// という文字を何気なく見ていますよね。この「S」が意味するもの、つまりTLS（Transport Layer Security）による暗号化通信は、現代のインターネットにおいて「絶対に欠かせない空気」のような存在です。

でも、新人のIT担当者や開発者の皆さんから、こんな風に聞かれることがよくあります。
「暗号化が大事なのは分かるけど、AESとかRSAとかDiffie-Hellmanとか、専門用語多すぎませんか？」
「TLS 1.3になって何がどう変わったの？昔と何が違うの？」

大丈夫です。今回は、泥棒や家の鍵に例えながら、TLS 1.3がもたらした「暗号の大改革」を一緒に優しく紐解いていきましょう！一歩ずつ、確実に理解を深めていきましょうね。

—

1. 昔の暗号（TLS 1.2以前）は「合鍵のバラまき」だった？

まずは、TLSの歴史と、なぜバージョンアップが必要だったのかを「空き巣対策」に例えて考えてみましょう。

泥棒が「合鍵」をこっそり複製できてしまうリスク

昔のTLS 1.2までの世界では、サーバーとあなたのパソコンが通信を始めるとき、「これからこの合鍵を使って通信の中身を隠そうね」というネゴシエーション（おしゃべり）をしていました。

ここで使われていたのが、おなじみの「RSA暗号」などをベースにした鍵交換の仕組みです。この方式だと、もし将来、悪い奴（攻撃者）が「その時使われたマスターキー（親の鍵）」を偶然どこかで手に入れたり、あるいは長い時間をかけて計算で解読してしまったりした場合、どうなるでしょうか？

過去に録画（キャプチャ）して保存しておいた、何年分もの「秘密の通信データ」が、そのマスターキー一本ですべて丸裸になってしまうのです。これをセキュリティの世界では「前方秘匿性（Forward Secrecy）がない状態」と呼びます。泥棒に合鍵を作られたら、過去の侵入記録まで全部見られてしまうようなものですね。怖くないですか？

TLS 1.3の登場：使い捨ての「幻の合鍵」を作る仕組み

そこでTLS 1.3では、この問題を根本から解決するために、通信のルールをガラリと変えました。それが「Diffie-Hellman（ディフィー・ヘルマン）鍵交換」の強制です。

Diffie-Hellmanのすごいところは、「お互いの通信を盗み見られているかもしれない危険な回線の上で、お互いに秘密の鍵を安全に作り出せる」という魔法のような仕組みにあります。しかも、この鍵は通信が終わるたびにポイッと捨てられ、二度と同じものは作れません。

たとえ将来、攻撃者がサーバーのメインの鍵を奪い取ったとしても、過去の通信で使われた「その場限りの使い捨て鍵」はもう残っていません。だから、過去のデータは絶対に解読されないのです。これが、私たちが「前方秘匿性（PFS）」を声高に叫ぶ理由なんですよ。

—

2. TLS 1.3で「無駄なもの」がすべて捨てられた理由

TLS 1.3のもう一つの大きな特徴は、「暗号スイートの圧倒的な簡素化」です。

これまでのバージョン（TLS 1.2など）では、歴史的経緯や互換性のために、実にたくさんの種類の暗号アルゴリズムを選べるようになっていました。メニューが多すぎる高級レストランのようですね。
しかし、メニューが多いということは、「シェフ（開発者）も客（管理者）も、どれが本当に安全でどれが古い危険なものか、パッと見で判断しにくい」という脆弱性を生む原因になります。実際、攻撃者はその「古い設定の隙」を巧みに突いて、あえて脆弱な暗号を使わせる（ダウングレード攻撃）という手口を好みました。

TLS 1.3では、もう過去の遺物は容赦なく切り捨てられました。

脆弱性が指摘された古い暗号モード（CBCモードなど）は廃止。
処理が遅かったり安全性が不安視されたりする鍵交換アルゴリズムも廃止。

現在残ったのは、最高峰の安全性とスピードを誇る精鋭たちだけです。例えば、以下の4つの組み合わせ（暗号スイート）しか基本的に使えません。

1. TLS_AES_128_GCM_SHA256
2. TLS_AES_256_GCM_SHA256
3. TLS_CHACHA20_POLY1305_SHA256
4. TLS_AES_128_CCM_SHA256 （主にIoT機器などの軽量環境向け）

これだけです！RSAによる鍵交換の指定項目すら消え去り、すべての通信で強制的に前方秘匿性が担保されるようになりました。迷いようがないほどシンプルですよね。

—

3. 実務で活かす！ NginxとApacheの設定サンプル

「理屈は分かったけど、自分の管理しているサーバーでどう設定すればいいの？」という方のために、実務でそのまま使える設定ファイルのサンプルをご紹介します。

現代のWebインフラでは、古いTLS 1.0や1.1はもちろん、設定ミスを生みやすいTLS 1.2の古い暗号スイートをバッサリと切り捨て、TLS 1.3を主役に据えるのが鉄則です。

設定例：Nginxの場合

/etc/nginx/nginx.conf またはバーチャルホストの設定ファイルに、以下のように記述します。

server {
    listen 443 ssl http2;
    server_name example.com;

    # 証明書と秘密鍵のパスを指定
    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    # 古いプロトコルを完全に排除し、TLS 1.3とTLS 1.2のみを許可する
    ssl_protocols TLSv1.2 TLSv1.3;

    # TLS 1.3の強固な暗号スイートを最優先で適用する
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers on;

    # セキュリティヘッダー（HSTS）を有効化し、強制的にHTTPS接続させる
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    location / {
        root /var/www/html;
        index index.html index.htm;
    }
}

設定におけるポイント解説

ssl_protocols TLSv1.2 TLSv1.3;: 時代遅れの TLSv1 や TLSv1.1 は設定から除外しています。これらは現代のセキュリティ基準では「穴だらけの古い門」とみなされます。
ssl_ciphers: TLS 1.2をサポートする場合でも、必ず前方秘匿性（PFS）を提供する ECDHE（楕円曲線Diffie-Hellman）から始まる暗号スイートを指定してください。
add_header Strict-Transport-Security ...: いわゆる HSTS ヘッダーです。「一度このサイトにアクセスしたら、今後は絶対に暗号化された安全な接続（HTTPS）以外でアクセスさせないでね」とブラウザに強く約束させるための、実務で必須の防御ヘッダーになります。

—

4. さいごに：安全なネットワークの土台を作ろう

今回は、TLS 1.3における暗号スイートの簡素化と、前方秘匿性（PFS）がもたらす安全性についてお話ししました。

セキュリティの技術は一見すると難解な言葉の羅列に見えますが、本質をたどれば「大切な情報を守るための現実的な防犯対策」に行き着きます。TLS 1.3はその防犯システムを「誰が使っても絶対に隙が生まれない自動ロック式の頑丈なドア」へとアップグレードしてくれたのです。

新人の皆さんも、インフラを構築したりコードを書いたりする際は、ぜひ「この通信は本当に前方秘匿性が守られているか？」「古い設定の残骸が残っていないか？」を意識してみてくださいね。一歩ずつ、確実に安全なエンジニアへの階段を上っていきましょう！