Networks
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 outer TLS record types from encrypted inner content and describe what a passive capture cannot determine.
- 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 --bind 127.0.0.1 (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?
A passive observer needs access to the relevant packets. Merely sharing a Wi-Fi network does not guarantee that access. Use your own loopback fixture and dummy values to compare what your capture point exposes.
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 peers negotiate supported TLS parameters.
- The client verifies the server certificate and requested hostname under its trust policy.
- Key agreement derives traffic secrets and directional keys according to the TLS version.
- TLS protects application records; endpoints still process the plaintext.
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 --bind 127.0.0.1
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.
The dummy HTTP value is visible at this capture point because the captured application data is plaintext. Another observer’s visibility depends on network and capture access; sharing Wi-Fi alone is insufficient evidence.
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
...
In TLS 1.3, encrypted handshake messages can use an outer record type called application_data. That label alone does not prove that the encrypted payload is an HTTP request. The certificate is inside the encrypted handshake. TCP acknowledgments and other traffic can also appear after ServerHello.
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..
The dump shows encrypted record bytes. Without the traffic secrets, this capture does not reveal their inner plaintext. The application_data outer type alone cannot distinguish encrypted handshake material from HTTP content.
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
This capture shows an unencrypted SNI value in a ClientHello. That is not universal: Encrypted Client Hello (ECH), when negotiated, can protect the inner server name. Destination IPs, timing, and packet sizes may still be observable at this capture point. State what this particular trace reveals.
Correctly configured TLS protects application content in transit from an observer without the traffic secrets. IP addresses, timing, and sizes may remain visible; SNI visibility depends on ECH. These observations do not by themselves identify a person or prove a particular action.
3-6. Inspecting the Certificate — The Padlock’s True Identity
Use the browser’s site-information controls to inspect the connection and certificate. The icon and menu labels vary by browser version; a padlock icon is not universal. Do not bypass a certificate warning for this exercise.
Screen example: a certificate window opens showing the subject (issued to whom), the issuer (who vouches), and the validity period.
Certificate verification checks the requested hostname, chain of trust, validity, and relevant policy. It supports authentication of the TLS peer’s key under that trust model. It does not establish that the site’s content, business, or application is benign.
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):
| Observation | Plain HTTP | HTTPS, passive trace without keys |
|---|---|---|
| HTTP request, headers, body | Potentially visible | Protected by TLS |
| Server name | HTTP Host header; no TLS SNI | SNI may be visible; ECH can protect the inner name |
| IP address, timing, sizes | Observable at this vantage point | Often still observable |
| In-transit modification | No HTTP transport-integrity guarantee | Detected/rejected by correctly authenticated TLS |
For each row, distinguish what your capture shows from what you infer. TLS version, keys available to the analyzer, ECH, and capture location affect visibility. Preserve those conditions with your comparison.
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.
Answers & completion criteria · expand/collapse
5. Model Answers & Completion Criteria
Mission Model Answer
Example conclusion sentences (grounded in today’s measurements):
- HTTP: the owned plaintext fixture exposes the dummy request and response at this capture point. - TLS: encrypted records conceal their inner content from this passive observer without keys. - Metadata: destination IP, timing and sizes may remain visible. SNI visibility depends on ECH. - Limits: compare the recorded conditions; an outer record type does not prove the inner content type.
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).”
Verify that each screenshot or capture excerpt names its source, conditions, and limits. Explain content protection separately from metadata visibility, account for ECH, and include the exact commands needed to reproduce your owned fixtures.
Exercise Answers
Answer 1: The sealed-envelope analogy describes transport confidentiality but omits metadata and endpoint access. In a passive capture without keys, HTTP content is protected by correctly configured TLS. IPs, timing, sizes, and sometimes an unencrypted SNI can remain visible; ECH can protect the inner name.
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: In TLS 1.3 the certificate is carried inside encrypted handshake records, whose outer type can be application_data. A passive observer without traffic secrets cannot read that certificate from those records. Other metadata remains subject to the capture point and ECH deployment.
Answer 4: At this capture point, destination IP, timing, and sizes may remain observable. An unencrypted ClientHello can expose SNI, whereas ECH may protect the inner name. These fields do not necessarily identify a person, application action, or physical device.
Completion Criteria Checklist
- [ ] I can capture my own loopback HTTP fixture and find a dummy value.
- [ ] I can distinguish TLS record types from their encrypted inner content.
- [ ] I can explain that IP/timing/size and SNI visibility have different limits, including ECH.
- [ ] I can inspect certificate validation without equating it with a benign application.
- [ ] My report separates observed evidence from conclusions and untested claims.
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.
If http shows nothing, first filter the intended TCP port and inspect the capture. Packets may be TLS, another protocol, truncated, or undecoded HTTP. Use Decode As only when you know the fixture speaks HTTP; finding TCP packets does not establish a port-recognition problem.
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.
Follow the intended TCP conversation and inspect decoded TLS record fields. In TLS 1.3, an application_data record type may contain encrypted handshake or application content. Timing after ServerHello alone does not classify the payload.
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 --bind 127.0.0.1 |
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
The local HTTP trace exposes the dummy request content. The separate HTTPS trace illustrates encrypted records; it does not prove that the same request was replayed under otherwise identical conditions. TLS protects confidentiality and integrity in transit when correctly configured and authenticated; it does not make endpoints or applications trustworthy.
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.
ONE STEP FURTHER
Finished this lesson?
Check the completion criteria, then mark your progress.