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.
- 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.
- 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).
- 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.
- 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).
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.