はじめに
この章では、本ドキュメントの目的と読み方をやさしく説明します。SSL/TLSハンドシェイクは、インターネット上で安全にやり取りするための「握手」にあたります。クライアント（例：ブラウザ）とサーバー（例：ウェブサイト）が互いに確認し合い、暗号化の方法を決めて共通の鍵を作り出します。本書はその仕組みと流れを丁寧に解説します。
目的
安全な通信を確立する具体的な目的を示します。主な点は、通信内容の秘匿（外部に見られないこと）、送信元の確認（なりすまし防止）、通信の改ざん防止です。身近な例として、オンラインショッピングやログイン情報の保護を想像してください。
対象読者
ネットワークやセキュリティの基礎を学びたい方、開発者、運用担当者、技術に興味がある一般の方を想定しています。専門用語は必要最小限にし、具体例で補います。
本書の構成と読み方
第2章でハンドシェイクの役割をわかりやすく説明し、第3章で実際のメッセージのやり取りを順を追って示します。まずは全体の流れをつかむことをおすすめします。
SSL/TLSハンドシェイクの基本的な役割と目的
概要
SSL/TLSハンドシェイクは、通信を始める前に安全な土台を作るためのやり取りです。以下の四つの目的を順に達成し、安全な接続を確立します。
1. サーバーの認証と検証
クライアントはサーバーの証明書を確認し、認証局（CA）の署名で正当性を確かめます。これは、相手が本当にそのサイトの運営者であるかを確認する作業です。たとえば、ネットショッピングで銀行サイトかどうか確かめるようなものです。
2. 暗号スイートの合意
クライアントとサーバーは、使う暗号方式やプロトコルのバージョンを決めます。両方が理解できて安全な方式を選びます。身近な例では、会話で共通の言葉を選ぶようなものです。
3. 共通鍵の生成と共有
実際の通信では対称鍵（セッションキー）で高速に暗号化します。ハンドシェイクでは公開鍵暗号を使って、そのセッションキーを安全に共有します。イメージは、相手にだけ開けられる箱に鍵を入れて送るような方法です。多くの場合、一時的な鍵を使い将来の盗聴にも備えます。
4. 通信の安全性確保
以上で暗号化されたチャネルができ、盗聴や改ざんを防げます。加えて、メッセージが途中で変えられていないかも確認します。オンラインバンキングやログイン情報の保護にこの仕組みが使われます。
これらの目的が組み合わさり、安全で信頼できる通信が成立します。
SSL/TLSハンドシェイクの詳細なステップフロー
1. ClientHello
クライアントは使えるプロトコルバージョン、暗号スイート候補、クライアントランダム（乱数）を送ります。例：どの暗号を使えるか一覧で提示します。
2. ServerHello
サーバーは使うバージョンと暗号、サーバーランダムを選択して返します。これで暗号の種類が決まります。
3. サーバー証明書送信
サーバーは証明書を送り、ドメイン名と公開鍵、発行者情報が含まれます。クライアントはこの証明書を使ってサーバーの正当性を確認します。
4. 証明書検証（クライアント）
クライアントは証明書の署名と有効期限、名前の一致をチェックします。問題があれば接続は中断します。
5. ServerHelloDone
サーバーは初期情報の送信が終わったことを通知します。
6. クライアント証明書（任意）
相互認証が必要な場合、クライアントは自分の証明書を送ります。サーバーは検証します。
7. ClientKeyExchange（鍵交換）
クライアントはプリマスターシークレットを送ります。通常はサーバーの公開鍵で暗号化します。これを元に両者が同じ鍵を導出します。
8. ChangeCipherSpec と Finished（クライアント）
クライアントは暗号設定の変更を通知（ChangeCipherSpec）し、ハンドシェイク全体の整合性を証明するFinishedメッセージを送ります。Finishedには鍵で保護された検査値が含まれます。
9. ChangeCipherSpec と Finished（サーバー）
サーバーも同様に暗号設定を適用し、自身のFinishedを送って整合性を確認します。双方がFinishedを正しく検証できれば安全な通信が始まります。
10. アプリケーションデータの送受信
ここからは暗号化されたデータ（HTTPSの本文など）を送ります。鍵はハンドシェイクで導出した共通鍵を使います。
追加事項
- セッション再開：以前のセッション情報で短縮ハンドシェイクが可能です。例：チケットやセッションIDを使います。
- 失敗時：検証エラーや対応する暗号がない場合は接続を終了します。
