How HTTPS and TLS Really Work: A Practical Guide

You type a URL, hit Enter, and the page loads. The padlock icon tells you the connection is secure, but what actually happens between your browser and the server? If you're a developer, understanding HTTPS and TLS isn't just academic—it affects how you configure servers, debug connection errors, and protect user data.

This guide breaks down the TLS handshake, encryption layers, and certificate validation in plain terms. You'll see how HTTPS really works and pick up practical tips for your own projects.

What HTTPS and TLS Actually Are

HTTPS is HTTP over TLS. TLS (Transport Layer Security) is the cryptographic protocol that encrypts data in transit. When you visit an HTTPS URL, your browser and the server perform a TLS handshake to agree on encryption keys before any HTTP data is exchanged.

TLS replaced SSL (Secure Sockets Layer) years ago, but the terms are often used interchangeably. Modern browsers support TLS 1.2 and TLS 1.3; older versions are deprecated due to known vulnerabilities.

The TLS Handshake: Step by Step

The handshake establishes a secure channel. Here's what happens in a typical TLS 1.2 handshake (TLS 1.3 simplifies this further):

1. Client Hello: The browser sends a list of supported cipher suites, TLS versions, and a random value (client random).
2. Server Hello: The server picks a cipher suite, sends its own random value (server random), and presents its SSL/TLS certificate.
3. Certificate Verification: The browser checks the certificate against trusted root CAs, verifies the domain name, and checks expiration.
4. Key Exchange: Using the certificate's public key, the client encrypts a pre-master secret and sends it to the server. Both sides derive the same session keys.
5. Finished: Both parties send a Finished message encrypted with the new session keys, confirming the handshake succeeded.

In TLS 1.3, the handshake is reduced to one round trip (1-RTT) and supports 0-RTT resumption for repeat connections, improving latency.

Encryption: Symmetric and Asymmetric

TLS uses both types of encryption:

• Asymmetric encryption (e.g., RSA, ECDHE) is used during the handshake to securely exchange keys. It's slow but solves the key distribution problem.
• Symmetric encryption (e.g., AES-GCM, ChaCha20-Poly1305) is used for bulk data transfer after the handshake. It's fast and efficient.

The session keys derived during the handshake are symmetric keys. They ensure that even if someone captures the encrypted traffic, they can't decrypt it without the keys.

Certificate Validation: Trust but Verify

Certificates are issued by Certificate Authorities (CAs). Browsers and operating systems ship with a list of trusted root CAs. When a server presents a certificate, the browser verifies:

• The certificate is signed by a trusted CA (directly or via an intermediate CA).
• The certificate's domain name matches the requested host.
• The certificate is within its validity period.
• The certificate hasn't been revoked (via CRL or OCSP).

If any check fails, the browser shows a warning. As a developer, you can use tools like openssl s_client to inspect certificates and debug chain issues.

Common TLS Misconfigurations and How to Fix Them

Use online SSL checkers or command-line tools to audit your configuration regularly.

Practical Tips for Developers

• Enable HSTS: Add the Strict-Transport-Security header to force browsers to use HTTPS for future visits.
• Use TLS 1.3: It's faster and more secure. Most modern servers support it; configure your server to prefer it.
• Automate certificate management: Tools like Certbot can obtain and renew certificates automatically.
• Test with openssl: Run openssl s_client -connect example.com:443 -servername example.com to inspect the handshake and certificate chain.

Here's a quick Nginx configuration snippet to enable modern TLS settings:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers off;

    add_header Strict-Transport-Security "max-age=63072000" always;
}

This configuration enables TLS 1.2 and 1.3, uses strong ciphers, and sets HSTS.

FAQ

What is the difference between HTTPS and TLS?

HTTPS is HTTP layered on top of TLS. TLS is the protocol that provides encryption and authentication. So HTTPS is the secure version of HTTP, powered by TLS.

How does the TLS handshake establish a shared key?

The client and server use asymmetric cryptography (like ECDHE) to agree on a shared secret without transmitting it directly. They then derive symmetric session keys from that secret for encrypting data.

Why do certificates expire?

Expiration limits the damage if a private key is compromised and encourages automation of renewal. Short-lived certificates are a security best practice.

Ready to inspect your own TLS setup? Use TryQuickToolBox's Nginx Log Analyzer to spot TLS errors and handshake failures in your server logs.