見えるセキュリティ
TLSフルハンドシェイク
TLS FULL HANDSHAKE
この概念とは？
TLSフルハンドシェイクは、Client（接続する側）とServer（接続先）が、前回の接続の再開情報を使わずに、安全な通信を始める準備をするやり取りです。通信に使う方式を決め、接続先の確認や、通信を守る鍵の準備を行います。
TLS 1.3とTLS 1.2は、TLSのバージョンです。目的は共通ですが、公開情報を送る順番や、通信を保護し始めるタイミングなどに違いがあります。タブを切り替えて、それぞれの流れを見てみましょう。
- THEME
- crypto
- KIND
- protocol
- REVIEW
- self-reviewed ·
公開情報から鍵を準備し、接続先を確かめて、データを守って送る流れ
ここでは、証明書と一時的な鍵共有を使うTLS 1.3のフルハンドシェイクを扱います。セッション再開・0-RTT・Clientの証明書認証は別の教材で扱います。
- ClientHelloClientからServerへ
方式候補・鍵共有の公開情報
STEP 1 まで表示しています。続きは「次へ」で追加します。
- Clientから送る
- Serverから送る
- 端点内の処理には通信矢印を付けない
縦の間隔・動く速さは実際の処理時間ではありません。STEPは学習上の区切りで、パケット数や往復数とは別です。
STEP 01 / 6
Clientが接続を提案する
STEP 1 / 6: Clientが接続を提案する
Clientは、使える通信方式と、鍵を作るための公開情報をServerへ送ります。公開情報のもとになる秘密の値は、Clientの中に保ちます。
このSTEPで押さえること
公開情報は送る。秘密の値はClientの外へ出さない。
技術的な詳細を見る
この例では、Clientが接続ごとの一時秘密値とECDHEの公開値を用意します。公開値はClientHelloのkey_shareに含めて送ります。ClientHelloにはバージョンや暗号方式などの候補も入ります。秘密の値を送るわけではありません。
この概念の要点
防御
秘密の値は送らず、各自で鍵を作る
相手へ渡すのは鍵共有の公開情報です。共有秘密や秘密鍵そのものを送り合うわけではありません。
要点
接続準備の途中から保護する
ServerHelloの後の証明書・署名・Finishedも、ハンドシェイク用の鍵で保護します。
防御
接続先の確認とデータ保護は役割が違う
証明書と署名で接続先を確認し、HTTPなどのデータは方向別の通信鍵で保護します。
要点
Clientは追加の完了通知を待たない
Server Finishedを検証し、自分のFinishedを送ると、Clientはデータを送り始められます。
理解確認
参考資料
- RFCRFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3
RFC 9846TLS 1.3のハンドシェイク、鍵スケジュール、record protection仕様
- RFCRFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 5280X.509証明書と証明書パス検証の仕様
- RFCRFC 9525: Service Identity in TLS
RFC 9525TLSで接続先サービスのidentityを検証する仕様
- RFCRFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
RFC 5246TLS 1.2のハンドシェイクとレコード保護
- RFC
- RFCRFC 7627: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
RFC 7627EMSによる記録と鍵導出の結び付け
- RFCRFC 5289: TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)
RFC 5289TLS 1.2のECDHE_RSAとAES-GCMの方式