メインコンテンツへスキップ

🔑 TLS1.3ハンドシェイクの流れを理解する

🌱 はじめに

TLS1.3は従来のTLSよりも「速く、安全」に通信を始められるように設計されています。その肝となるのがハンドシェイクの簡略化です。ここではTLS1.3のハンドシェイクを、図解を交えながら順を追って説明します。

📡 TLS1.2までとの違い

  • TLS1.2まで

    • 2往復（2-RTT）必要

    • RSA鍵交換や署名方式など、古い仕組みが多く複雑

  • TLS1.3

    • 1往復（1-RTT）で暗号化開始

    • Forward Secrecy必須（ECDHEベース）

    • 不要な暗号やメッセージを削除

TLS1.3の大きな進化は「セキュリティ強化」と「ラウンドトリップ削減」の両立にある。

🛠️ ハンドシェイクの流れ（1-RTTの場合）

① ClientHello

  • クライアント（ブラウザなど）が送信。

  • 含まれるもの:

    • サポートする暗号スイート（AES-GCM, ChaCha20など）

    • サポートする鍵交換方式（ECDHEなど）

    • 乱数（ランダム値）

    • 0-RTT再利用用のトークン（あれば）

② ServerHello

  • サーバーが受信し、利用する暗号スイートを決定。

  • サーバー乱数を生成。

  • ECDHEの公開鍵を送信。

  • TLS1.3以降は、ここからすでに暗号化が始まる。

③ サーバー証明書 & CertificateVerify

  • サーバーが自分の正当性を証明するために証明書を送信。

  • 証明書の秘密鍵で署名し、改ざんがないことを確認できる。

④ Finished（サーバー→クライアント）

  • サーバーが「ここまでの通信内容に改ざんがない」ことをMACで示す。

⑤ Finished（クライアント→サーバー）

  • クライアントも同様にFinishedを送り、これで相互に認証が完了。

  • 以降の通信はアプリケーションデータとして暗号化される。

🔄 0-RTTの流れ（再接続時）

  • すでに過去に接続してセッション情報が保存されている場合、クライアントはClientHelloの直後にデータを送れる。

  • 初回の応答を待たずに送れるため遅延がほぼゼロに。

  • ただし「リプレイ攻撃」に弱いため、サーバー側で再送を防ぐ工夫が必要。

📝 ハンドシェイクの全体像（図解）

Client                        Server
  |   ClientHello   -------->   |
  |                             |
  |   <--------   ServerHello   |
  |   <---- EncryptedExtensions |
  |   <--- Certificate          |
  |   <--- CertificateVerify    |
  |   <--- Finished             |
  |                             |
  |   Finished   ------->       |
  |                             |
  |   [暗号化通信開始]            |

TLS1.2では2往復かかったやりとりが、TLS1.3では1往復で完了する。

🎯 まとめ

TLS1.3のハンドシェイクは、

  • ClientHello → ServerHello → 相互Finished のシンプルな流れ

  • Forward Secrecyの徹底

  • 0-RTTによる再接続高速化

によって、より安全で高速な通信開始を可能にしています。


上に戻る