What Is SSL/TLS? How Encrypted Connections Actually Work

SSL/TLS is the cryptographic protocol that secures most of the traffic on the internet. It encrypts the data flowing between a client (like a browser) and a server, verifies the server's identity, and detects any tampering in transit. When you see https:// and a padlock in the address bar, TLS is doing the work underneath.

SSL vs. TLS: the naming

SSL (Secure Sockets Layer) was the original protocol, developed by Netscape in the 1990s. TLS (Transport Layer Security) is its successor and the name used for every modern version. All SSL versions and the early TLS versions (1.0 and 1.1) are deprecated and considered insecure; the protocols in active use today are TLS 1.2 and TLS 1.3.

In everyday speech people still say "SSL" — "SSL certificate," "SSL termination" — but the actual protocol running is TLS. The two terms are used interchangeably even though SSL itself is long dead.

What TLS actually provides

TLS delivers three guarantees, and it's worth keeping them separate because they solve different problems:

• Confidentiality — the data is encrypted, so an attacker who intercepts the traffic sees only ciphertext.
• Integrity — each message carries an authentication code, so tampering or corruption is detected and the connection is dropped.
• Authentication — the certificate proves you're talking to the real server for that domain, not an impostor. (Client authentication is also possible but optional.)

A common misconception is that HTTPS means a site is "safe" or "trustworthy." It only means the connection is encrypted and the server's domain identity is verified. A phishing site can have a perfectly valid certificate.

How the TLS handshake works

Before any application data moves, the client and server run a handshake to agree on encryption parameters and establish shared keys. At a high level:

1. The client sends a ClientHello listing the TLS versions and cipher suites it supports, plus random data.
2. The server replies with a ServerHello choosing the version and cipher suite, and sends its certificate.
3. The two sides perform a key exchange (modern TLS uses ephemeral Diffie-Hellman, typically over elliptic curves) to derive a shared symmetric key. The private key never leaves the server.
4. Both sides confirm the handshake, then switch to fast symmetric encryption for the actual data.

This is a hybrid design: slow public-key cryptography is used briefly to agree on a key, then fast symmetric cryptography (such as AES-GCM or ChaCha20-Poly1305) protects the bulk of the traffic.

What changed in TLS 1.3

TLS 1.3 streamlined the handshake to a single round trip (1-RTT), removed older and weaker cipher suites and key-exchange methods, and made forward secrecy mandatory. Forward secrecy means that even if the server's long-term private key is later compromised, past recorded sessions stay unreadable, because each session used a fresh, ephemeral key.

Certificates and the chain of trust

A TLS certificate binds a domain name to a public key and is signed by a Certificate Authority (CA). Your browser and operating system ship with a trusted root store — a list of CAs they trust by default. Trust flows down a chain: a root CA signs intermediate CAs, and an intermediate signs your server's leaf certificate. The client validates this chain back to a trusted root.

During validation the client checks that the certificate is signed by a trusted CA, that the current time falls within the validity dates, and that the requested hostname matches the certificate. Modern validation uses the Subject Alternative Name (SAN) field, not the old Common Name. You can inspect any certificate's fields with an SSL Certificate Decoder, and generate the signing request you submit to a CA with a CSR Command Generator.

Certificates are inexpensive or free today — automated CAs issue and renew them programmatically — so there's no longer a cost reason to leave a site on plain HTTP.

Where TLS is used

TLS is most associated with the web, where HTTPS is simply HTTP carried over a TLS connection. But the same protocol secures far more than browsers: email transport (SMTP, IMAP, POP3 with STARTTLS), database connections, message queues, API calls between services, and VPNs. Many newer protocols, including HTTP/2 and HTTP/3, effectively require TLS.

It's useful to compare TLS with SSH: both give you an encrypted, authenticated channel, but SSH is built around remote login and uses its own key model, while TLS is a general transport-security layer that leans on the CA trust system. They solve overlapping problems with different trust foundations.

Common pitfalls

TLS is easy to get subtly wrong. The mistakes that cause real outages and vulnerabilities tend to repeat:

• Expired certificates. The single most common TLS outage. Automate renewal and monitor expiry dates rather than relying on memory.
• Incomplete certificate chains. Forgetting to serve the intermediate certificate works in some browsers (which cache intermediates) but fails in others and in many command-line clients. Always send the full chain.
• Hostname mismatch. A certificate issued for example.com does not automatically cover www.example.com; the name must be present in the SAN list.
• Mixed content. An HTTPS page that loads scripts, images, or styles over HTTP undermines the security guarantee and is blocked by browsers. See the mixed content fix guide.
• Disabling certificate verification. Setting a client to skip validation (common as a quick fix in scripts) removes the authentication guarantee entirely and invites man-in-the-middle attacks. Fix the trust store instead.
• Outdated protocols and ciphers. Leaving SSL 3.0 or TLS 1.0/1.1 enabled keeps known-broken cryptography reachable. Restrict servers to TLS 1.2 and 1.3.

Once TLS is in place, you can tighten transport security further with HTTP headers such as HSTS and a Content Security Policy, which complement the encrypted channel rather than replace it.

The role of cryptographic primitives

TLS doesn't invent its own cryptography — it composes well-studied building blocks. Symmetric ciphers encrypt the data, key-exchange algorithms agree on keys, and hash functions underpin message authentication and the digital signatures on certificates. A cipher suite is essentially a named bundle of these choices, and TLS 1.3 deliberately shrank the menu to a small set of strong combinations so misconfiguration is harder.

Frequently Asked Questions