SSL vs TLS

Sam Erickson
Updated 21 hours ago
0

Key Takeaways

SSL is obsolete. TLS is its standardized successor and the protocol you should use.
Prefer TLS 1.3; retain securely configured TLS 1.2 where compatibility requires it. Disable SSL 2.0/3.0 and TLS 1.0/1.1.
TLS protects confidentiality, integrity, and peer identity. Ordinary HTTPS authenticates the server; client-certificate authentication is optional.
HTTPS protects HTTP traffic between TLS endpoints—not data after delivery or the trustworthiness of a website.

The difference between SSL and TLS is straightforward: SSL (Secure Sockets Layer) is the obsolete predecessor of TLS (Transport Layer Security). Modern HTTPS uses TLS to protect communications between a client, such as your browser, and a server. “SSL certificate” survives as terminology, not as a reason to enable SSL.

What is the difference between SSL and TLS?

TLS is an IETF-standardized successor based on SSL 3.0. The original TLS 1.0 specification explicitly says the differences prevent direct interoperability with SSL 3.0. Calling TLS 1.0 “SSL 3.1” obscures that distinction; it isn't a protocol version you should configure.

The practical question isn't which name sounds more secure. It's which protocol versions your server accepts:

Protocol versions	Deployment guidance
SSL 2.0 and SSL 3.0	Do not enable SSL 2.0 or SSL 3.0; both are obsolete.
TLS 1.0 and TLS 1.1	TLS 1.0 and TLS 1.1 are formally deprecated and must not be negotiated.
TLS 1.2	TLS 1.2 remains a compatibility option when securely configured.
TLS 1.3	Prefer TLS 1.3 when both endpoints support it.

These choices follow IETF deployment guidance and the formal deprecation of TLS 1.0 and TLS 1.1. TLS 1.2 isn't automatically insecure, but its configuration matters.

For new protocol specifications, the IETF's July 2026 update requires TLS 1.3 as the default. It allows TLS 1.2 as an additional, non-default option when deployment considerations justify it. That's guidance for designing protocols, not a declaration that every existing TLS 1.2 website must immediately stop working.

“SSL certificate” commonly means an X.509 server certificate used with TLS. The certificate doesn't select the protocol version; the client and server negotiate that during connection setup. For background on the older terminology, see what SSL is.

Why TLS matters: authentication, encryption, and integrity

Authentication: are you talking to the right server?

When you visit Google or another HTTPS site, your browser needs to authenticate the server for the hostname you requested. Receiving a certificate isn't enough: the browser must validate it, and the server must prove possession of the corresponding private key.

Certificate validation includes these checks:

Trusted chain: the certificate has a valid certification path to a trust anchor accepted by the client.
Hostname: the requested hostname matches an appropriate identity in the certificate's subject alternative name extension.
Validity period: the certificates being validated are valid at the time of the check.
Signatures and constraints: certificate signatures verify, and applicable certificate restrictions are satisfied.

These checks help prevent an attacker between you and the server from impersonating the intended endpoint. Disabling certificate verification removes that identity check, even if the connection remains encrypted.

Ordinary HTTPS authenticates the server. Mutual TLS, or mTLS, additionally authenticates the client using a client certificate and proof of its private key; it isn't required for a normal browser visit.

Encryption: what a packet sniffer can read

Imagine submitting a password over plain HTTP while an attacker captures traffic along the network path. Without another encryption layer, the captured request can expose its headers and body—including that password. With correctly configured HTTPS, those HTTP contents are encrypted in transit.

A packet sniffer can still capture encrypted packets. TLS makes their application contents unreadable to a passive observer who doesn't have the necessary secrets; it doesn't make the packets disappear.

Integrity: detecting tampering

Encryption alone isn't the whole security story. Integrity protection lets the receiver detect unauthorized changes instead of accepting altered traffic. TLS 1.3 uses authenticated encryption with associated data, or AEAD, which combines encryption and integrity protection for its records.

How a modern TLS 1.3 handshake works

A handshake establishes the connection's cryptographic parameters and keys. In a typical full, certificate-authenticated TLS 1.3 handshake:

Offer capabilities. The client sends supported versions, cryptographic options, and an ephemeral key share—a public contribution to a temporary key agreement.
Agree on parameters. The server selects compatible options and sends its own key share. Both sides derive shared secrets locally; those secrets aren't transmitted.
Authenticate the server. The server presents its certificate chain and signs the handshake. The client validates the certificate and verifies the signature.
Confirm the handshake. Finished messages authenticate the handshake transcript—the messages exchanged during setup. The endpoints derive traffic keys for protected application data.

The certificate supports authentication; it doesn't encrypt every HTTP request. Symmetric traffic keys protect application data. The client doesn't create a traffic key and send it encrypted with the certificate's public key in this TLS 1.3 handshake.

Resumed connections can use previously established shared-key material, so not every connection repeats the complete certificate exchange. See how TLS works for a deeper walkthrough.

How HTTPS uses TLS over TCP and QUIC

HTTPS is HTTP secured using TLS in ordinary web deployments. For HTTPS using HTTP/1.1 or HTTP/2, TLS runs over TCP. HTTP/3 instead uses QUIC, a UDP-based transport that integrates the TLS 1.3 handshake; QUIC uses the resulting keys for packet protection rather than carrying ordinary TLS records over TCP.

HTTP/1.1 or HTTP/2 over HTTPS:
HTTP -> TLS -> TCP

HTTP/3 over HTTPS:
HTTP -> QUIC (TLS 1.3 handshake integrated) -> UDP

The HTTP application semantics remain recognizable: requests, responses, methods, and status codes. The secure transport underneath differs.

What HTTPS does not protect

A malicious website can have a valid certificate and serve its content over HTTPS. An encrypted connection is not an endorsement of the site's business, downloads, or claims. Chrome's explanation of its connection-security indicator makes this distinction explicit.

TLS protects data between its endpoints. It doesn't encrypt database records, prevent an application from logging passwords, or stop a compromised endpoint from reading data after decryption. Those require separate controls.

Production Checklist

Prefer TLS 1.3 and keep TLS 1.2 only for a documented compatibility need.
Disable SSL and deprecated TLS versions; don't restore them to work around a failing client.
Keep certificate and hostname verification enabled in browsers, HTTP clients, and upstream connections.
Automate certificate renewal, monitor expiration, and protect private keys.
Serve every page and subresource over HTTPS, and deploy HTTP Strict Transport Security (HSTS) after checking its scope.
Test the deployed endpoint, not just the application's configuration file.

TLS is one layer of application security. For application-level controls, continue with Express.js security best practices.

FAQ

Is SSL still used, or has it been replaced by TLS?

TLS has replaced SSL for modern secure communications. SSL 2.0 and SSL 3.0 must not be enabled; products that advertise “SSL certificates” generally mean certificates used with TLS.

Which TLS versions should I enable?

Prefer TLS 1.3 and retain securely configured TLS 1.2 where client compatibility requires it. Disable TLS 1.0 and TLS 1.1, which are formally deprecated.

How does a TLS handshake authenticate a website?

In a full certificate-authenticated TLS 1.3 handshake, the client validates the server's certificate chain, hostname, validity period, and signatures. It also verifies a handshake signature proving possession of the certificate's corresponding private key.

Does a TLS certificate encrypt data?

A server certificate supports authentication rather than encrypting all application data. The handshake establishes symmetric traffic keys, which protect the HTTP traffic.

Does HTTP/3 use TLS over TCP?

No. HTTP/3 uses QUIC over UDP, with the TLS 1.3 handshake integrated into QUIC rather than TLS layered over TCP.