As we look for ways of protecting
our data and our traffic, one method is use secure protocols.
And one of those is the family of SSL, Secure Sockets
Layer/TLS, Transport Layer Security.
I'd like to chat with you in this video about exactly that.
And to bring this home, let's imagine
that you and I are at this computer
and we're going up to our favorite banking website
or we're going to a shopping website, what have you.
And as we see in our traffic, we don't want this traffic--
as it goes over the internet which is definitely WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as it goes over the internet which is definitely
an untrusted network--
we don't want that traffic if someone eavesdrops on it
to be able to see what's in it or perhaps manipulate it.
Maybe we have credit card information or perhaps
we have other sensitive details in banking
that we simply don't want anyone to be able to look at.
So we could use a secure protocol like SSL/TLS.
And the reason this is so popular
is because that functionality is built in to virtually
every browser on the planet.
And it basically goes like this, when the client connects
to the website, the client, our browser in this case
wants to validate that that's the correct website. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
wants to validate that that's the correct website.
This really talking to, let's call it bank 5.
We want to verify bank 5.
And the way they do that is through HTTPS,
which behind the scenes is using SSL/TLS.
The bank is going to give us, the client,
a copy of its digital certificate
and in that digital certificate it has a public key.
Not just any public key, but it has the bank's public key.
So when PC1, when we receive that, our browser says, "hmm.
This is the certificate I'm now getting from this bank. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is the certificate I'm now getting from this bank.
How do I know it's valid?
How do I know it's not a hacker who's
giving me its certificate with the hackers public key?"
And the answer to that is, we are
going to see if this certificate the bank is sending us
is signed by someone that we trust.
And the way we're going to do that is beforehand
our computer has a list of CAs Certificate Authorities
and if this PC receives a certificate from the bank
and sees it signed and it can verify that signature
and say, "Woop.
Yeah.
I trust it because it's signed by a CA that I trust." WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I trust it because it's signed by a CA that I trust."
The PC can then take the contents of that certificate
and very importantly, the public key from that certificate
and use that as part of setting up
a secure session between itself and the bank.
And many times if a customer goes to a website
and they go with HTTP not HTTPS, the server
will redirect them in the background to HTTPS,
so they can start the negotiation,
validate that the bank is really who it says it is
and then continue on to authenticating the user.
Now, a lot of times the bank is going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, a lot of times the bank is going
to use a digital certificate as explained here
and then as the bank needs to verify who the user is,
there's often a password or something
similar to a password that's used so that the bank can
verify who the user is like Bob or you or I
that is connecting to the bank.
So digital certificates on one side and possibly a username
and password or maybe multi-factor authentication
on the side of the PC.
And for fun, let's do this.
Let's look at a packet capture between a device that's
connecting to a website.
And we'll do it first with these HTTP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we'll do it first with these HTTP
without any type of encryption or protection
and then we'll do with HTTPS which is then leveraging TLS.
And from this PC over here, let's go ahead and connect over
with HTTP.
First, we'll authenticate at the router
and then we'll capture all that.
And then let's also then change gears,
we'll connect via HTTPS so we can visually
see with the protocol capture what's
going on behind the scenes and also identify that the HTTPS
session is completely protected
All right.
So this represents the client over on the 10.1 network.
Over on the left, we'll open up a browser WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Over on the left, we'll open up a browser
and let's first go to HTTP without the S.
And we'll go to 25.2.2.2.
Press Enter and we'll authenticate.
So the user is admin and this is the password.
And bada bing bada boom, we're connected.
Now that is not secure.
So up here in our browser, it's indicating that we are not
on a secure connection.
So it's just warning us.
If we did it again, but we did with HTTPS,
it would look like this.
I'll close that browser and open it up again WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'll close that browser and open it up again
and this time we'll go to https://25.2.2.2.
It's asking me to authenticate again which I will.
And this is the HTTPS session.
Now, right here, it's showing us under the little lock there,
they're saying, the connection is not secure
and that's because my browser, this one right here,
doesn't trust the certificate.
It can't verify the signature on the certificate.
That's because I'm using a self signed certificate over WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's because I'm using a self signed certificate over
on the router.
So now we've opened those two sessions, one with HTTP and one
with HTTPS, let's take a look at the packet captures.
So if we go down the capture a little bit here,
this looks like the three way handshake
for initial conversation there.
If we right click on that and specify Follow and then follow
the TCP stream, there's our connection.
So anything we typed in, it would show up here.
Because HTTP without TLS is going to be plain text,
anybody eavesdropping could read all of this information. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
anybody eavesdropping could read all of this information.
So that's without the protection.
I might go ahead and close that.
So let's scroll down a little bit further in the capture.
And here we have a--
fantastic right here.
So it looks like a three-way handshake starting right here
tag at 60, then we have a, client hello using TLS version
1.2 and then we have a server responding back.
And in the payload here of this packet from the server going
back to the client, if we open this up,
here is information, TLS information.
Well, first of all, it says it's 1.2 which is great.
And it's also the information here in your certificate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it's also the information here in your certificate
that is being presented by the server back to the client.
Then we have an acknowledgment here.
Some more traffic coming from the server.
And check this out.
Right here as part of the negotiation
it says EC for Elliptical Curve Diffie-Hellman server
parameters.
So it's using Diffie-Hellman as part of the TLS
for key negotiation.
So the initial authentication is done with a digital certificate
and a public private key pair.
However, they are setting up shared keying information
that they can then use for the bulk encryption of data WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that they can then use for the bulk encryption of data
they'll be sending back and forth between the client
and the server.
Also, here if we right click on one of these
and said Follow and said I want to follow the TCP stream.
There's not a lot of sense we can make out
of this because most of the payload here is encrypted.
Unless you have the keys involved to unlock the data,
it's just a bunch of gobbledygook.
Now, fortunately the client and the server
because they negotiated and set up
the keying material it can use, they have the keys to lock
and unlock that data respectively.
In this video, we've looked at the benefits WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In this video, we've looked at the benefits
of using transport layer security to protect our packets
as they're going between a client and a server
leveraging TLS or Transport Layer Security.
Now, one of the challenges that I'd
like to tackle in the next video is, how in the world
did a client like a PC and a browser,
how did it verify that the certificate it
got from the server is actually valid?
So we'll go into PKI and how that works in the next video.
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. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and I'd like to thank you for viewing.