[Contributor: Ginny Spicer]
So you thought you'd get to that site using HTTP, eh?
It has become an increasingly common practice to redirect from using HTTP to HTTPS after the TCP handshake. Even if this isn't the core focus of your trace file analysis, you are bound to see it eventually. This practice should be understood in order to differentiate it from other types of redirection. In this blog, we'll walk through a redirection to HTTPS and see this process in action. Feel free to grab the trace file and follow along.
Trace File: http-dictionary.pcapng
The first packets in the trace file resolve the IPv4 address for www.dictionary.com.
Note the CNAME (canonical name) response in Frame 2. It appears that www.dictionary.com is hosted by Fastly - a popular cloud-based content delivery service that hosts this site on edge servers.
So far, so good.
In Frame 3, the client sends a SYN packet to port 80 of 22.214.171.124 (the Fastly server's IP address). The target port is 80. The client wants to make an unencrypted connection to the Fastly server.
Frames 5 and 6 complete the TCP handshake. [Extra Credit 1: What's the Initial Round Trip Time between the client and the Fastly server? See the end of this blog for the answer.]
IPv6 Resolution Failure
In Frame 8, our client attempts to resolve the IPv6 address for www.dictionary.com, but, as we see in Frame 9, there is no IPv6 address associated with that host name.
In Frame 10, the client requests the default page ("GET /").
In Frame 11, the server sends the ACK to the GET request.
In Frame 12, the server responds with a 301 Moved Permanently Status Code.
Let's look inside the HTTP section of Frame 12.
Whenever an HTTP server sends a reply with a Status Code starting with "3," it is redirecting the client. Within that redirection packet, there should be Location field to indicate the desired target location. [Extra Credit 2: What display filter would show us only HTTP replies containing Status Codes that begin with a "3"? See the end of this blog for the answer.]
The server could be redirecting the client to a subdirectory or another server. In this case, the server is redirecting the client to establish a secure connection to https://www.dictionary.com (HTTP over TLS).
Frames 13-16 indicate the client and server are finished (FIN) using the port 80 connection.
In Frames 17-19, the client begins establishing a connection to TCP port 443.
Look for the Server Name information. It's easiest to find if you expand the Packet Bytes pane and click on the visible name. Wireshark highlights that field in the Packet Details pane. [Hint: I'd right-click on this field and select Apply as column.]
This client has been successfully redirected to a secure connection for www.dictionary.com.
As quickly as that, the client has been successfully redirected to a secure connection for www.dictionary.com.
Since redirection from HTTP to HTTPS is so common to see, it is useful to be able to identify it at a glance and now you can! Why not check out some of my other blog posts or sign up for the newsletter while you're here?
WANT TO LEARN MORE? We offer on-demand, online and instructor-led courses on Wireshark and TCP/IP communications! Check out the links under "Training" on the menu for more information and sign up for our biweekly newsletter to know when future blogs, events, or freebies are announced. Every new sign up also gets five free Wireshark labs!
Extra Credit Answers
Extra Credit 1: 0.010904 seconds
Extra Credit 2: http.response.code > 299 && http.response.code < 400 would be one filter option. Another would be http.response.code >= 300 && http.response.code < 400. There are obviously several variations possible for this filter.
Try yours on the http-dictionary.pcapng trace file.