Search code examples
sslcryptographyprotocolstls1.2

How does the TLS Record Protocol reassemble received data?


I can't find detailed information about how the TLS Record Protocol is able to reassemble received data. In the RFC 5246:

Received data is decrypted, verified, decompressed, reassembled, and then delivered to higher-level clients.

But HOW? This is how the record layer data looks like:

struct {
    ContentType type;
    ProtocolVersion version;
    uint16 length;
    opaque fragment[TLSPlaintext.length];
} TLSPlaintext;

The length field is just the length of the fragment:

The length (in bytes) of the following TLSPlaintext.fragment

I would expect to see the complete length in the Record Protocol Header. Google gives almost no results for this which makes me feel I'm missing something obvious...


Solution

  • TLS is performed on streams, and the data in those streams are put into one or more fragments (of max 2^14 bytes). This is called fragmentation.

    The spec itself talks reads:

    Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records).

    which is simply the same as putting them into a stream, and then breaking the stream in separate fragments again.

    If you receive data through TLS then you'll have to recreate that stream from the separate fragments. The "reassembly" that happens is therefore simple concatenation of the fragments into a stream.

    A socket contains an output and input stream. The output stream needs to fragment and the input stream needs to reassemble.

    Nothing magical happens, which is probably why you cannot find much.


    Often the application layer will however be given a relatively low level interface to the TLS layer, which will allow it to wrap or send its own fragments. For instance, this API by IBM shows that it allows the user to wrap & send or receive and unwrap each message itself. In that case the user of the library needs to take care of any message fragmentation / reassembly.

    As the actual method of fragmentation / assembly is not specified by TLS it should be considered implementation specific.