はじめに
本書の目的
本書は、SSL/TLSがどのようにして通信を安全に保つのかを、段階を追って分かりやすく説明します。専門知識がなくても理解できるよう、具体例を交えて丁寧に解説します。たとえば、ネット通販やオンラインバンキングでの通信がどのように守られるかをイメージしながら読めます。
対象読者
ネットワークやセキュリティの基本は知っているが、SSL/TLSの内部動作を詳しく知りたい方。エンジニアだけでなく、運用担当者や学習者にも役立つ内容です。
本書の構成と読み方
全7章で構成します。まず基本概念を説明し、公開鍵・秘密鍵を使った初期手続き、そこで作られるセッション鍵へ移行する仕組み、実際の暗号化と復号化、データの改ざん検知（ハッシュと署名）、最後に証明書チェーンの検証を扱います。各章は順を追って読めば理解が深まるように作りました。必要に応じて、実際の通信の流れを思い浮かべながら読み進めてください。
SSL/TLSプロトコルの基本概念
概要
SSL/TLSは、インターネットでやり取りするデータを第三者から守る仕組みです。ブラウザとサーバーが互いに安全な“専用線”を作り、送受信する情報を暗号化します。日常ではHTTPSで表示されるサイトがTLSを使っています。
なぜ必要か
例えばネットカフェでパスワードを送ると、隣の人に盗み見される恐れがあります。TLSはそのリスクを低くします。通信の秘密性、送信元の確認、データの改ざん検知、この三つを同時に実現します。
主な要素（やさしい説明）
- 暗号化：手紙を封筒に入れるように内容を隠します。復号には鍵が必要です。
- 認証：封筒の差出人が本当にその人か、印鑑（証明書）で確かめます。
- 完全性：封筒に封がされているかを確認するイメージで、途中で改ざんされていないかを検査します。
通信の流れ（概念）
- ブラウザとサーバーが挨拶をして使える暗号方式を決めます。
- サーバーは証明書を送り、本人確認を受けます。
- 鍵交換により一時の共通鍵を作り、その鍵で以後の通信を速く暗号化します。
ブラウザでの見え方
URLがhttps://で始まり、鍵マークが表示されればTLSで保護されています。接続が安全かどうか、ブラウザの表示で簡単に確認できます。
公開鍵暗号と秘密鍵を用いた初期ハンドシェイク
仕組みの概要
クライアントがサーバーに接続を始めると、まず公開鍵暗号方式で身元確認と鍵交換の準備を行います。サーバーはSSLサーバー証明書を送付し、証明書にはサーバーの公開鍵と認証局（CA）による署名が含まれます。
証明書の検証手順
- ブラウザは内蔵のルート証明書で、送られてきた証明書の署名を検証します。
- デジタル署名を認証局の公開鍵で復号するとハッシュ値が得られます。
- 証明書作成時のデータを同じハッシュ関数で処理し、得られたハッシュと照合します。
- 一致すれば証明書は改ざんされておらず、公開鍵を信頼できます。
公開鍵暗号を初期に使う理由
公開鍵暗号は安全ですが処理が重く、速度が遅い特性があります。ですから、初期の認証と一時的な鍵のやり取りに限定して使い、後続の通信は処理の速い共通鍵暗号に切り替えます。例えると、頑丈な金庫（公開鍵）で最初に重要な鍵を渡し、その後は軽い箱（共通鍵）で中身をやり取りするようなものです。
補足
証明書の検証が失敗すると接続は安全ではないと判断され、ブラウザは警告を出します。これにより中間者攻撃などを防ぎます。
セッション鍵の生成と共通鍵暗号への移行
背景と全体の流れ
証明書の検証が終わると、通信は公開鍵方式から共通鍵方式に移ります。共通鍵方式は処理が速く、長い通信に向きます。ここではクライアントが共通鍵（セッション鍵）を安全に作り、サーバーと共有する手順を説明します。
プリマスターシークレットとランダム値
クライアントはまず「プリマスターシークレット」と呼ぶ秘密の値を作ります。同時に、クライアントとサーバーはそれぞれランダムな値（client random／server random）を用意します。これら三つを組み合わせて、後述するマスターシークレットを生成します。
マスターシークレットの生成
プリマスターシークレットと両方のランダム値を、ハッシュ関数や擬似乱数生成関数で混ぜ合わせます。これによりマスターシークレットが得られます。マスターシークレットは直接使わず、そこから実際の共通鍵やMAC鍵、初期化ベクトル（IV）を派生させます。
共通鍵の受け渡し
プリマスターシークレットや共通鍵自体を送る際、クライアントはサーバーの公開鍵で暗号化します。サーバーは自分の秘密鍵で復号化し、同じマスターシークレットや共通鍵を得ます。これで両者が同じ鍵を持ち、安全に共通鍵暗号を使えます。
初期化ベクトル（IV）の役割
IVはブロック暗号で使われ、同じ平文ブロックが同じ暗号文にならないようにします。IVはランダムに作るか、鍵導出の一部として決めます。安全なIVがあれば、暗号化のパターンを見破られにくくなります。
注意点
鍵の生成と受け渡しは慎重に行う必要があります。公開鍵で暗号化する際は正しい証明書を使い、ランダム値は十分に予測不能であるべきです。これにより通信の秘密性が保てます。
共通鍵を用いた実際のデータ暗号化と復号化
暗号化の流れ
ハンドシェイクで共有したセッション鍵（共通鍵）を使い、送信側は平文を暗号化して送ります。一般にブロック長は128ビット（16バイト）で、データをこの単位で処理します。暗号化後のデータは「暗号文」と呼びます。
AESの基本処理（イメージ）
AESは複数の簡単な変換を繰り返してデータを混ぜます。主な処理はSubBytes（バイト置換）、ShiftRows（行の入れ替え）、MixColumns（列の混合）、AddRoundKey（鍵との合成）です。これらを何回も繰り返すことで、元のデータが復元しにくくなります。
IVと暗号モード
同じ鍵で繰り返し暗号化しても安全にするため、初期化ベクトル（IV）を使います。代表的な方式はCBCやGCMです。CBCは単純で分かりやすく、GCMは暗号と同時に改ざん検知も行えます。実務ではAES-GCMがよく使われます。
復号化の流れ
受信側は同じセッション鍵とIVを使い、暗号化の手順を逆順で適用して平文を取り戻します。ブロックモードではパディングの扱いに注意します。GCMなら改ざんがないかも同時に検証できます。
実用上の注意
共通鍵は安全に保管し、使い回しを避けます。大きなデータやストリーム処理でもAESは高速に動作しますので、機密性のある通信に適しています。
ハッシュ関数とデジタル署名によるデータ完全性の検証
ハッシュ関数の役割
ハッシュ関数はデータの「指紋」を作ります。元のデータが少しでも変われば、指紋（ハッシュ値）も大きく変化します。また、指紋から元のデータを復元できません。これにより、データが途中で改ざんされたかを素早く確かめられます。
デジタル署名の仕組み（簡単な流れ）
- 送信者はデータをハッシュ化して短いハッシュ値を作ります。
- 送信者は自分の秘密鍵でそのハッシュ値に署名します。これがデジタル署名です。
- 送信者は元のデータと署名を受信者に送ります。
受信側での検証手順
受信者は次のように確認します。まず、送られてきたデータを同じハッシュ関数でハッシュ化します。次に、送られてきた署名を送信者の公開鍵で検証します。公開鍵で復号した値と自分で計算したハッシュ値が一致すれば、データは改ざんされておらず、署名者が確かにその秘密鍵の持ち主であると確認できます。
TLSでの使われ方（簡単な例）
TLSでは鍵交換や証明書の検証にデジタル署名を使います。サーバーは証明書と署名を提示し、クライアントは公開鍵で署名を検証してサーバーの正当性とメッセージの完全性を確認します。
注意点
署名の安全性はハッシュ関数と鍵の管理に依存します。弱いハッシュや鍵漏えいがあると検証が意味を成さなくなります。適切なアルゴリズムと安全な鍵管理が重要です。
証明書チェーンの検証プロセス
概要
SSL/TLSでは、サーバー証明書だけでなく、その上位に続く証明書の連鎖（証明書チェーン）を検証します。最終的に信頼済みのルート認証局に到達できるかを確認することで、証明書の信頼性を担保します。
証明書チェーンの構造
- ルート認証局（Root CA）：信頼された公開鍵を持ち、自己署名された証明書です。
- 中間認証局（Intermediate CA）：ルートや他の中間から署名を受けた証明書を持ちます。
- サーバー証明書：サイト固有の証明書で、最終的にブラウザやクライアントで使用します。
検証の手順
- 署名の検証：上位の証明書の公開鍵で下位の署名を検証します。これにより改ざんを検出します。
- 期限と失効確認：有効期限を確認し、CRLやOCSPで失効していないかチェックします。
- 名前の一致：証明書のホスト名（CNやSAN）が接続先と一致するか確認します。
- パス構築：検証を繰り返し、最終的に信頼済みルートに到達するか確認します。
実際の例（イメージ）
ブラウザがサーバー証明書を受け取ると、中間証明書を順に検証し、ルートの公開鍵で最終チェックを行います。これで「この証明書は信頼できる」と判断します。
よくある問題と対処
- 中間証明書が欠けると検証できません。サーバーに中間証明書を正しく配置してください。
- 期限切れや失効があると接続が拒否されます。証明書の更新や失効解除の確認を行ってください。
