How HTTPS and TLS Really Work: The Handshake Explained

You type a URL, hit Enter, and a padlock appears. But what actually happens between your browser and the server to make that connection secure? Many developers treat HTTPS as a black box—until something breaks, like a certificate error or a performance issue. This article pulls back the curtain on TLS, the protocol behind HTTPS, and explains the handshake in plain terms.

What HTTPS Really Is

HTTPS is simply 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 real server, not an impostor.

Without TLS, HTTP sends everything in plaintext: passwords, cookies, and form data are visible to anyone on the network path.

The TLS Handshake in Plain English

The handshake is the negotiation that happens before any application data is sent. Its goal: agree on encryption algorithms, verify the server's identity, and establish shared secret keys. Here's the flow for TLS 1.3, the modern standard:

1. Client Hello – the browser sends a list of supported cipher suites, a random value, and its 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 verification – the browser checks the certificate against trusted root CAs, validates the domain name, and checks expiry.
4. Key derivation – both sides compute the same shared secret using the key exchange (typically ECDHE). Session keys are derived.
5. Finished – both sides send a MAC over the handshake transcript to confirm nothing was tampered with.

After that, encrypted application data flows. In TLS 1.3, the handshake takes one round trip (1-RTT), and resumption can achieve 0-RTT.

TLS 1.2 vs TLS 1.3

TLS 1.2 required two round trips and supported weaker algorithms. TLS 1.3 removed outdated ciphers, simplified the handshake, and encrypts more of the handshake itself. Always prefer TLS 1.3; most modern servers and browsers support it.

Certificates: The Trust Anchor

A certificate binds a public key to a domain name and is signed by a Certificate Authority (CA). Browsers ship with a store of trusted root CAs. During verification, the browser builds a chain from the server's certificate up to a trusted root.

Common certificate types:

• DV (Domain Validation) – proves control of the domain; quick and free (e.g., Let's Encrypt).
• OV (Organization Validation) – includes verified company details.
• EV (Extended Validation) – stricter identity checks; no longer shows a green bar in most browsers.

Certificates expire. Automate renewal with ACME clients like Certbot to avoid outages.

Key Exchange and Perfect Forward Secrecy

Modern TLS uses ephemeral key exchange (ECDHE). Each session generates a new key pair, so even if the server's private key is later compromised, past sessions can't be decrypted. This property is called forward secrecy. Avoid static RSA key exchange, which lacks this protection.

Common HTTPS Pitfalls and How to Avoid Them

• Mixed content – loading HTTP resources on an HTTPS page triggers browser warnings. Use relative URLs or update to HTTPS.
• Expired certificates – set up monitoring and auto-renewal.
• Weak cipher suites – disable TLS 1.0/1.1 and RC4/3DES. Use a tool like SSL Labs to test.
• Missing HSTS – add the Strict-Transport-Security header to force HTTPS.

Debugging TLS Issues

When a handshake fails, use openssl s_client to inspect the connection:

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

This shows the certificate chain, negotiated protocol, and cipher. For browser-specific errors, check the Security panel in DevTools.

FAQ

Is HTTPS the same as TLS?

HTTPS is HTTP over TLS. TLS is the cryptographic protocol; HTTPS is the secure version of the HTTP application protocol.

Do I need a separate certificate for each subdomain?

Not necessarily. A wildcard certificate covers all first-level subdomains, and a multi-domain (SAN) certificate can list several names.

How does TLS 1.3 improve performance?

TLS 1.3 reduces the handshake to one round trip (and zero on resumption), and simplifies cipher negotiation, lowering latency.

Ready to inspect your own site's security? Use our Nginx log analyzer to spot suspicious TLS errors and handshake failures in your logs.