SSLとヘッダの基本構造と暗号通信の仕組みを詳しく解説

2025 11/28

2025/11/28

はじめに

概要

本資料は、SSL/TLS通信における「SSLヘッダー」の構造と役割を分かりやすく説明します。専門的な説明を必要最小限に抑え、具体例を交えて理解しやすくまとめました。

この資料の目的

SSLヘッダーがどのように通信の安全性や信頼性を支えるかを明らかにします。ヘッダーの各フィールドが果たす役割や、ペイロードとの関係、改ざん検知やハンドシェイクでの重要性まで丁寧に解説します。

SSLヘッダーとは（簡単な例）

封筒で例えると、宛名や差出人に当たる部分がヘッダーです。受け取る側はヘッダーを見て中身の種類や扱い方を判断します。通信でも同様に、ヘッダーはデータの種類や長さ、保護方法を示します。

本資料で学べること

SSLレコードの基本概念
ヘッダーのフィールド構成と役割
ペイロードと改ざん検知の仕組み
ハンドシェイクから暗号化開始までの流れ

読み進め方

各章は段階的に理解できるように構成しました。まずは第2章から読み進めることをおすすめします。必要に応じて例や図を参照してください。

SSLレコードの基本概念

1. SSLレコードとは

SSLレコードは、SSL/TLSでやり取りする「ひとかたまりのメッセージ」です。データを安全に送るための最小単位で、送り手と受け手が同じルールに従って扱います。郵便の封筒に例えると、中身（データ）を包む封筒がSSLレコードです。

2. フォーマットの基本要素

主な要素は次の通りです。
– コンテンツタイプ：何を送るか（例：ハンドシェイク、アプリケーションデータ）を示します。
– バージョン：使うSSL/TLSのバージョンを示します。互換性の確認に使います。
– 長さ（Length）：中身のサイズを示します。
– ペイロード：実際のデータです。暗号化や署名がここに適用されます。

3. わかりやすい具体例

短いメッセージを送るときは1つのレコードに収まります。長いファイルは複数のレコードに分けます。封筒に手紙を入れて何通かに分けて送るイメージです。

4. サイズと分割の理由

ネットワークの効率や暗号処理の制約から、レコードには上限サイズがあります。大きなデータは分割して送ると、復元や再送が簡単になります。

5. 通信の安全性における役割

レコードごとに暗号化や改ざん検知が行われます。これにより、途中でデータが見られたり、勝手に変えられたりするのを防ぎます。普段意識しなくても、レコードが安全な通信の土台になります。

SSLヘッダーの構造と役割

概要

SSLヘッダーは、受信側が後続のデータを正しく扱うための「案内表示」のような役割を果たします。主に3つの情報を持ち、どの種類のデータが来るのか、どのプロトコル規格に従うか、そして後ろに続くデータの長さを知らせます。これにより安全な通信の処理順序を保てます。

各フィールドの詳細

コンテンツタイプ
何のデータかを示します。例として、通信の開始手続き（ハンドシェイク）、実際の送受信データ（アプリケーションデータ）、警告メッセージなどがあります。受信側はこれで処理経路を決めます。
プロトコルバージョン
どのバージョンの仕様に従って処理するかを示します。互換性の違いに対応するために重要です。たとえば古い仕様と新しい仕様で処理方法が変わる場合、受信側は適切な処理を選びます。
ペイロード長
後続するデータのバイト数を示します。通常は固定長のフィールドで表し、受信側はこの長さを読んで正確にデータを取り出します。長さが不正だと通信を中断する判断になります。

受信時の具体的な働き

受信側はまずヘッダーを読み、コンテンツタイプで処理先を決めます。次にバージョンを確認して互換性をチェックし、ペイロード長で必要なバイト数だけ読み取ります。たとえば「アラート」なら即時処理し、「ハンドシェイク」なら鍵交換の手順に渡します。

注意点

ヘッダー情報は通信の流れを制御する重要な手がかりです。長さやタイプに矛盾があるとエラーやセキュリティ上の問題につながります。パケット損失や改ざんの可能性がある場合は接続を切るなど厳密に扱う必要があります。

SSLペイロードの役割

概要

SSLヘッダーの後に続くペイロードは、実際に暗号化されるデータ本体です。クライアントとサーバーが交換するアプリケーションデータがここに入ります。たとえば、ウェブページのHTMLやAPIのJSON、ファイルの一部などです。

ペイロードの中身と例

ペイロードはアプリケーションが送る生のデータを含みます。例として、ブラウザが送るHTTPリクエストやサーバーから返るHTTPレスポンスが該当します。画像や動画の断片もペイロードになります。

暗号化の仕組み（やさしい説明）

送る前にデータを「箱」に入れて鍵で閉めるイメージです。実際は初期化ベクトルやパディング、認証タグが付加され、安全性を確保します。復号すると箱を開けて中身を取り出します。

分割と再構築

大きなデータは複数のペイロードに分割して送ります。受け側は順序を確認して再構築します。順序が乱れると正しく復元できないため、シーケンス管理が重要です。

実運用での注意点

ペイロードのサイズ制限やタイムアウト、認証失敗時の扱いに注意します。エラーが起きた場合は再送やセッションの再構築が行われます。

データ改ざん検知メカニズム

受信側がデータの改ざんを検知する基本は、送信側が付けた短い値（ハッシュやMAC）と受信側が計算した値を比べることです。送信側は元のデータからハッシュ値を作り、それをデータに添付して送ります。受信側は受け取ったデータから同じ方法でハッシュを算出し、添付された値と一致するか確認します。値が同じなら改ざんされていないと判断します。

ハッシュは一方向関数で、わずかな違いで全く異なる出力になります。たとえば“apple”と“applf”では元の文字列に1文字の違いがあるだけですが、ハッシュは大きく変わります。この性質で改ざんの有無を高精度で検出できます。ハッシュだけでは偽装される恐れがあるため、実際の通信では秘密鍵を使ったMAC（例：HMAC）を併用します。秘密鍵を知らない第三者は正しいMACを作れないため、安全性が高まります。

改ざん検知は暗号化と組み合わせて使います。暗号化は内容の秘匿を守り、MACは内容の完全性を守ります。さらに、順序番号やタイムスタンプを用いることで、再送や差し替えといった攻撃も防止できます。これらを組み合わせることで、受信側は受け取ったデータが正真正銘であることを確実に確認できます。

ハンドシェイクプロセスにおけるヘッダーの役割

概要

ハンドシェイクでは、クライアントとサーバーが連続するSSLレコードを交換します。各レコードはヘッダー（種類、バージョン、長さ）を持ち、このヘッダーがメッセージ処理の道しるべになります。

ヘッダーが果たす主な役割

種類の識別：ヘッダーの「Content Type」によって、その後のペイロードが何かが分かります。たとえば“Handshake”（値22）はClientHelloやServerHelloなどの手順を示し、“Change Cipher Spec”（値20）は暗号切替を指示します。サーバーやクライアントはこの値を見て適切に処理します。
バージョン確認：ヘッダーにあるプロトコルバージョンで互換性をチェックします。双方が対応しないバージョンを示すと接続が中断され、問題の早期検出に役立ちます。
長さと断片化の管理：ヘッダーの長さフィールドでレコードの終わりを判断します。大きなメッセージは複数のレコードに分割され、受信側はヘッダーの長さを頼りに再結合します。

ハンドシェイク各段階での動き（例）

ClientHelloはヘッダーでHandshake種別を知らせ、サーバーは読み取りを開始します。ヘッダーのバージョンや長さを確認して処理を続けます。
ServerHelloや証明書送信も同様にHandshakeヘッダーで運ばれ、受信側は証明書の大きさに応じて断片をつなぎ合わせます。
クライアントがマスター（プレマスター）シークレットを送る際は、暗号化が適用される前と後でヘッダーの扱いが変わります。Change Cipher Specメッセージのヘッダーを受け取ると、その次のレコードからはペイロードが暗号化されていると解釈します。