← Back to Table of Contents

TLS Records: How Data Is Framed

TLS doesn’t send raw data over TCP. It wraps everything in records. Think of it like putting letters in envelopes. You don’t just shove a letter into the mailbox bare. You put it in an envelope that has the recipient’s address, a return address, and a stamp. The envelope tells the postal system how to handle it.

TLS records are those envelopes. They wrap every piece of data with a small header that tells the other side what kind of message it is and how long it is. Understanding the record layer helps you make sense of what you see in Wireshark and why certain errors occur.

Record Structure

Every TLS message is wrapped in a record with this structure:

Field Size Description
Content Type 1 byte What kind of message this is
Protocol Version 2 bytes TLS version (e.g., 0x0303 for TLS 1.2)
Length 2 bytes Length of the payload
Payload Variable The actual message data

Content types:

Fragmentation

The maximum record payload is 16,384 bytes (16 KB). If a handshake message or application data is larger than this, it’s split across multiple records. The receiver reassembles them.

This means a single HTTP response might be split across dozens of TLS records. Each record is independently encrypted (after the handshake), and each has its own MAC or authentication tag.

Before and After Encryption

Before the handshake completes, records are sent in plain text (the handshake messages themselves). After ChangeCipherSpec, records are encrypted. The content type, version, and length fields are always in plain text (the receiver needs them to know how to process the record), but the payload is encrypted.

In TLS 1.3, even the content type is hidden. The real content type is placed inside the encrypted payload, and the outer record always shows content type 23 (Application Data). This makes it harder for middleboxes to distinguish handshake traffic from application data.

Why Records Matter

Records are the unit of encryption and integrity. Each record is encrypted and authenticated independently. If a record is corrupted or tampered with, only that record fails, and the connection is terminated with an alert.

Records also matter for performance. Smaller records mean more overhead (each record has a header and authentication tag). Larger records mean more latency (the receiver must wait for the entire record before it can process any of it). TLS implementations balance these trade-offs.


Next: The Full TLS 1.2 Handshake

← Previous ChapterNext Chapter →