The protocol provides three things. The traffic cannot be read, it cannot be altered undetected, and the server is who it claims to be.
Only the third depends on anything outside the mathematics, and it is where the practical weaknesses concentrate.
What the handshake establishes
The two sides agree on which algorithms to use, the server presents a certificate, the client validates it, and both derive a shared secret used to encrypt everything that follows.
The derivation is the important part. The secret is computed by both sides from values exchanged in the open, and an observer recording the entire exchange cannot reconstruct it.
What a certificate actually proves
It binds a public key to a name and carries a signature from an authority the client already trusts. Validation checks the signature chain, the name, the validity dates, and revocation where available.
What it does not prove is that the operator is honest, competent, or the organisation you assume. A certificate for a name asserts control of that name and nothing further, which is why the presence of encryption says nothing about the trustworthiness of a site.
Where 1.3 differs
| Property | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake round trips | Two | One |
| Forward secrecy | Optional | Required |
| Cipher options | Many, including weak ones | Small, all authenticated encryption |
| Static key exchange | Permitted | Removed |
| Handshake visibility | Largely in the clear | Mostly encrypted |
The removals matter more than the additions. Most attacks against the older version exploited negotiable weak options, so eliminating the options eliminated the negotiation attacks.
Forward secrecy, and why it is the important one
With ephemeral key exchange, the secret protecting a session is discarded when the session ends and is never derivable from the server's long term key.
An adversary recording traffic today and obtaining the server key years later can decrypt nothing. Without it, that key decrypts every recorded session retrospectively, which is why the property became mandatory rather than optional.
Where the session terminates
The guarantee runs to whichever device completes the handshake, and that is frequently not the application server. Load balancers, reverse proxies, and content delivery networks commonly terminate the session and forward the request onward.
Traffic beyond that point is only protected if a second session is established, and a great many deployments send it in the clear across an internal network on the assumption that the internal network is safe.
What it does not cover
The endpoints are outside the guarantee entirely. Content is plaintext where it is produced and where it is consumed, so a compromised device is unaffected by the protocol.
Metadata also survives. The destination address, the timing, the volume, and in most deployments the requested hostname are visible to anyone on the path, which identifies the service being used without revealing the content.
What the warnings actually mean
| Warning | Usual cause |
|---|---|
| Expired certificate | Renewal was missed |
| Name does not match | Wrong certificate, or accessed by address |
| Issuer not trusted | Self signed, or an interception device |
| Chain incomplete | Server not sending intermediates |
The third row is the one worth pausing on, because a corporate inspection device and a hostile interception produce an identical message. The client has no way to distinguish them.
The trust model is the soft part
A client trusts a set of authorities shipped by its operating system or browser, and any one of them can issue a valid certificate for any name.
That means the security of every connection depends on the least careful authority in the store. Certificate transparency logs and name pinning exist to constrain this, and the underlying structure remains one where trust is broad rather than specific.
Note: a certificate warning means validation failed, which is either a misconfiguration or an interception, and the client cannot tell which. Dismissing it discards the only assurance the protocol offers about who is at the other end.