While the Handshake Protocol handles the 'negotiation', the Record Protocol handles the actual data movement. It takes the application data, fragments it, compresses it (rarely now), adds a MAC for integrity, and encrypts it.
TLS does not send a continuous stream of bytes; it sends 'Records'. Each record has a header containing the content type (e.g., Handshake, Alert, or Application Data), a version number, and the length of the payload. This allows the receiver to know exactly how many bytes to read before attempting decryption.
๐ก Maximum record size is $2^{14}$ bytes (16 KB). If an application sends a 1MB file, the TLS layer will fragment it into approximately 64 records.
{
"record_header": {
"content_type": "Application Data (23)",
"version": "TLS 1.2 (0x0303)",
"length": "1024 bytes"
},
"encrypted_payload": "... [AES-GCM Ciphertext] ...",
"auth_tag": "... [GCM Tag for Integrity] ..."
}The structure above ensures that if a single byte of the encrypted payload is changed, the `auth_tag` (MAC) will fail to validate, and the connection will be terminated with a 'Bad Record MAC' alert.
In older versions of TLS, the protocol used 'MAC-then-Encrypt'. It calculated the MAC, appended it to the data, added padding to fit the block size, and then encrypted everything. This created a 'Padding Oracle'โif the server's error message differed when padding was wrong versus when the MAC was wrong, attackers could guess the plaintext.
โ ๏ธ This specific design flaw led to the Lucky13 and POODLE attacks. The solution was to move to AEAD (Authenticated Encryption with Associated Data) like AES-GCM, which handles encryption and authentication in a single atomic step.
| Method | Process | Security Status | Vulnerability |
|---|---|---|---|
| MAC-then-Encrypt | MAC $ ightarrow$ Pad $ ightarrow$ Encrypt | Insecure | Padding Oracles (Lucky13) |
| Encrypt-then-MAC | Encrypt $ ightarrow$ MAC | Secure | Resistant to Oracle attacks |
| AEAD (GCM) | Combined Encrypt/Auth | Gold Standard | Nonce reuse (if IV is repeated) |
To prevent an attacker from capturing a valid record and re-inserting it later in the stream (a 'Replay' or 'Reordering' attack), the Record Protocol maintains an implicit sequence number. Both the client and server increment this counter for every record sent. The MAC is calculated using this sequence number.
If a record arrives out of order or with a skipped sequence number, the TLS connection MUST be terminated immediately. Attempting to 'recover' the stream is a security risk.
Verify exercises to earn โ 150 XP and unlock next lab level.