Episode 1 — Fundamentals / 1.4 — Understanding HTTP and HTTPS
1.4.c — What is HTTPS and Why Is It Better Than HTTP?
In one sentence: HTTPS is HTTP carried over an encrypted, integrity-protected channel (TLS). It is “better” because it protects users from eavesdropping and tampering and helps clients verify they reached the real server.
Navigation: ← 1.4.b — Status Codes · 1.4.d — How HTTPS Secures →
1. Definitions
| Term | Meaning |
|---|---|
| HTTP | HyperText Transfer Protocol — web request/response semantics |
| HTTPS | HTTP over TLS (historically described as “HTTP over SSL”) — same HTTP, encrypted transport |
| TLS | Transport Layer Security — the modern encryption suite (SSL is legacy naming) |
Default ports (convention):
- HTTP: 80
- HTTPS: 443
2. What Attackers Can Do on Plain HTTP
On an untrusted network (coffee shop Wi‑Fi, compromised router, ISP injection):
| Threat | What happens without TLS |
|---|---|
| Eavesdropping | Anyone on-path can read tokens, passwords, personal data |
| Tampering | An attacker can modify HTML/JS in transit (malware injection, ads) |
| Impersonation | Without strong authentication, you might not be talking to who you think |
HTTPS addresses these with confidentiality + integrity + server authentication (and optional client authentication).
3. Why HTTPS Is the Default Today
- Browser pressure — HTTP-only pages are labeled Not secure; many features require a secure context.
- Free certificates — Let’s Encrypt made TLS certificates cheap/free for most sites.
- SEO — search engines favor HTTPS sites.
- Regulatory expectations — privacy laws and industry standards expect encryption in transit.
- HTTP/2 and HTTP/3 adoption — browsers and CDNs often assume modern TLS deployments.
4. HTTPS Does Not Magically Make a Site “Safe”
HTTPS protects data in transit. It does not guarantee:
- the server isn’t malicious
- the app has no bugs (XSS, SQLi, etc.)
- user data is stored safely at rest
- privacy from everything (metadata and DNS may still leak depending on setup)
5. Quick Comparison Table
| Dimension | HTTP | HTTPS |
|---|---|---|
| Encryption | No (payload visible on the wire) | Yes (TLS ciphertext) |
| Integrity | No guarantees | Yes (tampering detected) |
| Server identity | Weak / none by default | Strong (certificate chain to trusted CA) |
| Default port | 80 | 443 |
| Browser UI | “Not secure” | Lock / secure indicators (varies) |
| Certificate required | No | Yes (for public trust) |
6. Key Takeaways
- HTTPS = HTTP + TLS (conceptually: HTTP bytes inside an encrypted tunnel).
- It prevents reading and silent tampering of content in transit.
- Certificates help clients verify server identity (trust is rooted in CAs and local trust stores).
- HTTPS is necessary but not sufficient for overall application security.
Explain-It Challenge
- Name three threats HTTPS mitigates that plain HTTP does not.
- Name two things HTTPS does not protect against.
- Why did Let’s Encrypt change the economics of HTTPS adoption?
Navigation: ← 1.4.b — Status Codes · 1.4.d — How HTTPS Secures →