2

I have been trying to get my head around the MAC part of the TLS connection as both the key exchange and cipher seem to make sense.

As far as I understand the MAC is used to ensure that the information that is received is authentic, but here are my questions:

  • Is a MAC sent only during the handshake (the async bit) or is one sent with each piece of transferred information (both the async and sync bits)?

  • When a client talks to a server, does it always send a MAC?

  • When a server talks to a client, does it always a send a MAC?

  • In regards to TLS, is a MAC created via EtM, E&M or MtE? In short, is the MAC sent as plaintext?

  • If a MAC doesn't match-up is the connection terminated? Does the whole handshake process have to begin again?

3

Is a MAC sent only during the handshake (the async bit) or is one sent with each piece of transferred information (both the async and sync bits)?

Both.

When a client talks to a server, does it always send a MAC?

When a server talks to a client, does it always a send a MAC?

Yes. Direction does not matter. (Only cipher suite type: One of Stream/Block/AEAD. And stream and block do have the external TLS-MAC and AEAD does the MACing itself.)

In regards to TLS, is a MAC created via EtM, E&M or MtE? In short, is the MAC sent as plaintext?

The default case is to use the MAC-then-encrypt. And this is not really regarded as hip anymore. You can switch to Encrypt-then-MAC only via a newish TLS extension

If a MAC doesn't match-up is the connection terminated? Does the whole handshake process have to begin again?

Yup. And this is quite reasonable if you are communicating over a protocol like TCP that is supposed to guarantee integrity against things like line-noise. This bad_record_MAC alert is always fatal and will abort a session.

  • Hi, thanks for the above, it is very helpful. The bit that still confuses me is MtE part, it seems to make sense if the MAC is sent unencrypted, but what confuses me is when it is encrypted. Surely by encrypting both the text and the MAC with the private key that MAC would always match due to you needing the private key to decrypt the file to see the MAC. I can't imagine a scenario where, through MtE, the MAC would never match. Here is the image I have been using to try and visualise this: en.wikipedia.org/wiki/Authenticated_encryption#/media/… – Wub Dec 28 '15 at 21:12
  • @Wub Imagine one AES128 block. That's 16 bytes. Now imagine that you arbitrarily decide "I'm gonna treat those 16 bytes as 10 bytes payload and 6 bytes MAC!" You put your 10 bytes plaintext in, then you calculate the MAC with your MAC key. And then you encrypt the whole thing with your AES key. Now if someone flips a bit on this 16 byte blob in transit, then afterwards it will still decrypt to well something. But with high probability the last 6 bytes will no longer be a valid MAC for the first 10 bytes. (Sidenote: Also: in TLS the MAC keys and the AES keys are different.) – StackzOfZtuff Dec 29 '15 at 8:35
  • Hi, again thanks for this. It's your sidenote that makes this begin to make sense. Just so I understand this, this different key is still part of the master secret that is defined in the handshake, it is just a different part of the master key? – Wub Dec 29 '15 at 22:50
  • In a way. The master secret is expanded into a "key_block" that contains 6 secrets. (3 for each direction.) – StackzOfZtuff Dec 29 '15 at 23:00

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.