Tech Learning Daily

TLS が解決しようとしている 3 つの問題

平文の HTTP には 3 つの弱点がある。通信経路の途中で内容を覗き見される盗聴、内容を書き換えられる改ざん、そして偽サーバーが本物のふりをするなりすましだ。TLS（Transport Layer Security）はこの 3 つに対応する形で、暗号化による機密性、改ざん検知による完全性、証明書による真正性の 3 つを提供するプロトコルとして設計されている。

ハンドシェイクとは、この 3 つを実際の通信が始まる前に確立するための最初のやり取りのことだ。鍵マークが点くのは、暗号化が始まったからではなく、この確立処理そのものが最後まで成功したことを示している。

共通鍵を、内容を送らずに「合意」する仕組み

公開鍵暗号（RSA や楕円曲線暗号など、公開鍵と秘密鍵のペアを使う方式）は安全だが計算コストが高く、ページ本体のような大量データの暗号化には向かない。そこで TLS はハンドシェイクの間だけ公開鍵暗号を使い、その後の通信本体は計算の軽い共通鍵暗号（同じ鍵で暗号化と復号を行う方式）に切り替える。この共通鍵をどう安全に決めるかが、ハンドシェイクの核心だ。

TLS 1.3 が使うのは ECDHE（楕円曲線ディフィー・ヘルマン鍵交換の、接続ごとに使い捨ての鍵ペアを生成する方式）だ。クライアントとサーバーはそれぞれ自分だけの秘密の数値を持ち、そこから計算した公開値だけを交換する。回線上には公開値しか流れないのに、双方が自分の秘密の数値と相手の公開値を掛け合わせると同じ値にたどり着く。これが共通鍵の材料になる。

証明書チェーンは、何の「本物」を保証しているのか

鍵の合意ができても、合意した相手が正しいドメインの持ち主だという保証にはならない。ここで使われるのが証明書チェーンだ。サーバーが提示する証明書（そのドメインの公開鍵を含む）は上位の認証局が署名しており、その認証局の証明書もさらに上位の認証局が署名している。この連鎖を、ブラウザや OS があらかじめ信頼済みとして持っているルートストア（トラストストアとも呼ぶ、少数の信頼済みルート証明書の一覧）まで署名を検証しながら遡れれば、証明書は正当と判定される。途中の署名が 1 つでも合わなければ、その場で接続は拒否される。

鍵マークが付けば運営者そのものが信頼できると思うかもしれない。しかし実際に証明書が保証しているのは「このドメインの所有者と通信できている」ことだけで、Let's Encrypt のような無料の認証局が発行する証明書の大半はドメインの制御権を確認しているにすぎず、運営組織が実在の企業か詐欺目的かまでは一切保証しない。

1 往復のやり取りで、実際に何が送られているか

TLS 1.3 のハンドシェイクは 1 回の往復（1-RTT）で完了する。旧バージョンの TLS 1.2 が 2 往復かかっていたのに対し、クライアントが最初のメッセージに ECDHE の公開値をあらかじめ含めることで、サーバー側の応答を待たずに鍵の材料を渡せるようになったからだ。

Client                        Server
  │──ClientHello(鍵候補)──────▶│
  │                     鍵を計算・証明書準備
  │◀─ServerHello(鍵)───────────│
  │◀─証明書+署名(以降は暗号化)──│
  │──Finished──────────────────▶│
  │◀════ ここからアプリデータ ═▶│

ClientHello には ECDHE の公開値の候補と対応可能な暗号方式の一覧が入る。サーバーは ServerHello で使う方式と自分の公開値を返した時点でこの鍵の材料が揃うため、続く証明書やFinished メッセージ（ここまでのやり取りが改ざんされていないことを示す確認メッセージ）はもう暗号化された状態で送られる。双方が Finished を確認できて初めて、鍵マークが点きアプリケーションデータが流れ始める。

鍵が使い捨てだと、なぜ将来の漏洩に強くなるのか

TLS 1.3 では、サーバーの秘密鍵を使って共通鍵そのものを暗号化して送る古い方式（静的 RSA 鍵交換）が廃止された。この方式では、通信を記録しておいた攻撃者が後年サーバーの秘密鍵を入手すれば、過去に記録した全セッションを一括で復号できてしまう。ECDHE の鍵ペアは接続のたびに新しく生成され、ハンドシェイクが終わると破棄される。そのため後からサーバーの長期秘密鍵が漏れても、過去の各セッションを個別に復号する材料はもう存在しない。この性質を前方秘匿性と呼び、TLS 1.3 では全ての鍵交換方式で必須になっている。