How Does HTTPS Work? TLS, Certificates, and Security Headers Explained

Every browser shows a padlock icon when you are on an HTTPS page. Most people treat that padlock as a binary signal: locked means safe, no padlock means danger. In practice it is considerably more nuanced.

The padlock tells you that the connection between your browser and the server is encrypted — that someone intercepting your traffic on the network cannot read the content. It says nothing about the security configuration of the server itself, whether sensitive headers are set correctly, or whether the site has misconfigured its HTTPS in ways that leave it vulnerable to specific attacks.

The actual security of an HTTPS connection is readable in the response headers — the metadata the server sends back with every page. Those headers are visible right now for any site using myipco.com/my-headers.

This guide explains how HTTPS works at the TLS level, what the security headers mean, and how to tell from the headers alone whether a site's HTTPS is properly configured — or just wearing the padlock without the substance.

HTTP (HyperText Transfer Protocol) is the protocol your browser uses to request and receive web pages. HTTPS is HTTP with an encryption layer — TLS (Transport Layer Security) — wrapped around it.

Without encryption (HTTP): - Your browser sends a request in plain text - The server responds in plain text - Anyone between you and the server (your ISP, someone on the same Wi-Fi, a router in the path) can read both

With encryption (HTTPS): - Your browser and the server first negotiate an encrypted channel (the TLS handshake) - All subsequent communication — the request, the response, the cookies, the form data — travels through that encrypted channel - An observer sees only that you connected to a particular server; not what you requested or received

The shift to HTTPS as default has been one of the most significant security improvements in the web's history. In 2015, roughly 40% of web traffic was encrypted. By 2026, it exceeds 95% for most browsers. HTTP-only sites are now flagged with "Not Secure" warnings in all major browsers.

Before any HTTPS data is exchanged, the browser and server perform a TLS handshake — a negotiation that establishes the encrypted channel. Here is what happens:

Step 1: Client Hello Your browser sends a message to the server listing the TLS versions and cipher suites it supports, along with a random number. Modern browsers support TLS 1.2 and TLS 1.3; TLS 1.3 is faster and more secure.

Step 2: Server Hello The server responds by selecting the TLS version and cipher suite to use, sending its own random number, and presenting its TLS certificate.

Step 3: Certificate verification Your browser examines the server's certificate: - Is it signed by a Certificate Authority (CA) your browser trusts? - Does the domain on the certificate match the site you are connecting to? - Is the certificate still valid (not expired, not revoked)?

Certificate Authorities — organisations like DigiCert, Let's Encrypt, and Sectigo — are trusted by browsers because they verify domain ownership before issuing certificates. Let's Encrypt, a nonprofit, issues free certificates automatically and is responsible for the near-universal HTTPS adoption in recent years.

Step 4: Key exchange Browser and server use asymmetric cryptography (typically ECDHE — Elliptic Curve Diffie-Hellman Ephemeral) to negotiate a shared symmetric encryption key. The asymmetric step is used only to establish the shared key; all subsequent communication uses the faster symmetric key.

The "Ephemeral" part matters: each session generates a new key. Even if an attacker records your encrypted traffic now and later obtains the server's private key, they cannot decrypt past sessions. This property is called Perfect Forward Secrecy.

Step 5: Encrypted communication begins With the session key established, all HTTP traffic is encrypted symmetrically. From the outside, your connection looks like a stream of encrypted bytes to a specific IP address and port (443 for HTTPS).

TLS 1.3 (the current version) streamlines this to a 1-RTT handshake (one round trip) compared to TLS 1.2's 2-RTT. For connections to previously visited servers, TLS 1.3 supports 0-RTT resumption — the session can resume without a new handshake, at a small security trade-off for replay attacks.

The TLS layer is invisible — you experience it as the padlock. But the security *configuration* of an HTTPS site is visible in the response headers it sends. You can inspect these for any site using myipco.com/my-headers.

Here is what a well-configured HTTPS site's response headers look like:

``` strict-transport-security: max-age=31536000; includeSubDomains; preload content-security-policy: default-src 'self'; script-src 'self' 'nonce-abc123' x-content-type-options: nosniff x-frame-options: DENY permissions-policy: geolocation=(), camera=(), microphone=() referrer-policy: strict-origin-when-cross-origin ```

And here is what a site with minimal HTTPS configuration looks like — just the padlock, nothing more:

``` content-type: text/html; charset=UTF-8 server: Apache/2.4.51 ```

Both sites show a padlock. The first is meaningfully more secure. The difference is entirely in the response headers.

Strict-Transport-Security (HSTS) `strict-transport-security: max-age=31536000; includeSubDomains; preload`

HSTS tells your browser: "For the next 31,536,000 seconds (one year), only connect to this domain over HTTPS — never HTTP." Once your browser receives this header, it will automatically upgrade any HTTP request to HTTPS before it leaves your device, preventing SSL stripping attacks.

`includeSubDomains` extends this to all subdomains. `preload` means the domain is included in the browser's built-in HSTS preload list — protection applies even on the very first visit, before the header has been received.

Without HSTS: an attacker performing a man-in-the-middle attack can intercept your initial HTTP request (before the redirect to HTTPS) and serve a fake HTTP version of the site. With HSTS: that window doesn't exist.

Content-Security-Policy (CSP) `content-security-policy: default-src 'self'; script-src 'self' 'nonce-abc123'`

CSP defines which resources the page is allowed to load: scripts, styles, images, fonts, connections. A strict CSP prevents cross-site scripting (XSS) attacks — if an attacker injects a `<script>` tag pointing to a malicious domain, the browser refuses to execute it because the domain isn't in the allowlist.

CSP is one of the most powerful security headers and one of the hardest to configure correctly. A loose CSP (`default-src *` or `unsafe-inline` for scripts) provides little protection.

X-Content-Type-Options `x-content-type-options: nosniff`

Prevents browsers from guessing the MIME type of a response. Without this, a browser might execute a JavaScript file served as plain text (MIME confusion attacks). The header is simple, costs nothing, and should always be present.

X-Frame-Options `x-frame-options: DENY`

Prevents the page from being embedded in an `<iframe>`. Blocks clickjacking — attacks where your page is overlaid invisibly inside a malicious site to trick users into clicking hidden elements. Largely superseded by CSP's `frame-ancestors` directive, but still widely used.

Referrer-Policy `referrer-policy: strict-origin-when-cross-origin`

Controls how much URL information is sent in the `Referer` header when a user follows a link from your site to another. `strict-origin-when-cross-origin` sends only the domain (not the full path) for cross-origin requests — protecting users from having their browsing paths on your site leaked to third parties.

Permissions-Policy `permissions-policy: geolocation=(), camera=(), microphone=()`

Declares which browser APIs this page uses — and explicitly disables the ones it doesn't. An empty value (`()`) means "no origin is allowed to use this feature." This limits what malicious injected content can access even if CSP fails.

Open myipco.com/my-headers while on the site you want to check. Look for these specific response headers in the results:

Minimum baseline (every HTTPS site should have these): - `strict-transport-security` — present? Good. Missing? The site is vulnerable to HSTS bypass. - `x-content-type-options: nosniff` — trivial to add, should always be present. - `x-frame-options` or `content-security-policy` with `frame-ancestors` — at least one clickjacking protection should be set.

Strong configuration (well-secured sites have these): - `content-security-policy` with a specific allowlist (not `*` or `unsafe-inline`) - `referrer-policy` set to `strict-origin-when-cross-origin` or stricter - `permissions-policy` disabling unused browser APIs

Red flags: - No `strict-transport-security` header at all — HSTS bypass possible - `content-security-policy: default-src *` — CSP present but effectively disabled - `x-powered-by: PHP/7.2.0` — server is advertising its software version, helping attackers target known vulnerabilities - `server: Apache/2.4.41` — same issue; well-configured servers suppress this header

The myipco.com headers tool shows both request headers (what your browser sends) and response headers (what the server sends back), with descriptions of each. Run it on your own site to see exactly what security posture you are presenting to visitors.

These are the most frequent HTTPS security failures — all detectable by reading response headers:

Mixed content A site is served over HTTPS but loads resources (images, scripts, fonts) over HTTP. The page shows a padlock but some content is unencrypted. Browsers now block mixed active content (scripts, iframes) automatically but may still load mixed passive content (images). Look for `content-security-policy` with `upgrade-insecure-requests` — this directive tells the browser to automatically upgrade HTTP sub-resource requests to HTTPS.

HSTS without preload HSTS protects returning visitors but not first-time visitors. On the very first connection to a site, the browser hasn't yet received the HSTS header — an attacker can intercept that initial HTTP request. The `preload` directive solves this but requires the domain to be submitted to the HSTS preload list. Without `preload`, there is a window of vulnerability.

Overly permissive CSP Many sites add a CSP but use `unsafe-inline` or `unsafe-eval` to avoid breaking existing scripts. These directives largely defeat the purpose of CSP — inline scripts are exactly what XSS attacks inject. A CSP with `unsafe-inline` in the `script-src` provides minimal protection against actual XSS.

Missing certificate transparency Certificate Transparency (CT) is a public audit log for TLS certificates. All major CAs are required to submit certificates to CT logs. This prevents CAs from issuing rogue certificates without detection. You cannot see CT directly in headers, but if you are auditing a certificate closely, checking CT logs (crt.sh is a public search tool) verifies the certificate's issuance history.

Expired or mismatched certificates Browsers show a warning for these, but it is worth knowing what causes them: an expired certificate means the domain owner did not renew in time; a mismatched certificate means the certificate was issued for a different domain. Let's Encrypt's 90-day certificates with automated renewal have reduced expiry failures significantly.

The common assumption is that HTTPS is slower because of encryption overhead. In practice, HTTPS is often faster than HTTP for several reasons:

TLS overhead is negligible on modern hardware AES-NI (hardware-accelerated AES encryption) is standard on every modern CPU. The CPU cost of encrypting and decrypting HTTPS traffic is immeasurable in real-world conditions — typically less than 1ms per request.

HTTP/2 and HTTP/3 require HTTPS HTTP/2 — which provides header compression, request multiplexing (multiple requests over one connection), and server push — is only available over HTTPS in practice. A site served over HTTPS with HTTP/2 is significantly faster than the same site over HTTP/1.1, even accounting for the TLS handshake. HTTP/3 (QUIC) similarly requires TLS 1.3.

HSTS removes a redirect Sites without HSTS often redirect HTTP to HTTPS — a round trip that adds 50–200ms. With HSTS, the browser goes directly to HTTPS, eliminating the redirect entirely.

The TLS handshake adds latency once The TLS 1.3 handshake takes one round trip on new connections. TLS 1.3's 0-RTT resumption eliminates even this on return visits. For a page that loads dozens of resources, the handshake cost is amortised to nearly nothing.

The net result: a properly configured HTTPS site with HTTP/2 is typically 10–30% faster than an equivalent HTTP/1.1 site, despite the encryption. The performance argument against HTTPS is obsolete.

For a broader look at the headers involved in connection negotiation and caching, the complete HTTP headers guide covers the full request and response header set.