Overview
The S in HTTPS stands for the security that TLS (Transport Layer Security) adds to HTTP. Without it, web traffic travels in the clear, readable and modifiable by anyone in the path. This lesson explains what TLS provides and why HTTPS is the norm.
Learning objectives
- State the security properties TLS provides.
- Explain the role of certificates and the TLS handshake at a high level.
- Understand why HTTPS matters for every site.
Core concept
TLS wraps HTTP to provide three properties, turning HTTP into HTTPS:
- Confidentiality — traffic is encrypted, so eavesdroppers cannot read it.
- Integrity — tampering with data in transit is detectable.
- Authentication — a certificate proves the server is who it claims to be, so you are not talking to an impostor.
These come from a TLS handshake that authenticates the server (via its certificate) and negotiates encryption keys before any HTTP data flows.
How it works
When a client connects over HTTPS, TLS runs a handshake first: the server presents a certificate issued by a trusted Certificate Authority (CA); the client verifies the certificate chains to a CA it trusts and matches the domain; then both sides agree on keys used to encrypt the session. Only after this does the HTTP request/response exchange begin — now encrypted and integrity-protected. Modern TLS uses strong ciphers and forward secrecy so past traffic stays protected even if a key is later compromised.
Practical example
You visit https://example.com. Before your browser sends the request, TLS negotiates a secure channel: it checks that example.com's certificate is valid, unexpired, matches the domain, and is signed by a trusted CA. The padlock in the address bar reflects this. Your login credentials then travel encrypted, unreadable to anyone monitoring the network between you and the server.
Cybersecurity relevance
TLS defends against eavesdropping and man-in-the-middle attacks that plague plain HTTP. Certificate validation is what stops an attacker from impersonating a site; invalid-certificate warnings exist precisely to flag possible interception and should not be ignored. Analysts examine certificates, TLS versions, and cipher choices for weaknesses, and defenders enforce HTTPS everywhere (e.g. via HSTS) to prevent downgrade to insecure HTTP.
Common mistakes
- Thinking HTTPS only encrypts — it also provides integrity and, crucially, server authentication.
- Ignoring certificate warnings, which may indicate interception or misconfiguration.
- Assuming HTTPS makes a site fully "safe" — it secures the transport, not the application's own flaws.
Key takeaways
- TLS turns HTTP into HTTPS, providing confidentiality (encryption), integrity (tamper detection), and authentication (via certificates).
- A TLS handshake validates the server's certificate against a trusted CA and negotiates encryption keys before HTTP data flows.
- TLS defends against eavesdropping and man-in-the-middle attacks; certificate warnings are security signals, and HTTPS secures the transport but not application-level flaws.
Check your understanding
- What three security properties does TLS provide to HTTPS?
- What does a server's certificate prove, and why should certificate warnings never be casually dismissed?