Is there any CBC based ciphersuite which are secure for known attacks like LUCKY13?

Question

If you select the modern profile in https://mozilla.github.io/server-side-tls/ssl-config-generator/ , you can see it recommends to enable following four cipher suites also.

• ECDHE-ECDSA-AES256-SHA384 ( = TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384)
• ECDHE-RSA-AES256-SHA384 ( = TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384 )
• ECDHE-ECDSA-AES128-SHA256 ( = TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256 )
• ECDHE-RSA-AES128-SHA256 ( = TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256 )

According to various sources in the internet, attacks like LUCKY13 are possible if you use CBC based cipher suites. (e.g. Why did TLS 1.3 drop AES-CBC? )

The question I have is, - As Mozilla clearly recommend above CBC based cipher suites, are those not vulnerable to LUCKY13, and also are those secure against any known such attacks?

Answer 1

No, all TLS CBC cipher suites have the same problems: most old implementations and a minority of currently deployed implementations (some unpatchable, some where the vendor could not be contacted by researchers, etc.) have a variant of lucky13 or poodle (both have many named variants).

The Mozilla list is likely from before the discovery of the new variants of poodle which finally caused SSL Labs tester to mark all CBC cipher suites "weak".

It is possible to implement CBC cipher suites correctly, but it is too hard. If the effort is made to implement them correctly, it would be better to spend the effort at supporting GCM or CCM or ChaCha20-Poly1305.

If the other side can support AEAD, you should use AEAD. If the other side can't support AEAD, you have to be very suspicious and test its CBC thoroughly. TLS is supposed to be secure without first testing the other side, so if you can drop CBC support you should do that. This means you drop support for TLS versions below 1.2.

Of course, for business reasons, many will choose to support CBC cipher suites for a long time. When can a business drop support? When no such clients exist in practice. When will users stop using clients (or proxies) that can only do CBC? When such clients can't connect to important servers (e.g. google, facebook). This will take a long time.

Chrome might show UI for "insecure" for sites that require CBC cipher suites next year, but dropping them completely - I guess not. Google's servers can't show UI for insecure - they either allow connections or not, so I think they will allow connections with CBC cipher suites for a long time (though they have published they want people to upgrade to AEAD and only promise to support ECDHE with AEAD).

Answer 2

Lucky 13 applies to all cipher suites that use CBC, regardless of what else they use. The attack is solely against CBC and the way it's used in TLS, independently of what else the protocol does.

There are several defenses against Lucky 13, but none of them is a panacea.

• In principle, Lucky 13 is an attack against implementations of TLS, not an attack on the protocol itself. It is possible to implement TLS CBC-based cipher suites in a way that protects against Lucky 13. The problem is that it's very difficult to do so, and it comes with a significant performance penalty. I think OpenSSL's mitigation fully protects against the attack (and pays the performance cost) (note that it took a few tries), but not all TLS implementations do. This is a case where “just update your software” might not solve the problem.
• The encrypt-then-MAC extension fully defends against Lucky Thirteen or any other CBC padding oracle that may arise. It needs to be supported both on the server and on the client. The problem is that not all TLS implementations support it, and most software doesn't let you configure TLS cipher suites to say “this cipher suite is only allowed if EtM is enabled”.
• The best defense is of course to disable all CBC cipher suites, and use only AEAD (which requires TLS 1.2 or above). However, not all clients and servers out there support AEAD cipher suites. On the Internet, in mid-2017 to mid-2018, the proportion of TLS connections using AEAD (meaning that both sides support AEAD) stagnated around 85% (source: Coming of Age: A Longitudinal Study of TLS Deployment fig. 2; see §3 for how the measurements were collected).