I read that, on TLS, each TLS Record (after the handshake) is "reliable", meaning, it cannot be tampered with.

I understand the handshake, but I don't understand exactly how "tamper-proofness" is achieved per TLS Record or TCP packet.

I have a suspicion that each record includes the HMAC of the record itself plus the session/master-key, but I would like to confirm that.

How is each TLS record "signed"?


The property you're referring to is usually called integrity. In general, TLS uses one of two approaches for this.

The first approach, which is new in TLS 1.2, is called an AEAD (authenticated encryption with associated data) cipher. This type of cipher both encrypts the data and generates an authentication tag that the remote side can used to verify the integrity of the data. In TLS, the most common ciphers that are used this way are AES-GCM and ChaCha20-Poly1305, with AES-CCM used less frequently.

The older approach is to use HMAC in conjunction with an independent cipher. As part of the generation of session keys, an additional set of MAC keys is generated to be used with HMAC. TLS authenticates the plaintext and then encrypts the plaintext and MAC, instead of encrypting the data and then authenticating the ciphertext. The former approach means that a variety of timing attacks on padding and MAC verification can be exploited if the implementer is not exceptionally careful. The latter approach, called Encrypt-then-MAC, is preferred in the cryptographic community because it avoids those problems, but is not commonly used in TLS for historical reasons. TLS 1.3 no longer permits this mechanism because of the potential for timing attacks.

In all cases, the data authenticated is similar, and includes the sequence number (and in DTLS, the epoch), headers, and data. Authenticating this additional data, including the sequence number, prevents an attacker from replaying packets and is a best practice for cryptographic protocols.

  • That's a very elaborate answer @bk2204. Thank you very much – André Pena May 11 at 19:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.