I don't know enough about TLS < 1.3. In TLS 1.3, the whole handshake on both sides is covered by the handshake completion --- if the client handshake was modified in the middle, the client will not accept the server handshake completion.

However, that doesn't stop carriers from inserting something at the start of the stream that the client doesn't see. It would need to be coordinated with the origin server, but that's already true for HTTP header insertion. Sending a pre-handshake blob to a TLS server that isn't expecting such a blob would fail hard though, rather than going on its merry way like an extra header usually would.

I'm really not certain, as I've never seen an implementation that involved it. There was a lot of stink about it 5 years ago[1], which called out the exact argument of it not working for HTTPS traffic. Which, is a substantially larger portion of traffic now than it was at the time.

But you still see nondescript references to the capability in places like that that up-to-date Adobe Analytics doc, and the carriers aren't trying to use legal means (a la lobbying) to slow down the uptick in HTTPS traffic and preserve their revenue stream. Which leads me to presume they've developed technical solutions that are compatible with HTTPS traffic. They can't really use the spray-and-pay method[2] they were using. But all bets are off when they destination site and the carriers are coordinating with each other, as that coordination can involve technical modifications to facilitate it in addition to just the whitelisting itself.

[1] https://www.ghacks.net/2015/08/31/are-mobile-carrier-injecte...

[2] Some carriers would inject a header into all traffic, and any interested party could slurp them up. But you'd have to pay the carrier to access any of the other information the carrier had for that particular identifier.