TLS 1.3 handshake, resumption, and failure boundaries

TLS 1.3 authenticates the handshake transcript, derives traffic keys, and protects application bytes over a reliable transport. A full handshake, PSK resumption, optional early data, client authentication, and QUIC's TLS integration are distinct state machines and must not be collapsed into one RTT slogan.

Mental model

• In a server-authenticated full handshake, ClientHello carries a key share. ServerHello selects parameters; subsequent handshake messages are encrypted, and Finished authenticates the transcript.
• The certificate private key signs authentication data. Ephemeral key agreement produces the shared secret for full-handshake traffic keys.
• A HelloRetryRequest can add another round trip when a suitable key share was not offered.
• PSK resumption can reduce setup work. 0-RTT is optional, replayable, and rejectable; accepted early data still has weaker security properties.

Гарантии и границы

• Handshake completion means each TLS stack has sent and verified the relevant Finished message; application APIs can expose different readiness points.
• Service identity matching and certification-path validation are both required for PKIX server authentication.
• TLS protects only between its endpoints; a terminating proxy begins a new security context downstream.
• TLS does not make a retried application mutation idempotent.

Сценарии диаграммы

TLS 1.3 full handshake. A normal server-authenticated TLS 1.3 handshake derives fresh traffic keys and completes after both Finished messages are verified.

PSK resumption with optional 0-RTT. A ticket can resume a prior session; early data is replayable and may be rejected, so the application must explicitly permit it.

HelloRetryRequest and certificate failure. TLS 1.3 can require another ClientHello; authentication failure must abort rather than falling back silently.

Forward secrecy and traffic key updates. TLS 1.3 uses ephemeral (EC)DHE for certificate-based full handshakes and derives distinct handshake and application secrets.

Архитектурные решения

• Use TLS 1.3 and current secure-use guidance; disable obsolete protocol versions and weak algorithms according to compatibility requirements.
• Disable 0-RTT unless the application protocol defines replay-safe use and the deployment accepts its residual risk.
• Set handshake, idle, and application deadlines separately and report validation classes without bypass switches.

Сбои и неоднозначные исходы

• Ticket rejection or 0-RTT rejection is normal protocol behavior, not necessarily an outage.
• Certificate path success without reference-identity match does not authenticate the intended service.
• Clock error, SNI/ALPN mismatch, algorithm policy, or HelloRetryRequest can change the observed handshake without a server crash.

Операционный checklist

• Validate path, purpose, name, time, and revocation policy as applicable.
• Protect ticket keys, bound ticket lifetime, and rotate without making every node accept stale state.
• Measure full, resumed, rejected-0-RTT, HelloRetryRequest, failure, and key-update paths.
• Never log private keys, PSKs, exporter secrets, or unredacted session material.

Связанная концепция

Первичные источники

1. https://www.rfc-editor.org/rfc/rfc8446.html
2. https://www.rfc-editor.org/rfc/rfc9325.html
3. https://www.rfc-editor.org/rfc/rfc9525.html
4. https://www.rfc-editor.org/rfc/rfc7301.html