How HTTPS Works: SSL/TLS Explained Simply for Developers

The Padlock Icon You See Every Day

You have seen the padlock icon in your browser's address bar thousands of times. Most people know it means "secure" — but secure against what? What exactly happens when you connect to https:// versus http://? Why does it matter if you are just browsing a restaurant's menu?

Understanding HTTPS is not just academic. It directly affects decisions about where to handle sensitive data, why non-HTTPS form submissions are dangerous, what certificates actually prove about a website's identity, and what HTTPS does not protect against — which is just as important as what it does.

---

The Problem HTTPS Solves

HTTP (HyperText Transfer Protocol) sends data as plain text between your browser and the server. Every piece of information travels through multiple network nodes — your router, your ISP's infrastructure, potentially other intermediate servers — before reaching its destination.

Without encryption, anyone who can intercept traffic on any of those nodes can:

• Read everything you send and receive — login credentials, form submissions, page content.
• Modify data in transit — changing what a page displays, injecting malicious content, altering what you submit.
• Impersonate the server — serving a fake version of the website while appearing legitimate.

These are not theoretical attacks. Public Wi-Fi networks (coffee shops, airports, hotels) are common interception points. ISPs can and do read and modify HTTP traffic. Governments in various countries have intercepted HTTP traffic at scale.

HTTPS solves all three threats simultaneously:

1. Confidentiality — data is encrypted and unreadable in transit
2. Integrity — tampering with encrypted data in transit is detectable
3. Authentication — certificates verify you are actually talking to the real server

---

SSL vs. TLS: What Is the Difference?

These terms are often used interchangeably, which causes confusion.

SSL (Secure Sockets Layer) was the original protocol, developed by Netscape in the 1990s. SSL 1.0 was never released. SSL 2.0 (1995) and SSL 3.0 (1996) had serious vulnerabilities and are completely deprecated.

TLS (Transport Layer Security) is the modern, secure successor to SSL. TLS 1.0 (1999) and TLS 1.1 (2006) are deprecated. TLS 1.2 (2008) is still widely used. TLS 1.3 (2018) is the current standard, faster and more secure than its predecessors.

When someone says "SSL certificate" or "SSL encryption," they almost certainly mean TLS — the older SSL protocols have been dead for over a decade. The term "SSL" persists because it entered popular vocabulary before TLS existed, and the industry never managed to replace the terminology.

What you actually need to know: Modern HTTPS uses TLS 1.2 or TLS 1.3. If a server still supports TLS 1.0 or 1.1, that is a security misconfiguration.

---

How the TLS Handshake Works

Before any encrypted data flows, the browser and server perform a TLS handshake — a negotiation that establishes encryption parameters and verifies identity. Here is what happens, step by step:

Step 1: ClientHello

The browser sends a message to the server listing:

• The TLS version it supports (e.g., TLS 1.3)
• A list of cipher suites it can use (encryption algorithm combinations)
• A randomly generated number (the "client random")
• Supported extensions (Server Name Indication, etc.)

Step 2: ServerHello

The server responds with:

• The TLS version and cipher suite selected (from the client's list)
• A randomly generated number (the "server random")
• The server's digital certificate

Step 3: Certificate Verification

The browser examines the server's certificate:

• Is it signed by a trusted Certificate Authority (CA)?
• Is the domain name in the certificate the one the browser requested?
• Is the certificate's validity period current (not expired)?
• Has the certificate been revoked?

If any check fails, the browser displays a security warning and (by default) blocks the connection. This is the "certificate error" you see when a site's HTTPS is misconfigured.

Step 4: Key Exchange

This is the cryptographic heart of the handshake. The browser and server need to establish a shared secret key for encryption — without that key being readable by anyone intercepting the traffic.

TLS 1.3 uses Ephemeral Diffie-Hellman (ECDHE) key exchange. Both sides independently generate a key pair, exchange public keys, and mathematically compute the same shared secret without ever transmitting that secret directly. An observer watching the network traffic sees the public keys but cannot derive the shared secret from them.

The shared secret, combined with the client random and server random, generates the session keys used for all subsequent encryption.

Step 5: Finished

Both sides send a "Finished" message encrypted with the new session keys, confirming the handshake succeeded and encryption is working.

All of this takes a single network round-trip in TLS 1.3 (down from two in TLS 1.2), adding approximately 20–50ms to the connection — a tiny and acceptable overhead.

---

Digital Certificates: What They Actually Prove

A digital certificate is a file that contains:

• The website's public key
• The domain name(s) the certificate covers
• The certificate's validity period (issue date and expiry date)
• The issuing Certificate Authority (CA)
• A digital signature from the CA

The CA's signature is what makes the certificate trustworthy. When the browser receives the certificate, it verifies that signature against the CA's public key — which is pre-installed in the browser and operating system's trusted root store.

Certificate Validation Levels

Domain Validation (DV): The CA verifies only that the applicant controls the domain. This is automated and takes minutes. The padlock appears. Nothing about the organization's identity is verified.

Organization Validation (OV): The CA verifies domain control plus that the requesting organization is a legally registered entity. The organization name appears in the certificate details.

Extended Validation (EV): The most rigorous verification — identity documents, legal existence, physical address, authorization checks. Historically showed the organization name in the browser's address bar (the "green bar"). Most browsers removed this visual distinction, making EV certificates visually identical to DV from the user's perspective. Their value has become debated.

For most websites, DV certificates are appropriate and sufficient. EV certificates are used by banks, financial institutions, and enterprises that want maximum assurance in the certificate details.

Certificate Authorities

The trust model depends on browser and OS makers (Apple, Microsoft, Google, Mozilla) maintaining lists of trusted CAs. If a CA is found to have been compromised or issued fraudulent certificates, it can be removed from the trusted root store — instantly making all certificates from that CA untrustworthy.

Let's Encrypt, launched in 2016, is a free, automated CA that made HTTPS accessible to everyone. Before Let's Encrypt, certificates cost $50–$300/year. Today, HTTPS has no cost barrier.

---

What Happens During an HTTPS Connection: Your Data's Journey

With TLS established, here is what the browser-server communication looks like:

1. Your request (the URL path, headers, request body) is encrypted with the session key.
2. Encrypted bytes travel across the network. Anyone intercepting sees gibberish.
3. The server decrypts your request using the session key.
4. The server processes the request and sends an encrypted response.
5. Your browser decrypts the response and displays the content.

The session key is unique to your connection and is discarded when the session ends. Even if someone recorded your encrypted traffic today, obtaining the session key later would not help — because of Perfect Forward Secrecy (provided by ephemeral key exchange), each session uses a freshly generated key that is never stored.

---

What HTTPS Does NOT Protect Against

This is equally important. HTTPS is narrowly defined and has clear limitations.

HTTPS does not verify content quality or legitimacy. A phishing site with a valid certificate shows a padlock. The padlock means the connection to that fraudulent server is encrypted — not that the server is legitimate or trustworthy. Many users incorrectly interpret the padlock as a seal of legitimacy.

HTTPS does not protect against malware on your device. If your device is infected, malware can read your data before it is encrypted for transmission.

HTTPS does not protect against tracking. DNS queries (which reveal what domains you are visiting) are separate from TLS and visible to your ISP unless you use DNS over HTTPS (DoH) or a VPN. The IP addresses you connect to are also visible, even if the content is not.

HTTPS does not protect against server-side breaches. Once data is decrypted on the server, a breach of the server exposes that data regardless of how it was transmitted.

HTTPS does not protect against weak passwords or account takeovers. Your authentication credentials are transmitted securely — but if your password is weak, an attacker can still log in.

---

Mixed Content: When HTTPS Breaks

A common mistake in migrating sites to HTTPS is mixed content — an HTTPS page that loads some resources (images, scripts, stylesheets) over HTTP. Browsers treat this as a security issue because:

• An HTTP script on an HTTPS page can read data from the page and send it over unencrypted HTTP.
• HTTP images can be replaced in transit, displaying tampered content within an otherwise secure page.

Modern browsers block mixed content scripts and stylesheets by default, often causing broken pages during HTTPS migrations. Audit all resource URLs when migrating to HTTPS — all subresources must also be loaded over HTTPS.

---

HTTP Strict Transport Security (HSTS)

Even with HTTPS configured, a user who types example.com (without https://) will initially make an HTTP request. If an attacker can intercept that first request before the redirect to HTTPS happens, they can perform a downgrade attack.

HSTS solves this. When a server sends the Strict-Transport-Security header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The browser remembers to always connect via HTTPS for that domain for the specified duration (in seconds) — even for the first request, from then on. The preload directive allows the domain to be included in browser HSTS preload lists, which are built into browsers and cover the very first visit.

---

Summary

• HTTP sends data as plain text. Anyone intercepting traffic can read, modify, and impersonate.
• HTTPS = HTTP over TLS. Provides confidentiality (encryption), integrity (tamper detection), and authentication (certificate verification).
• SSL is deprecated; TLS 1.2 and 1.3 are the current standards.
• The TLS handshake establishes a shared session key through public-key cryptography without transmitting the key directly.
• Certificates prove domain control (DV), organization identity (OV), or extended identity (EV). Let's Encrypt provides free DV certificates.
• HTTPS does not verify site legitimacy, protect against device malware, prevent tracking, or guarantee server-side security.
• Fix mixed content during HTTPS migration. Enable HSTS to prevent downgrade attacks.
• Use HTTPS on every site, every page, always — there is no longer any cost or significant technical barrier.

---

Content Tracking Log