Now, let's go ahead and take a look at what the server sent back to us.
So I'm going to come up, and I'm going to select the next packet down,
I can see this is coming from the server back to the client,
and just because I'm interested,
I'm going to right‑click the Time value here and Set/Unset Time Reference.
And here, I can see I have 31 ms between the first and the second packets.
That gives me my network round‑trip time.
So here, the packet comes back from the server.
This is the Initial packet coming back.
And if we take a peek at the QUIC Information,
I'm going to condense this just so we can see the whole frame in context,
so here, I have just one QUIC IETF header,
and I'm going to go ahead and expand that.
Now, the server is coming back, saying, okay,
draft‑29, that's the version of QUIC that we're using,
and here is our Source and Destination Connection identifiers.
We saw those in the first Initial packet that came from the client.
Now, coming down here, you'll also see that there's an ACK part of our header.
Now, Largest Acknowledged is 0.
Now, if you remember, in the first Initial packet,
the client sent to the server a packet number of 0.
Well, here, the server is saying, I received that 0.
So this is QUIC's way of acknowledging a packet that's been received.
It does it by the actual packet number.
Now, moving on in the header, we can see the response for the Server Hello.
So here's our Server Hello, and the first part of that Hello message,
this is where we identify the Cipher Suite that we're
going to use for this connection,
and this is where we exchange our Key Share info.
Here, we have our x25519 Key Exchange,
so this is now a value that will be used with the encryption.
And coming down, I can also see that the server will support TLS 1.3.
Now, the thing about TLS 1.3, from this point forward, we're encrypted.
So remember, when the client sent to the server the Client Hello,
within that Client Hello, we had the QUIC transport parameters,
almost like the TCP options, if you will.
But here, we don't see those coming back from the server,
the QUIC transport parameters,
and that's because those are going to be encrypted.
So right after this point, we cut straight to padding,
so the server went ahead and padded out the rest of its Initial QUIC packet that
is sent back to us to make sure that it was at 1399 bytes.
Now, in a similar way, with the TCP three‑way handshake,
here's an Initial packet coming back from the client,
and it's basically acknowledging, there is the Largest Acknowledged: 1,
it's acknowledging that Initial packet that was just sent from the server.
So there's no extra information that's being sent from
the client to the server right now.
This is simply a client‑side acknowledgement.
Now, since we don't have the TLS decryption keys loaded right now,
the rest of the information is going to be encrypted.
And really,
I wanted to first show you how this information is
now encrypted from this point.
That speaks to the security of QUIC.
Really,
we can only tell about the transport parameters just from that
Initial packet that's sent from the client.
That's the only time that we see right off of the wire
in clear text some of the parameters.
But after that point, everything else is going to be encrypted.
So if we take a look at packet 39, this is coming from the server.
Likely, this is the rest of the credentials.
This is the rest of the TLS handshake.
This is also the QUIC transport parameters.
But since we don't have the session keys at this moment,
right now, Wireshark can't decrypt it. Now,
scrolling down, even deeper down into our conversation,
we can see the rest is protected payload with a simple connection identifier.
There's not a whole lot else we can get off the wire
unless we can decrypt this conversation.
So moving forward in our course,
I'm going to show you how to decrypt QUIC, and more about these
transport parameters, and what they mean, and why QUIC is such a resilient transport protocol.