Which TLS features are vulnerable to chosen-prefixes collision on SHA-1?

Question

Gaëtan Leurent and Thomas Peyrin's preprint From Collisions to Chosen-Prefix Collisions - Application to Full SHA-1 (in volume 1 of proceedings of the forthcoming Eurocrypt 2019) shows a feasible chosen-prefixes collision attack on SHA-1. Given distinct prefixes $P_A$ and $P_B$ of equal length, the attack produces suffixes $S_A$ and $S_B$ with $\operatorname{SHA-1}(P_A\mathbin\|S_A)=\operatorname{SHA-1}(P_B\mathbin\|S_B)$. The attack has feasible cost: a few times that for shattered, which given prefix $P$ produces distinct suffixes $S_A$ and $S_B$ with $\operatorname{SHA-1}(P\mathbin\|S_A)=\operatorname{SHA-1}(P\mathbin\|S_B)$.

Which TLS features (ciphersuites, certificates, etc..) are vulnerable to such chosen-prefixes collision attack?

Answer 1

Executive summary:

The history of attacks on SHA-1, especially by Marc Stevens et al since about 2012, made people realize SHA-1 will get broken soon enough and it's time to stop using it. This process was complete before SHA-1 got completely broken, so nothing terrible happened with the latest publication.

So let's review how TLS uses hash functions.

1. As PRF to derive shared secret values (symmetric keys, IVs, nonces, MAC keys, etc.) from key exchange.

The PRF of TLS 1.1 and below uses SHA-1, but in HMAC. HMAC-SHA1 is not affected by the latest break.

2. SHA-1 is used in HMAC-SHA1 as MAC for the TLS Record Protocol, in cipher suites that use HMAC (i.e. cipher suites whose names end in "_SHA").

HMAC-SHA1 is not affected by the new break of SHA-1, so those cipher suites are not affected. You shouldn't use them anyway because it's MAC-then-Encrypt and there are many bad implementations in the wild (lots of Lucky13 variants, lots of POODLE variants).

3. SHA-1 can be used to issue leaf certificates and intermediate certificates.

SHA-1 certs have not been allowed for a few years (both leaf certs and intermediate certs). At the time, Facebook, Cloudflare and Symantec fought for SHA-1 certificates, the first two because they saw some traffic from clients that only support SHA-1 certificates and the latter because they had customers who were willing to pay a lot of money for such certificates to enable support for old hardware that can't be patched to enable SHA-256 certificates. A few CAs got caught issuing SHA-1 certificates after the deadline and were punished by browsers. This is all old news by now.

SHA-1 was known to be weak long enough in advance that the Web PKI TLS ecosystems is unaffected.

I suppose private PKIs using TLS are affected if they don't follow the best practices enforced by Web PKI, the CA/Browser Forum Baseline Requirements, Chrome security (as the largest browser, when they deprecate something it's dead), etc.

4. SHA-1 can be used for authentication, to sign the handshake key share messages ServerKeyExchange (DHE and ECDHE cipher suites) and CertificateVerify (only used with client certificates).

TLS servers that perform SHA-1 signatures over ServerKeyExchange message and TLS clients using client certificates that perform SHA-1 signatures in CertificateVerify messages using the key of their certificate might be vulnerable (I suppose those are almost exclusively RSA-SHA1 signatures, though I suppose other kinds can be used too).

I was under the impression that SHA-1 signatures produced by the TLS server itself have also been not allowed, but now I see that the TLS RFC doesn't say that, and there is a proposal to change the RFC.

Chrome removed support for ECDSA-SHA1 signatures in 2016.

Google said that they really want servers to support SHA-256 or SHA-512 for signing ServerKeyExchange (and Chrome might treat servers not supporting "modern TLS" as insecure), but I guess Chrome does not require it yet, so existing TLS 1.2 servers might sign ServerKeyExchange using SHA-1. I don't think the current attacks on SHA-1 let you do anything with this (it's a signature over client random, server random and server DH params).

Conclusion:

I think the current attacks only break SHA-1 CAs, and only those that issue certificates with predictable serial numbers (all of that has not been allowed for a while for publicly trusted certificates).

Recommendation: Don't use SHA-1 certs even if they are not publicly trusted, don't support SHA-1 signatures in the TLS handshake, use SHA-256 and SHA-512 instead.