System Design Cases
TLS Handshake (1.2 vs 1.3, 0-RTT, PFS)
TLS 1.3 handshake: ClientHello with key_share (ECDHE), ServerHello+Certificate+Finished in 1 RTT, 0-RTT resumption with PSK and replay risk, comparison with TLS 1.2 (2 RTT), forward secrecy via ephemeral ECDHE, and certificate validation failures (chain/expiry/SAN/mTLS). Free concept lesson #53 in foundations.
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.