SSL/TLSハンドシェイクの仕組みをやさしく図解 — 手順・鍵交換・TLS1.3
アドレスバーの🔒がつくHTTPS通信では、データをやり取りする前に SSL/TLSハンドシェイク という「最初の打ち合わせ」が一瞬で行われています。ここで暗号方式を決め・相手が本物か確認し・本番用の共通鍵を安全に共有します。この記事では、その手順を1ステップずつ図解します。HTTPSの全体像は HTTPとHTTPSの違い、証明書の検証は ディジタル証明書 もどうぞ。手を動かすなら SSL/TLSの可視化 が対応しています。
ハンドシェイクは何のため？
暗号化通信を始めるには、通信相手と次の3つを決めておく必要があります。
- どの暗号方式で話すか（暗号スイートの合意）
- 相手が本物か（サーバー証明書による認証）
- 本番データを暗号化する共通鍵を、盗まれずに共有すること（鍵交換）
この打ち合わせが SSL/TLSハンドシェイク です。SSLは旧称で、いま実際に使われているのは後継の TLS（TLS 1.2 / 1.3）ですが、慣習的に「SSL/TLS」と呼ばれます。
ハンドシェイクの流れ（TLS 1.2）
まずは基本形として、TLS 1.2 の流れを見ます。大きく2往復で共通鍵の共有まで完了します。
各ステップでやっていること
① ClientHello（クライアント→サーバー）
ブラウザが「私はこれらの暗号方式（暗号スイート）に対応しています」というリストと、乱数を送ります。TLSのバージョンもここで提示します。
② ServerHello ＋ サーバー証明書（サーバー→クライアント）
サーバーがリストの中から使う暗号スイートを1つ選んで返し、あわせてサーバー証明書（公開鍵入り、認証局の署名つき）を提示します。ブラウザは証明書の信頼の連鎖・有効期限・ドメイン一致を検証し、「相手が本物か」を確認します（詳しくは ディジタル証明書）。
③ 鍵交換 — 共通鍵のもとを安全に渡す
ここが核心です。本番データは速い共通鍵暗号で暗号化したいので、その「共通鍵のもと」を相手だけに渡す必要があります。TLS 1.2 では、クライアントが「共通鍵のもと」をサーバーの公開鍵で暗号化して送ります。対応する秘密鍵を持つ本物のサーバーだけが復号できるので、途中で盗み見られても安全です。これで両者が同じ共通鍵を手にします。
④ Finished ＆ ⑤ 暗号化通信の開始
互いに「これで準備完了」（Finished）を送り合い、以降のHTTPのやり取りはすべて共通鍵で暗号化されます。🔒はこの状態を表しています。
🔒 動かして確かめる：このハンドシェイクの流れと「公開鍵で共通鍵を渡す」動きは SSL/TLSの可視化 でステップ表示できます。証明書の検証でなぜ警告が出るかは 証明書チェーン検証の可視化 をどうぞ。
公開鍵と共通鍵の「2段構え」
ハンドシェイクの肝は、2種類の暗号を使い分けることです。
- 公開鍵暗号（非対称）…安全に鍵を渡せるが処理が重い → 最初の鍵交換だけに使う
- 共通鍵暗号（対称）…速いが鍵の受け渡しが難しい → 本番データに使う
「重いが安全な方法で鍵を渡し、渡したあとは速い方法で本番通信」——この一瞬のバトンタッチがハンドシェイクです。鍵の使い分けの詳細は HTTPとHTTPSの違い でも図解しています。
TLS 1.2 と TLS 1.3 の違い
新しい TLS 1.3 は、ハンドシェイクが大きく改善されています。
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| 往復回数 | 約2往復（2-RTT） | 約1往復（1-RTT）で高速 |
| 鍵交換 | RSA など旧方式も可 | 毎回使い捨ての鍵のみ（前方秘匿性） |
| 再接続 | 短縮ハンドシェイク | 0-RTT でさらに速く |
| 安全性 | 弱い方式も残る | 弱い方式を廃止しシンプルに |
前方秘匿性（Forward Secrecy）とは、毎回使い捨ての鍵で鍵交換することで、「将来サーバーの秘密鍵が漏れても、過去の通信は復号されない」性質です。TLS 1.3 ではこれが標準になりました。
毎回フルでやるわけではない — セッション再開
ハンドシェイクは新しい接続のときだけです。一度つないだ相手とは、セッションID／セッションチケットを使った短縮ハンドシェイクで再開でき、鍵交換をやり直さずに済みます。さらに同じサーバーへの複数リクエストは接続を使い回す（Keep-Alive、HTTP/2）ため、1ページに画像が何十個あっても毎回ハンドシェイクは起きません。ポート番号（HTTPSは443）の話は ポート番号とは をどうぞ。
基本情報技術者試験ではこう出る
- 「SSL/TLSで、共通鍵を安全に渡すために使うのは？」（→ 公開鍵暗号）
- 「本番のデータ通信に使うのは？」（→ 共通鍵（対称）暗号）
- 「サーバー証明書は何を保証するか」（→ サーバーの正当性＝本物であること）
- 「公開鍵暗号と共通鍵暗号を組み合わせる理由」（→ 安全性と速度の両立）
関連：HTTPとHTTPS ／ ディジタル証明書 ／ ネットワークセキュリティの基礎 ／ 記事一覧。
まとめ
SSL/TLSハンドシェイクは、①暗号方式の合意 → ②証明書で認証 → ③公開鍵で共通鍵を共有 → ④以降は共通鍵で暗号化、という一瞬の打ち合わせです。「重いが安全な公開鍵で鍵を渡し、速い共通鍵で本番」という2段構えが核心。TLS 1.3 ではこれが1往復に短縮され、より速く安全になりました。🔒の裏側を、可視化でも確かめてみてください。