操作して学ぶ
TLS 1.3 ハンドシェイク可視化
https:// の裏で毎回起きている TLS 1.3 のハンドシェイクを、ClientHello から実際の Application Data までステップで追えます。 メッセージの色は暗号化の段階（平文／ハンドシェイク鍵／アプリ鍵）を表します。 「▶ 次へ」または「自動再生」で進めてください。
平文ハンドシェイク鍵で暗号化アプリ鍵で暗号化
1 / 8
平文クライアント → サーバー
1. ClientHello
supported_versions: TLS 1.3cipher_suiteskey_share（クライアントのECDHE公開鍵）signature_algorithmsserver_name（SNI）クライアントが対応バージョン・暗号スイート・鍵共有の材料を一度に送る。TLS 1.3 では key_share を最初から送るので、鍵合意に必要な往復が1回減る（1.2 より速い）。
要点SNI（接続先ホスト名）はこの時点では平文で、経路上から「どのサイトに繋いだか」は見える。ECH（Encrypted Client Hello）はこれを隠す拡張。
押さえどころ
- 1往復（1-RTT）で済む：ClientHello に鍵共有の材料（
key_share）を最初から積むので、1往復でアプリデータに入れる。TLS 1.2 は2往復かかっていた。 - ServerHello の直後から暗号化：証明書すら暗号化して送るため、経路上の盗聴者から「誰の証明書か」も見えにくい。図の色が平文（橙）から暗号化（青緑）へ変わる境界に注目。
- CertificateVerify がなりすまし防止の核心：証明書を見せるだけなら誰でもできる。これまでのやり取りに秘密鍵で署名して、その秘密鍵を本当に持っていることを証明するのが肝。
- 前方秘匿性：鍵は毎回使い捨て（ephemeral な ECDHE）。後日サーバーの秘密鍵が漏れても、録画された過去の通信は復号できない。
- TLS と OAuth は層が違う：TLS は「通信路の暗号化と相手の認証」、OAuth は「その上でアクセス権を委譲する」。両方揃って安全になる。