In a real-world example, a user may be sitting at home browsing the internet – IE going to web pages, where the web page is hosted on AWS.

In fact, the majority of websites default to using HTTPS.

Transport Layer Security (TLS) provides the encryption for HTTPs traffic with algorithms such as SHA-256. A Wireshark packet capture will not natively display the HTTPS packets, but if you have the server private key, you can decrypt the capture and view the contents in Wireshark. Obviously, a public website won’t share the private key but if you are building your own server/website, you can decrypt the contents of HTTPS using the private key.

In a previous post, MadPackets walked-through an HTTPS request to a static website hosted on AWS S3. So, the walk-through below will focus on HTTP, so we can view the details of the HTTP packets.

Stages in Accessing an HTTP Web Site

There are 3 main stages when accessing a website:

• DNS
• TCP
• HTTP

Stage 1 – DNS

We put in the website URL in the Chrome browser and the first thing that happens is the DNS lookup.

By filtering on udp.port == 53, we see 4 DNS packets. In order there is an A record request, AAAA record request, an A record response and AAAA record response. A records resolve IP version 4 addresses to domains and AAAA records resolve IPv6 addresses to domains. Also note the DNS transaction is between the Macbook Air and the local Gateway at 192.168.1.1. The local Gateway will then recursively resolve the DNS lookup (IE do all the work) and reply to the Macbook Air with the IP Address of the website. Highlighted in red is the type A record with IP Address 52.216.240.196 – the website address.

Stage 2 – TCP

TCP is the second stage of accessing a website and this setups the communication so we can transfer the HTTP requests. Remember, TCP requires a 3-way handshake to setup a TCP session and you can identity the 3-way handshake using the following parameters.

[By default, Wireshark converts all sequence and acknowledgement numbers into relative numbers. This means that all SEQ and ACK numbers always start at 0 for the first packet seen in each conversation.]

This HTTPS Wireshark blog goes over the 3-way handshake.

Stage 3 – The HTTP Request

When using Google Chrome and HTTP, you’ll see a “Not Secure” tag prepending the URL window, as noted below.

This is a simple website so we can more easily parse through the Wireshark output.

A quick summary and then we’ll look a little deeper.

• Frame 61: This is the HTTP GET Request
• Frame 68: This is the HTTP GET Response
• Frame 74: This is the HTTP GET Request for a favicon.ico
• Frame 77: GET Response that the favicon.ico request is Forbidden. Ouch!

HTTP GET Request

Frame 61 shows a couple key data points:

• Request Method: GET
• Request URI: /HelloWorld.html
• Request Version: HTTP/1.1
• Host: cloudsmart-testbucket.s3.amazonaws.com\r\n

You can learn more detail about HTTP Requests here.

Highlighted in light blue is that the GET Response is in frame 68.

Let’s look at frame 68

Since we’re using HTTP, Wireshark will display the contents of the HTTP GET Response in the content display window.

The interesting thing with a successful GET Response frame is you can see the contents in the decode window.

Frame 74:

Google Chrome requests a favicon.ico when issuing GET Requests. Favicon’s are the little images that show up on your browser tabs.

Frame 77:

If you don’t have a favicon.ico file in your website file directory, the HTTP GET response will include error code 403, indicating that the request is forbidden accessing ASW S3. Technically, the proper response would be a HTTP 404 message indicating that the favicon.ico file was “Not Found”. Instead, AWS returns an access denied message which is neutral in terms of the existence or non-existence of the favicon.ico file.

It would be nice to have a knob to turn off favicon.ico requests from the browser. To resolve the favicon issue, get a picture, save it as favicon.ico and upload it to your website.

That’s it. This webpage decode walked through a Wireshark analysis connecting from a home office to an AWS hosted static web page, which is a pretty typical, real-world, internet transaction.

Interesting findings:

• I ran the HTTP GET Request about 12 hours later than the DNS Lookups. Notice that the DNS points to 52.216.240.196 and the Wireshark HTTP GET Requests go to 52.216.169.83. There is no issue, AWS is so dynamic that IP’s change frequently.
• Know the TCP 3-Way Handshake Table
• Google Chrome issues a HTTP GET favicon.ico request, whether you like it or not.