Overview#SSL-TLS is layered and the bottom layer is the Record Protocol.
HH V1:V2 L1:L2 datawhere:
- HH is a single byte which indicates the TLS ContentType which indicates the data type in the record.
- V1:V2 is the protocol version, over two bytes. For all versions currently defined,
- L1:L2 is the length of data, in bytes (Big-Endian convention is used: the length is 256*L1+L2). The total length of data cannot exceed 18432 bytes, but in practice it cannot even reach that value.
- five-byte header (HH V1:V2)
- followed by at most 18 kB of data. (L1:L2)
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 handshake protocol, described in the next section. Compression, if any, is also applied at that point.
In full details, the building of a record works like this:
- Initially, there are some bytes to transfer; these are application data or some other kind of bytes. This payload consists of at most 16384 bytes, but possibly less (a payload of length 0 is legal, but it turns out that Internet Explorer 6.0 does not like that at all).
- The payload is then compressed with whatever compression algorithm is currently agreed upon. Compression is stateful, and thus may depend upon the contents of previous records. In practice, compression is either "null" (no compression at all) or "Deflate" RFC 3749, the latter being currently courteously but firmly shown the exit door in the Web context, due to the recent CRIME attack. Compression aims at shortening data, but it must necessarily expand it slightly in some unfavorable situations (due to the pigeonhole principle). SSL allows for an expansion of at most 1024 bytes. Of course, null compression never expands (but never shortens either); Deflate will expand by at most 10 bytes, if the implementation is any good.
- The compressed payload is then protected against alterations and encrypted. If the current encryption-and-integrity algorithms are "null", then this step is a no-operation. Otherwise, a MAC is appended, then some padding (depending on the encryption algorithm), and the result is encrypted. These steps again induce some expansion, which the SSL standard limits to 1024 extra bytes (combined with the maximum expansion from the compression step, this brings us to the 18432 bytes, to which we must add the 5-byte header).
The MAC 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 MAC is first computed and appended to the data, and the result is encrypted. This is MAC-then-encrypt and it is actually not a very good idea. The MAC is computed over the concatenation of the (compressed) payload and a sequence number, so that an industrious attacker may not swap records.