<b>Why does a single TLS handshake message sometimes arrive split across several network packets — and is that

<b>Why does a single TLS handshake message sometimes arrive split across several network packets — and is that an attack?</b>

A frequent source of confusion in TLS debugging is the gap between two distinct layers: the handshake protocol (the logical messages — ClientHello, Certificate, Finished) and the record protocol (the actual on-wire framing). They are not the same, and conflating them produces phantom bugs.

TLS messages travel inside records (RFC 8446 §5.1), each with a maximum payload of 2^14 = 16384 bytes. A large handshake message — a Certificate message carrying a long chain, or a post-quantum ClientHello with a kilobyte-scale key share — exceeds one record and is fragmented across multiple records. Conversely, several small handshake messages can be coalesced into one record. So there is no one-to-one mapping between handshake messages and records, and certainly none between records and TCP segments, which the OS may split or merge freely.

This matters for security analysis. The historic SSLv3/TLS 1.0 fragmentation behavior enabled the 1/n-1 record splitting mitigation against BEAST. It also means an implementation must reassemble handshake messages from the record stream before parsing — a parser that assumes "one record = one message" is exploitable. TLS 1.3 explicitly forbids interleaving handshake messages of different types across record boundaries to constrain this.

Evidence vs. speculation: record/handshake-layer separation and the 16 KB limit are normative (RFC 8446 §5.1, §5.2). Whether a given fragmentation is benign or hostile depends on parser robustness — fragmentation itself is expected protocol behavior, not inherently an attack.

<b>Further reading:</b> RFC 8446 §5.1, §5.2; RFC 5246 §6.2 (legacy record layer).

<b>Bottom line:</b> Handshake messages and records are independent layers — one logical message can span many records and many TCP segments, so fragmentation is normal; the only place it becomes a vulnerability is a parser that fails to reassemble before trusting the bytes.