TLS 1.2 ハンドシェイク

サーバーから証明書と一時的な ECDHE 公開鍵が送信されますが、クライアントはなぜ証明書の検証だけで暗号化を開始できないのでしょうか。証明書は長期アイデンティティと紐付けられ、ハンドシェイクの署名は一時的なパラメータをそのアイデンティティに紐付け、Finished メッセージは双方が交渉履歴とキーの解釈を一致させていることを確認します。これら3つのチェックが相互に連携して、認証可能な安全なチャネルを構成します。

本稿では、TLS 1.2、ECDHE、AEAD を用いた完全なサーバー認証ハンドシェイクを主に解説し、従来の RSA キー交換および復元の差異についても説明します。TLS 1.2 のすべての歴史的オプションが今日すべて有効化に適しているわけではありません。現代のデプロイメント選択は、セキュリティ使用規範とクライアントの互換性を組み合わせて行うべきです。RFC 9325：TLS のセキュリティ使用

2026年9月時点で、TLS 1.3 の更新仕様 RFC 9846 が公開され、RFC 8446 および関連するいくつかの旧版ドキュメントに取って代わり、TLS 1.2 実装に対する新たな要件も規定しています。本稿で RFC 5246 などを引用しているのは、TLS 1.2 のメカニズムを正確に説明するためであり、歴史的なオプションを現在のデプロイメントのベースラインとして扱わないためです。RFC 9846

まず TCP、TLS レコード、およびハンドシェイクメッセージを区別する

TLS は通常 TCP 上で動作しますが、TCP セグメント、TLS レコード、および Handshake メッセージは3つの異なる境界です。1つのハンドシェイクメッセージが複数のレコードに跨がることもあれば、1つのレコードに複数のハンドシェイクメッセージが含まれることもあります。TCP パケットをキャプチャしたからといって、完全な Certificate が確認できるわけではありません。

TLS 1.2 レコードの固定ヘッダーは 5 バイトで、コンテンツタイプ、バージョン、および長さを表します。Handshake メッセージには、さらに 1 バイトのタイプと 3 バイトの長さが追加されます。ハンドシェイクトランスクリプトは、プロトコルのハンドシェイクメッセージエンコーディングに従って累積され、イーサネットフレームや TCP セグメントのバイト列をそのままハッシュするものではありません。RFC 5246：記録層とハンドシェイク

4つのフライト：約2回の TLS ラウンドトリップ

クライアントが最初に ClientHello を送信し、サーバーは選択結果、証明書、および署名付きの一時的なパラメータを返します。クライアントが検証後、独自の一時的な公開鍵を送信し、保護に切り替えて Finished を送信します。サーバーが検証後、切り替えて Finished を返します。通常の完全なハンドシェイクは約2 RTT かかり、TCP 接続確立、DNS、再試行、および証明書処理は含まれません⁠。また、どのような拡張を使用しても固定の所要時間がかかるわけではありません。

ECDHE パスでは、サーバーは共有秘密を計算しますが、「クライアントが送信した pre_master_secret を RSA 秘密鍵で復号する」わけではありません。後者は別の歴史的なキー交換方式です。オプションのクライアント証明書認証では、CertificateRequest、クライアントの Certificate/CertificateVerify などのメッセージが追加され、mTLS については別篇で詳しく解説します。

ClientHello/ServerHello：選択には共通のコンテキストが必要

ClientHello には、バージョン、32 バイトのランダム、スイートリスト、および拡張が含まれます。ServerHello では、利用可能なバージョン、スイート、および対応する拡張の結果が選択されます。歴史的な Random フォーマットのタイムフィールドは信頼できるクロックやクライアントシステムのフィンガープリントとして使用できません。現代の実装も、ビジネスロジックの時間的セマンティクスを担うためにこれに依存すべきではありません。

SNI はサーバーが仮想ホストと証明書を選択するのに役立ちますが、クライアント側のサービスアイデンティティ検証を代行するものではありません。ALPN は h2 や http/1.1 などのアプリケーションプロトコルを交渉します。TLS が成功した場合でも、アプリケーション層は選択されたプロトコルに従わなければならず、ALPN と一致しないコンテンツを送信し続けることはできません。RFC 6066：SNI、RFC 7301：ALPN

supported_groups、署名アルゴリズム、およびスイートは異なる制約です。特定の楕円曲線をサポートしていても、任意の証明書アルゴリズムを受け入れるわけではありません。TLS 1.2 では歴史的に圧縮を交渉できましたが、現代のセキュリティ設定ではレコード圧縮を無効にするべきです。現代の要件を「RFC 5246 が null 以外の圧縮を定義していなかった」と誤解してはいけません。

スイート名の分解：RSA は署名のみを担当する場合もある

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 を例に挙げます：

例えば、AES-256-GCM-SHA384 スイートでは SHA384 PRF が使用されます。スイートは登録された全体の組み合わせであり、4つの文字列を任意に連結して有効なスイートが生成されるわけではありません。ハンドシェイク署名に使用されるハッシュは、署名アルゴリズムの交渉によって制約され、スイート名の末尾と一致する必要はありません。RFC 5289：ECC AEAD スイート

ECDHE：一時的なパラメータに署名し、共有秘密を計算

クライアントの一時的な秘密鍵を a、公開鍵を aG、サーバーの一時的な秘密鍵を b、公開鍵を bG とします。適切なパラメータチェックと認証を経て、双方はそれぞれ a(bG) と b(aG) を計算し、同じ共有秘密を得ます。オンライン上では a、b、または共有秘密自体が直接送信されることはありません。

サーバーは、証明書に対応する秘密鍵を使用して、ClientHello.random、ServerHello.random、および規定された ECDHE パラメータエンコーディングに署名します。クライアントは証明書チェーンと期待される名前をチェックするだけでなく、この署名も検証する必要があります。任意の ECDHE 公開鍵を受け入れると、中間者によるパラメータの置き換えの余地が残ります。RFC 8422：TLS ECC ハンドシェイク

前方秘匿性は、一時的なキー交換と秘密の適切な管理によってもたらされます。将来、長期の署名キーが漏洩しても、過去のキャプチャから破棄された一時的な DH 秘密を直接復元すべきではありません。これは、実行中のエンドポイントが侵害された場合にメモリ内のセッションを保護することを保証するものではなく、セッションチケット保護キーの漏洩を自動的に上書きするものでもありません。

従来の RSA key exchange では、クライアントが PMS を生成し、証明書の RSA 公開鍵で暗号化し、サーバーが復号します。記録されたトラフィックが保存された後、長期の復号用秘密鍵が漏洩すると、過去の秘密に影響を与えます。ここではプロトコルの差異を理解するために使用されており、新しいデプロイメントの推奨事項としては扱いません。RFC 5246：RSA と DH の計算

master_secret：従来の派生と EMS

古いキャプチャ資料との対比を容易にするため、本節では RFC 5246 の変数名を保持します。RFC 9846 では、master secret は main secret に、premaster secret は preliminary secret に、EMS は Extended Main Secret に改名されました。オンライン上の PRF ラベルは互換性を保つ必要があり、コード内のリテラルラベルをそれに合わせて改名すべきではありません。RFC 9846 付録 D

従来の TLS 1.2 派生式は以下の通りです：

master_secret = PRF(PMS, "master secret", client_random || server_random)[0:48]

EMS が交渉に成功した場合、"extended master secret" ラベルと規定された session_hash を使用し、メインシークレットを今回のハンドシェイクコンテキストにバインドします。EMS の保護について述べた後でも、古い式のみを列挙してすべてのハンドシェイクに適用可能と主張してはいけません。RFC 7627：Extended Master Secret

次に、レコード保護に必要な材料を生成します：

key_block = PRF(master_secret, "key expansion", server_random || client_random)

ここで、2つの random の順序は従来の master_secret 式とは逆です。PRF ラベル、入力順序、ハッシュ、および長さが結果に関与するため、双方が同じ PMS を持つからといって任意に連結することはできません。クライアント書き込みキーはクライアント送信方向に使用され、サーバー書き込みキーは逆方向に使用されます。

AES-128-GCM の例では、16 バイトの write key が2つ、4 バイトの固定 IV が2つ必要で、合計 40 バイトです。独立した write_MAC_key の長さはゼロです。AEAD は自身でレコード認証を提供するため、ここでは独立したレコード HMAC キーは割り当てられません。GCM nonce には各レコードの 8 バイトの明示的な部分も含まれており、固定 IV が各レコードで完全に同じ nonce を再利用可能であることを意味するものではありません。RFC 5288：TLS GCM

CCS と Finished：保護への切り替えと履歴の確認

TLS 1.2 の ChangeCipherSpec は独立したプロトコルメッセージであり、相手側にその後で交渉された保護状態を使用するよう通知します。Finished はハンドシェイクメッセージであり、新しいレコード保護を使用して送信され、その verify_data は master_secret、方向ラベル、およびトランスクリプトハッシュに基づく PRF 出力です。本例では 12 バイトです。RFC 5246：Finished

Finished は、サーバーが証明書の秘密鍵を使用して再度デジタル署名を行うものではありません。その検証には共有秘密が必要であり、交渉履歴もバインドされます。クライアント Finished のトランスクリプトには自身は含まれず、その後サーバー Finished のトランスクリプトには、すでに送信されたクライアント Finished が含まれます。CCS は Handshake メッセージとしてトランスクリプトには組み込まれません。

サーバー Finished の検証が完了して初めて、通常の完全なハンドシェイクフローに従ってこのフェーズが完了したと確信できます。特定の条件下で早期送信を許可する最適化もありますが、それらによってベースラインフローを任意に変更すべきではありません。TLS アラートと TCP 切断も異なります。プロトコルの終了セマンティクスとアプリケーションが自身のメッセージを完了したかどうかは、それぞれ別々に処理する必要があります。

入力を変更した場合、どの秘密が変化するか？

まず、従来のパスで他のハンドシェイクメッセージのみを変更します。メインシークレットとレコードキーは変更されず、Finished のみが変化します。次に EMS に切り替えると、同じ変更が session_hash を通じてメインシークレットおよび後続の出力に伝播します。色は実際のバイト比較に基づくものであり、事前に設定されたアニメーションではありません。

レコードオーバーヘッド：アプリケーションバイトはオンラインバイトと等しくない

本例の TLS 1.2 AES-GCM レコードでは、1000 バイトのアプリケーション平文に加え、8 バイトの明示的な nonce、16 バイトのタグ、および 5 バイトのレコードヘッダーがあり、TLS レベルでは合計 1029 バイトです。TCP/IP およびリンクヘッダーは未計上です。AEAD/CBC スイートによってオーバーヘッドは異なり、29 バイトを TLS 1.3 に適用することはできません。

レコードシーケンス番号などの情報は認証に関与し、受信側は接続状態に基づいて処理するため、レコードを任意に交換または変更しても、同じ有効なアプリケーションストリームが得られるわけではありません。アプリケーション側でメッセージレベルの重複排除やトランザクション確認が必要な場合、TLS はこれらのセマンティクスを代行して完了させるものではありません。

復元：セッション秘密の再利用と新しい接続状態の派生

Session ID 方式では、サーバーが ID を使用してキャッシュされたセッションを検索します。チケット方式では、セッション状態を、サーバーが復元可能で、機密性と完全性保護付きの形式でクライアントに渡すことができます。RFC 5077 では拡張交渉を通じて、NewSessionTicket ハンドシェイクメッセージでチケットが発行されます。最初のチケットが単に ServerHello 拡張に詰め込まれた blob であるとは言えません。RFC 5077：セッションチケット

復元が成功した場合、簡略化されたハンドシェイクが使用され、通常、サーバーが最初に ServerHello、CCS、Finished を送信し、クライアントが CCS、Finished を返すという約1 RTT の TLS 対話となります。双方は新しい random から接続キーを派生し、前回のすべてのレコードキー/nonce/シーケンス番号をそのまま引き継いで使い続けることはありません。

復元は、チケット/キャッシュの有効期限、キー、パラメータ、およびポリシーに応じて、拒否されて完全なハンドシェイクにフォールバックする場合があります。チケットメカニズムはセッションごとのサーバーストレージを削減しますが、サーバーが完全にステートレスであることを意味するものではありません。チケット保護キー、ローテーション、ポリシー、およびリソースの管理は依然として必要です。

公開で観察可能な暗号化されたチケット自体とチケットを復号できるサーバー保護キーの漏洩は、同じイベントではありません。後者は、カプセル化されたセッション秘密および関連する履歴トラフィックの露出を引き起こす可能性があります。クライアントが保存する復元秘密の盗難も影響を及ぼします。機密性とライフサイクルは、復元全体のメカニズムに基づいて分析すべきであり、「チケットの漏洩が必ずすべての履歴セッションの復号を意味する」と概括してはいけません。

ローカル PRF とエンコーディング予算

import hashlib
import hmac

def prf(secret,label,seed,length):
    seed = label+seed
    A = seed
    out = b''
    while len(out)<length:
        A = hmac.digest(secret,A,'sha256')
        out += hmac.digest(secret,A+seed,'sha256')
    return out[:length]

# 固定された公開教育用素材であり、本番キーではありません。
pms = bytes(range(32))
client_random,server_random = bytes(range(32)),bytes(range(32,64))
master = prf(pms,b'master secret',client_random+server_random,48)
assert len(master)==48
assert master != prf(pms,b'master secret',server_random+client_random,48)
transcript_hash = hashlib.sha256(b'teaching handshake transcript').digest()
ems = prf(pms,b'extended master secret',transcript_hash,48)
assert ems != master
block = prf(master,b'key expansion',server_random+client_random,40)
client_key,server_key,civ,siv = block[:16],block[16:32],block[32:36],block[36:40]
assert tuple(map(len,(client_key,server_key,civ,siv)))==(16,16,4,4)
assert client_key != server_key
finished = prf(master,b'client finished',transcript_hash,12)
changed = hashlib.sha256(b'changed handshake transcript').digest()
assert finished != prf(master,b'client finished',changed,12)
assert finished != prf(master,b'server finished',transcript_hash,12)
assert 1000+8+16+5==1029
print('TLS 1.2 PRF 入力順序、EMS 分離、方向別キー、Finished および GCM オーバーヘッド通過')

このコードは、SHA256 P_hash の組み合わせと依存関係をデモンストレーションするものであり、トランスクリプトは教育用のプレースホルダーバイトであり、完全な TLS ハンドシェイクではありません。実際の証明書の生成、外部サービスとのハンドシェイク、または TLS 設定の変更は行われません。

参照

• TLS 1.3 ハンドシェイク：キータイミング、HKDF、および事前共有 key share。
• 証明書と PKI：チェーン、名前、および用途の検証。
• mTLS と双方向認証：クライアントアイデンティティとアプリケーション認可。