# HTTPS Explained: How TLS Secures HTTP

> HTTPS is HTTP over TLS. What the TLS handshake does, how certificates prove identity, what HTTPS hides and what it does not, and how to migrate a site safely.

Source: https://howhttpworks.com/guides/https-and-tls
Last reviewed: 2026-10-05

> **TL;DR:** If you are starting out: always use HTTPS, keep certificates valid, and redirect HTTP to HTTPS with a single 301 hop. For modern browser traffic, prefer HTTP/2.

HTTPS is not optional infrastructure polish anymore. It is the baseline for trust, browser compatibility, cookie safety, and a large part of what makes modern web features available at all.

## Start Here (Fresh Grads)

If you only remember six things, remember these:

1. HTTP sends data in plain text. HTTPS encrypts it with TLS.
2. A certificate proves the server identity to the browser.
3. Always redirect `http://` to `https://` with a permanent `301`.
4. Never ship login/session cookies without `Secure` and `HttpOnly`.
5. Mixed content (`https` page loading `http` assets) breaks trust and can break features.
6. For websites, HTTPS + HTTP/2 is the default safe baseline.

## Quick Terms (So the Rest Is Easier)

- `TLS`: Transport Layer Security, the encryption layer used by HTTPS.
- `CA`: Certificate Authority, a trusted issuer of certificates.
- `HSTS`: Header that tells browsers to only use HTTPS for a site.
- `CDN`: Content Delivery Network, edge servers that cache/serve traffic globally.
- `SAN`: Subject Alternative Name, extra hostnames included in a certificate.
- `RTT`: Round-trip time, how long a request/response trip takes.

## HTTP vs HTTPS at a Glance

| Area              | HTTP                                  | HTTPS                                                                 | Practical impact                                           |
| ----------------- | ------------------------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------- |
| Transport         | Plain text                            | TLS-encrypted                                                         | Prevents eavesdropping on credentials, cookies, and tokens |
| Integrity         | No built-in integrity                 | Message authentication in TLS                                         | Defends against in-transit tampering                       |
| Identity          | No server identity proof              | Certificate-backed server authentication                              | Reduces man-in-the-middle and impersonation risk           |
| Browser UX        | Marked as not secure in many contexts | Trusted padlock / secure context                                      | Higher user trust and lower abandonment                    |
| Platform features | Limited                               | Required for many APIs (service workers, modern storage, permissions) | Core app features may fail without HTTPS                   |
| SEO signals       | Weaker trust signal                   | Preferred by search engines                                           | Better eligibility for competitive ranking                 |
| Typical port      | `80`                                  | `443`                                                                 | Easier policy and firewall standardization                 |

## How HTTPS Works

### 1. TLS handshake

Before application data is sent, the client and server establish a secure session.

```text
Client                               Server
  |                                    |
  |----- ClientHello ----------------->|
  |  (versions, ciphers, key share)    |
  |                                    |
  |<---- ServerHello + Certificate ----|
  |                                    |
  |----- Key Agreement ---------------->|
  |                                    |
  |<---- Finished ---------------------|
  |                                    |
  |===== Encrypted HTTP data =========>|
```

What matters operationally:

1. The client and server agree on TLS version and cipher.
2. The server proves identity with a certificate chain.
3. Both sides derive shared keys for symmetric encryption.
4. All following HTTP messages are encrypted and integrity-protected.

### 2. Certificate validation

Browsers validate that:

1. The certificate is not expired.
2. The certificate chain leads to a trusted CA.
3. The certificate matches the requested hostname.
4. Revocation checks are acceptable for policy.

### 3. Encryption after handshake

Modern TLS typically uses AEAD ciphers such as:

```text
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
```

## HTTPS Migration Checklist (Production-Safe)

Use this sequence to migrate without hurting user experience, crawlability, or rankings.

### Phase 1: Prepare inventory and certificates

1. Inventory every hostname and URL pattern currently served over HTTP.
2. Issue certificates for apex, `www`, and required subdomains.
3. Ensure TLS 1.2+ support before traffic cutover.
4. Verify origin and CDN both present full certificate chains.

### Phase 2: Redirect and canonical consistency

1. Add permanent one-hop redirects: `http://` -> `https://` (preserve path + query).
2. Update canonical tags, hreflang tags, sitemap URLs, and internal links to HTTPS.
3. Keep legacy redirects in place long-term; do not remove them after a few weeks.

Example one-hop redirect:

```nginx
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://$host$request_uri;
}
```

### Phase 3: Harden transport

1. Enable HSTS after HTTPS is stable in production.
2. Mark session/auth cookies as `Secure` and `HttpOnly`.
3. Eliminate mixed content (`http://` asset URLs).
4. Consider `Content-Security-Policy: upgrade-insecure-requests` during cleanup.

### Phase 4: Validate and monitor

1. Crawl key pages and confirm no redirect chains or loops.
2. Confirm all key pages return `200` over HTTPS.
3. Monitor TLS errors, certificate expiry, and 4xx/5xx changes post-cutover.
4. Re-submit sitemap in Search Console after migration.

## HTTP/1.1 vs HTTP/2: Practical Matrix

| Dimension         | HTTP/1.1                                   | HTTP/2                                                   | Practical tradeoff                                |
| ----------------- | ------------------------------------------ | -------------------------------------------------------- | ------------------------------------------------- |
| Framing model     | Text-based messages                        | Binary framing                                           | HTTP/2 is more efficient on noisy/mobile networks |
| Parallel requests | Multiple TCP connections often needed      | Multiplexing over one connection                         | HTTP/2 reduces connection churn                   |
| Header overhead   | Repeated full headers                      | Compressed headers (HPACK)                               | HTTP/2 helps header-heavy APIs                    |
| Blocking behavior | Requests can block each other at app layer | Better at app layer, still TCP-level head-of-line limits | Better than HTTP/1.1 for many assets              |
| Prioritization    | Limited                                    | Supports stream prioritization (browser behavior varies) | Gains depend on client/server implementation      |
| Server push       | N/A                                        | Spec feature, but largely deprecated in browsers         | Do not design around push                         |
| Browser usage     | Supported                                  | Effectively TLS-only in browsers                         | For websites, pair HTTP/2 with HTTPS              |
| Best fit          | Simpler legacy stacks                      | Modern web pages and APIs                                | Default choice for public browser traffic         |

### Decision guidance

1. If your pages load many small CSS/JS/image assets, HTTP/2 usually improves real-world latency.
2. Remove old HTTP/1.1 domain sharding patterns after moving to HTTP/2.
3. Benchmark on real user conditions (mobile + high RTT), not only local lab tests.

### Decision guidance by experience level

1. Fresh grad: choose HTTPS + HTTP/2 by default; avoid custom TLS tuning until basics are stable.
2. Junior engineer: focus on redirect correctness, certificate renewals, and mixed-content cleanup.
3. Experienced engineer: tune ciphers, OCSP behavior, cache headers, and edge/origin policy alignment.

Minimal Nginx enablement:

```nginx
server {
  listen 443 ssl;
  http2 on; # nginx 1.25.1+; older versions use `listen 443 ssl http2;`
  server_name example.com;
  # TLS config...
}
```

## Security Best Practices

### 1. Use HSTS (HTTP Strict Transport Security) carefully

Force browsers to always use HTTPS:

```http
Strict-Transport-Security: max-age=31536000; includeSubDomains
```

Roll out with a shorter `max-age` first, then increase once confident.

### 2. Disable weak protocols

Support TLS 1.2 and 1.3 only.

### 3. Prefer modern cipher suites

Prefer AES-GCM or CHACHA20-POLY1305 based configurations.

### 4. Automate cert renewal and monitoring

```bash
# Dry-run renewal
certbot renew --dry-run
```

Track expiration and failed renewals in alerts.

### 5. Avoid deprecated controls

Some legacy guides still mention old controls such as `Public-Key-Pins` (HPKP). Do not adopt these in new systems. Prefer strong certificate lifecycle automation and monitoring instead.

## Testing HTTPS Configuration

### SSL Labs

Use SSL Labs (`https://www.ssllabs.com/ssltest/`) for external posture checks.

### OpenSSL checks

```bash
# Inspect protocol/certificate details
openssl s_client -connect example.com:443 -tls1_3

# Check certificate validity dates
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
```

### curl checks

```bash
# Confirm redirect from HTTP to HTTPS
curl -I http://example.com/some-path

# Confirm final HTTPS response and headers
curl -I https://example.com/some-path

# Force specific TLS version
curl --tlsv1.3 https://example.com
```

## Common HTTPS Issues (and Fast Fixes)

### 1. Mixed content

Problem: HTTPS pages request HTTP assets.

```html
<!-- Bad -->
<script src="http://cdn.example.com/app.js"></script>

<!-- Good -->
<script src="https://cdn.example.com/app.js"></script>
```

Fix all hardcoded `http://` asset URLs and CDN templates.

### 2. Certificate name mismatch

Problem: certificate SANs do not include the hostname users requested.

Fix: issue a certificate that includes all served hostnames.

### 3. Redirect loops

Problem: edge redirects to HTTPS while origin redirects back, or vice versa.

Fix: define one redirect authority (usually edge/CDN) and align origin forwarding headers.

### 4. Expired certificate

Fix: automate renewal, monitor expiration, and test post-renewal reload paths.

## HTTPS for Development

Use `mkcert` for local trusted certs, so browser behavior matches production more closely.

```bash
mkcert -install
mkcert localhost 127.0.0.1 ::1
```

## Related Resources

- [HTTP Headers Hub](https://howhttpworks.com/headers)
- [Strict-Transport-Security Header](https://howhttpworks.com/headers/strict-transport-security)
- [Header Inspector Tool](https://howhttpworks.com/tools/inspect)
- [Cookie Security](https://howhttpworks.com/guides/cookie-security)
- [How HTTP Works](https://howhttpworks.com/guides/how-http-works)
- [HTTP Status Codes](https://howhttpworks.com/status-codes)

See also the comparison [HTTP vs HTTPS](https://howhttpworks.com/compare/http-vs-https): what TLS adds, what it still leaves visible, and HSTS.