HTTP vs HTTPS – SSL/TLS, Certificates & Security

2. What is HTTPS?

HTTPS (Hypertext Transfer Protocol Secure) is HTTP wrapped inside a TLS (Transport Layer Security) tunnel. The request-response model is identical to HTTP, but before any HTTP data is exchanged, a TLS handshake establishes an encrypted channel. Everything transmitted — URLs, headers, cookies, form data, responses — is encrypted end-to-end.

  HTTPS Connection Flow:

  Browser                                Web Server
    │                                        │
    │── TCP SYN ──────────────────────────▶  │
    │◀─ TCP SYN-ACK ──────────────────────   │
    │── TCP ACK ──────────────────────────▶  │  (TCP handshake on port 443)
    │                                        │
    │═══════ TLS HANDSHAKE ══════════════════│  (Certificate exchange,
    │        (see Section 5)                 │   key agreement — BEFORE
    │════════════════════════════════════════│   any HTTP data flows)
    │                                        │
    │── [ENCRYPTED] GET /index.html ───────▶ │  (Request — encrypted)
    │◀─ [ENCRYPTED] 200 OK + content ──────  │  (Response — encrypted)

  An interceptor sees only: [encrypted bytes] — cannot read content or URL path

3. HTTP vs HTTPS — Full Comparison

4. HTTP Methods

HTTP defines a set of request methods (also called verbs) that indicate the action to be performed on the resource identified by the URL. These apply to both HTTP and HTTPS.

5. HTTP Status Codes

Every HTTP response includes a three-digit status code that describes the outcome of the request. Status codes are grouped into five classes.

6. SSL and TLS — Version History

SSL (Secure Sockets Layer) was the original encryption protocol developed by Netscape in the 1990s. It was superseded by TLS (Transport Layer Security), which is the modern standard. Despite TLS being the correct term, the term "SSL" is still widely used colloquially.

7. The TLS Handshake — Step by Step

The TLS handshake is the process by which the browser and server agree on encryption parameters and establish a shared secret key before any application data flows. TLS 1.2 and TLS 1.3 use slightly different handshake flows; below is TLS 1.2 (the more commonly tested version).

  TLS 1.2 Handshake (2 Round Trips — 2-RTT):

  Browser (Client)                          Web Server
       │                                        │
       │── ClientHello ─────────────────────▶   │
       │   TLS version supported (max 1.2)      │
       │   Cipher suites supported              │
       │   Client Random (32 random bytes)      │
       │                                        │
       │◀─ ServerHello ──────────────────────   │
       │   Selected TLS version                 │
       │   Selected cipher suite                │
       │   Server Random (32 random bytes)      │
       │                                        │
       │◀─ Certificate ──────────────────────   │
       │   Server's digital certificate         │
       │   (contains server's public key)       │
       │                                        │
       │◀─ ServerHelloDone ──────────────────   │
       │                                        │
  [Browser validates certificate:              │
   - Is the CA trusted? (check CA root store)  │
   - Is it expired?                            │
   - Does CN/SAN match the hostname?           │
   - Is it revoked? (OCSP/CRL check)]          │
       │                                        │
       │── ClientKeyExchange ───────────────▶   │
       │   Pre-master secret encrypted with     │
       │   server's public key                  │
       │                                        │
  [Both sides derive the same session keys     │
   from: pre-master secret + client random     │
   + server random → Master Secret → Keys]     │
       │                                        │
       │── ChangeCipherSpec ────────────────▶   │
       │── Finished (encrypted) ────────────▶   │
       │◀─ ChangeCipherSpec ─────────────────   │
       │◀─ Finished (encrypted) ─────────────   │
       │                                        │
       │══ ENCRYPTED HTTP DATA FLOWS ══════════ │

TLS 1.3 Improvements

• 1-RTT handshake — completes in one round trip instead of two, reducing latency
• 0-RTT session resumption — previously connected clients can send data in the very first message (with some security trade-offs)
• Forward Secrecy mandatory — every session uses ephemeral key exchange (ECDHE); compromise of the server's private key cannot decrypt past sessions
• Removed insecure options — RSA key exchange, MD5/SHA-1, RC4, DES, and 3DES cipher suites all removed; only AEAD (Authenticated Encryption) allowed

8. Digital Certificates and Certificate Authorities

A digital certificate (X.509 certificate) is an electronic document that binds a public key to an identity (domain name, organisation) and is digitally signed by a trusted third party — a Certificate Authority (CA). Browsers and operating systems ship with a pre-installed list of trusted root CAs. When a server presents a certificate signed by one of these trusted CAs, the browser accepts it as proof of identity.

Certificate Types

Certificate Chain of Trust

  Root CA (self-signed, pre-installed in OS/browser trust store)
       │
       │ signs
       ▼
  Intermediate CA (signed by Root CA)
       │
       │ signs
       ▼
  Server Certificate (example.com — signed by Intermediate CA)

  Browser verification:
  1. Server sends: [Server Cert] + [Intermediate CA Cert]
  2. Browser checks: Is Intermediate CA signed by a Root CA I trust?
  3. Browser checks: Is Server Cert signed by this Intermediate CA?
  4. Browser checks: Is the certificate valid today? (not expired)
  5. Browser checks: Does CN or SAN match the hostname I'm connecting to?
  6. Browser checks: Is the certificate revoked? (OCSP stapling)
  → All pass → Padlock shown → Encrypted connection established

9. HTTPS Security Benefits — Confidentiality, Integrity, Authentication

HTTPS provides three distinct security properties, each protecting against different attack vectors.

10. Attacks Against HTTP and HTTPS

11. HSTS — HTTP Strict Transport Security

HSTS is a web security policy mechanism that forces browsers to interact with a server only over HTTPS, even if the user types http:// or clicks an HTTP link. The server sends an HTTP response header:

  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  │                           │               │                   │
  │                           │               │                   └─ Submit for HSTS preload list
  │                           │               └─ Apply to all subdomains
  │                           └─ Browser remembers HSTS for 1 year (31536000 seconds)
  └─ HSTS header name

Once a browser has received this header, for the max-age duration it will:

• Automatically rewrite http://example.com to https://example.com before sending any request
• Refuse to connect if the TLS certificate is invalid — no option to "proceed anyway" (unlike the normal browser certificate warning)
• Block SSL stripping attacks because the first request never goes over HTTP at all

12. HTTP/2 and Performance

HTTP/2 (RFC 7540) is a major revision of HTTP designed to improve performance over HTTP/1.1. While technically usable over plaintext (h2c), every major browser requires HTTPS (h2) to use HTTP/2. This makes HTTPS a prerequisite for modern web performance.

13. Implementing HTTPS — Step-by-Step

1. Obtain a certificate from a trusted CA: For free certificates, use Let's Encrypt (automated, DV certificates, 90-day validity, auto-renewable via certbot). For paid certificates with OV/EV validation, use DigiCert, Sectigo, GlobalSign, or similar. Internal-only servers can use a private/internal CA.
2. Install the certificate on the web server:

     # Apache — in VirtualHost block:
     SSLEngine on
     SSLCertificateFile     /etc/ssl/certs/example.com.crt
     SSLCertificateKeyFile  /etc/ssl/private/example.com.key
     SSLCertificateChainFile /etc/ssl/certs/intermediate.crt
   
     # Nginx:
     server {
         listen 443 ssl;
         ssl_certificate     /etc/nginx/ssl/example.com.crt;
         ssl_certificate_key /etc/nginx/ssl/example.com.key;
     }

3. Redirect all HTTP traffic to HTTPS:

     # Apache — in port 80 VirtualHost:
     RewriteEngine On
     RewriteCond %{HTTPS} off
     RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
   
     # Nginx:
     server {
         listen 80;
         server_name example.com;
         return 301 https://$host$request_uri;
     }

4. Enable HSTS to prevent SSL stripping attacks:

     # Apache:
     Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
   
     # Nginx:
     add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

5. Configure strong cipher suites and disable legacy protocols:

     # Nginx — recommended TLS configuration:
     ssl_protocols TLSv1.2 TLSv1.3;           # Disable SSL 2/3, TLS 1.0/1.1
     ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
     ssl_prefer_server_ciphers off;            # Let client choose (TLS 1.3)

6. Automate certificate renewal (Let's Encrypt certificates expire every 90 days):

     # Certbot — runs renewal check twice daily via cron/systemd:
     0 0,12 * * * root certbot renew --quiet

14. Key Points & Exam Tips

• HTTP: Port 80, plaintext, no authentication, no encryption, no integrity protection.
• HTTPS: Port 443, encrypted via TLS, server authentication via digital certificate, data integrity via HMAC.
• HTTP methods: GET (retrieve), POST (submit), PUT (replace), DELETE (remove), HEAD (headers only). GET parameters appear in URL — never use for passwords.
• HTTP status codes: 2xx = success, 3xx = redirect, 4xx = client error (404 Not Found, 401 Unauthorized), 5xx = server error.
• TLS versions: SSL 2/3 and TLS 1.0/1.1 are deprecated and must be disabled. TLS 1.2 is the minimum; TLS 1.3 is preferred.
• TLS handshake: ClientHello → ServerHello → Certificate → key exchange → session keys derived → encrypted channel established.
• TLS 1.3 advantages: 1-RTT (faster), mandatory forward secrecy (ECDHE), removed legacy ciphers.
• Certificate chain: Root CA → Intermediate CA → Server certificate. Browser validates the full chain to a trusted root.
• Certificate types: DV (domain only), OV (organisation verified), EV (extended validation), Wildcard (*.domain.com), SAN (multiple domains).
• HSTS forces browser to always use HTTPS; prevents SSL stripping; max-age controls how long; HSTS Preload solves the first-visit problem.
• MitM attack over HTTP: attacker intercepts and reads/modifies all traffic. HTTPS with certificate validation defeats MitM.
• HTTP/2 requires TLS in all major browsers — HTTPS is a prerequisite for modern web performance.
• HTTP 301 redirect sends browsers from HTTP to HTTPS permanently.
• Let's Encrypt provides free, automated DV certificates — widely used for most HTTPS deployments.

Related pages: DNS Purpose | DNS Lookup | DNS Configuration | Firewalls | OSI Model | Wireshark

← Back to Home