HTTPS is HTTP plus a TLS layer underneath
HTTPS isn't a separate protocol from HTTP so much as ordinary HTTP running on top of TLS (Transport Layer Security, the modern successor to SSL) — the actual request/response structure (methods, headers, status codes) is identical; TLS wraps the entire exchange in an encrypted, authenticated tunnel before any HTTP data travels over it.
The three things TLS actually provides
- Encryption — the connection's contents (including URLs, headers, and body) are unreadable to anyone intercepting the traffic between client and server, protecting against eavesdropping on public networks, ISPs, or anyone else positioned on the path.
- Integrity — TLS detects if data was tampered with in transit, preventing an attacker from silently modifying a response (like injecting malicious content into a page) without detection.
- Authentication — a certificate, issued by a trusted certificate authority, verifies the server is actually who it claims to be, protecting against a specific kind of impersonation attack (a fake server pretending to be the real one).
Plain HTTP provides none of these — anyone positioned on the network path between client and server can read, and potentially modify, the entire exchange.
What the "handshake" actually establishes
Before any encrypted data flows, a TLS handshake negotiates: which encryption algorithm both sides will use, verifies the server's certificate against a trusted certificate authority, and establishes a shared session key used to encrypt the actual HTTP traffic that follows. This negotiation adds a small amount of latency to the very first connection, though modern TLS versions and connection reuse (keeping a connection alive across multiple requests) minimize this to a largely one-time cost per session rather than a per-request penalty.
What HTTPS deliberately does not protect against
This is the part worth being precise about: HTTPS protects data in transit — it does nothing for data already sitting on the server, in a database, or the security practices of the site itself. A site with valid HTTPS can still have a SQL injection vulnerability, store passwords insecurely, or otherwise mishandle data once it arrives — the padlock icon confirms the connection is encrypted and the server's identity is verified, not that the destination is trustworthy or secure in every other respect.
Common mistakes
- Treating the padlock icon as a general trust signal for the site itself. It confirms encrypted transit and certificate validity, not that the site is legitimate, honest, or handles data securely once received.
- Assuming HTTPS eliminates all need for other security practices. It protects the connection specifically — application-level vulnerabilities, weak server-side security, and social engineering are entirely separate concerns HTTPS doesn't touch.
- Not renewing certificates before expiration. An expired certificate causes browsers to show prominent warnings and can break the encrypted connection entirely, unrelated to any change in the actual site content.
FAQ
Does HTTPS mean a website is trustworthy or legitimate?
No — it only confirms the connection is encrypted and the server's certificate is valid; a malicious site can still have valid HTTPS while being entirely untrustworthy in content or intent.
What does the TLS handshake actually negotiate?
The encryption algorithm to use, verification of the server's certificate against a trusted authority, and a shared session key for encrypting the subsequent HTTP traffic.
Does HTTPS protect data once it reaches the server?
No — it only protects data in transit between client and server; how the server stores, processes, or secures that data afterward is a completely separate concern.
Inspect and parse URLs (HTTP and HTTPS alike) with the URL Parser — entirely client-side.