What measures protect sensitive communication against SSL interception?

Use trusted networks and devices, check the certificate issuer, and prefer mechanisms that do not depend only on the local trust store: certificate pinning, mutual TLS, phishing-resistant logins, a trusted VPN, and Certificate Transparency monitoring.

For users:

• Use e-banking and similar services only on networks you trust; on public hotspots, a VPN to a trusted endpoint moves the "gateway" out of the hotspot operator's hands.
• Never click through certificate warnings; read the issuer when in doubt.
• Do not install unknown root certificates or "security profiles" when a network or app asks.

For applications and organisations:

• Certificate or public-key pinning in mobile and desktop apps: the app accepts only the expected certificate or key, so an interceptor's CA does not help, even if it is in the system trust store.
• Mutual TLS and FIDO2/passkeys: the client's proof is bound to the real server or origin, so a proxy cannot simply relay the credential.
• HSTS (with preloading) so browsers never accept plain HTTP or click-through warnings.
• Certificate Transparency monitoring and CAA records to detect or prevent mis-issued certificates for your domains.
• Govern the internal PKI: issue sub-CA certificates only under strict control and with name constraints; if TLS inspection is operated, declare it, exclude banking/health categories, and make the proxy validate upstream certificates properly.

Go deeper:

• CISA: HTTPS Interception Weakens TLS Security — recommendations for organisations that run interception.
• Wikipedia: Certificate Transparency — how public logs expose fraudulent certificates.
• Wikipedia: HTTP Strict Transport Security — preloading and the no-click-through rule.