Every time you see that padlock icon in your browser's address bar, an intricate cryptographic handshake has already occurred between your device and the web server — all in a fraction of a second. That padlock represents SSL/TLS encryption, the technology that makes secure online banking, private communications, and safe e-commerce possible. Without it, every password you type, every credit card number you enter, and every private message you send would be visible to anyone who can intercept your network traffic.

After spending over two decades in IT, I've watched the web transition from mostly unencrypted HTTP to the point where HTTPS is now the default for virtually every website. Understanding how this encryption works — even at a high level — helps you make better security decisions and recognize when your connection might not be as secure as you think.

SSL vs. TLS: Clearing Up the Terminology

You'll hear both "SSL" and "TLS" used interchangeably, but they're technically different protocols. SSL (Secure Sockets Layer) was the original protocol developed by Netscape in the mid-1990s. It went through versions 1.0, 2.0, and 3.0, each addressing vulnerabilities found in the previous version. In 1999, the Internet Engineering Task Force (IETF) took over and released TLS (Transport Layer Security) 1.0, which was essentially an incremental upgrade from SSL 3.0. TLS has since progressed through versions 1.1, 1.2, and the current 1.3.

Every version of SSL is now considered insecure and should never be used. TLS 1.0 and 1.1 have also been deprecated due to known vulnerabilities. Modern websites should use TLS 1.2 at minimum, with TLS 1.3 (released in 2018) being the recommended standard. Despite all this, people still commonly say "SSL" when they mean "TLS" — including terms like "SSL certificate," which is technically a TLS certificate. The terminology persists because SSL was around first and became the generic term for web encryption.

How the TLS Handshake Works

When you navigate to an HTTPS website, your browser and the web server perform a TLS handshake before any actual webpage content is transferred. This handshake accomplishes three things: it verifies the server's identity, it negotiates which encryption algorithms to use, and it establishes the encryption keys that will protect the session.

In TLS 1.3, the process is streamlined to a single round-trip. Your browser sends a "Client Hello" message that includes the TLS versions it supports, the cipher suites it can use, and a key share for the key exchange. The server responds with a "Server Hello" containing its chosen cipher suite and its own key share, along with its certificate. Both sides can now independently compute the same shared secret key using the exchanged key shares — this is the Diffie-Hellman key exchange, a mathematical process that allows two parties to create a shared secret over an insecure channel without ever transmitting the secret itself.

The server's certificate is crucial to the process. It's a digital document issued by a Certificate Authority (CA) that cryptographically proves the server is who it claims to be. Your browser verifies the certificate by checking that it was issued by a trusted CA (your operating system and browser maintain lists of trusted CAs), that it hasn't expired, that the domain name matches, and that it hasn't been revoked. If any of these checks fail, your browser shows a security warning.

Once the handshake completes, all traffic between your browser and the server is encrypted with the agreed-upon symmetric encryption key. Even if someone is capturing all the network traffic between you and the server — your ISP, a hacker on the same Wi-Fi network, or a government surveillance program — all they see is encrypted gibberish. They can tell you're connecting to a server and approximately how much data is being exchanged, but they can't read any of the content.

What HTTPS Protects (And What It Doesn't)

HTTPS encrypts the content of your communication with a website — the pages you view, the forms you submit, the data you upload and download, the cookies exchanged, and the headers. An eavesdropper cannot see your passwords, credit card numbers, personal messages, or any other data exchanged with the site.

However, HTTPS does not hide everything. The domain name you're connecting to is visible in several ways. The DNS query to resolve the domain is typically unencrypted (unless you use DNS over HTTPS or DNS over TLS). The Server Name Indication (SNI) field in the TLS handshake contains the domain in plain text, though Encrypted Client Hello (ECH) is beginning to address this. And the destination IP address is always visible, which can often be correlated back to the domain.

HTTPS also doesn't protect you from a malicious website itself. If you navigate to a phishing site that has a valid SSL certificate — and getting certificates is free and easy now thanks to services like Let's Encrypt — the padlock will still appear. The padlock means your connection to that server is encrypted, not that the server is trustworthy. This is an important distinction that many users misunderstand. Always verify you're on the correct domain, not just that there's a padlock.

Your IP address is always visible to the website you're connecting to, regardless of HTTPS. You can see exactly what websites see about your connection by visiting IP Lobster. If you want to hide your IP address in addition to encrypting your traffic, you need a VPN or Tor.

SSL/TLS Certificates Explained

Certificates are the trust mechanism of TLS. They're issued by Certificate Authorities — organizations that the browser and operating system vendors have vetted and included in their trusted root certificate stores. When a CA issues a certificate for a domain, they're asserting that the certificate requester has demonstrated control over that domain.

There are three levels of certificate validation. Domain Validation (DV) is the most basic — the CA verifies that the requester controls the domain, typically through a DNS record or file placed on the web server. This is what Let's Encrypt provides for free, and it's sufficient for most websites. Organization Validation (OV) additionally verifies the legal existence of the organization requesting the certificate. Extended Validation (EV) involves the most thorough vetting, including legal identity verification and physical address confirmation. EV certificates used to display the organization name in green in the browser's address bar, but most browsers have moved away from this visual distinction.

Certificates have an expiration date, typically 90 days for Let's Encrypt certificates or up to 397 days for commercially purchased ones. When a certificate expires, browsers display a security warning and may block access to the site. Automated certificate renewal (a feature of tools like Certbot for Let's Encrypt) prevents these lapses. If you encounter an expired certificate warning on a well-known website, it usually means their IT team missed a renewal — proceed with caution.

How to Check a Website's Certificate

You can inspect any website's TLS certificate directly in your browser. Click the padlock icon in the address bar, then look for "Certificate" or "Connection is secure" and click through to view the certificate details. You'll see the domain name the certificate was issued for, the Certificate Authority that issued it, the expiration date, and the encryption algorithms being used.

Pay attention to the certificate's issuer. Legitimate websites from major companies will typically have certificates from well-known CAs like DigiCert, Sectigo, or Let's Encrypt. If you see a certificate from an unfamiliar CA, or if the certificate domain doesn't match the website you intended to visit, treat it as a red flag. You can verify a domain's registration details using IP Lobster's WHOIS Lookup to cross-reference ownership information.

Browser developer tools also provide detailed TLS information. In Chrome, open DevTools (F12), go to the Security tab, and you'll see the TLS version, cipher suite, and certificate chain for the current page. This is useful for debugging TLS issues or verifying that a site is using modern encryption standards.

Common TLS Issues and Warnings

"Your connection is not private" is the most common TLS warning. It typically means the certificate has expired, the certificate doesn't match the domain, the certificate was issued by an untrusted CA, or the certificate has been revoked. On trusted sites you regularly visit, this could indicate a certificate renewal issue — check back later. On unfamiliar sites, don't proceed past this warning.

Mixed content warnings occur when an HTTPS page loads some resources (images, scripts, stylesheets) over unencrypted HTTP. Modern browsers block mixed active content (scripts and iframes) by default and may show a warning or broken padlock for mixed passive content (images). This is a website configuration issue, not something the visitor can fix.

TLS version warnings appear when a site only supports outdated TLS versions. If a site only supports TLS 1.0 or 1.1, modern browsers will block the connection or show a warning. This is increasingly rare but still occurs on legacy systems. If you encounter this on a site you trust, contact the site administrator — they need to update their TLS configuration.

HTTPS has become so standard that the absence of it is now the warning sign. Modern browsers display "Not Secure" in the address bar for HTTP sites, and some mark them with a red indicator. If a site asks for any personal information — even just an email address — and doesn't use HTTPS, that's a reason to be cautious. The cost and complexity of implementing HTTPS are now essentially zero thanks to Let's Encrypt, so there's little excuse for any website not to use it.