How HTTPS & TLS Really Work: A Practical Guide

You've probably seen the padlock icon in your browser and assumed it means a site is secure. But what actually happens when you visit an HTTPS URL? Why do some certificates trigger warnings? And how can you tell if a connection is really encrypted end-to-end? This guide breaks down HTTPS and TLS in practical terms, showing you the handshake steps, how certificates are validated, and how to inspect real connections using command-line tools. By the end, you'll understand the mechanics well enough to debug TLS issues and make informed decisions about your own web security.

What HTTPS Actually Is

HTTPS is HTTP layered on top of TLS (Transport Layer Security). TLS provides three guarantees:

• Confidentiality: Data is encrypted so eavesdroppers can't read it.
• Integrity: Data can't be modified in transit without detection.
• Authentication: You're talking to the server that owns the domain, not an impostor.

Without TLS, HTTP sends everything in plain text—passwords, cookies, and content—over the network. TLS wraps that traffic in an encrypted tunnel. The padlock means the connection is encrypted and the certificate is valid, but it does not mean the site is trustworthy or secure in other ways (e.g., it could still have vulnerabilities).

The TLS Handshake in Plain English

Before any HTTP data is exchanged, the client and server perform a TLS handshake. The exact steps vary slightly between TLS 1.2 and 1.3, but the core idea is the same: agree on algorithms, authenticate the server, and establish shared keys. Here's a simplified flow for TLS 1.3 (the modern default):

1. Client Hello: The client sends a list of supported cipher suites, a random value, and key share (for key exchange).
2. Server Hello: The server picks a cipher suite, sends its own random value and key share, and provides its certificate chain.
3. Certificate validation: The client checks the certificate's validity, domain name, and trust chain.
4. Key derivation: Both sides compute the same shared secret using Diffie-Hellman (often X25519). From that, they derive symmetric session keys.
5. Finished: Both sides send a MAC over the handshake transcript to confirm nothing was tampered with.

After the handshake, application data (HTTP requests/responses) is encrypted with the session keys. TLS 1.3 reduces the handshake to one round trip (1-RTT) and supports 0-RTT resumption, making it faster than TLS 1.2.

Certificate Validation: How Your Browser Decides to Trust a Site

When the server sends its certificate, the client must verify it. The browser (or your HTTP client) performs several checks:

• Trust chain: The certificate must be signed by a trusted Certificate Authority (CA) or an intermediate CA that chains up to a root CA in the client's trust store.
• Domain name: The certificate's Subject Alternative Name (SAN) must include the hostname you're connecting to.
• Validity period: The certificate must not be expired or not yet valid.
• Revocation: The client may check OCSP or CRL to see if the certificate was revoked (though this is often best-effort).

If any check fails, the browser shows a warning. For example, a self-signed certificate triggers "Your connection is not private" because it isn't signed by a trusted CA.

Inspecting a Real TLS Connection

You can see the handshake details yourself using OpenSSL. Run this command in your terminal (replace the hostname):

openssl s_client -connect example.com:443 -servername example.com -showcerts

The output includes the certificate chain, negotiated cipher, and TLS version. Look for lines like:

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit

This tells you the connection uses TLS 1.3 with AES-256-GCM. You can also use curl -v https://example.com to see the TLS handshake summary.

Common TLS Misconfigurations and How to Spot Them

Even with HTTPS enabled, misconfigurations can weaken security. Here are frequent issues:

Fixing these usually involves updating server configuration (e.g., in Nginx: ssl_protocols TLSv1.2 TLSv1.3;) and ensuring your certificate chain is complete.

HTTPS in Practice: What Developers Should Do

• Use TLS 1.2 or 1.3 only; disable older versions.
• Obtain certificates from a trusted CA (Let's Encrypt is free and automated).
• Enable HSTS to force HTTPS.
• Regularly renew certificates and monitor expiry.
• Test your configuration with tools like SSL Labs (qualys.com/ssllabs) or testssl.sh.

If you're debugging server logs, the Nginx Log Analyzer can help you spot TLS handshake failures and certificate errors in your access logs.

FAQ

What's the difference between TLS and SSL?

SSL is the predecessor to TLS. SSL 2.0 and 3.0 are deprecated and insecure; modern systems use TLS 1.2 or 1.3. People often say "SSL" colloquially, but they mean TLS.

Does HTTPS make a website completely secure?

No. HTTPS encrypts traffic and authenticates the server, but it doesn't protect against vulnerabilities like SQL injection, XSS, or misconfigured permissions. It's one layer of security.

How can I check if a site supports TLS 1.3?

Use openssl s_client -connect host:443 -tls1_3. If the handshake succeeds, TLS 1.3 is supported. Alternatively, check the protocol in your browser's developer tools under the Security tab.

Understanding the TLS handshake and certificate validation helps you build and maintain secure web services. When you need to analyze server logs for TLS errors or performance issues, try the Nginx Log Analyzer to quickly parse and filter log entries.