HTTPS / TLS / CRYPTOGRAPHY
TLS 1.3の暗号スイートとは？ HTTPSの暗号化と改ざん検知を身近な例で理解する
オンラインショップでカード番号を入力するとき、通信内容を他人に読まれず、こっそり書き換えられないようにする。そのための「暗号の道具セット」が、TLSの暗号スイートです。
まず押さえたいこと
TLS 1.3の暗号スイートは「AEAD（認証付き暗号）＋ ハッシュアルゴリズム」の組合せ。
鍵交換と電子署名の選択は、暗号スイートとは別に交渉します。名前が短くなっただけではなく、役割を切り分けた設計です。
1. 身近な例：通販サイトに住所を送る
ネットショップで「氏名・住所・注文商品」を送信するとします。途中のネットワークで第三者が通信を見られる環境でも、内容が読めないことが大切です。さらに「届け先住所を勝手に変更されないこと」も必要です。
秘密を守る
盗み見られても注文内容を読めない（機密性）
書き換えを検知
配送先などの改ざんを受信側が検知する（完全性）
相手を確認
偽サイトではなく、接続先サーバを認証する
①と②をまとめて担うのがAEADです。一方、③にはサーバ証明書と署名検証など、暗号スイートとは別の仕組みが関わります。HTTPSの鍵マークは暗号スイートだけで成立するわけではありません。
2. TLS 1.3の暗号スイートを分解する
データの暗号化と改ざん検知をまとめて実行。AESが暗号方式、128が鍵長、GCMが認証付き暗号の動作モードです。
HKDFによる鍵導出やハンドシェイクの記録（Transcript-Hash）に使います。注文データをSHA-256で暗号化するわけではありません。
もう一つの例は TLS_CHACHA20_POLY1305_SHA256。ChaCha20-Poly1305がAEAD、SHA-256がハッシュです。方式は違っても「AEAD＋ハッシュ」という構造は同じです。
3. AEADは「鍵付きの封筒＋封印」
普通の暗号化が「中身を見えなくする封筒」だとすれば、AEADは「中身を隠し、破られたことも分かる封印付きの封筒」です。送信者は秘密の共通鍵とnonceを使い、暗号文と認証タグを生成します。受信者はタグを検証し、改ざんがあればデータを受け入れません。
AEADの「Associated Data」は、暗号化せずに認証だけを行う付加情報です。TLSではレコードのヘッダなどがこれに相当します。なお、nonceの管理やタグ検証を誤ると安全性が崩れるため、通常は実績あるTLSライブラリを使用します。
4. 通信開始時、何をどう決める？
ブラウザが対応する暗号スイート、鍵共有に使えるグループ、鍵共有情報などを提示する。
サーバが共通で利用できる暗号スイートと鍵共有方式に関する情報を選ぶ。
（EC）DHEやPSK由来の秘密とHKDFを用いて通信保護用の鍵を導く。
証明書や署名を検証する。PSKによる接続など、一部の構成では異なる。
合意された暗号スイートのAEADを使い、HTTPの内容を保護する。
例えばクライアントがAES-GCMとChaCha20-Poly1305の両方に対応していても、サーバが対応しない方式は選べません。サーバがクライアントの提示した候補から1つを選び、双方がそれを使用します。
5. TLS 1.2との違い
| 項目 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 暗号スイート | 鍵交換・認証・暗号・MACなどの組合せ | AEAD・ハッシュの組合せ |
| 鍵交換／署名 | スイート名に含まれる | スイートと別に交渉する |
| 暗号化 | AES-CBCなどの従来方式も利用可能 | AEAD方式を使用 |
| 例 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | TLS_AES_128_GCM_SHA256 |
「TLS 1.3ではRSAが一切使えない」という意味ではありません。RSA署名を使う場面はありますが、TLS 1.2のようなRSA鍵輸送方式は廃止され、暗号スイート名にも鍵交換や署名方式を含めません。
6. 操作ラボ：ブラウザとショップの暗号を交渉してみる
ブラウザ側の対応方式を変更し、ショップのサーバがどの暗号スイートを選べるかを確認してみましょう。改ざんされたデータを受け取った場合のAEADの振る舞いも切り替えられます。
通販サイトのHTTPS通信を組み立てる
自分のブラウザが対応する方式をチェックしてください。ショップのサーバは、下に表示された優先順で共通の方式を選びます。
ブラウザの対応方式（変更可能）
通販サイトのサーバ（固定）
優先順：上から順に選択
交渉結果
TLS_AES_128_GCM_SHA256
暗号スイートの中身を確認
AESの128ビット鍵とGCMによる認証付き暗号。幅広い環境で使われます。
ECDHE・署名方式はこの暗号スイート名には含まれません。
通信の流れを一歩ずつ追う
ブラウザが対応する暗号スイートをClientHelloで提示します。
注：交渉やタグ検証を概念的に表した教育用モデルです。実際のTLS接続、秘密鍵生成、暗号化処理は行いません。サーバの優先順位も例示です。
7. 実務で押さえるポイント
証明書は別の役割
暗号スイートが強くても、証明書の検証を無効化すると偽サーバに接続する危険があります。
古い暗号を混ぜない
TLS 1.3ではAES-CBCやRC4などの旧来の方式を暗号スイートに含めません。
ライブラリに任せる
AEADのnonce・鍵・タグの扱いを独自実装せず、安全なライブラリと既定設定を基本にします。
ログで実態を確認
TLSのバージョンと選択された暗号スイートを確認し、意図しない古い方式へのフォールバックを防ぎます。
仕様の参照先：RFC 8446 ／ RFC 9846。本記事の操作ラボは仕組みの学習用であり、実際のTLSハンドシェイクや暗号計算を実行するものではありません。