6
$\begingroup$

I've been working through how TLS1.0 works, and think I've basically understood most of it. One thing I can't seem to find a explanation of though is the order in which MACing and encrypting should happen. Let's say we've got the client finished message. You generate the 12 bytes of verify_data from the master secret, the finished label, and the md5/sha1 hashes of the handshake messages. At that point, do you:

a-> use your MAC key to create a hash of the 12 bytes, tag it onto the end and then encrypt the whole thing with your Write Key, or

b-> use your MAC key to create a hash of the 12 bytes, then use your Write Key to encrypt the 12 bytes, and tag the hash onto the end of the encrypted bytes?

Improve this question
$\endgroup$
1
  • $\begingroup$ TLS CBC is mac-then-encrypt, so option a. Only TLS1.2 with aead is considered secure. There is an RFC for encrypt-then-mac TLS CBC but nobody implements it. $\endgroup$
    – Z.T.
    Commented Aug 10, 2015 at 12:02

3 Answers 3

Reset to default
9
$\begingroup$

It depends on which cipher suites and extensions the client and the server implement, enable and negotiate.

  • The default operation in TLS 1.2 and earlier, is MAC then Encrypt. This corresponds to alternative a in the question.
  • In TLS 1.2 it is possible to use AEAD cipher suites. Such cipher suites (e.g. AES-CCM but not AES-GCM) might correspond to alternative b in the question.
  • In all versions of TLS, the client and server might negotiate use of Encrypt then MAC with all non-AEAD cipher suites, provided that they both implement RFC 7366.
Improve this answer
$\endgroup$
4
  • 1
    $\begingroup$ I don't think anyone does RFC 7366 in practice. Do you have any information on this? CCM and GCM are THE solution to this problem! $\endgroup$
    – Yehuda Lindell
    Commented Aug 10, 2015 at 14:35
  • 1
    $\begingroup$ RFC 7366 is widely implemented, e.g. by Chrome, Mozilla, OpenSSL etc. $\endgroup$
    – Henrick Hellström
    Commented Aug 10, 2015 at 14:51
  • 1
    $\begingroup$ And servers? From what I see the RFC is from September 2014, so how can it be supported in older versions of TLS? My guess would be that it is now started to be supported in browsers with the hope that new servers will follow. If yes, this will be great and will solve a huge amount of our SSL problems. $\endgroup$
    – Yehuda Lindell
    Commented Aug 10, 2015 at 14:55
  • 1
    $\begingroup$ Some servers are updated. Technically, a modern browser and a modern server might still negotiate an older version of TLS. Since there are still a lot of buggy TLS 1.0 servers out there that will choke on TLS 1.1 and later, some generic TLS clients solve that by only enabling TLS 1.0 by default, unless they know for sure the server supports later versions. $\endgroup$
    – Henrick Hellström
    Commented Aug 10, 2015 at 15:06
4
$\begingroup$

Yes, TLS works by MAC then encrypt. This is the source of a large number of padding-oracle-type attacks over the past few years.

Improve this answer
$\endgroup$
0
$\begingroup$

I've actually just stumbled across this page which is a great explanation of how TLS all works. It explains that you take the hash first, then encrypt the whole thing.

http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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