HTTP and HTTPS

What is it? #

HTTP is the language clients and servers speak. HTTPS is the same language sent through an encrypted channel.

HTTPS adds three things. Encryption, so nobody in between can read the traffic. Integrity, so nobody can alter it undetected. Identity, so the client can verify it is talking to the right server.

That third one is the part people forget. Encryption alone would be useless if you could not tell whether you had connected to the real bank or an impostor. Certificates provide that proof.

HTTPS is not optional any more. Browsers mark plain HTTP as insecure, many browser features require it, and certificates are free.

Think of it like this #

Sending a postcard versus a sealed, tamper-evident envelope delivered to a verified address.

Anyone handling the postcard can read it and could rewrite it. The sealed envelope keeps the contents private, shows if it has been opened, and the recipient's identity has been checked by someone both parties trust.

Simple example #

A login form on plain HTTP sends the password as readable text across every network device between the user and the server. On HTTPS, the same password is unreadable to everything in between.

Code #

The handshake, in plain terms

1. Client:  "I want to talk securely. Here are the methods I support."
2. Server:  "Use this one. Here is my certificate."
3. Client:  checks the certificate:
              - is it signed by an authority I trust?
              - does the name match the domain I asked for?
              - has it expired? has it been revoked?
4. Both:    agree on a shared secret key using public-key cryptography
5. Both:    encrypt everything from here on with that fast shared key

If step 3 fails, the browser refuses and shows a warning.

# Inspect a certificate
openssl s_client -connect example.com:443 -servername example.com < /dev/null \
  | openssl x509 -noout -subject -issuer -dates

# Get a free certificate and auto-renew it
sudo certbot --nginx -d example.com -d www.example.com

# Check what protocol and cipher were negotiated
curl -v https://example.com 2>&1 | grep -E "SSL connection|subject|issuer"

# Redirect all HTTP traffic to HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://<span class="katex"><span class="katex-mathml"><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>h</mi><mi>o</mi><mi>s</mi><mi>t</mi></mrow><annotation encoding="application/x-tex">host</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="katex-base"><span class="katex-strut" style="height:0.6944em;"></span><span class="mord mathnormal">h</span><span class="mord mathnormal">os</span><span class="mord mathnormal">t</span></span></span></span>request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;

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

    # Tell browsers to use HTTPS for this domain from now on
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

How it works #

The handshake happens once per connection and costs a few milliseconds. After it, encryption uses a fast symmetric key, so the ongoing overhead is small — HTTPS is not meaningfully slower than HTTP in practice.

The certificate is the identity proof. It states a domain name and is signed by a certificate authority that browsers already trust. A mismatch between the certificate name and the requested domain is exactly what stops impostor sites.

Certificates expire, usually in 90 days for free ones. Automatic renewal is not optional — expired certificates are a common and entirely avoidable outage.

The Nginx block shows the two standard pieces: redirect port 80 to 443, and serve TLS on 443. The redirect matters because users type bare domain names.

Strict-Transport-Security tells the browser to use HTTPS for this domain for a year, even if a link says HTTP. It closes the small window where a first plain request could be intercepted.

What HTTPS does not do is worth stating. It protects data in transit. It does not secure your application, validate your input, protect your database, or hide which domain you visited — that is still visible in DNS and in the connection metadata.

Real-world use #

Every production site uses HTTPS. Let's Encrypt made certificates free and automatable, and certbot plus a cron renewal is the standard setup, covered in detail in the VPS track.

Behind a load balancer or CDN, TLS often terminates at the edge: the public connection is encrypted, and traffic on the internal network may or may not be. In regulated environments, it is encrypted end to end.

Mixed content is a common practical problem: an HTTPS page loading an image or script over HTTP. Browsers block it, and the fix is to serve every asset over HTTPS.

Certificate expiry remains one of the most common causes of sudden site outages, which is why monitoring certificate validity is a standard alert.

Common mistakes #

• Letting certificates expire because renewal was not automated.
• Serving some assets over HTTP on an HTTPS page, causing mixed-content blocking.
• Assuming HTTPS makes the application secure. It only protects the transport.
• Not redirecting HTTP to HTTPS, leaving a plaintext path open.
• Enabling HSTS with a long max-age before HTTPS is fully working, which is hard to undo.

Practice #

Inspect the certificate of a site you use with the openssl command above and note its issuer and expiry date. Then write the Nginx configuration for redirecting HTTP to HTTPS from memory, and check it against the example.