top of page
  • Writer's pictureLaura Chappell

HTTP to HTTPS Redirection

[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.

DNS Resolution

The first packets in the trace file resolve the IPv4 address for

Note the CNAME (canonical name) response in Frame 2. It appears that is hosted by Fastly - a popular cloud-based content delivery service that hosts this site on edge servers.

So far, so good.

TCP Connection

In Frame 3, the client sends a SYN packet to port 80 of (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, but, as we see in Frame 9, there is no IPv6 address associated with that host name.

The Redirection

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 (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

As quickly as that, the client has been successfully redirected to a secure connection for

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.

1 Comment

Debra Lee
Debra Lee
May 31, 2022

Because HTTP to HTTPS redirection is so prevalent, it's helpful to be able to spot it at a glance, and you can now! While you're here, why not read some of my other blog pieces or join up for the newsletter? drift boss

bottom of page