TLS

TLS 1.0 chains CBC across records: the initialization vector for a record is the previous record's last ciphertext block, already visible on the wire. BEAST used that predictability to test guesses at plaintext blocks.

It still sends a Certificate message, with an empty certificate_list and no CertificateVerify after it. The server may then either continue the handshake with an unauthenticated peer or abort it with a fatal certificate_required(116) alert.

Each side keeps a 64-bit record counter for reading and one for writing, both starting at zero. The counter is left-padded to the length of the static write IV and XORed with it, producing a distinct nonce for every record.

It carries one or more PskIdentity entries - each an opaque ticket plus an obfuscated_ticket_age - and a matching PskBinderEntry list. A binder is a MAC keyed from the pre-shared key, proving possession and tying the offer to this exact ClientHello.

Because the alert was never required. RFC 6066 lets a server that does not recognise the requested host_name either abort with a fatal unrecognized_name(112) or simply continue the handshake, so silence is a conforming choice and carries no information.

Because authentication needs a signature scheme both sides accept. The client's signature_algorithms(13) list, and signature_algorithms_cert(50) where present, constrain which certificate the server may select; a server whose only key or chain falls outside those lists cannot sign at all.

Ordering decides only which of the mutually acceptable suites wins, never which suites are permitted. Server order enforces one ranking on every peer, so clients without AES hardware acceleration may be pushed onto a suite they run slowly; client order lets each peer pick what it runs fastest.

Nothing beneath DTLS retransmits, so the sender does. DTLS groups handshake messages into flights and keeps a timer per flight: it should start at 1 second, double on each retransmission, and cap at 60 seconds, resending the entire flight each time.

Extension negotiation is strictly offer-then-answer: a server may only respond with extensions the client actually offered, and each extension type is legal only in the specific handshake messages the specification permits. Violations are fatal, not ignorable.

The client generated a 48-byte premaster secret, encrypted it under the RSA public key in the server's certificate, and sent it in client_key_exchange(16). TLS 1.3 has no such message: both ends contribute ephemeral key_share(51) values instead.

It declares that this hello is a retry offering less than the client's best version. A server that supports a version higher than the one offered answers with a fatal inappropriate_fallback(86) alert instead of completing the handshake.

From the verified client leaf certificate, normally a subjectAltName entry: that is the only name the handshake authenticated. An identifier inside the request is unauthenticated input, so a disagreement between the two must fail the request rather than be resolved silently.

With a KeyUpdate message, sent inside the protected stream after the handshake. It rotates only the sender's own write keys and resets that direction's record counter; its request_update field, set to update_requested, asks the peer to rotate its direction too.

None survives on its own. Single-use tickets and ClientHello recording both need state shared by every server that can open the ticket; a freshness check only bounds how long a copied flight stays usable. Partitioning ticket-opening per server is the alternative.

TLS 1.3 drops static key transport, so every full handshake uses an ephemeral exchange; it removes renegotiation and record-layer compression; its cipher suites are a separate set from TLS 1.2's; and everything from EncryptedExtensions onward, including the server's certificate, is encrypted.

Measure before enforcing: record the version every peer actually negotiates over a full check-in cycle, take TLS 1.2 as the deprecation baseline and prefer 1.3, run the floor in report-only first, then raise it population by population with a separately scoped, time-boxed exception.

The client asks with status_request(5) in its ClientHello. TLS 1.2 answers with a separate CertificateStatus handshake message after Certificate; TLS 1.3 carries the response as an extension inside the CertificateEntry it describes, so any entry in the chain can carry one.

TLS 1.3 suites are a separate family with their own code points, chosen by their own policy once version 1.3 is negotiated. Narrowing the 1.2 list constrains only connections that settle on 1.2, so a 1.3 connection is unaffected by it.

SSL 2.0 authenticates messages with an MD5-based construction, leaves the handshake unprotected so an intermediary can silently weaken the agreed suite, uses one key for both authentication and encryption, and lets an injected TCP FIN end a session undetectably.

TLS 1.3 moved the real content type inside the encrypted payload. The outer header's opaque_type reads application_data(23) for every protected record; the receiver decrypts, strips trailing zero octets, and reads the last non-zero byte as the type.

The outer hello names the ECHConfig's public_name in its server_name(0) extension; the host the client actually wants sits in the ClientHelloInner, sealed with HPKE inside the encrypted_client_hello(0xfe0d) extension the outer carries.

Because TLS 1.3 makes severity implicit in the alert description. Every error alert must be treated as an error whatever level the sender claimed, and only the closure alerts close_notify(0) and user_canceled(90) are not error alerts.

Middlebox compatibility mode. A TLS 1.3 client sends a non-empty legacy session id that the server echoes, plus a dummy change_cipher_spec record, so the exchange resembles a TLS 1.2 resumption to elements in the path. Neither changes any key.

The connection_id(54) extension. Each party advertises a ConnectionId it wishes to receive, the peer stamps that value on records it sends, and the receiver selects the association by that identifier instead of by the source address and port.

Compatibility only. TLS 1.3 keeps a dummy session id and a ChangeCipherSpec record so the exchange resembles a TLS 1.2 handshake to intermediaries written for that version. Neither affects keys, and neither is part of the handshake transcript.

It derives the TLS 1.2 master secret from a hash of the handshake messages instead of the two hello random values, so a master secret can belong to only the one handshake that produced it.

The post_handshake_auth(49) extension in its ClientHello. Without it the server must not send a late CertificateRequest, and a client that receives one anyway aborts the connection with a fatal alert.

RFC 8470 has the forwarding hop add the Early-Data request header field with the value 1, warning the next hop the request may be a replay. An origin unwilling to act on it answers 425 (Too Early), asking for a retry after the handshake completes.