A server uses TLS 1.3 with a valid certificate — why might the connection still not be secure?
Because TLS is only as strong as its weakest link: a buggy implementation, a misconfiguration, or a compromised/over-trusted certificate authority can all defeat an otherwise-modern protocol.
* The TLS handshake — hello, certificate, key exchange, finished — establishes the keys before any data is encrypted. *
Picking a modern protocol version is only step one. Always negotiate TLS 1.3 (or at least 1.2) — versions below 1.2 have known, exploitable flaws (POODLE, BEAST) and should never be used. mTLS (mutual TLS) goes further: both sides present a certificate, so each authenticates the other, not just the client verifying the server. But even a perfect protocol choice leaves these practical gaps:
- Bad implementation — flaws in the protocol code or its arithmetic (e.g. timing side-channels) can leak secrets even when the maths is sound on paper.
- Misconfiguration — weak cipher suites, expired or self-signed certificates, or downgrade-friendly settings quietly weaken the channel.
- Weak or vulnerable CAs — browsers trust hundreds of certificate authorities, so a single compromised or negligent one can issue a valid certificate for any site.
- A (corrupt) government can compel a trusted CA to issue fake certificates and impersonate a site to intercept traffic.
Key insight: the protocol is the easy part — implementation, configuration, and whom you trust to vouch for identities decide whether TLS actually protects you.
Go deeper:
RFC 8446 — TLS 1.3 — the canonical TLS 1.3 standard; what the protocol actually mandates.- Transport Layer Security (Wikipedia) — broad overview with a dedicated handshake section (basic, mTLS, resumed, 1.3).