So let's go ahead and get a closer look at the QUIC
handshake process in this lab.
This time, we're going to use Lab2, the QUIC Handshake,
so open up that trace, and let's dig.
Again, you're going to have to go into your TLS preferences,
and you're going to have to add the key to decrypt this session.
So there's a reason why I keep doing this to you because it's something
that I want to make sure you get a lot of practice with,
so opening up a trace file and making sure that you have the right keys.
So now that we have the right keys loaded,
and you're going to know that if in the Protocol column,
you see HTTP3, and also, in the handshake info,
we'll see some specific stuff once we really get in there.
So we're going to take a look at this first packet that
comes over from the client to that server,
and this is called a QUIC Initial packet,
okay, so we're not yet technically in our handshake.
This is just the client basically knocking on the door of the server,
saying, hey, are we're going to do a QUIC?
Is this good?
So in that information, if we look in our details, we have our Long Header.
Now, what this allows the client to do is to identify the connection.
Now, in our module, we haven't yet talked about connection IDs.
We're going to get there in just this next clip.
But for now, this is where we identify that connection.
Now, if you come down here, this payload,
this can now be dissected as TLS, Record Layer,
Client Hello.
So this is the client sending its Client Hello.
This is a CRYPTO frame within QUIC.
And if we come down here to the Handshake Protocol,
let's go ahead and expand this out,
and this is where we can see the client advertising certain
things and extensions to that server.
So if we come here, if we notice here, TLS 1.2,
now that's a common thing that we see in our TLS handshakes,
just because if there's any middle boxes that don't get support,
TLS 1.3,
or if there's any issues coming up to speed on that version
for any network devices along the path, what this does is it just says,
hey, TLS 1.2, that's what this really is,
but in fact, each endpoint is actually using TLS 1.3.
Now, the way that we know that, if we come down to supported_versions,
if we expand this,
we can see that the client is only offering TLS 1.3 to the server.
So sometimes that's a point of confusion for people.
They say, hey, wait a second.
Supported Version is 1.3, but the advertised version up here is 1.2.
What gives?
And, again,
this is just to get through firewalls or middle boxes that try
to be helpful that don't yet support TLS 1.3.
It's just a way around that limitation for some older or legacy devices.
Okay, so let's do a little bit more digging.
What else do we have in here?
We also have our server name.
Let's go ahead and expand this.
So here, we have the SNI.
So in this handshake, we can see that that's available to us.
So here's google.com.
That's who we're trying to connect to.
Also, if we come down here, we see our application_layer_protocol_negotiation,
so ALPN.
If I open that up, here, the client is advertising to the server,
hey, I'd like to use HTTP3 over draft 29 QUIC,
and that's what I'd like to do here.
And one other thing at this point, let's go ahead and take a look at,
let's go down to our quic_transport_parameters.
Now, we're not going to dig too deep in the weeds here,
but this is basically where the client identifies to the server the
different transport parameters that it can support,
so the amount of streams bidirectional that we can support,
the max_stream_data that we can support,
and also our max_idle_timeout,
so different values that will be supported for this connection.
Now, you'll also notice on the client side,
if I just collapse this first QUIC packet,
we can also see that there's a padding packet here too.
Now, with QUIC, this has to be here, at least for this version.
So we've got a pad this thing out.
And in this case, we have to have this minimum length of 1399.
If this packet was sent to the server, and it says, hey, you're using draft 29.
Where is your padding?
If we didn't have the padding, if it was a really,
really small frame, then the server would say,
you know what?
You're not really using draft 29.
I'm not even going to respond to this.
So this has to be here.
But let's go ahead and take a look at what the server does.
So 31 ms later, the server comes back with its Initial packet.
Let's go ahead and expand this out.
And in this case, the server, it's using a Long Header as well,
so it's identifying the full Connection IDs,
this is Packet Type: Initial, and in that Initial packet,
there's a couple of things that are happening here.
First, it's acknowledging the packet that was sent from the client to the server,
so this is ACKing that first Initial packet from the client.
Now,
we're going to dig more into that in our next module where we
actually get into troubleshooting with Wireshark.
Also, the server is sending back to us a Server Hello,
so let's take a look at that a little closer.
Here's our Server Hello, TLS 1.2, the Cipher Suite that was selected,
the actual version that we're using is 1.3,
and the rest is padding.
So this is all we got back from the server, this Initial packet.
And in packet number 3, we can see this is the client,
and all we have in here is an acknowledgment.
This is just the client ACKing the Initial packet sent from the server.
This is no more data that's being sent.
And really, we only have a partial response from the server at this point.
All we got was just the version of TLS that we're going to use,
the Cipher Suite.
But let's go ahead and key in a little closer on Frame number 4.
Now, this is coming from the server back to the client.
Now, this time, it's not an Initial packet.
Now, we're into the actual QUIC handshake.
Long Header, so we see our Connection IDs.
But if we come down here into the TLS information,
we see multiple handshake messages, so this is a lot more data in here.
Now, if we did not have the keys,
if we did not have the ability to decrypt this conversation,
we would not be able to see this information.
So let's go ahead and dig deeper into this handshake.
This is where the server says, that's no problem, ALPN.
Let's go ahead and use HTTP/3 over draft 29 QUIC.
Sounds good.
Here's also my quic_transport_parameters,
so we saw this from the client to the server.
Now, we see the response, and this is where we see initial_max_data.
This is where we see idle_timeout.
This is where we can see the max number of streams.
So this is setting up those parameters of the QUIC connection.
And also, in this part of the connection,
the server is sending part of the certificate,
so it's just a fragment of that certificate.
The rest of that certificate is available for us in packet number 6,
or that's where it's fully reassembled.
So packet number 5, if we look at that, this is also a handshake message.
This is another section of the certificate.
And finally, in packet number 6, in our trace,
if we come down, this is the last part of our certificate,
and then we can say Finished.
So at this point, the server is basically done with the handshake.
And if we look at our timing, really, as far as network round‑trip time,
31 ms, we're only 44 ms in, so we're not even at 2 round trips just yet.
So let's go ahead and take a look at what the client
does with all this information.
Here, we can see the client handshake,
so this is the client acknowledging that certificate that came back.
Here, we see the ACK, and it's able to acknowledge the packets that it received.
And immediately after this,
the client then can start to actually use this connection.
This is where we start to see HTTP3.
So this is where we start to see the streams being set up,
and then data can begin to move.
So here, time to first bite.
So from our Initial packet to where we can actually begin,
sending application data was 53 ms.
And if we take a look at the response from the server,
the server begins responding.
Here's a full‑sized packet here with actual data in it.
This is where we can see that was 95 ms.
Now, just a note for you, because, again,
QUIC is emerging, it's possible that you could look in your trace file,
you might see some slightly different things,
maybe a different use of the Initial packets,
maybe you see a few more handshake packets, but this is a good idea, generally, of how QUIC establishes those connections.