ToppyMicroServices

RFC 5077 Quiz

TLS session tickets

🇺🇸 🇯🇵
0 / 0

References (URLs)

範囲: RFC 5077は旧TLS version向けのstateless session ticketを定義します. TLS 1.3はRFC 5077をobsoletesしたRFC 8446の異なるPSK-based designを使います.

Q1: TLS session ticketの主目的はどれか?

Multiple Choice
**Explanation:** RFC 5077 Sections 1, 2, and 3.1はticketを, per-client stateをserverへ残さずsessionを再構成するためのserver-createdかつcryptographically protectedなstateと定義します. clientはopaque ticketを保存し, 後のClientHelloで提示します. A: ticketはsessionを最初に確立するhandshakeのcertificateまたはendpoint validationを置き換えません. B: session ticketはTLS内で働き, plaintext HTTPを可能にしません. C: 正解. protected stateをclientへ返すことでper-session cache entryを不要にできます.

Q2: ticket内容のconfidentialityとintegrityを守る主体はどれか?

Multiple Choice
**Explanation:** RFC 5077 Sections 2, 4, and 5はticketをclientに対してopaqueとし, confidentialityとintegrityの保護を要求します. serverはsecret ticket-protection keyでticketを作成し, 後でdecryptとvalidateを行います. A: clientはticketを保存して返しますが, client private keyでserver stateを暗号化しません. B: 正解. ticket construction, protection, validation, key managementはserverの責務です. C: DNSSECはDNS dataを保護し, TLS session ticketへ署名しません.

Q3: long-lived ticket keyの大きなriskはどれか?

Multiple Choice
**Explanation:** RFC 5077 Sections 4 and 5.5はticketがTLS master secretを含み得ることを示し, ticket keyのregularな変更を推奨します. 運用上のinferenceとして, long-lived protection keyの漏えいはcapture済みticket stateを露出し, TLS versionとconfigurationによっては関連する記録済みresumed trafficのdecryptを可能にします. A: 正解. backward-looking impactをTLS construction依存として正しく限定しています. B: compromised keyで既に保護されたticketも影響を受け得ます. C: ticket-protection keyはcertificateと別にrotateできます.

Q4: session ticket運用の良い衛生として正しいものはどれ (複数選択)

Multi-Select
**Explanation:** RFC 5077 Sections 5.5 and 5.6はticket-protection keyのregularな変更を推奨し, acceptable lifetimeをdeploymentのsecurityとoperational requirementへ委ねます. cross-node acceptanceには関連serverがcompatible keyへaccessする必要があり, その共有範囲はlocal deployment designです. A: 選択. rotationはcompromiseの影響期間を限定します. B: 選択. serverが環境に応じてlifetimeを決めます. 常に最短を要求する規則ではありません. C: 選択. 必要なnodeへaccessを限定し, shared-secret boundaryを明示します. D: 非選択. ticket keyはserver secretであり, client storageへ置けません.

Q5: server-side session cacheとticketはどう違うか?

Multiple Choice
**Explanation:** RFC 5077 Sections 1 and 2はper-session server storageとclient-held opaque ticketを対比します. serverにはticket contentを保護し再構成するための少数のkeyが残ります. A: state配置が逆です. cacheはsessionごとのserver entryを保持します. B: 正解. per-session stateを減らす代わりにticket key managementが必要です. C: 保存されたticketは周囲のTLS connection外にあるため, server-side protection keyが必要です.

Q6: TLS resumptionのためclientが保存するencrypted blobを何と呼ぶか?

Short Text
**Explanation:** RFC 5077 Sections 2 and 3.2のticketはsession-specific stateを運ぶopaqueなstructureです. clientはinternal formatを仮定せず保存し, 後続handshakeの`SessionTicket` extensionで提示します.

Q7: RFC 5077のticket security analysisに最も合う対応はどれか

Multiple Choice

TLS 1.2のA2A fleetがRFC 5077 ticketを30日間受理します. 40台のgatewayが1つのticket-protection keyを共有し, その中のlow-trustなregional nodeが侵害されました. operatorは, session stateをclientが保存するstateless方式なのでincidentはそのnodeに限定されると主張します.

**Explanation:** RFC 5077 Section 5.3は, integrity protectionが破れるとforged ticketによるsession延長, impersonation, privilege取得が起こり得ると説明します. shared protection keyを持つnodeは, そのkeyのticketを受理する全gatewayのtrust boundary内です. sessionごとのstateをclientへ移しても, このserver secretはなくなりません. Section 5.5はticket-protection keyを専用目的に限定しregularly changeすることを推奨します. Section 5.6はacceptable lifetimeをserverのoperational/security requirementに委ねます. したがってcompromise後のcontainment, rotation, lifetime reviewは必要ですが, RFCは単一のfleet topologyや最短lifetimeを一律には指定しません. RFC 8446は後にTLS 1.3についてRFC 5077をobsoletesしました. このpremiseはRFC 5077 mechanismを使うTLS 1.2 deploymentを意図しています.

Q8: copyしたticketだけでattackerは何ができるか?

Multiple Choice

application logにopaqueなTLS 1.2 session ticketがあります. attackerはticketをcopyしましたが, clientがcacheしたmaster secretもserverのticket-protection keyも得ていません. attackerは新しいClientHelloでticketを送ります.

**Explanation:** RFC 5077 Sections 3.1 and 5.2ではclientがticketとともにmaster secretなどのsession stateをcacheします. opaque ticketの盗難だけではresumptionできず, 対応するsecret stateなしにresumed handshake keyとFinished messageを生成できません. A: このprotocolのticketはself-sufficient bearer credentialではありません. B: 正解. 前提ではmaster secretへ至る両経路がありません. C: ticket protectionはcertificate public keyではなくserver-held symmetric keyを使います. D: protocolはticket-protection keyを送信しません.

Q9: 1つのticketを再利用するときのprivacy上の結論はどれか?

Multiple Choice

Agentは複数handshakeで同じencrypted session ticketを使います. passive observerはdecryptできませんが, opaque byte stringの反復を見られます. profileはこれらのconnectionをcorrelateできないと保証します.

**Explanation:** RFC 5077 Section 5.8はticket contentのconfidentialityを要求する一方, on-path observerが同じticketを使うhandshakeをcorrelateできると明記します. confidentiality, anonymity, unlinkabilityは異なるpropertyです. A: encryptionは内容を隠しますがvisible ciphertextのequalityを隠しません. B: plaintext nameがなくてもequality comparisonは可能です. C: 正解. 提示されたunlinkability保証はRFC 5077 mechanismの範囲を超えます. D: passive correlationにticket decryptやcertificate private keyは不要です.

Q10: successful resumptionは以前のdelete permissionを維持するか?

Multiple Choice

serverはcertificate-based client authentication後, Agent Aがtask Tをdeleteできた時点でticketを発行しました. ticketはserver-selected lifetime内ですが, task ownerは後からAgent Aのdelete permissionをrevokeしました. TLS resumptionは成功し, 記録されたclient identityを復元します.

**Explanation:** RFC 5077 Section 4はticket stateへclient-authentication informationを含め, resumption後もTLS serverがauthentication capabilityを保てるようにします. Section 5.6はticket lifetimeをserverのsecurityおよびoperational choiceとします. application authorizationをその期間snapshotする要求はありません. A: TLS session validityはresource-owner policyを固定しません. B: 正解. current authorizationはresumed identityをevidenceとして用いる別のapplication decisionです. C: confidentialityはticket内容を保護し, external policy stateを保護しません. D: applicationはTLS resumption自体をinvalidとせずoperationをdenyできます.