SSLとレイヤの関係性をわかりやすく解説するブログタイトル

2025 11/29

2025/11/29

はじめに

本書は、SSL/TLSプロトコルの仕組みとそのネットワーク上での役割を分かりやすく解説する入門ドキュメントです。インターネットでのやり取り（例：オンラインショッピングやメール）を安全にするための技術を、具体例を交えて丁寧に説明します。

SSL/TLSは、通信内容を暗号化し相手の正当性を確認し、データが途中で改ざんされていないことを確かめます。イメージとしては、重要な手紙を鍵のかかる封筒に入れ、受取人が本物かどうかを確認する仕組みです。

ネットワークの構造では、SSL/TLSはアプリケーション層（例：HTTP）とトランスポート層（例：TCP）の間に位置するミドルレイヤで動作します。例えば、HTTPSはHTTPの上にTLSを重ねて安全な通信を実現します。

以下の章で、通信開始時のハンドシェイク、証明書のやり取り、共通鍵の確立、実際の暗号化通信、セッション管理、そして実装の形態まで順を追って説明します。初心者の方にも理解しやすいよう、用語は最小限にして具体的な例で補足します。どうぞ安心して読み進めてください。

SSL/TLSの基本定義と役割

定義

SSL（Secure Sockets Layer）は、ウェブブラウザとウェブサーバー間のデータを暗号化して安全にやり取りする仕組みです。現在は改良されたTLS（Transport Layer Security）が標準です。日常ではブラウザのアドレスが「https://」になることで使われていると分かります。

主な役割

プライバシー：通信内容を第三者に読まれないようにします。例えば、ログイン情報やクレジットカード番号を守ります。
認証：通信相手が本当にそのウェブサイトかどうかを確認します。銀行サイトで偽サイトを見分ける助けになります。
データ整合性：送ったデータが途中で改ざんされていないことを確認します。

簡単な仕組みのイメージ

サーバーが証明書（身元を証明する電子文書）を提示します。
ブラウザが証明書の発行元を確認し、問題なければ鍵交換を行います。
以後は共通鍵で高速に暗号化して通信します。具体例としては、オンラインショップでカード番号を安全に送る場面を想像してください。

よくある利用例

ウェブサイト（HTTPS）
API通信やモバイルアプリのサーバー接続
一部のメールやファイル転送の保護

注意点

証明書の有効期限や信頼できる発行元かを確認する必要があります。古いプロトコルや弱い暗号は脆弱性につながるため、最新版のTLSや適切な設定を使うことが大切です。

（章のまとめは省略します）

TLSハンドシェイクプロセス – Client Hello

概要

通信開始時、クライアントは最初に「Client Hello」メッセージを送ります。これはサーバーに対して「こういう暗号方式や設定で通信したいです」と提案するものです。これにより双方が使う暗号の候補をすり合わせる準備を整えます。

Client Helloの主な項目

TLSバージョン候補：クライアントが対応するバージョンを知らせます。サーバーが選びます。
クライアントランダム：乱数（client_random）を送り、後で鍵生成に使います。再生攻撃を防ぎます。
対応可能な暗号スイート：暗号や鍵交換の組み合わせをリストします。サーバーが一つ選びます。
セッションID（再利用時）：以前のセッションを再開するためのIDを送ることがあります。
拡張（例：SNI、ALPN、サポート曲線、署名方式）：どのホストに接続するか（SNI）やアプリプロトコル（ALPN）など、追加情報を送ります。

TLS1.3での違い

TLS1.3では、Client Helloに鍵共有（key share）を含めて、鍵確立を速くします。これにより往復回数が減り、接続確立が高速化します。

実際の流れ（短く）

クライアントがClient Helloを送る。 2. サーバーが受け取り、最適な設定を選んで応答する。これが安全な通信の出発点です。

TLSハンドシェイクプロセス – Server Helloと証明書交換

Server Hello の役割

サーバーは Client Hello に応じて「Server Hello」で返答します。ここで通信に使うTLSのバージョンや暗号方式、サーバー側のランダム値を決定します。これによりクライアントとサーバーの条件がそろい、次の手順へ進みます。

Server Hello に含まれる主な項目

選択されたTLSバージョン（例: TLS 1.2/1.3）
暗号スイート（例: AESによる暗号化と鍵交換方式）
サーバーランダム（セッションごとに変わる乱数）
サーバー証明書（次節で詳述）

サーバー証明書とトラストチェーン

サーバー証明書はサーバーの正当性と公開鍵を示します。証明書は通常、発行者（CA）により電子署名されます。複数の証明書をたどる「トラストチェーン」により、最終的に信頼済みのルート証明書までつながることで信頼が成立します。クライアントはチェーンを検証し、署名が有効か、発行先ドメインが一致するか、有効期限内かを確認します。

証明書の検証ポイント

ドメイン名（ホスト名）が証明書の対象と一致するか
有効期限内か
発行元の署名がルートまで遡って信頼できるか
失効リスト（CRL/OCSP）で取り消されていないか

その他のやり取り

鍵交換に追加情報が必要な場合は Server Key Exchange を送ります。サーバーがクライアント証明書を要求する場合は Certificate Request を送ります。これらの後、共通鍵確立の段階へ進みます。

共通鍵の確立と暗号化通信の開始

共通鍵はどう作るか

クライアントとサーバーはそれぞれ秘密の値（自分だけが知る数字）を作ります。互いにその値から計算した“公開値”だけを送り合い、受け取った公開値と自分の秘密値を組み合わせて同じ共通鍵を導き出します。秘密そのものは送られないため安全です。TLS 1.3では一時的な鍵を使うため、過去の通信が後で漏れても安全性が保たれます（フォワードセキュリティ）。

TLS 1.3 と1-RTT

TLS 1.3ではハンドシェイクの効率が上がり、通常は1回の往復（1-RTT）で共通鍵が確立します。クライアントが最初に送った情報にサーバーが応答すると、両者はほぼ同時に共通鍵を作成し、すぐに暗号化通信を開始できます。これにより接続の遅延が少なくなります。

共通鍵で始まる暗号化通信

共通鍵ができると、AES-GCMのような共通鍵暗号でデータを速く安全に暗号化します。暗号化されたデータは記録レイヤーで送られ、両方が同じ鍵で暗号化・復号します。ハンドシェイク終了時に交換されるFinishedメッセージで、手順が正しく行われたことを相互に確認します。これによって、以降の通信は盗聴や改ざんから守られます。

具体例（イメージ）

郵便で秘密の箱を交換する代わりに、両者が同じ鍵で箱を作るような仕組みです。箱そのものは共有しませんが、開けられる鍵は両方で同じになります。これで高速に安全なやり取りができます。

実際の暗号化通信とデータ保護

共通鍵での高速暗号化

ハンドシェイクで決まった共通鍵（共有の秘密）を使い、通信データはAESなどの高速な共通鍵暗号で暗号化します。共通鍵暗号は処理が速いため、ウェブページの閲覧やファイル送受信など実用的な速度で使えます。たとえば、銀行サイトにパスワードを送るときは、この暗号で中身を秘匿します。

改ざん検知（MAC／AEAD）

盗聴だけでなく、途中で内容を書き換えられることを防ぐため、各メッセージに改ざん検知用の付加情報を付けます。従来はMAC（メッセージ認証コード）を別に付けて検証しました。最近はGCMのようなAEAD方式で、暗号化と改ざん検知を同時に行う方式が多く、処理と安全性の両方で有利です。受信側はまず検証し、不正なら破棄します。

Recordプロトコルの役割

Recordプロトコルがデータの圧縮、暗号化、復号を順に担当します。送信側ではデータを（必要なら）圧縮し、改ざん検知情報を付け、暗号化してレコード単位で送ります。受信側では復号して検証し、問題なければ上位へ渡します。パケットの順序管理や再送の検出に使うシーケンス番号も付与され、再生攻撃（古いデータの繰り返し）を防ぎます。

実務上の注意点

暗号化は正しく使うことが重要です。初期化ベクトル（IV）やノンス（使い捨て値）を適切に管理しないと安全性が落ちます。性能面では、通信のたびに小さなデータを何度も暗号化すると効率が下がるため、TLSはデータをまとめて処理します。

セッション管理と複数セッション対応

概要

SSL/TLSのセッションはハンドシェイクで作られる接続情報です。毎回フルハンドシェイクを行わず、既存のセッション情報を使うことで接続を早くできます。

セッション確立と再利用

初回はフルハンドシェイクで鍵や認証を行います。再接続時は“再開（resumption）”を使い、短い手順で暗号鍵を導出します。これにより遅延が減り、サーバーの計算負荷も下がります。

セッションIDとセッショントークン

従来はセッションIDを交換し、サーバーが情報を保持しました。別の方式であるセッショントークン（Session Ticket）はサーバー側で状態を持たず、クライアントに暗号化した情報を渡します。運用の都合で使い分けます。

サーバーの管理（キャッシュと期限）

サーバーはセッション情報を一定期間保存します。短くすると安全ですが再接続の利便性は下がります。長くすると効率は上がりますが、失効管理を厳密にする必要があります。

クライアントと複数セッション

同じクライアントは複数のセッションを同時に持てます。例えばブラウザは複数タブでそれぞれセッションを再利用します。各セッションごとに有効期限や暗号仕様が管理されます。

TLS 1.3の違い

TLS 1.3では再開が簡素化され、0-RTTと呼ぶ即時送信の仕組みもあります。速さは向上しますが、0-RTTはリプレイ攻撃の対策を考慮する必要があります。

運用上の注意点

キャッシュサイズ、期限設定、鍵の回転方針を決めると安全と性能のバランスを取れます。ログや監視を整え、不要な長期保持を避けてください。

SSL/TLSとレイヤ構造

レイヤの位置と役割

SSL/TLSはアプリケーション層（例：HTTP）とトランスポート層（例：TCP）の間に入り、暗号化と認証を提供します。ブラウザがHTTPSで通信するときは、アプリケーションのデータを受け取り、下位のTCPへ渡す前に暗号化します。これにより、上位アプリケーションは平文のまま扱え、下位では暗号化されたパケットが送受信されます。

なぜ中間層が便利か

ミドルレイヤとして動作するため、既存のアプリケーションを大きく変えずに安全性を高められます。たとえば、既存のWebアプリはそのまま動き、SSL/TLSが通信の機密性と改ざん防止を担います。

SSLプロキシの役割

SSLプロキシはTLS接続を受け止めて復号し、内容を検査してから再暗号化して転送します。企業がマルウェア検査や情報漏洩防止を行う際によく使います。具体的には：
– TLSを終端（復号）してトラフィックをチェック
– 必要であればポリシーに従って通信を遮断
– 別のTLS接続で目標サーバへ再接続

利点と注意点

利点は検査や監査が可能になることと、アプリケーション側の改修が不要な点です。一方で、復号によりプライバシーの懸念が生じます。プロキシを使う場合は、社内の信頼できる証明書を配布してクライアントが受け入れるようにし、秘密鍵の管理や性能への影響にも注意してください。

具体例

社内のメールゲートウェイがSSLプロキシを使い、受信メールを復号してウイルススキャンを実行、問題なければ再暗号化して配信します。これにより既存のメールサーバは改修せずにセキュリティを強化できます。

SSL/TLSの実装形態

フォワードプロキシ（クライアント保護）

フォワードプロキシは社内クライアントと外部サーバー間の通信を仲介します。プロキシが一度TLSを終端して復号し、ウイルスチェックや不正通信の検出を行います。具体例として、社内のPCから外部Webサイトへ接続するとき、企業のプロキシが中継して安全性を確認します。実装にはプロキシ用のCA証明書をクライアントに配布する必要があります。これによりプロキシは”中間者”として振る舞えます。