Is HMAC part of the TLS/SSL process?

Question

Does HMAC take part in TLS/SSL? When the client and the server pass the TLS handshake and create a common SESSION key, do they also HMAC each message that is being sent out for the purpose of data integrity?

Answer 1

Modern versions of TLS (TLS 1.2 with modern cipher suites, TLS 1.3) do not use HMAC for the to protect the integrity or authenticity¹ of each message. They use dedicated authenticated encryption (AEAD) primitives, such as a block cipher (e.g. AES) in GCM or CCM mode, or ChaCha20+Poly1305. CCM uses the block cipher for integrity as well as confidentiality. GCM and Poly1305 use different constructions that are neither based on a block cipher nor based on a hash.

It is possible to construct authenticated encryption with HMAC, and that's what versions of TLS up to 1.2 did, with either a stream cipher (RC4) or a block cipher in CBC mode for confidentiality. Those methods are problematic and deprecated (I won't go into details here, look up 2000s and 2010s attacks against TLS such as BEAST, POODLE, Lucky Thirteen, etc.). The problems come from the confidentiality side, not from HMAC. HMAC itself is very robust, but combining an authentication primitive and a confidentiality primitive is tricky. The main reason standard AEAD constructions don't use HMAC is that it's slower than the standard constructions, and the robustness of HMAC is not needed.

HMAC is used in some places in modern TLS, just not for the integrity or authenticity of normal messages. In TLS 1.3, it's used for the integrity of the handshake. (Older versions of TLS just use a hash there. A hash is good enough, but HMAC is more robust in case an unlikely weakness is discovered in the hash function.) HMAC is also used to derive keys and other cryptographic material, not for its authenticity or integrity properties, but because with standard cryptographic hash functions, HMAC is a very robust pseudorandom function. TLS 1.0/1.1, TLS 1.2 and TLS 1.3 use slightly different constructions, all based on HMAC.

¹ _{Integrity: protection against modification. Authentication: allowing to verify the origin of a message. HMAC can guarantee both. An integrity guarantee is generally not useful in a communication protocol: integrity would mean that the recipient would compare the HMAC with a previously known value, but the recipient has no previously known value to compare with. The recipient of a message verifies its authenticity by checking that the MAC or authentication tag is correct. Since the message is authentic, it must be part of the conversation, but it might be out of order, or resent. So to validate the integrity of the conversation, each message contains a number (0 for the first message, 1 for the second message, etc.) which is part of the authenticity-protected data, and the recipient verifies that it receives messages in the correct order.}

Answer 2

Yesno.

HMAC is used to create the authentication tag in the cipher suites for TLS 1.2 and older that contain a non-authenticated cipher such as ciphers in CBC mode or RC4.

For the other cipher suites HMAC is also used, but only as part of the key derivation mechanism that derives the session keys from the master secret (which is created by key establishment, e.g by using RSA encryption or ephemeral Diffie-Hellman (DHE / ECDHE). In that case HMAC is part of a TLS-specified PRF - TLS 1.2 or lower, or part of HKDF (TLS 1.3). It is also used to authenticate the handshake (this part taken from Gilles answer).

Of course, if an authenticated cipher is used then it also creates an authentication tag (concatenated to the ciphertext), however it would use another message authentication code for it, such as GMAC for AES-GCM or Poly1305 with ChaCha20/Poly1305 (obviously) and CBC-MAC for CCM.