How SSL and TLS Work

Modern HTTPS relies on TLS, even if people still say SSL

SSL is the older family of protocols. In modern systems, TLS is the actual protocol used to secure web traffic and many other network connections. In practice, people still say “SSL certificate” or “SSL connection,” but the underlying mechanism is almost always TLS.

The point of TLS is to let a client talk to a server over an untrusted network while still getting confidentiality, integrity, and server authentication.

Last updated: May 11, 2026

Colorful TLS handshake diagram showing Client Hello, Server Hello, certificate validation, and shared key setup. — TLS starts with identity and key agreement, then switches to fast symmetric encryption for the rest of the session.

The basic idea

TLS combines public-key cryptography and symmetric encryption. Public-key operations are used during the handshake to authenticate identity and agree on key material. Once that setup is done, both sides switch to symmetric keys because symmetric encryption is much faster for bulk data transfer.

What happens during the handshake

The client connects and says which protocol versions and cipher suites it supports.
The server responds with its chosen parameters and presents a certificate.
The client validates that certificate against trusted certificate authorities and the requested hostname.
Both sides derive shared session keys using the negotiated key exchange process.
After the handshake finishes, application data is encrypted and authenticated with those symmetric keys.

Why certificates matter

A certificate binds a public key to a domain name or entity identity. It lets the client verify that the public key really belongs to the server it intended to reach, rather than an attacker sitting in the middle.

Without a trusted certificate chain, encryption alone would not prove who you are talking to.

What handshake failures usually mean

If a browser warns about a certificate, the problem may be an expired certificate, a hostname mismatch, a missing intermediate certificate, a client that does not trust the issuing authority, or a network device intercepting traffic unexpectedly. Those failures are often operational, not theoretical cryptography problems.

What TLS protects

Confidentiality: outsiders cannot read the plaintext traffic.
Integrity: traffic cannot be modified silently without detection.
Authentication: the client can verify the server identity if certificate checks succeed.

What TLS does not hide

TLS protects application data in transit, but it does not automatically hide every piece of metadata. Observers can still often see the destination IP, connection timing, traffic volume, and whether a TLS session happened at all. It also does nothing to fix application-layer vulnerabilities such as broken authorization or unsafe data handling after decryption.

Common confusion

HTTPS is HTTP running over TLS.
TLS does not make an insecure application safe if the application itself leaks data or has authorization bugs.
Encryption in transit is different from encryption at rest.

Why developers care in practice

TLS is involved in local development certificates, API client trust settings, reverse proxies, load balancers, service-to-service traffic, and public browser warnings. Even if you never implement a cryptographic primitive yourself, you still need a working mental model to debug real systems.