HTTP vs HTTPS: what encryption protects
On This Lesson 11 topics
Lesson Overview
In the last lesson, every request and response travelled as readable text. That is how plain HTTP works. Any computer that handles the data along the way could, in principle, read it or change it. HTTPS is HTTP with a security layer added, and the extra S stands for secure.
This lesson explains what that layer adds and, just as important, what it does not do. Beginners often believe the padlock in the browser means "this site is safe and everything about my visit is private". That is not what it means, and the gap between the belief and the truth causes real mistakes.
We will use the postal picture again. HTTP is a postcard: anyone who handles it can read it. HTTPS is a sealed envelope: handlers can see the address on the outside but not the letter inside.
This lesson builds on Lesson 4 (requests and responses) and Lesson 2 (ports).
Learning Objectives
By the end of this lesson you will be able to:
- Explain why plain HTTP is not private.
- State what HTTPS adds: encryption of the content in transit, proof of the server's identity, and protection against tampering.
- Explain in simple terms what encryption and a certificate are.
- Name what HTTPS does not hide, such as which site you connect to.
- Explain why a padlock does not mean a website is trustworthy.
- Say which port HTTPS uses by default and what TLS is.
- Explain why a backend should serve traffic over HTTPS.
Written Explanation
The problem with plain HTTP
When your browser sends an HTTP request, the text travels across many machines on the way to the server: your Wi-Fi router, your internet provider's equipment, and several others. Each one forwards the data. With plain HTTP, the data is readable at every stop, and a machine that wants to could:
- Read it. If you type a password into a form that is sent over HTTP, a person on the same café Wi-Fi network might be able to see it.
- Change it. A machine in the middle could alter a page, for example by adding advertisements, or alter what the server receives.
- Pretend to be the server. Plain HTTP offers no strong way to check that the machine answering is really the one you meant to reach.
Think of a postcard. Everyone who handles it, such as the postman, the sorting office, and the neighbour who finds it at the wrong door, can read it, and a dishonest one could scribble over it.
What is HTTPS?
HTTPS (HyperText Transfer Protocol Secure) is HTTP sent over an encrypted connection. MDN's glossary describes it as an encrypted version of HTTP that uses TLS to encrypt all communication between a client and a server, which allows clients to exchange sensitive data safely, such as for banking or online shopping.
TLS (Transport Layer Security) is the security protocol that sets up the protection. You may also see its older name, SSL. In practice, an https:// URL means: connect, run a TLS security handshake first, and only then send ordinary HTTP messages inside the protected connection. HTTPS uses port 443 by default, whereas HTTP uses 80 (Lesson 2).
The HTTP messages themselves are unchanged: the same requests, methods, headers, bodies, and status codes you learned in Lesson 4. HTTPS wraps them in protection.
The three things HTTPS adds
1. Confidentiality: encryption in transit. Encryption scrambles data using a mathematical key so that only someone with the right key can read it. In HTTPS, your browser and the server agree on keys during the TLS handshake, and everything afterwards is scrambled. A machine in the middle sees unreadable data. The data is protected while it travels ("in transit"). It is not protected on your device or on the server once it arrives.
2. Authentication: proof you reached the real site. How do you know the server answering for example.com really is example.com? During the handshake the server presents a certificate, a digital document that ties the domain name to a cryptographic key. The certificate is signed by an organisation your browser already trusts, called a certificate authority (CA). The browser checks the signature and checks that the certificate matches the domain you asked for. If something is wrong, it shows a warning page. This is the "sealed envelope with the real sender's seal" part.
3. Integrity: protection against tampering. TLS also lets each side notice if data was altered along the way. If a machine in the middle changes the content, the check fails and the connection is dropped. The page you receive is what the server sent.
The module's short answer is: HTTPS adds encryption in transit and proof that you reached the real site. Integrity is the third part and goes along with encryption in how TLS works. I describe these from standard TLS background; MDN's glossary page itself mentions only the encryption.
What HTTPS does not do
This is the part people get wrong. HTTPS does not:
- Hide which site you visit. Anyone watching the network can usually see the address of the server you connect to. The domain name is also typically visible, because it is looked up through DNS and, in many connections, sent in the clear at the start of the TLS handshake in a field called SNI (server name indication). A newer feature called Encrypted Client Hello can hide the name where it is supported, but you should not count on it. The safe lesson for a beginner: assume the site name is visible; the content is not. (This point is explained from general knowledge; I could not open one reference page I tried for it, so treat the SNI and Encrypted Client Hello detail as a hedged statement.)
- Hide everything about the traffic. An observer can still see roughly when you connected and how much data moved.
- Make the website trustworthy. HTTPS proves you are talking to the site that owns the domain. It does not prove the owner is honest. A fraudulent shop can have a valid certificate for its own domain.
- Protect data once it arrives. If a server stores your password carelessly, HTTPS does not help. It protected the trip, not the destination.
- Remove all risk on your own device. Software on your computer can still read what you type.
In envelope terms: the envelope hides the letter, not the address, not the fact that you are posting a letter, and not whether the recipient is a good person.
The padlock and the address bar
Browsers show an indicator, usually a padlock or a similar icon, when a page is loaded over HTTPS with a valid certificate. The exact look and wording change between browsers and versions, so do not rely on a particular picture. The key facts are:
- Padlock or "secure" means the connection is encrypted and the site's identity matches the domain.
- It does not mean the site is safe, honest, or the right site. Always read the domain itself.
examp1e.comwith a1instead of anlcan have a perfectly valid certificate.
If the browser shows a certificate warning, treat it as serious. It can mean an expired certificate, a mismatched domain, or a real attack in the middle. Do not click through when you are about to enter a password or a payment card.
How a certificate gets there
A site owner obtains a certificate for their domain from a certificate authority and installs it on the server. Some CAs verify only that the applicant controls the domain, and that is enough for the browser's padlock. Certificates expire, which is why a site can suddenly show a warning if its owner forgets to renew. As a backend developer you will configure HTTPS for your own service, usually through a platform or a front-door server that handles certificates for you. The exact steps depend on your hosting, so we leave them to later modules.
Why everyone uses HTTPS
Today browsers mark plain HTTP pages as not secure, and many features work only over HTTPS. Whenever a page handles logins, personal data, or payments, HTTPS is not optional. Even for a simple blog it protects readers from having pages altered on the way. Treat HTTPS as the default for every service you build.
Examples
Example 1: Postcard or envelope (simple)
You type your name and address into a form on a website.
- Over HTTP, the text travels as a postcard. A person sharing your café Wi-Fi who runs the right tool might read it.
- Over HTTPS, it travels in a sealed envelope. The person in the café sees that you connected to the site's server, but cannot read the form data.
The thing to remember is the difference between content and destination. The content is hidden. The destination is not.
Example 2: A bank-lookalike (practical)
You receive a message with a link to https://my-bank-login.example. The page has a padlock. Does that mean it is your bank?
No. The padlock tells you the connection is encrypted and that the certificate matches that domain. It says nothing about whether that domain belongs to your bank. A fraudster can register a similar-looking domain and obtain a valid certificate for it. The right check is whether the domain is your bank's real domain, which you can compare with the address on your bank card, or by typing the address yourself instead of following the link. HTTPS answers "is this private and is it who it says it is?", not "is it who I wanted?".
Example 3: Moving a backend from HTTP to HTTPS (realistic)
A team has an internal service answering on http://api.example.com:8080. A mobile app sends customers' login tokens to it. A security review points out that on public Wi-Fi the tokens could be read.
The plan:
- Obtain a certificate for
api.example.comand install it on the front-door server that receives traffic. - Listen on port 443 for HTTPS. The service behind it can stay on a private port.
- Redirect old HTTP traffic: answer port 80 with a
301 Moved Permanentlypointing to thehttps://URL (Lesson 4). - Update the mobile app to use
https://api.example.com. - Set a reminder to renew the certificate before it expires.
After the change the app's requests are encrypted in transit and the app can check that it is talking to the genuine server. What has not changed: the domain is still visible to network observers, and the server still must store the tokens and passwords safely.
Backend Insight
As the person building the server, you are responsible for turning on HTTPS and for what lies beyond it.
- Serve everything over HTTPS and redirect HTTP to HTTPS. A single plain-HTTP endpoint can leak data from your otherwise protected service.
- Never place secrets in URLs. The URL, including the query string, can end up in logs and browser history even when the connection is encrypted. Put sensitive values in the body or in headers, with care.
- HTTPS ends at some point. In many systems a load balancer or proxy handles TLS and passes plain HTTP to your service over a private network. Know where the encryption stops in your design.
- Encryption in transit is only one layer. You still need to store passwords properly, check inputs, and control who may see what. Later modules in this roadmap cover them.
- Watch certificate expiry. An expired certificate takes your site offline in practice, because browsers will warn users away.
Common Mistakes
Mistake 1: Believing HTTPS hides which site you visit
- Incorrect: "With HTTPS nobody can tell I visited this site."
- Correct: "With HTTPS nobody can read the content, but the destination is generally still visible to network observers."
Mistake 2: Treating the padlock as a trust seal
The padlock says the connection is private and the certificate matches the domain. A scam site can have one. Check the domain.
Mistake 3: Thinking HTTPS protects stored data
HTTPS protects data in transit only. A badly stored password is exposed no matter how it arrived.
Mistake 4: Putting private information in the URL
Even over HTTPS, URLs are often logged and saved. Keep secrets out of them.
Mistake 5: Clicking through certificate warnings
A warning is the browser telling you identity or privacy is in doubt. Stop and check, especially before entering passwords or payments.
Exercises
Try each exercise yourself before opening the solutions.
Level A: Foundation
A1. What does the S in HTTPS stand for, and which protocol provides the protection?
Show solution A1
A1. Secure. TLS (Transport Layer Security) provides the encryption and security checks.
A2. Which port does HTTPS use by default, and which does HTTP use?
Show solution A2
A2. HTTPS uses 443 by default. HTTP uses 80.
A3. True or false: HTTPS makes a website honest. Give a one-sentence reason.
Show solution A3
A3. False. HTTPS only protects the connection and checks the site's identity against its domain. It says nothing about whether the owner of the site is honest.
Level B: Application
B1. Someone on a café Wi-Fi network tries to read your traffic. What can they see if you use HTTP? What can they probably still see if you use HTTPS?
Show solution B1
B1. Over HTTP, they could potentially read the full requests and responses, including forms and pages. Over HTTPS they cannot read the content, but can probably still see which server (and usually which domain) you connected to, plus roughly when and how much data moved.
B2. Explain what a certificate proves, in your own words, and who signs it.
Show solution B2
B2. A certificate links a domain name to a cryptographic key and shows that the server presenting it controls that domain. A certificate authority that the browser trusts signs it.
B3. Your friend says, "The site has a padlock, so it is my bank." Explain what is wrong with this reasoning and what the friend should check.
Show solution B3
B3. A padlock proves a private connection and a certificate that matches the domain shown, not that the domain belongs to the bank. A look-alike domain can have a valid padlock. The friend should check the exact domain against the bank's real address, or type the address manually.
Level C: Challenge
C1. You are asked to review a service that accepts logins over HTTPS but puts the session token in the URL as ?token=abc. Explain the problem and suggest a fix.
Show solution C1
C1. URLs are often saved in browser history, server logs, and other tools, so a token in the URL can leak even though the connection is encrypted. Move the token to a request header or a cookie, and make sure it is not logged.
C2. A teammate says: "We have HTTPS on the front door, so the passwords we store are safe." Explain why this is not true and name two additional things the team must do.
Show solution C2
C2. HTTPS protects data only while it travels. Once stored, passwords need their own protection. The team should, for example, store passwords in a hashed form and not in plain text, and restrict who and what can read the database. Controlling access and validating input are other valid answers.
Mini Challenge
Run an "envelope audit" on a site you use.
- Open a site you use over HTTPS and look at the address bar. Write down what the browser shows for the connection. The look of the indicator varies by browser and version, so describe what you see in your own words.
- Write down the exact domain, character by character.
- List three things HTTPS protects for this site and three things it cannot protect.
- If you can, try the
http://version of the same domain and note what happens (many sites redirect tohttps://). If something unexpected happens, write it down but do not enter any passwords.
Check your work: your "cannot protect" list includes the fact that your visit to the site is usually visible, and you did not rely on the padlock to claim the site is honest.
Summary & Next Lesson
Key takeaways
- HTTP sends data as readable text. Anyone along the path could read or alter it.
- HTTPS is HTTP inside a TLS connection. It adds encryption in transit, proof that you reached the real site (through a certificate), and protection against tampering.
- It uses port 443 by default.
- HTTPS does not hide which site you connect to, does not make a site trustworthy, and does not protect data once it is stored.
- A padlock means a private connection to the domain shown, not that the site is safe.
- Backends should serve HTTPS everywhere, keep secrets out of URLs, and watch certificate expiry.
Next lesson
You have the full theory. The next lesson, "Watching a request in the browser's developer tools", lets you see real requests, methods, and status codes with your own eyes.
Self-check
- What does HTTPS add over HTTP?
- What protocol provides the encryption?
- Does HTTPS hide which site you visit?
- Does a padlock prove a site is honest?
- Which port does HTTPS use by default?
Show answers
- Encryption of the content in transit and proof that you reached the real site (and protection against tampering).
- TLS.
- No. The destination is generally still visible to network observers; the content is encrypted.
- No. It only shows a private connection and a certificate matching the domain.
- 443.
References
- Mozilla Developer Network, HTTPS (glossary). Supports HTTPS as the encrypted version of HTTP that uses TLS to encrypt communication between client and server. The points on certificates, integrity, port 443, and what stays visible (the server address, and the hostname unless Encrypted Client Hello is used) come from general TLS knowledge, not from that page.
- Mozilla Developer Network, Port (glossary). Supports the default ports of 80 for HTTP and 443 for HTTPS.
- Not verified: the details of SNI and Encrypted Client Hello are stated as general knowledge because the Cloudflare page I tried to read was not available. Check an up-to-date source before relying on them.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.