What is SSL/TLS? The protocol behind the padlock

SSL is the old name; TLS is what actually runs

SSL (Secure Sockets Layer) was the original protocol, but it was retired years ago after serious security weaknesses were found in it. TLS (Transport Layer Security) is its successor and the protocol actually in use today — and it keeps getting updated to newer, more secure versions. In practice, almost everyone still says “SSL” or “SSL certificate” out of habit, even though the connection itself is running TLS. When you see “SSL/TLS” written together, that’s exactly why: the familiar name and the technically correct one, used interchangeably.

What SSL/TLS actually protects

SSL/TLS delivers three distinct protections at once, and it’s worth separating them because each guards against a different failure.

• Confidentiality — the contents of the traffic are encrypted, so anyone intercepting it sees unreadable data rather than your actual request or response.
• Integrity — the data is protected against tampering in transit; if someone tried to alter it along the way, the change would be detectable.
• Server identity — a certificate proves the server you’re connecting to is who it claims to be, guarding against imposters standing in between you and the real destination.

Certificates and the handshake, briefly

A TLS certificate is issued by a trusted certificate authority and effectively vouches for a server’s identity — it’s the piece your browser checks before showing the padlock. When you connect to a server over HTTPS, the two sides run a brief negotiation called the TLS handshake: they agree on encryption methods, the server presents its certificate for your browser to verify, and they establish a shared secret used to encrypt everything that follows. All of this happens in a fraction of a second before a page even starts loading, which is why encrypted browsing feels no slower than an unencrypted connection to most people.

SSL/TLS in the cloud

Cloud platforms build TLS into the infrastructure you already use. Load balancers commonly handle TLS termination — decrypting incoming HTTPS traffic at the load balancer itself so the backend servers behind it don’t each need to manage certificates individually. Managed certificate services can issue and automatically renew certificates for you, and a content delivery network typically serves cached content over HTTPS at edge locations close to the visitor, keeping the encrypted connection fast worldwide. “HTTPS everywhere” — encrypting every connection, not just login pages — is now the standard baseline for any cloud-hosted application.

Why this matters beyond the padlock icon

SSL/TLS is one half of the “encrypt in transit” half of a well-known pairing: data should be protected both while it’s stored (at rest) and while it’s moving (in transit), and TLS is the workhorse for the second. It’s also foundational to a great deal else on the web — DNS lookups, API calls between services, and the trust signals browsers show visitors all lean on it. Anywhere data crosses a network you don’t fully control, TLS is the default answer for keeping it private and unaltered.