Welcome to the TCP web analysis session.
During our web session analysis,
we'll be covering a web session from its inception to its end,
but before we begin with the dissection,
let's drop to a video where we can see a visual
representation of what we'll actually be decomposing.
Welcome to Wired Brain Coffee's Intranet page.
This page is currently under construction and not meant for
dissemination outside the IT department of Wired Brain Coffee.
Consider this an Alpha build.
From the screen presented to us, it's a pretty basic page.
Actually, it's got a real 90s flair to it with simple graphics,
text, and buttons.
It shouldn't be too complicated to decompose, right.
Before we begin decomposing our simple web page,
let's review some new acronyms that we'll encounter
during our session decomposition.
We're already familiar with the ACK and SYN acronyms.
Try saying that five types fast.
But within this session decomposition, you'll encounter a couple of new acronyms.
The first one that you'll encounter is the Get command.
The Get command is a download request for a file.
The second acronym you'll encounter is the 200 OK,
and the 200 OK signifies a successfully located resource.
And with that, our acronyms have been successfully covered.
Let's decompose our HTTP web session.
Starting with session 1,
we can see the source computer of 192.168.56.1 is utilizing a
source port of 54,834 and it's initiating a three‑way handshake
with the web server of 192.168.56.2.
We can verify that this is the first portion of the three‑way
handshake due to our flag of SYN being activated along with the
sequence and acknowledgement numbers of 0.
Also, take note of the window size of 64,240.
Watch how it's adjusted through the various sessions.
You should also be cognisant of the changing check sum values.
We can also verify that the destination is most likely a web
server due to Port 80 being the destination port.
In session 2,
we can see the web server of 56.2 has responded to the
three‑way handshake with a SYN‑ACK of its own.
Notice how the ack number has been incremented by one.
This is due to the acknowledgment flag now becoming active.
From within session three,
we can see the requesting PC of 56.1 completing the
three‑way handshake with an ack of its own.
Notice how the sequence number and acknowledgement numbers are both now at one.
In session 4, we can see another three‑way handshake is starting,
utilizing the source PC of 56.1.
Also,
notice how the source port has changed to 54,835 and the sequence
and acknowledgement numbers are now both at 0.
We are now going to have two active sessions to one machine.
Can you imagine how many sessions are running on a website like YouTube?
In session five,
we can see the web server of 56.2 replying with a
SYN‑ACK to the requesting PC of 56.1.
Notice how the acknowledgment number has increased by one.
Within session 6,
we can see the source PC of 56.1 responding to the
SYN‑ACK of 56.2 with an ack of its own.
Notice how the sequence and acknowledgement numbers are both now at one.
The second three‑way handshake has now been completed.
In session seven,
we finally move past the boring three‑way handshake stuff
and we're onto our actual TCP web session.
The source PC of 56.1 utilizing the source port of 54,834 is now asking
the web server of 56.2 for its HTTP 1.1 information.
This request asks for various information about the web
server and the website that it's hosting.
And in session nine, we'll see some more of that information.
It's important to notice the flags in the session,
though, the acknowledgment flag and the push flag saying don't buffer this.
You should also note how the sequence number has increased
from 1 to 449 for its sequence number.
And this is due to the source PC sending an actual data payload of 448 bytes,
to be exact.
And if we scroll down, we can actually see some of that information being sent.
Let's review some of the more important factors we can see that
we are attempting to utilize the host of 56.2,
and from the user agent string,
we can see our operating system is Windows 10 64‑bit.
From session eight,
we can see the web server of 56.2 is acknowledging our get requests.
Also notice how the acknowledgment number has been incremented to 449
to match the sequence number from session seven.
Session 9 is the web server of 56.2 saying,
okay, here is the requested information and there is a ton of information,
and if we scroll down, we can actually see everything that's requested.
Essentially, in this session, it's all the HTML backend of the site,
text, fonts, image locations, it's all here.
Within Session 10,
our source PC of 56.1 Utilizing the source port of 54,834 has
successfully received the payload of the web server.
The source PC of 56.1 is now going to request the image
of buttons.jpeg and I have a sneaky suspicion that those
are the buttons to the site.
Notice how the next sequence number has also jumped to 804.
Wow,
it's really starting to climb and we're not even
that far into our session analysis.
Huh.
Well, that's odd.
Session 11 sequence and acknowledgement numbers have
decreased in size by quite a bit.
I wonder what's going on with us.
And the simple answer is that this is the first session for our
second established session in our capture.
If we're trying to be specific,
it belongs to the SYN‑ACK exchange in sessions four,
five, and six.
You should also notice how the source port is 54,835, not 54,834.
From within session 11,
we can also see it's attempting to download the file of coffee‑orange.jpg,
and I don't know about you guys, but orange coffee sounds absolutely disgusting.
In Session 12,
we can see the acknowledgment from the web server of
56.2 for the prior session of 11.
So this is the acknowledgment for the request of the nasty coffee‑orange file.
In session 13,
we can see the acknowledgment for the web server of
56.2 for the prior session of 10.
So this is the acknowledgment for the request of buttons.jpg,
and we can verify that this session belongs to the button.jpg
request due to the destination port being 54,834.
It's also important that we highlight the section of
TCP segment of a reassemble PDU,
meaning that this image is being broken down into sections for transport.
Notice how the data size is 1460 bites.
From within session 14, we can see the web server of 56.2 is sending more data,
1,460 bytes to be exact to the destination PC of
56.1 utilizing the port of 54,834.
At Session 15,
the source PC of 56.1 is acknowledging the data being sent in session 14.
Remember,
we don't acknowledge every piece of data sent as this has
helped to mitigate traffic congestion.
Through session's 16 through 24,
we can see the requesting PC of 56.1 utilizing port 54,834 receiving data from
the web server of 56.2 and acknowledging the received data.
At Session 25 we can see the web server is sending a 200 OK response to
the requesting PC of 56.1 utilizing the port of 54,834.
And remember, the response of 200 OK means the data was successfully sent.
Awesome.
One image down, one to go.
During Session 26, we'll now be utilizing the destination port of 54,835,
so this is our second established session.
Again,
notice that the TCP segment of a reassembled PDU indicating that this
packet is being broken down into more manageable sizes.
Session 27 is identical to session 26,
except for the actual data that's being sent.
During session 28, we can see the requesting PC of 56.1 acknowledging session 27.
Please remember, though, we don't acknowledge for everything,
so the ACK for 27 would actually apply to session 26.
You should begin to notice a trend that's starting to
develop as the web server sends two pieces of data and then
the ACK is sent from requesting PC.
I don't want to bore anyone anymore, so let's skip to the end of this session.
Wow!
We jumped all the way to session 54.
During session 54,
we can see the web server is sending a 200 OK message indicating a
successful transfer of the coffee cup image.
At session 55,
we can see the requesting PC of 56.1 utilizing the source port of
54,835 is replying to the 200 OK message with an ACK.
And with that simple exchange, our image has now been successfully downloaded.
Huh.
From within session 56,
we can see our other source port of 54,834 is
responding with an ACK to session 25.
Let's navigate all the way back to session 25 to see
what we're actually responding to.
Okay,
it appears that this was an acknowledgment for our first
image download of the buttons.jpg file.
And with that, now all of our images should successfully be downloaded.
During session 57,
we can tell that we're getting really close to the end and we can tell this due
to the web server initiating a FIN with the FIN ACK flags.
Looking closer at the session,
we can see that the FIN ACK is specifically attempting to
terminate the session belonging to the destination PC of 56.1
utilizing the destination port of 54,834.
Also notice how there is no TCP data during this session.
Remember,
session termination doesn't require the exchange of data besides the flags.
So this is similar to our three‑way handshake in which a session is initiated.
At session 58,
we can see the requesting PC utilizing the source port of 54,834
acknowledging the request to end the session with the web server.
Now you maybe thinking to yourself, Aaron, I know what's next in session 59.
Port 54,834 is going to end.
Well, I've totally tricked you.
Actually,
the Web server has now begun to terminate the session
belonging to port number 54,835.
So if we examine this session,
we can see that the flags of FIN and ACK are now active.
Also, notice again how no data is being exchanged.
From within session 60,
we can see that the session belonging to port number 54,835 is
acknowledging the FIN ACK flags from session 59.
During session 61, we're going to mix things up.
It's time to confuse you even more.
From within this session,
the session utilizing the source port of 54,834 is now
sending a FIN ACK to the web server.
So if we remember, the session termination is similar to a four‑way handshake,
so we should have only one more ACK to finally end this session.
Session 62 is here to disappoint you as nothing is officially ending yet.
During session 62,
the source port of 54,835 is going to send a FIN ACK to the web server
to formally end its data exchange with a web server.
So again,
we should only need one more ACK from the web
server to end this session as well.
Finally, from within session 63,
we've officially ended the data exchange for port 54,834 as the web
server has finally ACK to the FIN ACK in session 61.
Only one more session to go.
All right, everyone, we made it.
It's the last session, session 64.
From within this session,
we can see that the web server has responded with an ACK
flag to the destination PC of 56.1, which is utilizing the port of 54,835.
And with that, our traffic to the web server has officially ended.
As you can see, even a basic website,
such as Wired Brain Coffees beta intranet has a ton of
things going on in the background.
Can you imagine doing a full session analysis for an
encrypted website like Facebook?
You better grab some food and water for your month's long journey,
and as a side note, you can also see that data exchanges are not linear.
It's quite common to find data that is not contiguous, so just be cautious when you're doing an analysis through Wireshark.