Record Protocol

Overview#

SSL-TLS is layered and the bottom layer is the Record Protocol.

Record Protocol takes messages to be transmitted, fragments the data into manageable blocks, protects the records, and transmits the result. Received data is verified and decrypted, reassembled, and then delivered to higher-level clients.

TLS records are typed, which allows multiple higher-level protocols to be multiplexed over the same record layer. TLS 1.3 specifies three content types: handshake, application data, and alert. Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST terminate the connection with an "unexpected_message" alert. New record content type values are assigned by IANA in the TLS ContentType Registry as described in TLS 1.3 Section 10.!! Record Layer The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Message boundaries are handled differently depending on the underlying ContentType. Any future content types MUST specify appropriate rules. Note that these rules are stricter than what was enforced in TLS 1.2.

TLS Handshake Message MAY be coalesced into a single TLSPlaintext record or fragmented across several records, provided that:

Implementations MUST NOT send zero-length fragments of TLS Handshake types, even if those fragments contain padding.

TLS Alert Messages (Section 6) MUST NOT be fragmented across records and multiple TLS Alert Messages MUST NOT be coalesced into a single TLSPlaintext record. In other words, a record with an Alert type MUST contain exactly one message.

application_data contain data that is opaque to TLS.

application_data are always protected. Zero-lengthfragments of Application Data MAY be sent as they are potentially useful as a traffic analysis countermeasure.

some more details TBD#

Whatever data is sent in a SSL-TLS tunnel is split into records (or blocks). Over the wire (the underlying TCP socket or TCP-like medium), a record looks like this:

HH V1:V2 L1:L2 data
where: So a record has a

The data is where Symmetric Key encryption and integrity checks are applied. When a record is emitted, both sender and receiver are supposed to agree on which Cryptographic algorithms are currently applied, and with which keys. The agreement is obtained through the TLS Handshake protocol. TLS Compression, if any, is also applied at that point.

In full details, the building of a record works like this:

The Message Authentication Code is, usually, HMAC with one of the usual Cryptographic Hash Functions (with SSLv3, this is not the "true" HMAC but something very similar and, to the best of our knowledge, as secure as HMAC). Encryption will use either a Block Cipher in CBC mode, or the RC4 Stream Cipher.

Note that, in theory, other kinds of modes or algorithms could be employed, for instance one of these nifty modes which combine encryption and integrity checks; there are even some RFC for that. In practice, though, deployed implementations do not know of these yet, so they do HMAC and CBC. Crucially, the Message Authentication Code is first computed and appended to the application_data, and the result is encrypted. This is MAC-then-encrypt and it is actually not a very good idea. The Message Authentication Code is computed over the concatenation of the (compressed) payload and a sequence number, so that an industrious attacker may not swap records.

More Information#

There might be more information for this subject on one of the following: