TLS

A TLS 1.2 suite name lists four choices in fixed order: the key exchange, the algorithm that authenticates the server, the bulk cipher with its key size and mode, and the hash used for the record MAC or the pseudorandom function.

TLS assumes an ordered, reliable byte stream: drop or reorder one record and decryption fails, and a lost handshake message stalls forever. DTLS puts that back into the protocol itself with explicit per-record numbering, fragmented handshake messages and its own retransmission timer.

A completed TLS 1.3 handshake has fixed one protocol version and one cipher suite, derived shared traffic keys, established the server's identity by signature, selected an application protocol, and confirmed both peers saw an identical message transcript.

The key_share extension carries ephemeral Diffie-Hellman public values the client generated, one per named group it guessed the server would accept. The ServerHello returns exactly one such value, for the group the server chose.

POODLE exploits how SSL 3.0 itself defines CBC padding, so every conforming implementation had it and only withdrawing the version repaired it. Heartbleed was a missing length check in one TLS library, repaired by a new build.

An ordinary TLS handshake authenticates only the server: it sends a certificate and a signature proving it holds the matching private key. Mutual authentication adds a client certificate and signature, so both peers prove identity before any application data flows.

TLS protects one record at a time, not a byte stream. The sender cuts data into fragments of at most 2^14 bytes, and each fragment becomes an independently encrypted record whose protected length may not exceed 2^14 + 256 bytes.

A resumption handshake reuses a secret both peers already hold, so the server sends no certificate chain and no signature over the transcript, and neither side repeats public-key authentication. Fresh randoms, new record keys and the Finished exchange still happen.

unknown_ca(48) means what arrived never reached a trust anchor the validator holds. certificate_expired(45) means a certificate it needed is outside its validity window. bad_certificate(42) means a certificate was corrupt or its signature did not verify.

Because clients that already hold the missing intermediate, or can fetch it from a location named in the certificate, complete the path anyway. Clients with neither cannot reach a trust anchor and reject the chain, so the same server looks healthy and broken at once.

A TLS 1.3 suite names only an AEAD algorithm and the hash used for key derivation. Key exchange moved to supported_groups(10) and key_share(51), and authentication to signature_algorithms(13), so the combinatorial explosion that produced dozens of TLS 1.2 suites disappeared.

TLS 1.3 has the client send its key-exchange contribution with the ClientHello, so the server can derive keys and send its entire flight, identity and Finished included, in one response. TLS 1.2 needs a second exchange before either side can protect anything.

The server must answer with HelloRetryRequest, naming the group it wants in key_share(51). The client generates a fresh share for that group and sends a second ClientHello, and the handshake costs one extra round trip.

SSL 3.0 defines only the last padding byte, the padding length, and leaves the other padding bytes free, so a receiver cannot verify them. POODLE builds records whose final block is entirely padding, and acceptance confirms a guess.

The server sends CertificateRequest, after EncryptedExtensions and before its own Certificate. The client answers with Certificate, then CertificateVerify, whose signature covers a hash of the handshake transcript so far, made with the private key for the leaf it just sent.

A close_notify(0) alert is the only thing that marks an orderly end of data in TLS. A transport end of file with no close_notify is a truncated stream, and the receiver cannot tell a finished sender from a cut connection.

A SessionID session_id is only a handle: the server keeps the session state in its own cache. An RFC 5077 SessionTicket is the state itself, sealed under a key the server side holds and stored by the client.

protocol_version(70) narrows the failure to version selection: the version offered was recognised and not supported. handshake_failure(40) narrows nothing - it is the catch-all for no acceptable set of security parameters, whichever dimension failed.

In TLS 1.3 the supported_versions extension carries the real version list and the server's single choice; ClientHello's legacy_version stays frozen at 0x0303 because implementations in the path rejected unfamiliar values there, while an unknown extension is ignored instead.

A datagram source address is unverified, so an unchecked server is both an amplifier and a state-exhaustion target. HelloVerifyRequest returns a cookie the client must echo, proving it can receive at the address it claimed, and the server stores nothing while it waits.

Only the peer that completed the handshake: the onboard gateway, which sent Certificate and signed CertificateVerify for that host name. The shore-side booking service sent nothing the kiosk verified, so nothing was proved about it.

Position eliminates causes. An alert arriving before any Certificate has been sent cannot be a verdict on a certificate, and one that arrives as a protected record came from the peer that completed the key exchange rather than from anything on the path.

Because it does not hold that certificate's private key, and copied bytes fail at the signature step. So it generates its own key pair and mints a leaf for the requested host name, signed by an authority the client already trusts.

It signs a value derived from the transcript of the handshake so far, not the certificate bytes. That binds possession of the first entry's private key to this specific handshake, which a copied Certificate message — public data anyone can replay — can never do.

It reads the host_name the client put in the server_name(0) extension of its ClientHello and selects a configured certificate that names that host. With no extension, or an unknown name, it falls back to a default certificate and the client rejects the name mismatch.

The epoch names which key set protects the record and the 6-byte sequence_number numbers it within that epoch, so a receiver can decrypt records that arrive late, out of order or twice. Stream-mode TLS infers both because the transport guarantees order.

DTLS adds message_seq, fragment_offset and fragment_length to the handshake header. A sender splits one message into fragments that each fit the path MTU, every fragment repeats the message's type, total length and message_seq, and the receiver reassembles by offset.

From EncryptedExtensions. In TLS 1.3 only the two hello messages travel in the clear; every handshake message after ServerHello is protected under the handshake traffic keys, which is exactly why the EncryptedExtensions message exists.

The client offers both in its ClientHello: server_name carries one host name as a byte string, ALPN carries an ordered list of protocol identifiers. The server acknowledges server_name with an empty extension and answers ALPN with exactly one protocol it selected.