Step 85. Project — HTTP vs HTTPS Comparison Report

Level 1 — Programming and the Inside of a Computer | Difficulty ★★★☆☆ | Estimated time: 3 hours

Prerequisites: Steps 83–84 complete — capture, filters, and protocol analysis. You can handle curl and a simple Python server.

What you need: Wireshark (or tshark), two terminals, a web browser, a document tool.
Caution: ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. The plaintext experiments all happen inside your own computer (127.0.0.1), and the HTTPS experiment consists only of normal visits to a public site. The packet outputs in this chapter were measured on 2026-09-09 on WSL Linux (TShark 4.2.2, curl 8.5.0), and browser/GUI screen descriptions are "Screen examples."

The padlock in the address bar — that’s HTTPS. But almost no one has seen with their own eyes what difference the presence or absence of that padlock makes on the actual wire. This project has exactly one goal: send the same content once over HTTP (plaintext) and once over HTTPS (ciphertext), capture both side by side, and write a comparison report. Once you confirm it with your own eyes, "HTTPS is secure" stops being a textbook phrase and becomes a fact you proved yourself.

1. Learning Objectives

By the end of this chapter, you will be able to:

Open a plaintext web server locally and prove with a capture that requests/responses ride in packets letter for letter
Reproduce and record the scene where a plaintext POST body (including a password) is exposed
Distinguish the TLS handshake from Application Data, and confirm that only ciphertext is visible
Organize what encryption hides and what it cannot hide (metadata) into a comparison table
Complete one comparison report with interpretation attached to screenshots (or capture excerpts)

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Linux terminal + Wireshark (or tshark) + browser
Today’s commands/features	`python3 -m http.server 8000` (plaintext server), `curl` (generating requests), Follow TCP/HTTP Stream (conversation reconstruction), `tshark -Y tls`
Concepts needed	Plaintext/ciphertext, TLS handshake, certificates, metadata, the capture skills from Steps 83–84
Today’s artifact	One copy of the "HTTP vs HTTPS Comparative Analysis Report" (4 pieces of capture evidence + comparison table + conclusion)

2-1. What Is Plain Text?

Plaintext means "letters as they are, unencrypted." If you send the password mypw123 over HTTP, the letters mypw123 ride as-is inside packets crossing the network. Anyone who can see packets on the same segment — another user on the same public Wi-Fi, the carrier managing the line — can read them if they have the tools. Today we read them ourselves.

2-2. HTTPS and TLS at a Glance

HTTPS is "HTTP placed inside an encrypted tunnel called TLS (Transport Layer Security)." The process of building the tunnel is the TLS handshake.

The client greets: "I’d like to speak encrypted" (Client Hello).
The server presents its certificate — "an ID proving this server really is that server."
The two agree on a one-time encryption key used only for this session.
All subsequent HTTP content travels encrypted with that key (Application Data).

Open a packet from after the encryption and all you get is a meaningless sequence of bytes — ciphertext.

2-3. Why Write a Report

In real-world security, observation is half the work; the other half is documentation. Breach reports, assessment reports — all are "the skill of writing what I saw so others can reproduce it." The format is simple.

[Report skeleton]
1. Experiment purpose
2. Experiment environment (date, OS, tool versions)
3. Experiment procedure
4. Observations (capture evidence + interpretation)
5. Conclusion — what encryption hid and what it could not hide

3. Follow Along

3-1. Open a Plaintext Web Server Inside Your Computer

Input (terminal 1)

mkdir -p http-lab && cd http-lab
echo "<h1>hello plain world</h1>" > index.html
python3 -m http.server 8000

Output (Screen example):

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

How to read it: this means "serving HTTP on port 8000." Don’t close this window for the rest of the experiment. Since nearly every site on today’s internet is HTTPS, to observe plaintext you have to build it yourself like this.

3-2. Capturing Plaintext Traffic — The Letters Show As-Is

Input

# terminal 2 (capture)
tshark -i lo -a duration:6 -w plain.pcap
# while the capture runs, in terminal 3
curl -s http://127.0.0.1:8000/ > /dev/null
curl -s -X POST http://127.0.0.1:8000/login -d "username=hacker&password=mypw123" > /dev/null

How to read it: 127.0.0.1 traffic doesn’t pass through a network card, so you must capture on loopback (lo; on Windows, Npcap Loopback Adapter). The simple server can’t handle POST and returns a 501 error — but what matters is that the packet already went out onto the wire.

3-3. Plaintext Login — The Moment the Password Is in Plain View

Let’s reconstruct the entire POST conversation from the capture file.

Input

tshark -r plain.pcap -Y http
tshark -r plain.pcap -q -z follow,tcp,ascii,1

Output (measured 2026-09-09, stream reconstruction excerpt):

POST /login HTTP/1.1
Host: 127.0.0.1:8000
User-Agent: curl/8.5.0
Accept: */*
Content-Length: 32
Content-Type: application/x-www-form-urlencoded

username=hacker&password=mypw123

HTTP/1.0 501 Unsupported method ('POST')
Server: SimpleHTTP/0.6 Python/3.12.3
...

How to read it: look at the bottom line. username=hacker&password=mypw123 rides in plaintext, exactly as-is. Whether the server rejected it (501) or not, anyone who saw the packet already knows the password. In the GUI, right-click the POST packet → Follow → HTTP Stream to get the same window (Screen example). This is evidence 1 — the reconstructed plaintext conversation screen.

Why: in the experiment you just ran, "the people who know the password" are not the server — it’s everyone who saw the packet. Log in over plaintext HTTP on public Wi-Fi and exactly this happens.

3-4. Capturing HTTPS Traffic — What’s Visible and What Isn’t

Now for the ciphertext side. Capture while making a normal visit to a public site.

Input

tshark -i eth0 -f "tcp port 443" -a duration:10 -w tls.pcap
# in another terminal
curl -s https://example.com -o /dev/null

Output (measured 2026-09-09):

    4 0.016170231 192.168.39.82 → 172.66.147.243 TLSv1   583 Client Hello (SNI=example.com)
    6 0.032460886 172.66.147.243 → 192.168.39.82 TLSv1.3 3750 Server Hello, Change Cipher Spec
    7 0.032461144 172.66.147.243 → 192.168.39.82 TLSv1.3 372  Application Data
   10 0.035322790 192.168.39.82 → 172.66.147.243 TLSv1.3 146  Change Cipher Spec, Application Data
   11 0.035690588 192.168.39.82 → 172.66.147.243 TLSv1.3 152  Application Data
   14 0.048524337 172.66.147.243 → 192.168.39.82 TLSv1.3 619  Application Data, Application Data
   ...

How to read it: after the greeting Client Hello and the reply Server Hello, everything from then on is Application Data — encrypted content. And there’s something to note carefully: the list has no Certificate line. In modern TLS 1.3, even the server’s certificate is encrypted and goes inside Application Data (the negotiation in the measurement environment settled on TLS 1.3). In an older TLS 1.2 environment, you’d see the certificate pass in plaintext in the list.

Open the contents of an Application Data packet (measured 2026-09-09, hex dump excerpt):

0ed0  7e ae 32 45 54 c9 5b 9f 53 1c 24 fc c6 2f 00 33   ~.2ET.[.S.$../.3
0ee0  71 5d 76 25 15 64 6d 78 b2 06 59 82 33 c9 d8 c5   q]v%.dmx..Y.3...
0ef0  65 b8 b5 a5 57 9d 3d d0 77 8b 9b fa 66 79 93 b1   e...W.=.w...fy..

How to read it: nothing but a random sequence of bytes. The page content is in here, but it can’t be read. An exact contrast with 3-3. This is evidence 2 — the ciphertext dump screen.

3-5. What Leaks Anyway — SNI and Metadata

Even in the age of ciphertext, some things leak. Let’s unfold the Client Hello.

Input

tshark -r tls.pcap -Y "tls.handshake.type == 1" -V | grep -A2 "Server Name"

Output (measured 2026-09-09):

Server Name Indication extension
    Server Name Type: host_name (0)
    Server Name: example.com

How to read it: the content is all encrypted, yet "where you connected" (SNI, Server Name Indication) is visible in plaintext. Add the destination IP address, the time of communication, and packet sizes (the numbers 583, 3750, 372… in the list above), and an observer knows quite a lot without any content. This is evidence 3 — the "visible anyway" screen.

Why: TLS hides the content perfectly, but it cannot hide "who communicated with whom, when, and how much" (metadata). That’s why Step 84’s behavioral analysis still works in the encryption era.

3-6. Inspecting the Certificate — The Padlock’s True Identity

Input: click the padlock icon in the browser address bar → "Connection is secure" → "Certificate" menu.

Screen example: a certificate window opens showing the subject (issued to whom), the issuer (who vouches), and the validity period.

How to read it: a certificate is like an official transcript. A trusted body called a CA (Certificate Authority) has signed a document declaring "we vouch that the owner of this domain is the owner of this public key," and the browser shows the padlock only after verifying that signature. Encryption alone leaves a hole — "what if the other side isn’t really the bank but an impostor?" — and the certificate fills that hole. This is evidence 4 — the certificate information window.

3-7. Assembling the Report — Attaching the Comparison Table and Interpretations

Open your document tool and write following the skeleton from 2-3. The core is this comparison table (verified by today’s measurements):

Item	HTTP (plaintext)	HTTPS (ciphertext)
Request line (GET / …)	Visible	Not visible
Headers (User-Agent, etc.)	Visible	Not visible
Body (password included)	Visible	Not visible
Server name connected to (SNI)	Visible	Visible
Destination IP address	Visible	Visible
Time and size of communication	Visible	Visible
Content swapped in the middle	Possible	Impossible (integrity check)

How to read it: read vertically and it’s each protocol’s exposure range; read horizontally and it’s what encryption did per item. The three rows where "Visible" remains connect precisely to 3-5’s conclusion — metadata remains.

Why: a table is a device that turns "what I saw" into "a form the reader can compare at a glance." In a security report, one table does the work of ten sentences. Under each piece of evidence (capture excerpt or screenshot), always attach two or three lines of interpretation — the figure is evidence; the interpretation is the claim.

4. Missions & Exercises

Mission — Complete the "HTTP vs HTTPS Comparative Analysis Report"

Write the experiment purpose, environment (date, OS, tool versions), and procedure following the 2-3 skeleton.
Attach 4 pieces of evidence: ① reconstructed plaintext conversation (Follow Stream) ② the password in the plaintext POST body ③ HTTPS Application Data ciphertext ④ the certificate window. Without a GUI, substitute tshark output excerpts.
Attach 2–3 lines of interpretation to each piece of evidence ("what to look at in this screen is X, and this means Y").
Fill in the comparison table from 3-7, including the "swapped in the middle" row.
Conclusion: write in one sentence each — 2 things TLS hid + 1 thing it could not hide. Save the file as step85_http_vs_https.

Exercises

Exercise 1. When comparing plaintext HTTP’s danger to a "postcard" and HTTPS to a "sealed letter," what does this analogy explain exactly, and what does it miss (metadata)?

Exercise 2. Why do we say the password leaked even though the server rejected the POST (501)?

Exercise 3. Why is there no Certificate line in a TLS 1.3 capture list, and what does this make harder for an observer?

Exercise 4. Name three things an observer can learn from HTTPS traffic.

5. Model Answers & Completion Criteria

Mission Model Answer

Example conclusion sentences (grounded in today’s measurements):

- Hidden thing 1: request line, headers, body — the password in the POST body read as-is
  in plaintext (the pcap's follow stream), but under TLS appeared only as random bytes
  of Application Data.
- Hidden thing 2: response content — the HTML the server sent could not be reconstructed
  from any packet on the TLS side.
- Could not hide: the fact of connection itself — the Client Hello's SNI (server name)
  and destination IP, communication time and size (metadata) remained in plaintext.

Example environment record: "2026-09-09, WSL Ubuntu, TShark 4.2.2, curl 8.5.0, targets 127.0.0.1:8000 (plaintext) and example.com (HTTPS, negotiated TLS 1.3)."

How to verify: ① are all 4 pieces of evidence attached, each with interpretation? ② are the table’s last two rows (IP / time·size) "Visible/Visible"? ③ does the conclusion state "content is hidden but metadata is not"? ④ is a reproducible procedure (full commands) written so someone reading alone could redo it?

Exercise Answers

Answer 1. What the analogy explains: a postcard (HTTP) can be read by anyone along the way; a sealed letter (HTTPS) cannot have its contents read. What it misses: even a sealed letter’s envelope exterior — sender, recipient, time sent, thickness of the letter — is visible. In reality, the Client Hello’s SNI and the IP address, time, and size remain in plaintext.

Answer 2. Because the packet has already crossed the wire the moment the request is sent. The server’s response (the 501 rejection) happens afterward, and anyone who saw the passing packet has already read password=mypw123 in the body. "Did the server process it" and "was the content exposed" are separate questions (confirmed by measurement on 2026-09-09).

Answer 3. Because in TLS 1.3 the certificate goes inside the handshake’s encrypted section and is sent as Application Data (in older TLS 1.2 it passed in plaintext). From an observer’s standpoint, even "this server’s certificate contents" can no longer be peeked at, reducing the clues for identifying the peer to SNI and the IP address.

Answer 4. ① The name of the server connected to (the Client Hello’s SNI) and the destination IP address, ② the time and duration of the communication, ③ the size and rhythm of the data exchanged. Even without knowing the content, you can know "who, with whom, when, how much."

Completion Criteria Checklist

[ ] I can open a simple Python server and capture plaintext HTTP on loopback
[ ] I can prove that the password is visible in a plaintext POST body
[ ] I can distinguish the TLS handshake (Client Hello/Server Hello) from Application Data
[ ] I can explain that SNI and metadata remain outside the encryption
[ ] I can explain the certificate’s role (preventing impersonation)
[ ] I completed and saved one comparison report with evidence and interpretations attached

6. Common Pitfalls & Fixes

Wall 1. Nothing gets captured on loopback

Symptom: it’s a 127.0.0.1 experiment but zero packets appear.

Cause: you’re capturing on a regular network card. 127.0.0.1 traffic doesn’t pass through a card — it circulates only inside the operating system.
Fix: pick the loopback-dedicated interface (Linux lo, Windows Npcap Loopback Adapter). If it’s not in the list on Windows, you need to reinstall Wireshark with Npcap included.

Wall 2. The http filter shows nothing

Symptom: curl succeeded but the http filter stays quiet.

Cause: the http filter sometimes fails to recognize a non-standard port like 8000.
Fix: change the filter to tcp.port == 8000. If packets show up, it’s a port-recognition issue, and you can still inspect contents with Follow → TCP Stream in that state. In the measured field extraction, -Y http did correctly recognize port 8000 as HTTP, but it may differ by environment.

Wall 3. Not even a Client Hello gets captured over HTTPS

Symptom: the tls filter comes up empty.

Cause: the browser reused a connection it had already opened (the handshake already finished), or it rendered the page from cache alone.
Fix: close the browser completely, reopen it, and visit again. If that still fails, widen the filter to tcp.port == 443 and check. Making a fresh connection with curl (3-4) is the most reliable.

Wall 4. I can’t tell which packets are Application Data

Symptom: it’s all TCP packets and I can’t pick out the TLS records.

Cause: either Wireshark failed to interpret the connection as TLS, or a filter is still applied.
Fix: find the connection that has a Server Hello first. The packets of the same address pair right after it are Application Data. You can also right-click a packet → Decode As to designate TLS.

Wall 5. My report turned into "a list of screenshots"

Symptom: a document with only figures and no idea what to look at.

Cause: interpretation is missing. Figures are evidence; claims are text.
Fix: use the two-line formula under each piece of evidence: "what to look at in this screen is X, and this means Y." Bad example: "(screenshot) done" / good example: "The password is visible in plaintext in the POST body — anyone who can view packets on this segment can read this value."

7. Summary

Today’s Concepts

Concept	One-line explanation
Plaintext	Letters as they are, unencrypted — ride in packets letter for letter
Ciphertext	A sequence of bytes meaningless without the key
TLS handshake	Greeting (Client/Server Hello) → certificate → key agreement → everything after is ciphertext
Certificate	An ID where a CA vouches "the peer is genuine" — prevents impersonation
SNI	The name of the connection target inside Client Hello — remains in plaintext even in TLS 1.3
Metadata	Who, with whom, when, how much — what encryption cannot hide
TLS 1.3	Even the certificate goes inside the encrypted section — no Certificate line in capture lists

Today’s Commands

Command	What it does
`python3 -m http.server 8000`	Practice plaintext web server
`curl -X POST address -d "..."`	Plaintext body transmission experiment
`tshark -i lo -a duration:6 -w plain.pcap`	Loopback plaintext capture
`tshark -r file -q -z follow,tcp,ascii,1`	Reconstruct an entire conversation — proving plaintext
`tshark -i eth0 -f "tcp port 443"`	Capture HTTPS only
`tshark -r tls.pcap -Y "tls.handshake.type == 1" -V`	Client Hello details — checking SNI

An Instinct More Important Than Commands

From today you can say "HTTPS is secure" like this: "The password I sent from 127.0.0.1 read as-is in the packet, and the same experiment under TLS left only random bytes — that’s why it’s secure." A security professional’s first qualification is the habit of saying "I verified," not "I heard."

At the same time, remember the boundary today’s comparison table speaks of. The padlock protects content, but it doesn’t hide where you connected. And the act of leaving observations as a document with interpretations attached — there’s a saying in the penetration testing industry, "skill is half, the report is half," and its reason is today’s final lesson.

Once every box is checked, Step 85 is complete. Click the checkbox in the sidebar to save your progress.