Hello everyone in this lesson. We will talk about SSL and
Kelly's protocols and Telus handshake.
Let us talk about HTTP protocol a
little bit.
The HTTP protocol hypertext transfer
protocol and TCP transmission control
protocol R2 separate protocols that
work together to transfer data over the internet.
So the HTTP is an application layer
protocol. As you know, that is used to transfer data
in the form of web pages and other types of files.
It is responsible for formatting and structuring the
data that is sent and received between
a client such as a web browser and a
server such as a web server.
It defines a set of rules and commands such
as get and post it declined and
server and the server used to use
to communicate with each other.
TCP on the other hand is a transport
layer protocol as you know, and it is responsible for
establishing at maintaining a
reliable connection between the
client and the server.
It ensures that data is transferred
in an orderly and error-free manner
it established a connection between
the client and server and it also breaks down
data into small packets that
can be sent over the internet.
It then reassemble the packets back into
the original data at the
other end and we know that
border transfer of HTTP data
a tcpc session must be
established in the transport layer.
and
so in terms of data transferring HTTP
runs on
top of TCP as you know, when I client
such as a web browser wants to
request a web page from a server. It
sends an HTTP request message to
the server using TCP.
So when a client sends an HTTP
requests to a server, the
requisite message is first packaged as
a TCP segment by adding a
TCP heater trade and the resulting
packet is done sent to the destination server over
the Internet the server receives the packet and
the TCP layer removes the header
and delivers the request message to the
HTTP layer the HTTP layer than
processes the request and HTTP response
back to the client, which is again packaged as
a TCP segment by adding by
adding a TCP heater and sent
to the client.
So the https, which means
HTTP secure is an
extension of the HTTP, as you
know, that adds an additional
layer of security by encrypting the
data that is sent and received between
a client and a server.
Https uses the same commands and rules
as HTTP, but it adds an
extra layer of an extra
layer of security by encrypting the data
using a secure sockets layer.
As you know the SSL or the TLs
the transport layer
security chart, but this
third bit is used to establish a secure
connection between the client and server
and it is used to encrypt and decrypt
and decrypt the data that is
sent and received.
The process of establishing a secure connection using
https starts with
decline such as a web browser. You
can think of a web browser sanding
a request to the server the server
down response with a response that includes
a copy of its SSL
or TLS shortcut the client
verifies short, but by checking that it that
it was issued by a trusted third
you could order the and that it has
not expired if the
third but is valid and the client generates
addition key and Sans it
to the server encrypted with the service
publicly.
And the servers then decrypts the
session key using its private
key and both the client at server use
the session key to encrypt and decrypt
all data sent between them.
So when a client makes a request to an https site
the browser will first establish
a secure connection to the server.
Once the connection is established. The browser
will send the request to the server
using the standard HTTP protocol.
And the server will then process to request and
send the response back to the browser, which will
then decrypt the response and display to
the user.
In comparison to http and https
provides several advantages
first, it encrypts
the data that is sand and received
which protects against used dropping and
tampering. This means that
anyone intercepting the data will
not be able to read or modify.
Second it ordained case the server
which ensures that the client is communicating with
the intended server.
and not an imposter
So this prevents fishing attacks and man
in the middle attacks?
finally
It provides Integrity protection and
which ensures that the data
hasn't been tampered with within Transit.
So in summary https is an
extension of HTTP that adds an
additional layer of security by encrypting the
data.
Using SSL and SSL or
a TLS certificate https used
the same commands and rules as HTTP,
but it encrypts the data to
ensure privacy integrity and authentication
of the server.
So the https is more secure than
HTTP protocol because it encrypts the
data authenticates the server and provides
Integrity protection.
Now, let's look at the SSL
and TLS protocols.
As you know the SSL which means secure circuits
layer and the TLs which means
transport layer security are both cryptographic
protocols and they provide
secure communication over networks. They are
used to secure a variety of application variety of
applications including web processing email
instant message of and
voice over IP. The main difference
between SSL and TLS is that
SSL is now considered to be
absolutely and insecure and
it has been replaced by TLS.
In summary SSL and theories are
both cryptographic protocol that provides
secure communication over network. But ALS
is an updated and more secure
version of SSL. It is
recommended that to use the
latest version of ALS, which is a 1.3
or better security.
And we will also investigate the
TLs version 1.3.
And now let's look at the TLs version
1.3 handshake process.
Now, let's see how the TLs handshake
process progresses in TLS version
one 1.3 the latest
version as you know, so let's
look at what happens in a PLS
and shake after TCP connection is established.
TLS handshake starts when the client
sends a client Hello message to
the server. So there is a
client Hello message from the client to the
server and
there are some extensions in this message.
And let's take a look at what these extensions are
at the structure of the clientele. Hello
packet in Wireshark. So we
will compare this this messaging with
the Wireshark packets
details.
So advise shark, we will examine handshake packets
on decrypted traffic because we
can't see many details when it
is encrypted. Also some of the handshake packets
appear.
AS application data
and
Van encrypted some of the handshake packets
appear AS application date of any
group that
you will see how it is decrypted in
the next lesson. Let's focus now the handshake
process and the structure of the packets associated
with the handshake process, and we will
look at the TLs handshake
puppets.
first and we can use
the filter expression to investigate
the packets associated with the TLs
protocol and you can use this
filter in here.
Just you can type TLS.
and
click on the enter and as you can see.
Here is a TLS protocol.
And Shake process and it
begins with the packet if the
two and we will follow the
TCP stream in clearly.
a stream in order to see the only the
handshake traffic people follow
the TCP string in here and
our process begins with
this packet the client hello packet
so that
we will follow the TCP.
stream in here on this packet and right
click you can do right click follow
and TCP stream that we
will follow
and okay, you can close this window because in
the background we have the packets now associated
with the
ALS
and shake and as you can see in here firstly
we can see the TCP handshake
packets in.
The beginning with a scene packet the
connection the communication begins with
the scene packet then.
Here is a thin egg packet.
As the second packet and at the
end of the TCP and Shake.
connection ISP handshake communication the egg
message in here so scene and
Scenic and egg messages in
here to establish a
TCP connection before the TLs and
and we have now.
By the packet 501 we
have now a TCP connection
between the client and the server.
so
and
at this point the TLs handshake
process begins
with the packet 52
and we will investigate on this packet
decline Hello message the
client. Hello Tech.
So packet 52 is
a client. Hello packet as you can see in here.
And we have the packet details as
well.
So
now we will expand the details in
here.
The transport layer security field. I
am expanding it and then we
can see the TLs version 1.3.
And let's expand it.
so in here
the version of the client hello packet appears to
be 1.0 1.0 as
you can see TLS version
is 1.0 because the
client sends this message with the lowest TLS
version it can send the Terrace
version is one point zero.
And this requirement is specified in the
RFC document of the TLs protocol and
it also shows and asks the
client also shows and ask the
TLs versions that they
can't talk to the server in this packet.
So the client says to the
server a server. I am supporting these
versions of the TLs.
And we can see the other.
Versions of the TLs which the
clients support currently and you
can find this version
information in the extensions.
And that extension is
in here the supported versions
extension. You can expand this
extension and you can
see the supported versions in
here as you can see.
So as you can see the client supports
the TLs version
1.2 at the
TLs version 1.3. In this
case, the server will choose the highest the latest
version it has.
And so it will probably choose TLS version
1.3.
And when we look at the server hello
packet.
You will see the TLs version 1.3 that
the server has chosen.
And let's look at in here you can see.
the supported version in here
And here is you can see in the server Hello
message packet. The server
says yes. I am also supporting details version
1.3 and
we can talk in this TLS version
we can talk to each other with this
TLS version as we get
before the server would choose
the TRS version 1.3.
The keep in mind that and turn back
to the clientele message again and let me
close this extensions.
this extensions and
we will expand later.
them
Let me close them now.
Not to confuse you.
and in here
the second important point
is
About the client Hello message
so we
can say that when we come
to the blind. Hello part and Shake protocol.
We see that the version TLS. Let
me
Shove you we come to the handshake protocol
client. Hello part as you
can see in here, we can see the version is
TLS 1.2.
Not the 1.0 or 1.3. We
can see the version is.
The version is 1.2. And the
client says that with this version. Hey,
as I as I am also supporting
supporting the version 1.2. I
am sending a and hello.
Hello message with this version as well
and we can see the PLS
version 1.2 in
here because because the
another version the
client has
and when we look at the another part in here,
we can see the random value a
random value declined as and the
client is sending a packet
with this random value. So
this is a very important value to us in transport layer
Security in TLS both the
client and the server Generate random values during
the initial handshake process. And so
you will see another random value in the response
of server as well.
Let's look at the server Hello message. You can
see another random value in the
on the server side
as well as you can see in here.
The server also has a random value that
it generates.
Before and and we
turn back to the client have a message. The client
also has a random value.
So these random values are used as input
to generate the session keys
that are used to encrypt and decrypt data
exchanged during this session.
Specifically the random values are used as
inputs to a key exchange algorithm
such as the DP algorithm to
generate a shared secret that is
then used to drive the session keys.
And once the shared
once the shared secret is generated. It
is used as an input to a key
Drive derivation and input to
a key derivation function. It
is the shared screen the
shared secret is used as an input
to a key Drive derivation function
and in order to
generate the session keys.
To sum up once the shared secret is
generated. It is used as an input
a key derivation function in
order to generate the session Keys. Keep
in mind.
So the session keys are used to encrypt and
decrypt data exchanged during this session.
The random values also used to
ensure that the session keys are unique and not
predictable which helps to protect
against certain types of attacks additionally
the use of random
values in the key exchange process
has to ensure that the
shared secret is also unique and not predictable
if the shared secret was predictable and
attacker could potentially intercept it
and use it to decrypted exchange
during this session.
So remember that always and to sum up
the use of random values in the key exchange
process in tears version
1.3 helps to ensure
that the session keys and shared secret
are unique and not predictable which
helps to protect against a
certain types of attacks and ensures forward
secrecy.
Don't forget that.
So when we look at the cipher streets
on the other hand, we we will
also.
See another specific and the
important information about the cryptographic
algorithms.
Maybe some of you know these algorithms
before and we will
talk about The Cypher streets in here as you
can see.
In the figure as well. We
have as a Cypher. So it's
in the client Hello message and we
will talk about The Cypher sweets
now, so in declined Hello message
and the extension of Cipher streets.
the extension of Cypher sweets
is used to indicate the cryptographic algorithms
that decline supports for the
secure connection and perhaps we may
say it is also used to indicate that
the client is willing to use for the secure
communication session. The extension is
identified by the type supported groups.
Maybe
you will notice that here is a
support group.
And you can also see the support groups
in other.
parts
supported versions
as you can see in here supported version
in here is reserved and
this version and
when we look at the Cypress streets
On the other hand we can see it.
to in here
The cipher Street support version
is in here, too.
so
supported groups information
arms from
the another part in here the other
extensions and you can find in
the state. Sorry support
versions information.
in the support versions
and you can check check it also in this part.
So let's turn back to the cycle seat
now and
We said that the extension is
identified by the type support groups
and the value.
Is a list of support groups encoded as
a list of two byte value?
So you can see.
It is a 2 byte values in here
support groups.
and supported groups in here
and you can see the support group information in
the extension supported groups.
I have told you wrongly before
I have said you can
see the support versions. It is not true. I'm
sorry.
My apologize to this and you can see
the support groups in the extension support
groups. And when we look at the
support groups data, you can see the
support group as the reserved one
in here. And this group is
also used in the cipher Street
field Cipher sweets as you can see the
same supported group in here.
and
it is encoded as a list of 2
byte values in here.
And you can check.
whether it
has two byte values in the packet
bytes pain.
I will.
Show you the packet bytes.
in here
and when we
Make closer in here.
You can see now.
Let me resize the window in here.
And you can see the another part. So in
here the supported group
encoded as a list of
two byte values and when we
click on this information, you can
see it corresponds to
the two byte values
on the packet bytes pane.
You can see in here.
when we click on this value
It is responding to bytes values
in the packed bytes.
So click on let's look at it corresponds
to the two bytes value.
Okay, the cipher switch extension in
the client Hello message.
Let's turn back to the side for sweets.
Decide for Suite extension in the client Hello
message includes a list of supported Cipher
streets in here as you can see and there
are 16 seats in here
now.
We have 16 algorithms in
here and there corresponding
chords. Also we
can see.
In here there corresponding because in
at the end of the algorithm name,
we can see their corresponding quotes
which This Server can use to
choose the suitable Cipher suite for the session.
So declined will typically include
a list of Cypress seeds in order
of preference as I told you the client
will typically include a list
of Cypher. So it's in order of preference with
most preferred Cipher Street
listed first and in here the
TLs AES 128 GCM
s h
a 256 is
the most preferred one
as a Cypress Street.
So server will choose this one.
most likely
then look at the server side
servers Hello message. We will see this Cipher
Street has been chosen by
the server.
And when we look at the chosen Cipher Suite
on the server Hello message, we will see this Cipher
Suite in here. Let's look at
this.
As you can see the cipher Suite has
been chosen as TLS.
AES 128 GCM
sha 256 or
you can see the corresponding quotes
in here 1000 300
and one and
when we look at clientele message, we
will see the disciple treat at first
in the Cypress streets part.
Let's look at the clientele.
As you can see it is the same one.
The same Cipher suite at the
first line in here, so and
we can understand that it
is listed in order of preference since
the cryptographic algorithm that the server
choose in its response message is
the first algorithm here when we look at the server side,
we could have seen the sign for
sheet and the server choose this algorithm in
its answer the children. Algorithm
is the first one offered in the client message.
We have noticed that.
Okay, let's move on to investigate the
our packet or client hello
packet and now we will
look at the status request extension.
We will investigate the
status request extension in
here and you can see the status request
in here as you
notice in here that and this
request is used to provide additional
security by allowing the
client to verify the status of a server certificate
before establishing a secure session with
the server.
And the status request extension includes
a certificate status
type value.
As you can see in here.
So it includes a certificate status type field and
which is used to
indicate the type of short with status
that the client is requesting.
One of the types that can be used is ocsp
which means
online certificate status protocol.
And which is a protocol that allows the
client to check the status of a certificate by acquiring and
by creating an ocsp
responders server.
Maybe some of you you have heard
it before and when the clients
sends the client hello packet with the
status request extension.
It includes the certificate States
type value in here with this
data to indicate that it would
like to check the status of the server certificate
using the ocsp protocol.
In here the ocsp protocol
the server if it supports
this type of extension will include the
status request will include the status request
extension in the server help packet and we
will see this extension later on the
response packet and the necessary
information to check the status of
the shortcut like the ocsp responder
URL and the ocsp responder ID
parameters. We will see
in the server response packet.
With this information when the
client receives the response packet from the
server it can use the information provided the
status request extension to
check the status of the server recertificate. This
allows the client to verify that the service sort
of code is seta valid and hasn't been
revoked before establishing a secure
session with the server.
And so this extension is
used to
check the certificate.
validation
as I told you before
and when we look at the
Client Hello message. We will move
on the clientele message and I'm closing
the status request extension now.
Now, let's look at the extension PS
key.
Or we can say pure shared
key exchange modes.
Let's expand this extension now and
we will talk about it a PSG or
a period a shared key
is a shared secret that a
PS key is a shared secret that is
established and exchanged between the
client and the server prior to
the start of the TLs session. The extension
is used to negotiate the use of PS keys
with the server which allows both the
client and server to establish station keys that are
derived from the pure shared secret
and ensuring ensuring
security of the session.
So to do this we have the PSG
exchange mode information in the
client Hello message.
and when we look at the another extension
the application layer protocol negotiation
we can see the a LPN information
in here and Alp and
protocol which means application layer
protocol negotiation.
Alpian allows the
client and the server to negotiate which application layers
protocol to sorry the
Alp and allows declined and
the server to negotiate which application layer protocol to
use for the session such as HTTP version
2 or HTTP version 1.1
without the need for
a separate negotiation process.
So this can help to improve the performance and
the security of the session by allowing the
client and the server to use the most suitable
protocol for their needs.
and the server can select the most suitable protocol
based on its available resources
and the features provided by the
protocol and here is the client
represents some HTTP
protocol in
here and
when we look at the related server response
here.
in here you can see
And they're related packet is the packet 61
that we can see the
chosen alpn value.
And we will look at the alpn value in
here.
So you can see the same extension in the server
response and other server response
packet not the server hello packet and
you can see the Alpine value
in here. We see that
the alpian preference is H2,
which means HTTP version
2.
So that is HTTP version.
That is HTTP version 2.
And let's turn back to the client Hello message again.
And we can close now the alpian fields.
Don't forget the clients.
Over an LPN protocol type
as http/2 and
the server says that hey, okay,
we can talk to each other using HTTP
to so it means that HTTP 2
is okay for me as well
and they will talk to each other
using the HTTP version 2
protocol later as you
can see in the traffic.
the http/2 packets
So, okay now we can close the alpn application
layer protocol negotiation extension
and we can close the
status request and the other ones.
We should close them.
not confuse
each other
and
let me close these ones.
Okay.
Okay. Now we will investigate the
key share, okay.
One of the most important extension is Keyshia.
and you can see also in the
illustration of the TLs and
Shake
We have a g Share value extension.
Within the clientele message and decline
is sanding a key
share to the server in the
client. Hello Tech. So let's
look at the details now.
We will.
Look at the client. Hello messaging here.
And I will close this one, okay.
Now we should talk about this point
when a client connects to a
server the server will present its digital
certificate.
To the client the shortcut includes information such
as the servers public key the side the
service domain name and the digital signature
of the certificate orderity
CA you should know
that issue the shortcut the client
uses the public key included in the sort of cut to
encrypt the random value to encrypt its random
value. It's own random value
as we can see in the random field.
In here, you can see the clients
random value.
in here
you can see the random value and
don't forget this the client uses
the public key to encrypt the random
value as we can see in the
random field and since it
back to the server.
Which then the server uses its
own private key to decrypt the
value the decryption of the value by the
server with its private key proves that
the server is in position of the
private key.
So and that the certificate presented by the
server is true and not tempered
with.
And this process is called the server key
exchange and is a
very of authenticating the servers
identity to ensure that
the certificate presented by the server is valid
the client checks the digital signature
of the ca shortcut Authority
that it should sort of good. It
does saw by using the ca's public
key, which is typically stored in a local trust
store. If the signature is valid the
client can trust that the sword
was issued by a trust CA and that
the servers identity has been verified as
a result. The client uses
the certificate to verify the servers
identity.
And we will see that the server
will share its sort of
got by this packet.
has been sent
from the server to the client and as a
result, the client uses the certificate to
verify the server's identity and to ensure that
the server is the intended recipient
of the communication.
So the key share extension when
we turn back to the teacher extension
in here.
Let's expand all of the other.
values you can see in here a key
exchange value
and the key share extension in the client. Hello
packet is used to convey the key exchange
parameters for the with this
key exchange value and for
the agreed upon key exchange algorithm.
so
And the cheese share extension in the
client. Hello packet is used to indicate the key
exchange method that the client supports and
is willing to use for the session and it also
includes in this value key
exchange value also includes the
clients public key, which is
used as part of the key exchange process and declines
publicity is usually usually
the right from a private key
that the client generates for the session the public
key is sent to the
server with this key
exchange process.
And the server uses it as part of
the key exchange process to establish a shared
Secret.
And just like the client has made
which will be used to generate
the session keys. So
after the client sends the necessary parameters
with the key exchange
value.
And the necessary options for encryption such
as cypresseed algorithms
to the server. The
server returns a response informing the
choices it has made.
With the server Hello message and
the other extensions packet
later.
and
this becomes the server
have a packet we can say that this the
server also generates a random
value in his sorry in
its server Hello message.
As you can see Server also has
a another random value.
that it generates generates and
it's important to note that the key share extension
is included in both
the client. Hello and server. Hello
packets.
As you can see the key share extension
is in a server Hello
message as well.
And the server is sanding
the key exchange
values too to the
client side with the server Hello message
and the clients.
And the clients public
key is included in the clientele packet and
the service public key is included in the server.
Hello packet.
These public keys are used to these
public keys are used to establish
the shared secret which will
be used to generate the session keys.
Keep in mind that everything after
this phase of the client. Hello
and the server. Hello packets everything
after this phase will be
encrypted.
So since everything will be encrypted
after the key exchange stage unless
you decrypt the traffic.
You will see both packets after the
handshake and the rest as application data.
You will see.
The packets after the
handshake and the rest of the traffic as
the application data.
So we can see the decrypted versions
of the packets in here. So we we
can see the another.
handshake packets as encrypted extensions, which
it can whether it
contains encrypted extensions compressed
certificate or shortcut verify and
the other package details we
can see but without decrypting the
traffic
So just like in here you can't
see these packets in clearly. So
when we
look at the the version of
Traffic without decrypting. You
can't see this packets like this.
You will see the packets AS application
data in encrypted
mode.
Let me show you the encrypted
version of the traffic to
you.
and
let me
use the same filter again.
And now we are looking the same traffic in
here.
This is the same traffic. But as you can see after the
clientele and server. Hello
messages, you can see the another handshake
packets AS application
data.
The packet with number 61
is an application data
packet. So there is no details about
the handshake process.
And you can see the details this TLS
packets. You can only see
the application data and it is encrypted mode.
It is in encrypted mode as
you can see in here. There is a there is an encrypted application
data.
normal
There is no more information.
In here, but but you can but
you when you when you
decrypt when you decrypted traffic, you
can see the details of
the TLs packets in
clearly on Russia.
Let's look at the same packet with the
decryption.
or with the description process
when we compare
This situation in here.
Sorry.
So let's look at this.
the same in the same traffic the packet
61
is
an application data packet
we can see anymore.
the details of the TLs packets
there is no details about the handshake extensions or
anything any other thing,
but when we look at the other side
the decrypted traffic
we can see
the
details of the packets in here
You can compare.
These ones easily.
So we can see the details informations. The
in the detailed information is Packet
contains encrypted instant
extensions compressed sort
kit certificate and the certificate verify
and the finished message in its own.
So
but when we look at the packet without
decryption, we
just see the application data
in the pack. There is no detail.
on the other hand
with this packet
We can see all details of the
TLs handshake packet.
We can see the all extensions.
all encrypted extensions
under the
handshake protocol encrypted extensions and
we can also see the certificate in
here.
You can see here. We can
see the compressed shortcut values and
the certificate values.
We can see in here.
But there is no information in the encrypted.
mode
so
to sum up there for we can't clearly
see the data for the rest of
the handshake without decrypting the traffic.
And as you can see the following data.
Is in the form of encrypted application data,
however, when the traffic
is decrypted we can clearly see the sort of
data sent by the server
as here.
and so the rest
of the handshake
Is visible in here the rest of the handshake
packets is visible in here.
You can see this packet.
Is sent by the server and the other
one is sent by the client and we
can see these packets these handshake
packets clearly.
But when we look at the other side, we only
see the application data and the
summarized information about packets
about the TLs packets in
here.
So you can see only the application data
in here you can see.
And there is no more.
So you can see
also the HTTP packets
clearly.
You will see the HTTP as
packets.
as the TLs packets as TRS packets
TLS application data packets
And you can see the HTTP HTTP
to packets in.
the encrypted traffic but you can
see the HTTP two packets, which
means HTTP s
which assigns the TLs encrypted TLS
packets in the version HTTP
2 you can see the http/2 packets
in here clearly, but you can't see in
the encrypted traffic then and
by sending the server certificate data in here.
By sending server certificate data. It says to
the client. Hey, I am the server you are
looking for and as you can see and Shake
protocol extensions.
are encrypted
For example, we see that the LPN selection.
is in here
LPN selection in here HTTP
HTTP tool
and the certificate data is given in compressed.
Mod in compressed format and
we see that it uses the
broadly algorithm for
compressing which was offered by the
client as a compressed option to the
server.
and the following contains
necessary some some necessary
information following data
contains the necessary certificate information.
We see the version and
the serial number in here.
Let me show you.
in the shortcut field, you can
see the version information and the serial
number of the of this shortcut which
is sent by the server and
on the other hand
here is the selected signature
all your
team in here.
the selected
the selected signature algorithm is
in here.
We can see it and we will see important information
about the validity of
this certificate under the validity field.
So in here not before
value and and not after value, let's talk
about this.
In did not before section.
We see from which date this
certificate is valid.
So time data in UTC time
format format and it was
a valid certificate as of that that
date.
And here is the expired date
in here is the
expired date of shortcut and
the end time is given under the
not after field so
and here.
We see the public key.
Failed also we can
expand this window now again to see
the clearly.
Okay, now we can also in here the
on the another server message.
And before before the
investigation of this packet,
let's look at the inspiration for
this packet.
First we have we have seen a
decline Hello message from the client
to the server side then.
the server sent its
server Hello message with the
same key share extension
to make a key exchange
process and a
chosen Cipher Street it gave
a anformation about
about its Cypher Suite that it
has chosen and then we see
the another packet after
the server help message in
here.
with this packed
you can see in here. Another packet
is in here and it contains encrypted
extensions and the
compressed certificate and the sort of
got verify and the finished.
So before this packet, we have
a key exchange process.
By both client and the
server side.
And after the key exchange process nor we
have a process about
the server perimeters and
the Authentication.
So in this in at
this point, the server will
make a make an authentication
about itself.
So and it will give the information about
it sort of code and the other parameters in
order to the
client.
can can make an authentication that the
server is the
server is the true one is the is
developed is the server that
it is looking for and when we
look at this packet, we have some another extensions
in its so
Now let's turn back to the subject public
key for area and
when we look at this field.
We should say something about it.
and
we see the public K under this field
as you can see in here.
The server also has its
own public key information in
here, but you can see this
information within the encrypted
traffic.
You can see this details.
Okay, and now we will look at the status request.
in here
the state's request
Let me find the status request extension
in here.
And we will find.
the
status request
now we will talk about the state's request
extension in here.
So as you can see.
We have some information about State circuits and
maybe you can remember the client
has been made a request
about the status of the server certificate.
And now the server is responding about
its own status about its
own certificate status to the
client and the response
is in.
Status request extension. So
let's investigate the response now
in here and
in status regards there is the response given
by all CSP regarding the
validity of the certificate. If
you remember I have told you client request
and answer from oscp protocol
which means online certificates protocol
whether the shortcut is valid or not. So here
we can see the details of the
answer and I am expanding the
in here
I'm expanding in here.
the TBS response data
in order to see the details about response about
the response of the ocsp protocol
and you can see the responder ID
information and let's
look at the responses.
field
we have a single response in
here and
As you can see the certificate the certificate
status is good.
So the ocsp protocol
says that this certificate
status is good to
the client.
The ocsp says to the
client. Hey, the server certificate
States status is good.
So and
the status of the sort of cut validation
has an update time.
As you can see in here.
And we also see this update
as the date these status
information was issued in here.
And when we look at the next update.
We can see that it will be valid for.
7 days and the certificate States will
be updated again on the date the
next update date.
So you can find many more details about
the certificate in here and to
sum up the server shared its
certificate with the client by sanding this
encrypted normally
in encrypted mode by
sending this encrypted
packet and said that hey
I am the server you are looking for.
So the server shared its certificate
to in order to say that.
Hey, I am the server you are
looking for.
And that includes a handshake finish
message in here.
As you can see I finished message is
in this packed.
And it means the handshake
will be completed.
So let's turn back to the illustration. There
is a finished message
in our packet.
And we look at the next one the client also.
declined also will send another certificate verify
message and the finished message
as a packet and it will
check the authentication of
the server.
By by checking the
information that that
is sent by the server in the
in the previous packet. So and they
send to each other change Cypher
change Cypher
message change. Sorry they
sent to each other a change Cypher
spec message which signals
that their session case is being
activated and you can
see in here. The client is
signing a change sign for
spec message and it means
and their session Keys
is being activated so
The next packet is sent by the client to
the server which contains a handshake finish message
in here.
And this completes these companies
the sorry and this completes.
And this completes the TLs
handshake?
so by this message
the TLs handshake is being completed.
So now let's look at the next illustration.
At this point the TLs handshake is completed
now.
Bye.
By the client is sending
the last message the last
TLS handshake message.
So we see after this
stage data can be exchanged between
the client and the server
and we see data exchange
as TLS version TLS version
1.3 application data in
network traffic.
You can see.
the application data
after the TLs handshake is completed.
so you can see these application data
packets in the
Traffic on Wireshark also as well
and as you can see after the
TLs handshake there's an
HTTP 2.
In the decrypted traffic we can see like that. We
have an HTTP to packet in
here and the server is sending
a packet with the
protocol HTTP to to the
client then.
The client signing an
egg message. Okay. I have received your
http/2 packet, and then
the client is
sending another HTTP to message
in here. So in this
message, we can see
As clear text the hypertext
transfer protocol data in
here.
Empty after this http-2 messages
declined is
sending a get message and a
HTTP get message get request message
to the server as you can see in here,
but you can't see these packets clearly
without decrypting. Let's
look at the
encrypted traffic in here
to the same packet the packet with the
get a message.
Http/gate message is 72 and
we can see this packet
in clearly here. But when
we look at the encrypted traffic.
to the same packet
72
You can see.
The protocol is TLS version 1.3.
Not the HTTP 2.
We don't know.
Which protocol is used in here?
HTTP or another one? We we don't
have this information in here because this
packet is encrypted by the trailers.
And we can see only the
protocol TLS version 1.3 and
as data we can see only the
application data.
Information there is no more in here.
But when we look at the traffic that that
has been decrypted before
we can we can see
this packet we can
see that this packet is an is an HTTP 2 packet
and it is a it is
a get request packet.
And okay, then we can
investigate the rest of
the traffic.
In this way.
and we can see the
other packs
so that's all about the TLs handshake careless
version 1.3 and shape process.
And we will investigate the decision of
of the http/s protocol on
the next lesson.
That's all for now.
See you on the next video.