Traffic Analysis and Cleartext Credential Interception
Imagine you are sitting in a coffee shop, connected to the free Wi-Fi, logging into a corporate portal. The connection feels normal — the page loads, you type your email and password, and you click "Login." What you cannot see is that another laptop at the next table has been quietly capturing every packet flowing through the access point since you sat down.
When that attacker opens Wireshark and applies the filter http.request.method == "POST", your login request appears in the list — timestamp, source IP, destination IP, and the full request body including your password in plain readable text. They do not need to crack anything. They do not need to guess. The password is right there, as clear as the coffee menu on the wall behind you.
This is not a theoretical scenario. It is a well-understood, decades-old attack that requires only a laptop, a free tool, and a few minutes on the same network as the victim. The only thing that prevents it is transport-layer encryption — HTTPS with TLS.
Why HTTP exposes everything
HTTP is a text-based protocol designed for simplicity, not security. Every request and every response travels across the wire as readable ASCII. When a browser submits a login form over HTTP, the packet payload is literally the text that the server will parse. There is no transformation, no scrambling, no encryption. A packet capture is a perfect transcript.
HTTPS wraps HTTP inside TLS (Transport Layer Security). Before any HTTP data is sent, the browser and server negotiate a set of session keys using asymmetric cryptography. From that point forward, the HTTP data is encrypted with a symmetric cipher — AES-256-GCM in modern TLS 1.3. What an attacker sees in a packet capture is ciphertext: apparently random bytes with no recoverable information unless they have the session key, which was never transmitted across the network.
What you will do in this lab
The interactive panel on the right side of this screen shows a simulated Wireshark packet capture. It contains 30 packets representing real network traffic — a mix of DNS lookups, TLS-encrypted HTTPS sessions, and TCP control packets.
Hidden among them is one HTTP packet: a POST request to /api/login. This packet contains the cleartext credentials submitted by a user on an unencrypted corporate application. Your task is to find that packet, inspect its contents using the packet details panel, and extract the cleartext password exactly as it appears.
As you work through this lab, keep the following questions in mind:
- If this were a real network capture, how many users might be affected?
- Would the attacker need to stay on the network, or is this a one-time capture?
- How does the presence of HTTPS packets in the same capture illustrate the contrast between encrypted and unencrypted traffic?
The attacker's perspective
An attacker performing this type of interception does not need to break any cryptography. They are not cracking a hash or exploiting a vulnerability in TLS. They are simply reading data that was transmitted without any protection.
This is why OWASP classifies cleartext transmission of sensitive data under A02:2021 — Cryptographic Failures. The failure is not that the cryptography was broken — it is that no cryptography was applied in the first place.
By the end of this lab, you will have seen firsthand what an attacker sees when they intercept HTTP credentials, and you will understand exactly which controls (HTTPS, HSTS, Secure cookies) are required to prevent it.