5
$\begingroup$

Encrypt-then-Authenticate (EtA) seems to generally be considered the better option, compared to Authenticate-then-Encrypt (AtE) (see this Crypto.SE question, for example). The people writing the RFC for TLS 1.2 seem to have been aware of this, but have chosen to use AtE anyway.

Is there a reason why this is the case? Is this a case of "Someone standardized something at some point and now we're stuck with it for backwards compatibility, even though we know it's bad", or is there a good reason why AtE is better for TLS?

Clarification, because this wasn't very well-written originally: I am referring to the actual encrypted channel after the handshake has finished. It's clear that you have to authenticate the server and perform a key exchange before you can perform any useful form of encryption.

$\endgroup$

2 Answers 2

12
$\begingroup$

SSL was designed long ago when encrypt-then-MAC wasn't that popular yet. Even TLS 1.2, published in 2008, is pretty old by now, and while encrypt-then-MAC was preferred by then, the practical risks were underestimated for a long time. Padding oracles attacks became well known after several high profile attacks in 2010.

With stream ciphers, MAC-then-encrypt is safe and easy to implement correctly. With CBC it's trickier, but technically the way it's used in TLS is provably secure if you ensure that the attacker doesn't learn anything about the cause of a detected manipulation (invalid padding vs incorrect MAC etc).

The choice of MAC-then-encrypt has lead to several weaknesses over the history of SSL and TLS, including POODLE and Lucky 13.

  • Lucky 13 was a timing attack, which gave an attacker information about why decryption failed, invalidating the proof.
  • POODLE was an attack against SSL 3.0 (and some careless TLS implementations) which didn't have as strict padding validation requirements as newer versions of TLS.

In response to these attacks TLS implementations were carefully written to avoid side channel attacks, working around these weaknesses.

There is a draft TLS extension (Encrypt-then-MAC for TLS and DTLS draft-gutmann-tls-encrypt-then-mac) to use encrypt-then-MAC, but it didn't gain much traction and still hasn't been finalized.

TLS 1.3 will only support AEAD suites, where each suite is responsible for ensuring both confidentiality and authenticity, instead of combining MAC and encryption at the protocol level. So in TLS 1.3 this problem will finally be fixed.

$\endgroup$
2
  • $\begingroup$ So, basically, it really is a case of "someone standardized it like this and they never got around to changing it because of backwards compatibility". Figured as much, but good to have it confirmed. Thanks! $\endgroup$
    – malexmave
    May 24, 2015 at 11:24
  • $\begingroup$ The Gutmann draft was superseded by an IETF draft and adopted as rfc7366 in Sep. 2014, before this answer was written. It didn't get widely implemented immediately though. It did become fairly common by about 2018 -- the same time TLS1.3 finally was approved, which as you say eliminates the issue by requiring AEAD. About the same was true for Sep. 2015 rfc7627 Extended Master Secret, better known as 'fix renegotiation again this time we really mean it'. $\endgroup$ Aug 11, 2020 at 5:39
-1
$\begingroup$

if you do encrypt first you have to have pre-shared secret keys between client and servers? once master secret is generated then Record protocol job is to encrypt/decrypt.

$\endgroup$
2
  • $\begingroup$ I think you misunderstood the question. I was referring to the actual operation of the protocol after the handshake has finished, and the order in which the encrypted content of the connection is encrypted and authenticated. You seem to be talking about the handshake protocol itself. $\endgroup$
    – malexmave
    May 24, 2015 at 10:38
  • $\begingroup$ I re-read the question and noticed that this was indeed not very clear. I have updated it to make this more obvious. $\endgroup$
    – malexmave
    May 24, 2015 at 10:41

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.