ToppyMicroServices

RFC 5077 Quiz

TLS Session Tickets

πŸ‡ΊπŸ‡Έ πŸ‡―πŸ‡΅
0 / 0

References (URLs)

Scope: RFC 5077 defines stateless session tickets for earlier TLS versions. TLS 1.3 uses the different PSK-based design in RFC 8446, which obsoletes RFC 5077.

Q1: What is the primary purpose of a TLS session ticket?

Multiple Choice
**Explanation:** RFC 5077 Sections 1, 2, and 3.1 define a ticket as server-created, cryptographically protected state that lets a TLS server reconstruct a session without retaining per-client state. The client stores it and presents it in a later ClientHello. A ticket does not replace certificate or endpoint validation in the handshake that establishes the session. Session tickets operate inside TLS and do not enable plaintext HTTP. Returning protected state to the client lets the server resume without retaining a per-client session-cache entry.

Q2: Who protects the confidentiality and integrity of the ticket contents?

Multiple Choice
**Explanation:** RFC 5077 Sections 2, 4, and 5 make the ticket opaque to the client and require confidentiality and integrity protection. The server creates it under secret ticket-protection keys, then decrypts and validates it before using the recovered state. The client stores and returns the ticket; it does not encrypt the server's session state with a client private key. Ticket construction, protection, validation, and key management are server responsibilities. DNSSEC protects DNS data and has no role in signing a TLS session ticket.

Q3: What is a major risk of long-lived ticket keys?

Multiple Choice
**Explanation:** RFC 5077 Sections 4 and 5.5 show that a ticket can contain the TLS master secret and recommend changing ticket keys regularly. As an operational inference, compromise of a long-lived protection key can expose captured ticket state and, for affected TLS versions and configurations, enable decryption of associated recorded resumed traffic. It captures the possible backward-looking impact while correctly making it conditional on the TLS construction. Previously issued tickets protected by the compromised key can also be affected. Ticket-protection keys are separate from the certificate, and RFC 5077 recommends changing them regularly.

Q4: Good hygiene for session tickets includes (select all)

Multi-Select
**Explanation:** Stateless resumption replaces per-session server storage with protected client-held state and server-side key management. A cluster must make an explicit choice about the lifetime and the nodes that can decrypt a ticket. RFC 5077 recommends changing ticket-protection keys regularly and when the format or algorithms change. The server controls acceptable lifetime based on the deployment's operational and security requirements. Cross-node acceptance requires the relevant servers to have access to compatible protection keys, with the resulting sharing risk managed. Ticket keys are server secrets; exposing them to client storage would destroy the protection boundary.

Q5: How do server-side session caches and tickets differ?

Multiple Choice
**Explanation:** RFC 5077 Sections 1 and 2 contrast per-session server storage with a client-held opaque ticket. The server retains the smaller set of keys needed to protect and recover ticket contents. The state placement is reversed: a cache stores per-session server entries, while a ticket moves that state to the client. It states the storage-versus-key-management tradeoff that distinguishes stateless tickets. The server still needs a key to protect the confidentiality and integrity of ticket contents.

Q6: What is the encrypted blob stored by the client for TLS resumption called?

Short Text
**Explanation:** RFC 5077 Sections 2 and 3.2 define the ticket as an opaque structure carrying session-specific state. The client must not assume an internal format; it stores the value and presents it in the `SessionTicket` extension when requesting resumption.

Q7: Which response best follows RFC 5077's ticket-security analysis?

Multiple Choice

A TLS 1.2 A2A fleet accepts RFC 5077 tickets for 30 days. Forty gateways share one ticket-protection key, including a low-trust regional node that has been compromised. Operators argue that stateless tickets isolate the incident because clients store the session state.

**Explanation:** RFC 5077 Section 5.3 explains that a forged ticket can extend a session, impersonate a user, or gain privileges if integrity protection fails. A node holding the shared protection key is therefore inside the trust boundary for every gateway that accepts tickets under that key; moving per-session state to the client does not remove this server secret. Section 5.5 recommends that ticket-protection keys be dedicated to this purpose and changed regularly. Section 5.6 leaves the acceptable lifetime to the server's operational and security requirements. Those sections support containment, rotation, and a lifetime review after compromise, but they do not prescribe one universal fleet topology or shortest lifetime. RFC 8446 later obsoletes RFC 5077 for TLS 1.3. The premise deliberately concerns a TLS 1.2 deployment using the RFC 5077 mechanism.

Q8: What can an attacker do with only a copied ticket?

Multiple Choice

An application log contains an opaque TLS 1.2 session ticket. An attacker copies that ticket but obtains neither the client's cached master secret nor the server's ticket-protection key. The attacker sends the ticket in a new ClientHello.

**Explanation:** RFC 5077 Sections 3.1 and 5.2 say the client caches the ticket together with the master secret and other session state. A stolen opaque ticket does not by itself let an attacker resume; the attacker cannot produce the resumed handshake keys and Finished messages without the corresponding secret state. A: The ticket is not a self-sufficient bearer credential in this protocol. B: Correct. The premise withholds both paths to the master secret. C: Ticket protection uses server-held symmetric keys, not the certificate public key. D: The protocol does not transmit the ticket-protection key.

Q9: Which privacy conclusion follows from reusing one ticket?

Multiple Choice

An Agent reuses the same encrypted session ticket in several handshakes. A passive observer cannot decrypt it but can see that the opaque byte string repeats. The profile promises that these connections cannot be correlated.

**Explanation:** RFC 5077 Section 5.8 requires ticket-content confidentiality but explicitly warns that an on-path observer can correlate handshakes in which the same ticket appears. Confidentiality, anonymity, and unlinkability are distinct properties. A: Encryption hides contents; it does not hide equality of visible ciphertext values. B: Removing a plaintext name does not prevent equality comparison. C: Correct. The stated unlinkability guarantee exceeds RFC 5077's mechanism. D: Passive correlation needs neither ticket decryption nor a certificate private key.

Q10: Does successful resumption preserve an old delete permission?

Multiple Choice

A server issued a ticket after certificate-based client authentication when Agent A could delete task T. The ticket remains within its server-selected lifetime, but the task owner has since revoked Agent A's delete permission. TLS resumption succeeds and restores the recorded client identity.

**Explanation:** RFC 5077 Section 4 allows ticket state to carry client-authentication information so the TLS server retains authentication capabilities on resumption, while Section 5.6 defines ticket lifetime as a server security and operational choice. It does not require application authorization to be snapshotted for that lifetime. A: TLS session validity does not freeze resource-owner policy. B: Correct. Current authorization is a separate application decision using the resumed identity as evidence. C: Confidentiality protects ticket contents, not external policy state. D: The application can deny the operation without declaring the TLS resumption itself invalid.