One of the challenges that computers
go through thousands of times a day
is how do we verify that the server we're talking to
is literally the authentic and authorized server that we
think we're talking to when we're using transport layer
security.
So let's talk about that in this video.
So let's start off with a banking or commerce server,
and we'll call this server 1.
And if we have a client that connects
to that server with a browser using HTTP PCZ,
well-known port is TCP443 for each TTPS WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
well-known port is TCP443 for each TTPS
which is leveraging TLS.
And during the initial negotiations
that server is going to send the client who's
connecting skin send a copy of its digital certificate.
Now that digital certificate it's got a few things.
It's got a validity date like it.
This certificate is valid from this date to that date.
So it's great.
The client can check the validity date,
make sure that the client believes the current time is
within that window.
The client can also look at the public key, which
is be needed for the secure establishment of keying
material between the PC and the server. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
material between the PC and the server.
But the question is, why should the PC believe any of that?
I mean a hacker could create a digital certificate
with a public key and a validity date, why should the PC believe
this certificate is the one that's authentic and valid?
And the answer is because this certificate that the server's
presenting also someone's called an identity certificate is
signed, and it's not signed by just anybody
it's signed by a device that this PC, the browser on this PC
trusts.
Trust means that this PC can validate the signature WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Trust means that this PC can validate the signature
and say oh yeah, this is signed by a certificate authority,
which is what that entity is called.
By a certificate authority that I trust
and as a result of that being signed
I can then trust the contents of the rest
of the digital certificate including
the public key, and the identity, and the validity
date, and all the other details that are in the certificate.
And a question that often comes up
is, well, how does this browser on this PC
know about a trusted certificate authorities,
and they are free loaded on Windows, and Linux, and Apple WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and they are free loaded on Windows, and Linux, and Apple
computers, they are preloaded with a whole laundry
list of trusted certificate authorities in the cloud.
So certificate authorities would work
like this, the bank who are ever owns the server beforehand,
before they go online they would work with a certificate
authority, they would generate a public and private key pair,
and then they would submit to the certificate authority
saying I would like our own identity certificate.
They hand over the public key, the certificate
authority people verify that server and the organization WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
authority people verify that server and the organization
really is who they say they are.
And then they issue an identity certificate
that is signed by that CA.
And that's the certificate that is then
presented to the client.
And this whole infrastructure is called
the public key infrastructure, or PKI for short.
So the way this work is that if we want the server to be
trusted, the server would participate
as a client to the PKI go out to a certificate,
authority they did a certificate have it signed by a CA WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
authority they did a certificate have it signed by a CA
that most browsers on the planet trust as part of PKI then
they are good to go.
Clients connect, they hand over the cert
it's signed by CA server.
The client because it can verify the signature
trust the details in that cert and then
they go on to negotiating the keys involved
for a private session between the client and the server.
And at that moment PC1 in this case,
has validated, or identified, and authenticated the server
due to the certificate.
Now the other half of that is the server
might one also verify the client. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
might one also verify the client.
And at that point, the client would
be prompted for something like, hey, what's your username?
And password?
Or your credentials for authentication.
So servers are authenticated via their certificates
while end users are traditionally
verified or authenticated using passwords.
Now TLS is not the only protocol it
can be used to protect traffic as it goes
over a network, a whole other family and other suite
of protocols that we use for cryptography, which includes
encryption and hashing is the family of IPsec which we'll
talk about in the next video.
So I'll see you there in just a moment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.