The Record Protocol’s five steps, and the two one-line protocols

Two services, five steps, and the order is the answer

The Record Protocol provides exactly two services to everything above it: confidentiality, using a shared secret key for symmetric encryption of payloads, and message integrity, using a shared secret key to form a MAC. The handshake establishes both keys; the record layer just applies them, over and over, to every byte that passes.

Worked example. A browser hands the record layer a 40 KB HTTP response body. Follow it through the pipeline, in order:

1. Fragment. The message is broken into blocks of $2^{14}$ = 16,384 bytes or less. 40,960 bytes therefore becomes three records: 16,384 + 16,384 + 8,192.
2. Compress. Optional, and applied per fragment. Modern deployments switch it off — L14.6 explains why.
3. Compute a MAC over the compressed data. One MAC per record, under the appropriate write MAC key.
4. Encrypt the compressed fragment plus the MAC with the symmetric algorithm.
5. Prepend the record header, which carries the content type, the version and the length.

The resulting unit goes out in a TCP segment. Receiving reverses it exactly: decrypt, verify, decompress, reassemble, then deliver upward.

Notice what steps 3 and 4 say together: the MAC is computed first, over the plaintext, and then the plaintext-plus-MAC is encrypted. That ordering has a name — MAC-then-encrypt — and it is the ordering that later attacks against the record layer exploited, because a receiver must decrypt attacker-controlled bytes before it has any authentication to tell it whether they were worth decrypting.

Every record carries one of four content types: change_cipher_spec, alert, handshake, and application_data. The first three identify the TLS-specific protocols; the fourth is everything else, and TLS makes no distinction among the applications producing it.

The record header, to the byte

The textbook says only that the header "includes version and length fields", which is not enough to answer a question about the header. The real layout is five octets: a content type octet, a major version octet, a minor version octet, and a 16-bit length. That length is what bounds a fragment at 16,384, and those five bytes are the per-record overhead you add when you compute how much a large message actually costs on the wire.

Two protocols you can describe in one line each

Change Cipher Spec Protocol. A single byte with the value 1. Its sole purpose is to cause the pending state to be copied into the current state, so the cipher suite the two sides just negotiated becomes the one actually in use. That is the whole protocol. It is separate from the Handshake Protocol precisely because the record layer needs an unambiguous boundary at which to switch cipher state.

Alert Protocol. Two bytes: a level byte — warning(1) or fatal(2) — and an alert code byte naming the specific condition. Alerts are themselves compressed and encrypted under the current state, like any other record.

The fatal/warning asymmetry is exactly the sort of detail a multiple-choice question is built on, so state it precisely: on a fatal alert TLS terminates the connection immediately; other connections on that same session may continue, but no new connection may be established on it. The session is poisoned for future use without being destroyed for current use. An incorrect MAC is fatal. close_notify — the polite "I have nothing more to send" — is not fatal.