From SSL to TLS
SSL 2.0 and SSL 3.0 are historical TLS predecessors and should not be enabled. TLS 1.0 and 1.1 are also obsolete for current deployments. TLS 1.2 remains for compatibility, while TLS 1.3 has a redesigned handshake and key schedule.
A version number is not the only criterion. TLS 1.2 security depends on the cipher suite, key exchange, signature algorithm, and implementation configuration.
Record layer
The record layer divides higher-level data into fragments and protects them with traffic keys. TLS 1.3 uses AEAD algorithms that provide encryption and data authentication in one construction.
A record sequence number participates in nonce formation and ordering. Reusing one key and nonce pair can break AEAD security. Implementations must follow key-usage limits and update procedures.
TLS 1.3 parameter negotiation
ClientHello carries supported versions, cipher suites, key-exchange groups, signature algorithms, and extensions. key_share can include the client's ECDHE contribution immediately.
ServerHello selects a version, cipher suite, and server key share. A server can send HelloRetryRequest when the client did not provide a share for the required group. Messages after ServerHello are protected with handshake keys.
Server authentication
The server sends its certificate chain and CertificateVerify. The CertificateVerify signature covers the handshake transcript hash and demonstrates possession of the private key corresponding to the certificate.
The client checks the signature, issuer trust, validity interval, key usage, and service name. TLS can also authenticate a client certificate when the server sends CertificateRequest.
Full handshake sequence
- The client sends ClientHello with parameters and a key share.
- The server returns ServerHello and both sides derive handshake secrets.
- The server sends EncryptedExtensions, its certificate, and CertificateVerify.
- The server Finished authenticates the transcript so far.
- The client validates the server and sends its Finished.
- The peers use independent application traffic keys.
Key schedule and forward secrecy
TLS 1.3 uses HKDF to derive separate secrets for successive stages. Handshake keys, application data, and resumption material have distinct contexts.
Ephemeral ECDHE provides when ephemeral secrets are erased and were not captured during the session.
Session resumption and 0-RTT
NewSessionTicket gives a client material for later PSK-based resumption. A resumed connection can reduce cryptographic work and retain fresh keys by combining PSK with ECDHE.
0-RTT permits application data before the new handshake completes. Early data lacks full replay protection. Servers and applications must reject or safely repeat state-changing operations.
Alerts and connection closure
A protocol error can generate an alert and terminate the connection. A fatal alert requires immediate shutdown, and some failures do not permit a useful alert to be sent.
close_notify signals controlled closure of a TLS direction. An application that ignores missing closure can mistake a truncated stream for a complete message.
Secure deployment requirements
- Disable SSL, TLS 1.0, and TLS 1.1.
- Prefer TLS 1.3 and secure TLS 1.2 suites.
- Protect the private key and restrict access.
- Validate certificates and service names.
- Use a secure random generator and a maintained cryptographic library.
- Control 0-RTT according to operation semantics.
- Monitor negotiation failures without logging session secrets.
Limits of TLS protection
TLS protects the channel between endpoints that terminate it. Data is plaintext before encryption and after decryption. TLS does not repair authorization errors, parser vulnerabilities, compromised endpoints, or insecure data storage.