TLS ハンドシェイクの流れ

TLS ハンドシェイクとは

TLS ハンドシェイクは、クライアントとサーバーが暗号化通信を開始する前に、使用する暗号方式の合意、鍵の交換、サーバーの認証を行うプロセスです。

HTTPS との関係: HTTPS は「HTTP over TLS」です。HTTP 通信の前に、まず TLS ハンドシェイクで暗号化チャネルを確立します。

TLS ハンドシェイクの目的

TLS 1.2 ハンドシェイクの流れ（2-RTT）

TLS 1.2 では、ハンドシェイクに往復 2 回（2-RTT） かかります。

クライアント                                サーバー
    |                                           |
    |-- 1. ClientHello ------------------------>|
    |                                           |
    |<- 2. ServerHello + Certificate + Done ----|
    |                                           |
    |-- 3. ClientKeyExchange + Finished ------->|
    |                                           |
    |<- 4. Finished -----------------------------|
    |                                           |
    |== 5. 暗号化通信開始 ========================|

ステップ 1: ClientHello

クライアントがサポートする暗号スイートとパラメータをサーバーに送信します。

ClientHello:
- TLS Version: 1.2
- Random: (32 バイトの乱数)
- Cipher Suites:
  - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  - ...
- Extensions:
  - server_name: example.com (SNI)
  - supported_groups: x25519, secp256r1
  - ec_point_formats: uncompressed

ステップ 2: ServerHello + Certificate + ServerKeyExchange + ServerHelloDone

サーバーが暗号スイートを選択し、証明書と鍵交換パラメータを返します。

ServerHello:
- TLS Version: 1.2
- Random: (32 バイトの乱数)
- Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Certificate:
- Server Certificate Chain（サーバー証明書と中間証明書）

ServerKeyExchange:
- ECDHE Public Key（サーバーの ECDHE 公開鍵）

ServerHelloDone:
- （メッセージの終了を示す）

ステップ 3: ClientKeyExchange + ChangeCipherSpec + Finished

クライアントが鍵交換パラメータを送り、共通鍵を生成して暗号化を開始します。

ClientKeyExchange:
- ECDHE Public Key（クライアントの ECDHE 公開鍵）

ChangeCipherSpec:
- （以降のメッセージを暗号化することを通知）

Finished:
- （ハンドシェイクメッセージの MAC、暗号化されている）

この時点で、クライアントとサーバーは同じ共通鍵（セッション鍵） を持ちます。

ステップ 4: ChangeCipherSpec + Finished（サーバー）

サーバーも暗号化を開始し、ハンドシェイクが完了します。

ChangeCipherSpec:
- （以降のメッセージを暗号化することを通知）

Finished:
- （ハンドシェイクメッセージの MAC、暗号化されている）

ステップ 5: 暗号化通信開始

以降、HTTP リクエスト/レスポンスは共通鍵で暗号化されます。

[クライアント] --暗号化された HTTP リクエスト--> [サーバー]
[クライアント] <--暗号化された HTTP レスポンス-- [サーバー]

TLS 1.3 ハンドシェイクの流れ（1-RTT）

TLS 1.3 では、ハンドシェイクが往復 1 回（1-RTT） に短縮されました。

クライアント                                サーバー
    |                                           |
    |-- 1. ClientHello + KeyShare ------------->|
    |                                           |
    |<- 2. ServerHello + KeyShare + Finished ---|
    |                                           |
    |-- 3. Finished ---------------------------->|
    |                                           |
    |== 4. 暗号化通信開始 ========================|

主な改善点

ステップ 1: ClientHello + KeyShare

TLS 1.3 では、ClientHello に鍵交換パラメータ（KeyShare）を同時に送信します。

ClientHello:
- TLS Version: 1.3
- Random: (32 バイトの乱数)
- Cipher Suites:
  - TLS_AES_128_GCM_SHA256
  - TLS_AES_256_GCM_SHA384
- Extensions:
  - server_name: example.com (SNI)
  - key_share: (ECDHE 公開鍵を含む)
  - supported_groups: x25519, secp256r1

ステップ 2: ServerHello + KeyShare + Certificate + Finished

サーバーが鍵交換パラメータと証明書を返し、この時点で暗号化を開始します。

ServerHello:
- TLS Version: 1.3
- Random: (32 バイトの乱数)
- Cipher Suite: TLS_AES_128_GCM_SHA256
- key_share: (ECDHE 公開鍵)

EncryptedExtensions:（ここから暗号化）
- Extensions...

Certificate:
- Server Certificate Chain（暗号化されている）

CertificateVerify:
- 証明書の署名検証（暗号化されている）

Finished:
- ハンドシェイクメッセージの MAC（暗号化されている）

ステップ 3: Finished（クライアント）

クライアントが証明書を検証し、ハンドシェイク完了を通知します。

Finished:
- ハンドシェイクメッセージの MAC（暗号化されている）

ステップ 4: 暗号化通信開始

以降、HTTP リクエスト/レスポンスを交換します。

TLS 1.2 vs TLS 1.3 比較表

ECDHE 鍵交換の仕組み

ECDHE（Elliptic Curve Diffie-Hellman Ephemeral）は、TLS 1.3 で必須となった鍵交換方式です。

ECDHE の流れ

1. クライアントが秘密鍵 a を生成し、公開鍵 A を計算
   A = a × G（G は楕円曲線の基準点）

2. サーバーが秘密鍵 b を生成し、公開鍵 B を計算
   B = b × G

3. お互いの公開鍵を交換
   クライアント → サーバー: A
   サーバー → クライアント: B

4. 共通鍵を計算
   クライアント: S = a × B
   サーバー: S = b × A
   → どちらも S = a × b × G になり、同じ値になる

証明書検証の流れ

TLS ハンドシェイク中に、クライアントはサーバー証明書を検証します。

検証項目

証明書チェーンの例

[ルート CA]（ブラウザに内蔵）
    ↓ 署名
[中間 CA]
    ↓ 署名
[サーバー証明書]

サーバー証明書:
- Subject: CN=example.com
- Issuer: CN=Let's Encrypt Authority X3
- Public Key: (RSA 2048 bit)
- Signature: (中間 CA の秘密鍵で署名)

中間証明書:
- Subject: CN=Let's Encrypt Authority X3
- Issuer: CN=DST Root CA X3
- Signature: (ルート CA の秘密鍵で署名)

クライアントは、ルート CA の公開鍵（ブラウザに内蔵）で中間証明書を検証し、中間証明書の公開鍵でサーバー証明書を検証します。

SNI（Server Name Indication）

1 つの IP アドレスで複数のドメインを運用する場合、SNI で接続先のホスト名を通知します。

ClientHello:
- Extensions:
  - server_name: blog.example.com

サーバーは SNI を見て、対応する証明書を返します。

ALPN（Application-Layer Protocol Negotiation）

TLS ハンドシェイク中に、どのアプリケーション層プロトコルを使うかを決めます。

ClientHello:
- Extensions:
  - alpn: h2, http/1.1

ServerHello:
- Extensions:
  - alpn: h2

これにより、HTTP/2（h2）と HTTP/1.1 のどちらを使うかをハンドシェイク時に決定できます。

まとめ

TLS ハンドシェイクは、暗号化通信を開始する前の鍵交換・認証・暗号方式の合意を行うプロセスです。

TLS 1.3 では、1-RTT ハンドシェイク と前方秘匿性必須により、速度とセキュリティの両方が向上しています。現代の Web インフラでは TLS 1.3 の導入が推奨されます。

参考リソース

• RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
• Cloudflare - What happens in a TLS handshake?
• Mozilla - Server Side TLS
• RFC 6066 - TLS Extensions: SNI