HTTP and HTTPS Packet Analysis

# CHAPTER 10

HTTP and HTTPS Packet Analysis #

1. Introduction #

Once the DNS query resolves the IP address, and the TCP 3-Way Handshake establishes a reliable connection, the actual data transfer begins. For web browsing, this data is formatted using the Hypertext Transfer Protocol (HTTP). In the early days of the internet, all web traffic was sent in plain text via HTTP, making Wireshark the ultimate tool for reading other people's emails and passwords over the wire. Today, the internet relies on encrypted HTTPS. In this chapter, we will use Wireshark to autopsy a classic, unencrypted HTTP GET request, analyze server Response Headers, and examine the boundaries of what Wireshark can and cannot see when a connection is encrypted with TLS (HTTPS).

2. Learning Objectives #

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

• Filter Wireshark specifically for HTTP web traffic.

• Analyze the structure of an HTTP GET Request.

• Extract valuable forensic data from HTTP Request/Response Headers.

• Understand the difference between HTTP (Port 80) and HTTPS (Port 443).

• Recognize a TLS Client Hello packet in an encrypted HTTPS connection.

3. Beginner-friendly Explanations #

The Postcard vs. The Safe (HTTP vs HTTPS):

• HTTP (Port 80): Sending data over HTTP is like mailing a postcard. Anyone who touches the postcard in transit (the postman, the mailroom clerk, the Wireshark capture) can simply flip it over and read exactly what is written on it.

• HTTPS (Port 443): Sending data over HTTPS is like placing a letter inside an indestructible titanium safe, locking it with a cryptographic key, and mailing the safe. Wireshark can see the safe moving across the network. It can see where the safe is going (the IP address). But it absolutely cannot see what is inside the safe.

4. Analyzing an HTTP Request (The GET Method) #

Let's look at an unencrypted web request. Filter Wireshark for http. Click on a packet labeled GET /index.html HTTP/1.1. In the Middle Pane, expand the Hypertext Transfer Protocol layer.

The Request Details:

• Method: GET (The browser is asking to download a file). If you were submitting a login form, the method would be POST.

• Request URI: /index.html (The specific page requested).

• Host: www.example.com (The domain name of the server).

• User-Agent: Mozilla/5.0 (Windows NT 10.0...) (This tells you exactly what web browser and operating system the user was running!).

*Forensic Note:* Because this is unencrypted, if the user submitted a password, you would see a Line-based text data folder at the bottom containing the literal username and password in plain text.

5. Analyzing an HTTP Response (The 200 OK) #

Right below the GET request, you will see the server's reply: HTTP/1.1 200 OK. Expand the HTTP layer for this response packet.

The Response Headers:

• Status Code: 200 OK (Success). If the page didn't exist, you would see the famous 404 Not Found. If the server crashed, you would see 500 Internal Server Error.

• Server: Apache/2.4.41 (Ubuntu) (The server explicitly tells you what software it is running—a major clue for hackers looking for vulnerabilities).

• Content-Type: text/html (Tells the browser to render the payload as a webpage).

*If you click on the "Line-based text data" folder in the response, Wireshark will actually show you the raw HTML code of the website being downloaded!*

6. The Reality of HTTPS (Encrypted Traffic) #

If you browse to https://google.com and filter Wireshark for http, you will see nothing. Because the traffic is encrypted via TLS (Transport Layer Security), Wireshark can no longer read the Application Layer.

If you change your filter to tls (or tcp.port == 443), you will see the encrypted traffic. Instead of GET /index.html, the packets are labeled Application Data. If you expand the details, you will just see an Encrypted Application Record containing random, useless hexadecimal garbage. The payload is totally secure.

7. The TLS Handshake (What Wireshark CAN see) #

Even with HTTPS, the very beginning of the conversation is unencrypted. Before the secure safe is locked, the Client and Server must negotiate the locks. This is the TLS Handshake. Look for a packet labeled Client Hello. Expand the Transport Layer Security -> TLSv1.2 Record Layer -> Handshake Protocol. Here, you can see the Server Name Indication (SNI).

*The Security Loophole:* Even though the payload is encrypted, the SNI extension in the Client Hello packet transmits the website's domain name (e.g., google.com) in plain text! A network administrator using Wireshark cannot see *what* video you are watching on YouTube, but by reading the SNI, they can definitively prove you are *on* YouTube.

8. Best Practices #

• Testing over HTTP: When writing backend APIs or setting up a new web server, developers often intentionally perform initial testing over unencrypted HTTP (Port 80). This allows them to use Wireshark to easily read the raw headers and JSON payloads to debug their code, before turning on the SSL/TLS certificates for production.

9. Common Mistakes #

• Assuming "Follow TCP Stream" decrypts data: A beginner captures HTTPS traffic, right-clicks the packet, and selects "Follow TCP Stream," expecting Wireshark to magically show them the website. A window pops up filled with thousands of random symbols. Wireshark is an analyzer, not a decryption cracking tool. If you do not possess the server's private RSA keys, the data remains permanently unreadable.

10. Mini Project: Capture an HTTP Login (Theory/Lab) #

*Note: Only perform this on a site designed for testing, like http://testphp.vulnweb.com/login.php.*

1. 1. Start a Wireshark capture.

1. 2. Go to the vulnerable HTTP testing site. Type "admin" and "password123" into the login box and hit submit.

1. 3. Stop the capture.

1. 4. Filter for http.request.method == "POST".

1. 5. Find the POST packet, expand the HTTP layer, and scroll to the bottom. Look at the "HTML Form URL Encoded" section. You will see your fake username and password exposed in bright, plain text. This perfectly demonstrates why the internet migrated to HTTPS.

11. Practice Exercises #

1. 1. Explain the forensic value of the "User-Agent" string found in an HTTP GET Request header.

1. 2. Differentiate between what Wireshark can dissect in a standard HTTP connection versus an HTTPS connection.

12. MCQs with Answers #

13. Interview Questions #

• Q: Walk me through the structural anatomy of an HTTP GET Request packet as viewed in Wireshark. Identify at least three critical headers you would analyze.

• Q: A security team suspects an employee is visiting restricted websites. The entire network forces HTTPS. How can the team use Wireshark to prove which domains the employee is visiting despite the encryption?

• Q: Contrast the analytical utility of filtering for http versus filtering for tls in a modern enterprise packet capture.

14. FAQs #

Q: Can I load the SSL keys into Wireshark to decrypt my own server's traffic? A: Yes! If you are the administrator of the web server and possess the private SSL/TLS key, you can go into Wireshark's Preferences -> Protocols -> TLS, and upload your private key. Wireshark will dynamically decrypt the Application Data packets and show you the raw HTTP traffic underneath.

15. Summary #

In Chapter 10, we reached the Application Layer. We autopsied the Hypertext Transfer Protocol (HTTP), reading unencrypted GET and POST requests to extract forensic intelligence like User-Agents and Server software versions. We visually demonstrated the terrifying insecurity of plain-text protocols, highlighting the necessity of modern encryption. We transitioned to HTTPS analysis, acknowledging that while TLS obscures the payload into Application Data, unencrypted remnants like the Server Name Indication (SNI) in the Client Hello still leak critical routing metadata to the packet sniffer.

16. Next Chapter Recommendation #

You now know how to read MACs, IPs, TCP, UDP, DNS, and HTTP. But scrolling through a million packets to find one HTTP request is impossible. It is time to master the search engine. Proceed to Chapter 11: Filtering Packets in Wireshark.