見えるセキュリティ
TLS接続準備の再調整(HelloRetryRequest)
TLS 1.3 HELLO RETRY REQUEST
この概念とは?
HelloRetryRequestは、TLS 1.3の接続準備中に、ServerがClientへ挨拶の送り直しを求める仕組みです。ここでは、Serverが使いたい鍵共有方式の公開値をClientに用意してもらい、接続準備を続ける例を見ます。
Clientが対応できる方式でも、最初の挨拶にその公開値をすべて入れるとは限りません。Serverの要求に合わせて必要な値を送り直し、その後にServerの確認と通信の準備を進めます。
- THEME
- crypto
- KIND
- protocol
- REVIEW
- self-reviewed ·
Serverの要求に合わせて公開値を用意し直し、接続準備を進める流れ
A/Bは鍵共有方式の違いを示すラベルです。Clientは両方に対応していますが、最初はA用の公開値だけを送ります。この例ではServerがBを選びます。
- ClientHello 1ClientからServerへ
対応:A・B/実際に送る公開値:A用のみBにも対応しているが、B用の公開値はまだ送っていない。秘密値は送らない。
STEP 1 まで表示しています。続きは「次へ」で追加します。
- Clientから送る
- Serverから送る
- 端点内の処理には通信矢印を付けない
縦の間隔・動く速さは実際の処理時間ではありません。STEPは学習上の区切りで、パケット数や往復数とは別です。
STEP 01 / 7
Clientが最初の挨拶を送る
STEP 1 / 7: Clientが最初の挨拶を送る
ClientはAとBの鍵共有方式に対応しています。最初の挨拶では対応方式を伝え、A用の公開値だけを送ります。B用の公開値は、まだ送っていません。
このSTEPで押さえること
対応できる方式と、公開値を用意して送った方式は別です。A/BはTLS 1.3の鍵共有方式で、TLSバージョンの違いや安全性の優劣を示していません。
技術的な詳細を見る
ClientHelloのsupported_groupsは、Clientが対応できる鍵共有方式の一覧です。key_shareには、その中から実際に用意した公開値を入れます。対応方式すべての公開値を、最初から送る必要はありません。 この例ではAをX25519、BをP-256(secp256r1)として説明しています。どちらもTLS 1.3の鍵共有に使う方式で、TLS 1.2/1.3の違いや、データ暗号化方式の違いを表しているわけではありません。Aが危険・古いという意味でも、Bを常に優れた方式として推奨する意味でもありません。 TCP接続は確立済みとし、ECDHEとServer証明書を使うTLS 1.3フルハンドシェイクを扱います。Serverの証明書・署名用秘密鍵と信頼設定は準備済みです。双方でバージョン・暗号スイート・署名方式・鍵共有方式などの条件を合意できる成功例です。合意できる方式がなければ、この接続を中止します。 最初の挨拶と調整後の挨拶は、どちらもClientHelloです。説明上はClientHello 1/2と区別しますが、別のメッセージ型ではありません。PSK・セッション再開・0-RTT・Client証明書・QUIC・DTLSは、この図の主フローに含めません。
この概念の要点
要点
対応できることと、送ってあることは別
Clientが対応できる鍵共有方式でも、その公開値を最初の挨拶で送っているとは限りません。HRRでは、まだ提示していない方式の公開値を求められることがあります。
要点
接続準備の途中で調整する
ClientHelloを送り直しても、最初のやり取りは接続記録に含まれます。TCP接続からすべて作り直したり、過去の接続を再開したりする処理とは異なります。
要点
送り直した後も、相手の確認が必要
HRRだけでは相手を確認できません。公開値をそろえた後も、証明書、署名、Finishedを確認して、安全なデータ通信へ進みます。
要点
TLS 1.3でも往復が増える場合がある
今回は調整のために1往復分が加わります。TLSのバージョン名と、データ送信までに待つ往復数は別のものです。
理解確認
参考資料
- RFCThe Transport Layer Security (TLS) Protocol Version 1.3
RFC 9846IETF · HRRの条件・履歴・認証・鍵(2.1、4.1、4.2.1–4.2.4、4.3.2、4.3.7–4.3.8、4.5.2–4.5.3、7.1、7.3、7.4.2節)
- RFCExample Handshake Traces for TLS 1.3
RFC 8448IETF · HRRでX25519からP-256へ公開値を切り替える通信例(5節)。仕様要件はRFC 9846を参照
- RFCService Identity in TLS
RFC 9525IETF · Serverの識別情報と意図した接続先の照合(6、6.1.1節)
- RFCA Round-trip Delay Metric for IPPM
RFC 2681IETF · RTTの意味(2.3–2.4節)。TLSの待ち往復数はRFC 9846のフローから整理