⑥では、公開鍵で秘密の材料を送り、その後は共通鍵で通信する、古典的なSSLの説明を追いました。ところが、現在のTLSでは、そのままの手順は使われていません。今回は、SSL・TLSが何を改善してきたのかを整理します。DH方式の二つの軸と、複数の方式が長く併存してきた歴史を見た上で、使い捨ての鍵から双方が同じ秘密を作る流れへ進みます。
暗号化と認証⑦
SSL・TLSの歴史と、使い捨ての鍵共有
⑥では、公開鍵で秘密の材料を送り、その後は共通鍵で通信する、古典的なSSLの説明を追いました。ところが、現在のTLSでは、そのままの手順は使われていません。
今回は、SSL・TLSが何を改善してきたのかを整理します。DH方式の二つの軸と、複数の方式が長く併存してきた歴史を見た上で、使い捨ての鍵から双方が同じ秘密を作る流れへ進みます。
ここでは、共有秘密を作る仕組みを言葉と図で追います。次回⑧ではOpenSSLで実際の接続を見て、⑨では用途別の鍵導出と証明書・署名による認証を詳しく調べます。
SSL・TLSは、何を改善してきたのか
「SSLからTLSへ変わった」と聞くと、鍵を渡す方法が順番に置き換わっていったようにも思えます。けれど、バージョンの変遷は、鍵共有だけの歴史ではありません。
図では、今回の話に関係する改善を三つに分けています。
- 鍵を共有する方法：離れた双方だけが、同じ秘密を持つにはどうするか。
- 通信内容を守る方法：その秘密から作った鍵で、内容を暗号化し、改ざんを検出するにはどうするか。
- 用途別に鍵を作り分ける方法：一つの秘密から、どの仕事を担当する鍵を作るか。
一つの列だけが変わったわけではありません。通信の中の違う仕事を、並行して見直してきました。接続を始める手順や、認証の仕組みにも変更がありますが、この図では三つに焦点を当てています。
鍵の作り分けは、TLS 1.3から始まったのではない
SSL 2.0では、本文の暗号化と改ざん検出に同じ鍵を使っていました。SSL 3.0では、この二つの用途の鍵を分け、さらにブラウザーからサーバーへ送る方向と、その逆方向でも別の鍵を作っています。[1][2]
「共通鍵を共有する」という簡略化した説明の中にも、実際には、役割と方向の違う複数の鍵があります。TLS 1.3で初めて作り分けを始めたのではなく、接続準備中と本文通信中を分けるなど、その設計をさらに整理しています。[3]
TLS 1.1が直したのは、暗号化の出発点
図のTLS 1.1にあるCBCとIVは、鍵の渡し方ではなく、本文を暗号化する方法の話です。
CBCでは、データを一定の大きさのブロックに分け、前のブロックの暗号文を次のブロックの暗号化に混ぜます。ただし、最初のブロックには「前」がありません。そこで、暗号化の出発点に混ぜる値を用意します。これがIV（初期化ベクトル）です。秘密鍵とは別の値で、IV自体を隠す必要はありません。
TLS 1.0では、次の通信のまとまりを暗号化するとき、前のまとまりの最後の暗号文をIVとして使っていました。盗聴している人にも、次に使うIVが事前に分かります。攻撃者が送り込むデータも操作できる条件では、その予測可能性が攻撃の足掛かりになります。
TLS 1.1では、通信のまとまりごとに、事前に予測できないIVを用意して添える形へ変更しました。暗号方式の名前だけでなく、どう使うかも安全性に関係します。[4]
パスワードの処理で使うソルトを思い浮かべると、「同じ入力から同じ結果が出るのを避ける」という発想は近いものがあります。ただし、ソルトとIVは用途も要求される性質も違います。今回のCBCでは、暗号化する前にIVを予測できないことが重要です。
暗号化と改ざん検出を組み合わせる
TLS 1.2では、AES-GCMなどのAEADを使う選択肢が加わります。AEADは、暗号化と改ざん検出を組み合わせた方式です。従来の方式も残っているため、TLS 1.2なら必ずAES-GCMになるわけではありません。[5][6][7]
TLS 1.3では、本文の保護に使う方式をAEADに限定しました。AEADでは、本文の暗号化とは別に従来型のMAC鍵を導出する構成にはなりません。一方、接続準備のやり取り全体に食い違いがないかを照合するためには、別の確認用の鍵を使います。通信内容の改ざん検出と、接続準備全体の照合では、担当する仕事が違います。この違いは⑨で詳しく見ます。[3]
全体を見渡したところで、今回は一列目の「同じ秘密をどう共有するか」へ戻ります。その前に、DHという名前の中身を整理しておきます。
Diffie–Hellmanには、二つの別の軸がある
DHは、Diffie–Hellmanによる鍵共有です。双方が秘密の値を手元に残し、公開してよい値だけを交換して、同じ秘密を計算します。完成した共有秘密をそのまま相手へ送る方式ではありません。
ここで混ざりやすいのが、計算方法の違いと、鍵ペアをどれだけ長く使うかの違いです。
通常のDHは、楕円曲線を使いません。大きな素数を使い、べき乗して余りを求める計算をします。ECDHは、その鍵共有の考え方を、楕円曲線上の点の計算で実現する方式です。[2][8]
それぞれに、長期の鍵ペアを使う固定方式と、一時的な鍵ペアを使う方式があります。組み合わせると、図の四つになります。
- 固定DH：通常のDHで、少なくともサーバー側が長期の鍵ペアを使う。
- 固定ECDH：楕円曲線のDHで、少なくともサーバー側が長期の鍵ペアを使う。
- DHE：通常のDHで、鍵共有用に一時的な鍵ペアを使う。
- ECDHE：楕円曲線のDHで、鍵共有用に一時的な鍵ペアを使う。
名前のECはElliptic Curve（楕円曲線）、末尾のEはEphemeral（一時的）です。ECDHEは「楕円曲線版の、使い捨ての鍵ペアを使うDH」と読めます。[8]
使い捨てにするのは、鍵共有用の秘密鍵・公開鍵のペアです。証明書まで接続ごとに取り直すわけでも、数学の共通設定を毎回作り直すわけでもありません。図の楕円曲線の形は、計算方法を区別するための模式図です。
また、「固定」は双方が必ず固定鍵を使うという意味ではありません。サーバーが証明書に載った長期のDH公開鍵を使い、クライアントは一時的な鍵を用意する構成もあります。[2][8]
楕円曲線を使う利点は、同程度の安全性を比較的小さな鍵で実現できることです。一時的な鍵を使う利点は、長期の秘密鍵が後から漏れたときに、過去の通信へ影響を広げない設計にできることです。二つは別の改善です。[8][9]
ただし、そのためには一時的な秘密鍵を適切に生成し、使い終えたら破棄することなども必要です。「DHE」という名前だけで、実装や鍵の管理まで安全だと決まるわけではありません。
鍵交換スイートの選択肢は、長く併存していた
この図の年は、仕様の公開や運用指針の更新の時期です。すべてのブラウザーやサーバーが、その年に一斉に切り替わったという意味ではありません。
SSL 3.0では、RSA鍵輸送に加えて、固定DHとDHEが選択肢にありました。2006年のTLS向け楕円曲線拡張では、固定ECDHとECDHEも定義されています。[2][8]
図では年でまとめていますが、TLS 1.0は1999年1月、TLS 1.1は2006年4月、楕円曲線拡張は同年5月、TLS 1.2とAES-GCMの暗号スイートは2008年8月に仕様が公開されています。楕円曲線方式やAES-GCMの追加は、バージョン更新と並行した選択肢の拡充として見られます。[5][10][4][8][6][7]
つまり、「最初はRSAだけ、その後にDH、最後に楕円曲線」という一本道ではありません。複数の方式が長く併存していました。
TLS 1.0でも、TLS 1.2でも、RSAで秘密の材料を暗号化して送る方式は仕様に残っていました。TLS 1.3では、そのRSA鍵輸送と固定のDH・ECDH方式が選択肢から外れます。公開鍵による鍵共有にはDHEやECDHEを使い、RSAは署名・認証に引き続き使えます。[3][5][10]
誰が、どの方式を選んでいたのか
利用者がWebサイトへ接続するたびに、ブラウザーの設定メニューで「今回はDH」を選ぶ手順ではありません。
まず、ブラウザーの実装や設定が、使える候補と優先順位を決めます。サーバー側にも、実装と管理者の設定があります。接続時にはブラウザーが候補一覧を提示し、サーバーが、その中から自分も使えて設定上許可されている組み合わせを選んで返します。SSL 3.0でも、ブラウザーの申し出とサーバーの返答で、使う暗号スイートを選んでいました。[2]
双方に共通する候補がなければ、接続は成立しません。仕様に新しい方式が加わっても、両側の実装や設定が揃わなければ、その方式ではつながりません。
選択肢にあることと、使ってよいことも違う
方式が古くなると、まず使用を勧めなくなり、実装の既定の候補から外れたり、対応自体が削除されたりします。これらは同じ時期に起きるとは限りません。
図の2022年はRFC 9325の運用指針、2026年はRFC 10015によるTLS 1.2への要求の更新です。2026年の文書では、RSA鍵輸送、固定DH、通常のDHEを、TLS 1.2で提示・選択しないことが要求されています。[11][9]
固定ECDHへの要求は、原則として提示・選択しないというSHOULD NOTです。他の禁止対象に使われているMUST NOTより、弱い表現になっています。「楕円曲線だから延命された」ようにも見えますが、この違いだけから理由を断定することはできません。[11]
また、通常のDHEはTLS 1.2では禁止対象になりましたが、TLS 1.3では引き続き選べます。TLS 1.2で問題になった鍵交換の手順が、TLS 1.3では見直されているためです。[11]
図では、DHEとECDHEを、それぞれ二本の平行な矢印で示しています。上段は従来のSSLからTLS 1.2まで、下段はTLS 1.3で使う方式です。同じDHE・ECDHEでも、鍵交換の手順や方式の選び方が異なるため、分けて描いています。
SSL 2.0は2011年、SSL 3.0は2015年、TLS 1.0と1.1は2021年に、IETFの文書で使用しないことが要求されています。図の過去の矢印は、今も古いバージョンを使ってよいという意味ではありません。[1][12][13]
仕様を読むときの年にも注意があります。RFC 6101の公開は2011年ですが、収録されているSSL 3.0仕様は1996年11月18日のものです。[2]
TLS 1.0はSSL 3.0を基にしていますが、名前を変えただけでも、SSL 3.0とそのまま通信できる上位互換でもありません。片方がSSL 3.0だけ、もう片方がTLS 1.0だけに対応している場合は通信できず、双方が共通するバージョンに対応している必要があります。[2][10]
TLS 1.3が登場しても、TLS 1.2が一斉に置き換わったわけではありません。両者は並行して使われ、その後の使用指針も別々に変わっています。[3][11]
これで、古典的なSSLの説明と、今回見るTLS 1.3の違いを置く場所ができました。ここからは、現在の一回の接続で、何を交換し、何を計算し、相手をどう確かめるのかを順番に追ってみます。
いまの鍵交換を、まず言葉で追ってみる
ログの名前を見る前に、今回のTLS 1.3接続を、ブラウザーとサーバーが何をするかで追ってみます。
まず、双方が使える方式を合わせる
ブラウザーは、対応している暗号方式、鍵交換の方式、検証できる署名の方式などを伝えます。
サーバーは、その中から自分も使えて、設定上も許可している方式を選びます。
片方が使えない計算を選んでも、双方で同じ秘密は作れません。最初に、同じやり方で進められるかを確かめます。
今回だけの鍵ペアを用意し、公開情報を交換する
⑧の実験では、X25519という方式を使います。楕円曲線を使うDiffie–Hellman型の鍵共有です。[14]
ブラウザーとサーバーが、それぞれ今回の接続のために、使い捨ての秘密鍵と公開鍵のペアを用意します。サーバーの証明書に入っている鍵ペアとは別のものです。
この秘密鍵は、鍵交換と必要な鍵の導出が済んだら、安全に破棄します。次の接続では、新しい鍵ペアを用意します。
公開鍵は相手へ渡し、秘密鍵は自分の手元に残します。
この公開情報は、途中で見られても構いません。共通鍵や、これから作る秘密そのものを入れて送っているわけではありません。
実際のTLS 1.3では、ブラウザーは方式の候補と一緒に、鍵交換の公開情報も送れます。ここでは仕事を分けて説明していますが、通信のメッセージも一段階ずつ別々になる、という意味ではありません。[3]
相手の公開鍵と、自分の秘密鍵で計算する
ブラウザーは、サーバーから受け取った公開鍵と、自分だけが持つ秘密鍵を使います。
サーバーは、ブラウザーから受け取った公開鍵と、自分だけが持つ秘密鍵を使います。
| 計算する側 | 手元にあるもの | 相手から受け取ったもの | 得られるもの |
|---|---|---|---|
| クライアント | 自分の一時秘密鍵 | サーバーの一時公開鍵 | 共有秘密 |
| サーバー | 自分の一時秘密鍵 | クライアントの一時公開鍵 | 同じ共有秘密 |
組み合わせは違うのに、計算すると同じ秘密の値が得られる。以前の楕円曲線の記事で追った仕組みです。
途中で見ている人は、双方の公開情報を見られます。でも、どちらの秘密鍵も持っていないので、同じ秘密を求めるのは困難です。
ここで得た共有秘密は、通信の鍵を作るための材料になります。
出来上がった秘密も、双方の秘密鍵も、一度も送りません。
その秘密から、まず接続準備を守る鍵を作る
双方は、共有秘密や、ここまでの接続準備でやり取りした内容を材料にして、用途ごとの鍵を作ります。決められた同じ手順で計算するため、出来上がった鍵を改めて送り合う必要はありません。この鍵を作る計算は、⑨で詳しく見ます。[3][15]
ただし、材料をそのまま一つのAES鍵にして、何にでも使い回すわけではありません。
まず、接続の準備を守る鍵を作ります。ブラウザーから送る方向と、サーバーから送る方向では、別々の鍵を使います。Webページなどの通信を守る鍵は、この後の手続きが進んだ段階で作ります。すべての用途の鍵が、ここで一度に完成するわけではありません。
どこで使う鍵なのかは、後で一つずつ整理します。
暗号化する準備ができても、相手の確認はこれから
ここまでで、接続準備のやり取りを暗号化できるようになりました。
でも、一緒に秘密を作った相手が、本当に接続したかったサーバーかどうかは、まだ確認できていません。
そこでサーバーは、今作った鍵で保護して、証明書と、今回のやり取りに対する署名を送ります。ブラウザーは証明書を確認し、その公開鍵で署名を確かめます。
その署名には、鍵交換で送った公開情報も含め、ここまでのやり取りが結び付いています。証明書に対応する秘密鍵を持つ相手が、今回の鍵交換に参加している、と確認します。
最後に、双方がここまでの手続きと、作った秘密を使って照合用の値を計算し、食い違っていないか確かめます。
そこまで済ませて、Webページなどの通信へ進みます。
前回⑥のRSA型の説明では、証明書を確認してから、秘密の材料を渡していました。今回は、先に秘密を作って通信を保護できるようにし、その鍵交換に参加した相手を確かめる流れです。[3]
証明書に入っている公開鍵は、サーバーの署名を確かめるためのもの。今回だけ用意した鍵交換の公開鍵は、共有秘密を作るためのものです。同じ「公開鍵」でも、役割も鍵ペアも別です。
これなら、但し書きの「公開鍵は署名を確認するために使う」にも、担当する仕事が見えてきます。
次回
次回は「暗号化と認証⑧ ― OpenSSLで、TLSの接続と鍵交換を追いかける」を取り上げます。
OpenSSLで実際の接続を見て、メッセージの名前と順序、選ばれた方式を確かめます。
参考資料
- RFC 6176 — Prohibiting SSL Version 2.0：SSL 2.0の歴史と、2011年の使用禁止。
- RFC 6101 — SSL Version 3.0：1996年の仕様の記録。RSA鍵輸送とDiffie–Hellman。
- RFC 8446 — TLS 1.3：§2、§4.4、§6.1、§7。ハンドシェイク、CertificateVerify、Finished、鍵導出、接続の終了。
- RFC 4346 — TLS Version 1.1：2006年の仕様更新。
- RFC 5246 — TLS 1.2：旧来のRSA鍵交換と、そのほかの方式。
- RFC 5288 — AES-GCM Cipher Suites for TLS：RSA鍵輸送を含むAES-GCM暗号スイートの歴史。
- RFC 5289 — TLS ECC with SHA-256/384 and AES-GCM：ECDHE_RSAなどでのAES-GCM。
- RFC 4492 — ECC Cipher Suites for TLS：ECDHE_RSAと、既存RSA証明書による鍵交換の認証。
- RFC 9325 — Recommendations for Secure Use of TLS and DTLS：2022年の運用指針。前方秘匿性、鍵共有方式と鍵の大きさに関する推奨。
- RFC 2246 — TLS Version 1.0：SSL 3.0との関係と、RSA鍵輸送。
- RFC 10015 — Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2：2026年7月のRSA鍵輸送廃止と、その理由。
- RFC 7568 — Deprecating SSL Version 3.0：2015年のSSL 3.0使用禁止。
- RFC 8996 — Deprecating TLS 1.0 and TLS 1.1：2021年の旧版使用禁止。
- RFC 7748 — Elliptic Curves for Security：X25519と鍵共有。
- RFC 5869 — HKDF：鍵導出の基本。