Labs · Cyber Security

Lab: Send the Same Practice Login over HTTP and HTTPS, Capture Both in Wireshark, and See Why TLS Matters

By Ravindra Bagale Last updated: 8 October 2026

Beginner30 minWireshark (free) · curl · httpbin.org (public request-testing service)

Course: Cyber Security · Chapter 24: Traffic Sniffing and Analysis

Chapter 24 explains traffic sniffing; this lab captures only your own traffic to show exactly what HTTPS protects.

Chala mitrano! People say "always use HTTPS", but why? Today we see it with our own eyes. We send the same fake username and password twice, once without encryption and once with it, and look at the packets. One will be readable like a postcard, the other like a sealed envelope. Bagha tar!

Suppose we are…

Suppose we work in the IT security team at Café Coffee Day, which offers free Wi-Fi in its cafés. A manager asks: "If someone on the same café Wi-Fi watches the traffic, what can they see when a customer logs in?" We answer with a safe demo: we send a fake login from our own laptop to httpbin.org (a public service built for testing web requests) and capture only our own traffic in Wireshark.

Goal of this lab

By the end you will be able to:

Capture your own HTTP request and read a password in plain text.
Capture the same request over HTTPS and see only encrypted "Application Data".
Explain what HTTPS still reveals (the website name) and what it hides.

What you need (all free)

Your own laptop with Wireshark (Lab 3) and curl (built into Windows 10+, macOS and Linux).
Internet access. 25–30 minutes.

Safety and ethics

Capture only your own traffic on your own laptop. Capturing other people's traffic on a shared Wi-Fi without permission is illegal. Use only the fake practice details below, never a real password.

Steps

Open Wireshark and double-click your active adapter (Wi-Fi or Ethernet) to start capturing.
In the display filter bar type http.request.method == "POST" and press Enter. The list is empty for now.
In a terminal, send a fake login over HTTP (on Windows use curl.exe):
```
curl -d "username=student01&password=Practice@123" http://httpbin.org/post
```
What you should see in the terminal: a JSON reply that echoes "password": "Practice@123" in the form section.
Back in Wireshark, one POST /post HTTP/1.1 line appears. Right-click it → Follow → HTTP Stream.

What you should see: the full request in red text, including username=student01&password=Practice@123. Anyone able to watch this network path could read it.

Close the stream window. Now send the same login over HTTPS:

curl -d "username=student01&password=Practice@123" https://httpbin.org/post

Change the display filter to tls and press Enter.

What you should see: Client Hello, Server Hello, then many Application Data lines. Nothing says POST and no password is visible.
Click the Client Hello line. In the middle pane expand Transport Layer Security → Handshake Protocol → Extension: server_name.

What you should see: Server Name: httpbin.org. HTTPS hides the content, but the website name is still visible.
Right-click an Application Data line → Follow → TLS Stream. You see only scrambled bytes.
Stop the capture (red square). Write a 3-line answer to the manager: what HTTP exposes, what HTTPS hides, what HTTPS still shows.

Ravindra Bagale's Tip

This is why browsers show "Not secure" for HTTP pages with a password box, and why your own site must redirect HTTP to HTTPS (Lab 13). And on public Wi-Fi, a padlock is the minimum, not the maximum. Mobile data or a trusted network is better for banking.

Common mistakes

Mistake	What happens	Fix
Typing a real password in the test	A real secret is sent to a public test service	Use only `Practice@123`
Capturing on the wrong adapter	No packets appear	Pick the adapter with the moving traffic graph
Using `curl` in Windows PowerShell 5	`curl` there is a different command and the `-d` option fails	Type `curl.exe`
Filter `http` shows nothing for HTTPS	HTTPS is not readable HTTP on the wire	Use the `tls` filter for HTTPS
Thinking HTTPS hides everything	The site name, IPs and timing are still visible	Remember Server Name (SNI) in step 7

Self-check checklist

I read the fake password in the HTTP stream.
I saw only Application Data for the HTTPS request.
I found the Server Name in the Client Hello.
I captured only my own traffic with fake details.
I can explain HTTP vs HTTPS in three lines.

0 of 5 done

Try-at-home challenge

Repeat the HTTP test with header -H "Authorization: Basic c3R1ZGVudDAxOlByYWN0aWNlQDEyMw==" added. Find it in Wireshark and decode it. Is Basic authentication over HTTP safe?

Check your answer

The header is visible in the HTTP stream. Base64 is encoding, not encryption: decoding it (for example with echo c3R1ZGVudDAxOlByYWN0aWNlQDEyMw== | base64 -d) gives student01:Practice@123. Basic authentication is only acceptable over HTTPS.

Samjla ka? HTTP is a postcard, HTTPS is a sealed envelope with the address still on it. Aata pudhe jaauya: Chapter 25 secures the Wi-Fi itself.