What is the difference between HTTP and HTTPS, and what does TLS actually do?
HTTPS is HTTP sent inside a TLS connection. TLS gives three things plain HTTP lacks - encryption so others on the network cannot read the data, integrity so it cannot be changed in transit, and authentication through a certificate so you know you are talking to the real site.
Explain it simply
Plain HTTP is like writing your bank PIN on a postcard. Every person who handles it on the way, the hostel Wi-Fi, the router, the ISP, can read it and even change it.
HTTPS is like sending the same message in a sealed, tamper-evident envelope to someone whose identity card you have already checked. Nobody on the way can read it, if anyone opens or changes it you will notice, and you know the receiver is really your bank and not someone pretending to be it.
TLS (Transport Layer Security) is the envelope plus the ID check. HTTP itself does not change at all; it just travels inside TLS.
Example
| HTTP | HTTPS | |
|---|---|---|
| Default port | 80 | 443 |
| Data on the network | Plain text | Encrypted |
| Can someone in the middle change it? | Yes, silently | Tampering is detected |
| Proves the server's identity? | No | Yes, with a certificate |
| Browser shows | "Not secure" | Normal, no warning |
| Required for | Nothing | Modern features like service workers, geolocation, camera access, HTTP/2 in browsers |
You can see the TLS handshake yourself:
curl -v https://example.com 2>&1 | grep -E "SSL connection|subject|issuer"How it works
The TLS handshake happens right after the TCP connection opens and before any HTTP data is sent. In TLS 1.3, it takes one round trip:
- ClientHello: the browser sends the TLS versions and cipher suites it supports, plus its share of a key exchange (an ephemeral Diffie-Hellman public key).
- ServerHello: the server picks the settings and sends its own key share. Both sides can now compute the same shared secret without ever sending it.
- Certificate and proof: the server sends its certificate and signs the handshake with its private key, proving it owns that certificate.
- Verification: the browser checks the certificate is for this domain, has not expired, and chains up to a certificate authority (CA) it already trusts, such as Let's Encrypt or DigiCert.
- Finished: both sides confirm the handshake, and all HTTP data from now on is encrypted with fast symmetric keys (for example AES-GCM or ChaCha20-Poly1305).
So asymmetric cryptography (public and private keys) is used briefly to authenticate and agree on keys, and symmetric encryption does the heavy lifting because it is much faster. Because TLS 1.3 uses ephemeral keys, even if the server's private key leaks later, old recorded traffic cannot be decrypted. This is called forward secrecy.
Real-world use
Every payment page, login form and API uses HTTPS. On public Wi-Fi at a railway station or café, HTTPS is what stops others on the same network from reading your session cookies. Certificates are free from Let's Encrypt and renew automatically, so there is no reason for any site to use plain HTTP today. Sites also send the Strict-Transport-Security (HSTS) header so browsers refuse to load them over HTTP at all.
Common mistakes
- Saying HTTPS hides which site you visit. Your IP address and the destination IP are visible, and the domain is usually visible in the handshake's Server Name Indication unless Encrypted Client Hello is used.
- Saying HTTPS means the site is safe or honest. A phishing site can have a valid certificate too; HTTPS only proves you are talking to the owner of that domain.
- Saying TLS encrypts everything with the public key. The public key is used in the handshake; the data uses symmetric keys.
- Calling it SSL. SSL is the old, broken predecessor; current versions are TLS 1.2 and 1.3.
What to say in the interview
"HTTPS is HTTP over TLS, usually on port 443. TLS provides confidentiality, integrity and authentication. During the handshake the client and server agree on a cipher, do an ephemeral Diffie-Hellman key exchange to derive a shared secret, and the server proves its identity with a certificate signed by a trusted CA. After that, HTTP traffic is encrypted with symmetric keys like AES-GCM, which is fast. TLS 1.3 does this in one round trip and gives forward secrecy. HTTPS protects data in transit, but it does not make the site itself trustworthy."
Follow-up questions
- How does a browser decide whether to trust a certificate?
- Why is symmetric encryption used for the actual data?
- What is a man-in-the-middle attack and how does TLS prevent it?
- What is HSTS?
Go deeper
Read these once the basics above feel easy.
A certificate chain usually goes leaf certificate (your domain), then an intermediate CA, then a root CA stored in the OS or browser trust store. Servers must send the intermediate; a missing intermediate is a common reason a site works in one browser and fails in another. TLS 1.3 removed older options like static RSA key exchange, so every connection gets forward secrecy by default.