I was watching this video about TLS 1.3: "Deploying TLS 1.3: the great, the good and the bad (33c3)" and was somewhat surprised to see that in their effort to provide

"fewer, better choices"

they dropped AES-CBC as a supported block cipher mode.

The video lists a number of attacks (Lucky13, POODLE and others), that to my untrained eye seem to be implementation issues. I understand that it is better to have a mode that doesn't encourage such implementation issues, but was that all it took to deprecate this entire cipher mode?

While this book is somewhat dated (2010), Cryptography Engineering it recommends AES-CBC using a randomly generated IV as the best option.

  • 10
    Crypto that is difficult to implement in practice is crypto that is broken in practice. – Stephen Touset Feb 8 '17 at 20:40
  • 1
    @StephenTouset All crypto is difficult to implement correctly. If we had to give up on every cryptographic construction which had been implemented correctly a few times I don't think there would be any secure algorithms left to choose from. – kasperd Feb 8 '17 at 22:12
  • 4
    Some crypto is more difficult to implement than others. Much of the focus in the past decade of cipher design has been on the development of ciphers and constructs that are misuse-resistant, both from the perspective of end-users and from implementors. Your statement totally glosses over the huge strides we've made through replacing RSA with elliptic curves, ECDSA with EdDSA, unauthenticated ciphers with authenticated ones, S-box ciphers with ARX ciphers, and so on. – Stephen Touset Feb 8 '17 at 22:21

The problem here is not so much with CBC, but with alternatives that are easier to implement safely, without losing mathematical security.In fact, AES-CBC turned out to be notoriously difficult to implement correctly. I recall that older implementations of transport layer security don't have cryptographically secure initialization vectors, which are a must-have for CBC mode

A lot of recent attacks are padding oracle attacks, like the Bleichenbacher attack. These especially depend on old modes kept for support. POODLE is a downgrade vulnerability. LOGJAM is downgrading TLS to old, export-grade (read NSA-sabotaged) crypto suites.

For CBC mode, there is the Vaudenay attack. These attacks depend on the server explicitly saying "invalid padding", thereby leaking 1 bit of information on each transaction. Error messages were removed, but the problem of timing remained. The server still used more time before responding if the padding was valid.

In response they were forced to come up with the peculiar workaround of generating a dummy key, and using that for decryption so it would fail in another part of the implementation. In every implementation. So they decided to no longer force that on developers by supporting it in the specs.

Cryptography is a very broad field, and a specialty on its own. History had learned through uncomfortable experience, that doing it perfectly is almost never guaranteed, even for the best in the field. For example MD5, created by Ron Rivest, co-inventor (and part-namesake) of RSA was widely used, then broken in 2013 . Its collision resistance was circumvented in 2^18 time, less than a second on a desktop computer for 128 bit hashes.

| improve this answer | |
  • MAC-then-authenticate? I don't think that is what you meant to say. – kasperd Feb 8 '17 at 22:13
  • 1
    I don't watch youtube but the only relevant Bleichenbacher attacks I know are on the PKCS1 padding used for RSA encryption and signing, which are used in SSL/TLS only during key-exchange which can apply to all data ciphers, and also can be avoided for all data ciphers by using e.g. ECDHE-ECDSA instead. The padding used for (data) CBC in TLS is not in any PKCS, although it is similar to that in PKCS7. – dave_thompson_085 Feb 9 '17 at 9:27
  • Correct, i meant Vaudenay. Feel free to edit my answer as you see fit. – J.A.K. Feb 9 '17 at 11:47
  • Practical breaks of MD5 were demonstrated as early as 2005. By late 2008 there was already a demonstration of a practical certificate forgery attack. – Luis Casillas Feb 17 '17 at 2:20

CBC is a good mode for encryption if implemented correctly. In one short sentence, I've pointed out two defects of CBC.

  • CBC is an encryption mode only: it provides confidentiality, but not authenticity or integrity. You need to authenticate the data separately. It can be done, of course, and that was the only way to do it before TLS 1.2. But it's hard to get right, which is why authenticated encryption modes are recommended. TLS 1.3 pushes GCM instead of CBC + HMAC.
  • CBC is hard to implement correctly. There's the issue of how to combine it with a MAC that I already mentioned. Another issue is to not leak information through padding errors. The IV really must be random; an IV that is influenced by an adversary is insecure and is at least a BEAST.

If it's so hard to implement correctly, it's best not allowed by the protocol. Cryptography design is slowly moving towards from having a few well-studied, flexible primitives to having a few well-studied, robust primitives, because in practice the problem is less that people can't do what they want, but more that they do things that work in the nominal case but fall down to attacks.

| improve this answer | |
  • 1
    The IV must of course not be influenced by the adversary. But I don't know of any usage of CBC that failed because of that. What is subtle and easy to miss is that the even though the IV doesn't have to remain secret, it is important that the adversary does not learn it ahead of time. If you use CBC for streaming data the IV will become known to the adversary before you have encrypted the last block of the stream. – kasperd Feb 8 '17 at 22:21
  • Isn't GCM also hard to get right, especially for things like timing attacks? – user1686 Feb 9 '17 at 5:56
  • @grawity Timing attacks have a tendency to not work very well over a network, because the timing information you are interested in (generally, that related to the cryption process) tends to be completely dwarfed by timings that you have no real control over or exact knowledge of and which can show significant jitter (often, that related to the network transmission itself). Timing attacks are sometimes a valid threat for a local attacker, but really, how often is that the threat model for TLS? Not very often, I'd think. – user Feb 9 '17 at 8:57
  • @grawity The difficulties with CBC and GCM are a bit different. With GCM, implementing the primitive itself is difficult, but no more so than CBC (both are vulnerable to timing attacks if done wrong). With CBC, there's more difficulty around how to use the primitive, such as how to combine it with authentication; GCM bundles authentication, and it's robust if you have a robust RNG. – Gilles 'SO- stop being evil' Feb 9 '17 at 10:35
  • @MichaelKjörling Timing attacks are harder over a network, but not impossible. Especially if the attacker is located on the same rack in the same datacenter, or ever more so on a different VM running on the same processor, which is a practical threat in those days of shared cloud hosting. – Gilles 'SO- stop being evil' Feb 9 '17 at 10:36

Basically, Lucky13 happened, and the results were very bad: Amazon s2n thought they fixed it, but turns out they didn't. OpenSSL introduced a much worse vulnerability when they tried to fix it. Google's Adam Langley, possibly the best TLS implementer in the world, chose to not implement the fix in the Go standard library's TLS implementation and recommended people don't support CBC cipher suites if they're worried.

The correct implementation of TLS CBC ciphersuites is much too difficult.

Implementations thought fully patched and secure are discovered to be insecure as variations on the attack improve.

People knew there must be more issues than those listed above, because history taught us that whenever a person thinks of a new stupid thing that a bad TLS implementer might do wrong (like repeating nonces or checking only a single byte of the MAC) and writes a scanner that can check for this wrongness at scale, they inevitably find some implementations that indeed do it wrong and yet manage to get deployed in production, often at Fortune 500 companies.

This as-yet unpublished paper tells of some of the newest round: https://github.com/RUB-NDS/TLS-Padding-Oracles

Nobody who knows about the qualify of implementation of TLS by the smaller players (e.g. cavium, citrix, F5, wolfSSL and mbedTLS) can say that you can rely on them to do it correctly. An alternative exists which is more performant and is much easier to implement correctly, so the correct thing to do is to drop support.

| improve this answer | |

"Why" is always hard to answer without speculation. In the case of cryptography, our best guides to the future are attacks of the past. In this particular case, simply having the flawed CBC implementation present contributed to the POODLE attack.

We may now think everyone knows they should test their padding bytes schemes, but that's only an assumption. Sadly, too many people stop testing once they get the good results they expect, without ensuring there are no side effects in their leftovers.

Now, consider the cost of implementing TLS 1.3. Writing the code is easy. But developers are then going to have to test a combinatoric nightmare of versions, algorithms, key exchanges, etc. And we know that attackers have frequently exploited protocols by combining elements in unexpected and novel ways. Anything they can throw out of the suite makes studying it and testing it orders of magnitude simpler.

Was CBC really to blame, or did it just lead down a path where an unexpected mistake created a vulnerability? The answer is if that's a path we don't need, perhaps it's best to close it entirely, reducing the attack surface.

| improve this answer | |
  • 1
    POODLE was CBC/(old)padding combined with Mac-then-Encrypt (which latter could have been corrected); BEAST was a protocol flaw that could have applied to another chaining mode if another had been selected; CRIME is actually impeded by CBC versus stream, though not by much. Lucky13 is similarly CBC/(new)padding plus MtE. – dave_thompson_085 Feb 9 '17 at 9:07
  • @dave_thompson_085 For CRIME, compression matters more than encryption. And when we are talking about encryption, it is rather about block vs. stream. – v6ak Feb 9 '17 at 14:42

I believe that AES-CBC is still good, provided that you use it properly. Because TLS uses mac-then-encrypt, it is a dangerous field that allows multiple vulnerabilities. Current TLS implementations contain multiple hacks to implement it (hopefully) securely. For example, when a peer sees invalid padding, it just destroys some data (probably through xor) in order to break MAC check a while later. The whole process must take the same amount of time regardless of the error type (bad padding or MAC error) and error position in order not to leak any information in timing.

Removing CBC is one way how to fix it for the new protocol version. Using encrypt-then-mac would be another way, but this would AFAIK change structures of TLS, which could cause implementation difficulties, I guess. Changing the protocol structures could be painful in code that supports multiple TLS versions. Since there are other good modes, it is probably easier to switch to them than to change the protocol structures.

| improve this answer | |

It boils down to Moxie Marlinspike's Cryptographic Doom Principle, which states:

If you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

With the AES-CBC as implemented in TLS 1.2, an HMAC of the plaintext (and header information) is taken. Then, this HMAC is concatenated with the plaintext, padded to the necessary length, then encrypted with AES-CBC, and sent over the wire. See section of RFC5246 for more information.

This is the Authenticate then encrypt case, as described in the blog post referenced above by Moxie: The sender computes a MAC of the plaintext, then encrypts both the plaintext and the MAC. Ek1(P || MACk2(P)). This is susceptible to Vaudenay's Attack, as described in the blog post.

| improve this answer | |

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.