要約

  • TLS session ticketは、serverが再構成できる暗号状態を不透明なobjectにし、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を挙げる。

内容が読めないことと、objectが識別できないことは同義ではない。発行頻度、更新、再利用、寿命も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の導入率を示すものではない。