要約

  • TLS session ticket は、server が再構成できる暗号状態を不透明なエンティティにし、client に保管させた。client は運び手であって、内容の解釈者でも受理の決定者でもない。
  • client ごとの記録を減らす代わりに、ticket 保護鍵、寿命、共有範囲という少数の server 状態が大きな影響力を持った。rotation と full handshake への fallback は仕組みの中心だった。

「番号を返す」から「封じた中身を返す」へ

TLS にはもともと session 再開があった。最初の handshake で決めた暗号 parameter を次の connection でも使えれば、重い公開鍵処理と round trip を繰り返さずに済む。

RFC 5246の TLS 1.2では、session は複数 connection で共有できる security parameter の集合であり、server が作る session identifier は active または再開可能な状態を指した。client が短い identifier を返すと、server は対応する record を探した。

この方式は、identifier そのものより背後の保管が難しい。大量の record を expire させ、fatal error 時に invalidate し、次の connection を受けた machine から読めるようにする必要がある。load balancer の後ろでは、同じ node へ戻すか、cache を共有するか、再開を諦めるかを選ばなければならなかった。

2006年のRFC 4507は、session-specific state を server に置かず再開する方法を示した。server は state を ticket へ封入して client へ渡す。2008年のRFC 5077は前文書を obsoletes し、同じ考えをより強い推奨構成で整理した。

client が返すものは、棚の番号ではなく、server が自分で封じた棚の中身になった。

client には不透明、server には再構成可能

RFC 5077の ticket は client にとって opaque である。推奨 format は key name、初期化値、暗号化された state、integrity check から成る。中には cipher suite、master secret、timestamp、最初の client authentication に関する情報を入れられる。

confidentiality は運び手に内容を見せず、integrity protection は寿命や identity や権限の改変を防ぐ。client は ticket だけでなく、関連する master secret と parameter も cache する。再開時には ticket を提示し、短縮 handshake の Finished を通じて必要な secret を持つことを示す。

したがって、通信路で ticket だけを複製しても、直ちに再開できるわけではない。一方、正規の ticket を持つ client にも、application の現在の権限が自動付与されるわけではない。account 停止や role 変更は TLS より上の層が再確認する。

物理的な保管を委ねることと、意味を決める権利を委ねることは別だった。

拒否しても壊れないことが必要だった

server は ticket を検証できない、または使いたくない場合、full handshake へ戻れる。未知の key、期限切れ、restart、別 region への到着、policy 変更はいずれも再開を断る理由になり得る。

この fallback は単なる互換性ではない。古い ticket を安全に捨てるための出口である。full handshake が不安定なら、operator は古い key を退役させにくくなる。performance optimization が availability の前提になれば、過去の state が現在を拘束する。

新 ticket の発行にも確認境界がある。server が送っただけでは、client が受け取り次回使うとは限らない。handshake 完了前に採用を前提とすれば、両端の記憶がずれる。

大量の record を少数の強い key へ変える

stateless という語が消したのは client ごとの server record である。server 全体の状態ではない。ticket を開く key、format version、受理 policy、現在の connection state は残る。

しかも、少数の key は広い範囲を支配する。同じ保護 key を複数 node が共有すれば、どの node でも他が発行した ticket を受理でき、load balancing は容易になる。反面、key を持つ全 node が一つの compromise domain になる。region ごとに key を分ければ範囲を縮められるが、境界を越えた client は full handshake になりやすい。

RFC 5077は key を ticket 専用にし、定期的に変更することを推奨した。RFC 9325は定期 rotation、validity 終了後の旧 key 破棄、妥当な ticket 寿命を要求する。古い key を長く残すと、一時的な侵害が広い再開履歴へ届き、元の handshake が目指した forward secrecy を弱める。

lifetime hint は予約券ではない

TLS 1.2 ticket の寿命値は client への hint だった。client は満了時に削除し、local policy で早く消してもよい。server は hint より短く、または長く受理する場合がある。

運用上は三つの時間を分ける必要がある。client が保存する時間、server が現在受理する時間、ticket 保護 key が復元可能な時間である。rotation は受理を早く終わらせ、誤った rollback は退役した key と古い ticket を復活させる。

field 一つを見ても、lifecycle 全体は分からない。

正しく封じても、元の handshake は修復できない

再開は元 session の security property を引き継ぐ。RFC 7627は、従来の master secret が重要な handshake parameter へ十分に暗号学的 binding されていなかった問題を扱った。active attacker が二つの session で secret を同期させると、unique な master secret を前提にした再開や authentication が崩れ得た。

extended master secret は handshake transcript の hash を使って secret を導出する。これは container の外側だけを強くしても足りないことを示す。ticket へ入る前の history が曖昧なら、portable になった state も曖昧なままである。

TLS 1.3では PSK を指す ticket になった

RFC 8446は再開を pre-shared key として整理した。主 handshake 後に server が送るNewSessionTicketには lifetime、ticket age を隠す値、nonce、opaque ticket が含まれる。次の ClientHello で client は identity を提示し、binder で対応 PSK の所持を示す。

ticket lifetime は最大7日で、client もそれ以上 cache できない。再開 PSK に新しい ephemeral Diffie–Hellman 交換を組み合わせることもできる。RFC 9325は forward secrecy を得るためpsk_dhe_keと新しい key share を推奨する。

0-RTT early data は別の option である。ticket は通常の1-RTT 再開にも使える。全 ticket が single-use だと決めつけたり、0-RTT を無効にすれば key 管理が不要だと考えたりしてはいけない。

暗号文でも同じ物だと分かることがある

RFC 5077は ticket 内容の confidentiality を求め、user 情報の漏洩を防いだ。同時に、同じ ticket の再利用を path 上の観測者が見れば、複数 handshake を関連付けられると警告した。RFC 9325も session 再開による tracking risk を挙げる。

内容が読めないことと、エンティティが識別できないことは同義ではない。発行頻度、更新、再利用、寿命も privacy control である。

移動した state と残った authority

session ticket は、再構成に必要な client 別 data を server lookup から client 保管へ移した。client は持ち運び、server は検証し、fleet operator は key 共有範囲を決め、application は現在の権限を決める。

ticket は人の identity を証明せず、期限までの受理を保証せず、常に一回限りでもなく、server の完全な無状態を示さない。歴史的な価値は、state の所在地と解釈権を分離した点にある。その分離を維持するには、key 範囲、expiry、破棄、full handshake への出口を明示し続けなければならない。

情報源と証拠の限界

公式記録はRFC 4507、RFC 5077、RFC 5246、RFC 7627、RFC 8446、RFC 9325である。fleet の key 境界と incentive に関する記述は仕様からの運用上の推論であり、特定 vendor の導入率を示すものではない。