TLS Record Protocol

In short: The lowest layer of the TLS protocol, responsible for the actual fragmentation, encryption and transmission of data once the handshake is complete.

In more detail: The record protocol receives data from the higher TLS sub-protocols (Handshake Protocol, Change Cipher Spec, Alert Protocol, Application Data Protocol), splits it into blocks, encrypts and signs it with the keys negotiated during the handshake, and passes it on to the transport layer (TCP) for transmission. On the receiving side, the process runs in reverse: decrypt, check integrity, pass on to the appropriate upper layer.

In Depth

The record protocol is the shared “wrapping layer” that ALL other TLS sub-protocols run through — even the handshake itself is formally already wrapped as a record message, just still unencrypted, while the keys are still being negotiated:

Higher TLS layer (Handshake/Alert/ChangeCipherSpec/Application Data)
        |
        v
  TLS Record Protocol: fragment -> compress (optional) ->
                        encrypt -> append MAC/auth tag
        |
        v
      TCP (transport layer)

A single record consists of a header (content type, TLS version, length) followed by the actual, encrypted payload block. The maximum size of a single record is limited (16 KB) — larger amounts of data (e.g. a large downloaded file) are therefore automatically split into several consecutive records, which are reassembled on the receiving side.

In TLS 1.3, the record protocol was simplified and sped up compared to TLS 1.2: older versions allowed, for example, optional compression before encryption, which later turned out to be a security risk (the CRIME attack, which could draw conclusions about the content from the compressed size) — TLS 1.3 does away with compression at this level entirely and reduces the number of supported encryption schemes to a small list of options considered secure.

Authenticated encryption (AEAD)

Modern TLS versions use so-called AEAD schemes (Authenticated Encryption with Associated Data, e.g. AES-GCM or ChaCha20-Poly1305) almost exclusively for encryption at the record level — these combine encryption and integrity checking in a single cryptographic step, instead of handling both separately (as older TLS versions did: encrypt first, then separately append a MAC). This avoids an entire class of historical attacks (so-called padding oracle attacks like Lucky Thirteen or POODLE), which resulted precisely from handling encryption and authentication separately.

Sequence numbers against replay attacks

Every record implicitly incorporates a sequential sequence number into the encryption (even though it doesn’t appear explicitly in the visible header) — this prevents an attacker from simply replaying an intercepted, valid encrypted record a second time (replay attack), since a repeated record with an “old” sequence number would be detected as invalid during the integrity check.

Fragmentation of large amounts of data

The 16 KB upper limit per record has practical consequences for the performance of large downloads: a 10 MB file is split into several hundred individual records during transmission, each with its own encryption and integrity overhead. Server implementations often actively optimise this fragmentation — smaller records at the start of a connection allow the browser to start rendering a web page as soon as the first data arrives, instead of waiting for a single large record (“TLS record size optimization”), while larger records on already-established connections reduce the overhead per transmitted byte.

Relationship to the application layer

From the perspective of an application using TLS (e.g. a browser), the record protocol is completely invisible — application code only sees a finished, already decrypted data stream, similar to a normal unencrypted TCP connection. This clean separation is deliberately designed this way architecturally: it allows TLS to be run as a standalone layer between the transport and application layers, without every single application (HTTP, SMTP, FTP over TLS) having to implement its own encryption logic — every higher-level application simply benefits from the same, centrally maintained TLS implementation in the operating system or in a shared library like OpenSSL.

See also: TLS, Handshake Protocol