HTTPS and TLS: How Secure Connections Work

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 a “nice to have” anymore. It is the baseline for trust, browser compatibility, and operational safety on the modern web.

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.

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

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:

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

### 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;
  server_name example.com;
  # TLS config...
}

Security Best Practices

1. Use HSTS (HTTP Strict Transport Security) carefully

Force browsers to always use HTTPS:

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

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

# 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
```text

### 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.

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

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

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
• Strict-Transport-Security Header
• Header Inspector Tool
• Cookie Security
• How HTTP Works
• HTTP Status Codes