WEBVTT

1
00:00.000 --> 00:00.770 align:middle line:84%


2
00:00.770 --> 00:02.360 align:middle line:90%
One of the challenges
that computers

3
00:02.360 --> 00:04.160 align:middle line:90%
go through thousands
of times a day

4
00:04.160 --> 00:07.880 align:middle line:90%
is how do we verify that
the server we're talking to

5
00:07.880 --> 00:10.820 align:middle line:90%
is literally the authentic
and authorized server that we

6
00:10.820 --> 00:13.820 align:middle line:90%
think we're talking to when
we're using transport layer

7
00:13.820 --> 00:14.580 align:middle line:84%
security.

8
00:14.580 --> 00:16.740 align:middle line:90%
So let's talk about
that in this video.

9
00:16.740 --> 00:20.110 align:middle line:90%
So let's start off with a
banking or commerce server,

10
00:20.110 --> 00:22.640 align:middle line:84%
and we'll call this server 1.

11
00:22.640 --> 00:24.440 align:middle line:90%
And if we have a
client that connects

12
00:24.440 --> 00:27.290 align:middle line:90%
to that server with a
browser using HTTP PCZ,

13
00:27.290 --> 00:31.280 align:middle line:90%
well-known port is
TCP443 for each TTPS
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

13
00:27.290 --> 00:31.280 align:middle line:90%
well-known port is
TCP443 for each TTPS

14
00:31.280 --> 00:33.350 align:middle line:84%
which is leveraging TLS.

15
00:33.350 --> 00:34.880 align:middle line:90%
And during the
initial negotiations

16
00:34.880 --> 00:37.100 align:middle line:90%
that server is going to
send the client who's

17
00:37.100 --> 00:41.240 align:middle line:90%
connecting skin send a copy
of its digital certificate.

18
00:41.240 --> 00:43.730 align:middle line:90%
Now that digital certificate
it's got a few things.

19
00:43.730 --> 00:45.320 align:middle line:90%
It's got a validity
date like it.

20
00:45.320 --> 00:48.007 align:middle line:90%
This certificate is valid
from this date to that date.

21
00:48.007 --> 00:48.590 align:middle line:84%
So it's great.

22
00:48.590 --> 00:50.215 align:middle line:90%
The client can check
the validity date,

23
00:50.215 --> 00:52.910 align:middle line:90%
make sure that the client
believes the current time is

24
00:52.910 --> 00:53.900 align:middle line:84%
within that window.

25
00:53.900 --> 00:56.720 align:middle line:90%
The client can also look
at the public key, which

26
00:56.720 --> 00:59.570 align:middle line:90%
is be needed for the secure
establishment of keying

27
00:59.570 --> 01:02.180 align:middle line:90%
material between the
PC and the server.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
00:59.570 --> 01:02.180 align:middle line:90%
material between the
PC and the server.

28
01:02.180 --> 01:05.827 align:middle line:90%
But the question is, why should
the PC believe any of that?

29
01:05.827 --> 01:07.910 align:middle line:90%
I mean a hacker could
create a digital certificate

30
01:07.910 --> 01:11.330 align:middle line:90%
with a public key and a validity
date, why should the PC believe

31
01:11.330 --> 01:14.690 align:middle line:90%
this certificate is the one
that's authentic and valid?

32
01:14.690 --> 01:17.990 align:middle line:90%
And the answer is because this
certificate that the server's

33
01:17.990 --> 01:21.260 align:middle line:90%
presenting also someone's called
an identity certificate is

34
01:21.260 --> 01:23.840 align:middle line:90%
signed, and it's not
signed by just anybody

35
01:23.840 --> 01:28.880 align:middle line:90%
it's signed by a device that
this PC, the browser on this PC

36
01:28.880 --> 01:29.780 align:middle line:84%
trusts.

37
01:29.780 --> 01:34.520 align:middle line:90%
Trust means that this PC
can validate the signature
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:29.780 --> 01:34.520 align:middle line:90%
Trust means that this PC
can validate the signature

38
01:34.520 --> 01:38.100 align:middle line:90%
and say oh yeah, this is signed
by a certificate authority,

39
01:38.100 --> 01:39.710 align:middle line:90%
which is what that
entity is called.

40
01:39.710 --> 01:41.420 align:middle line:90%
By a certificate
authority that I trust

41
01:41.420 --> 01:43.670 align:middle line:90%
and as a result of
that being signed

42
01:43.670 --> 01:46.070 align:middle line:90%
I can then trust the
contents of the rest

43
01:46.070 --> 01:47.660 align:middle line:90%
of the digital
certificate including

44
01:47.660 --> 01:50.230 align:middle line:90%
the public key, and the
identity, and the validity

45
01:50.230 --> 01:52.730 align:middle line:90%
date, and all the other details
that are in the certificate.

46
01:52.730 --> 01:54.147 align:middle line:90%
And a question
that often comes up

47
01:54.147 --> 01:56.990 align:middle line:90%
is, well, how does
this browser on this PC

48
01:56.990 --> 01:59.390 align:middle line:90%
know about a trusted
certificate authorities,

49
01:59.390 --> 02:03.320 align:middle line:90%
and they are free loaded on
Windows, and Linux, and Apple
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
01:59.390 --> 02:03.320 align:middle line:90%
and they are free loaded on
Windows, and Linux, and Apple

50
02:03.320 --> 02:06.620 align:middle line:90%
computers, they are preloaded
with a whole laundry

51
02:06.620 --> 02:09.788 align:middle line:90%
list of trusted certificate
authorities in the cloud.

52
02:09.788 --> 02:11.330 align:middle line:90%
So certificate
authorities would work

53
02:11.330 --> 02:14.930 align:middle line:90%
like this, the bank who are
ever owns the server beforehand,

54
02:14.930 --> 02:17.870 align:middle line:90%
before they go online they
would work with a certificate

55
02:17.870 --> 02:22.370 align:middle line:90%
authority, they would generate
a public and private key pair,

56
02:22.370 --> 02:24.860 align:middle line:90%
and then they would submit
to the certificate authority

57
02:24.860 --> 02:27.320 align:middle line:90%
saying I would like our
own identity certificate.

58
02:27.320 --> 02:29.990 align:middle line:90%
They hand over the public
key, the certificate

59
02:29.990 --> 02:32.870 align:middle line:90%
authority people verify that
server and the organization
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
02:29.990 --> 02:32.870 align:middle line:90%
authority people verify that
server and the organization

60
02:32.870 --> 02:34.590 align:middle line:84%
really is who they say they are.

61
02:34.590 --> 02:36.830 align:middle line:90%
And then they issue an
identity certificate

62
02:36.830 --> 02:38.895 align:middle line:84%
that is signed by that CA.

63
02:38.895 --> 02:41.060 align:middle line:90%
And that's the
certificate that is then

64
02:41.060 --> 02:42.560 align:middle line:84%
presented to the client.

65
02:42.560 --> 02:44.720 align:middle line:90%
And this whole
infrastructure is called

66
02:44.720 --> 02:49.947 align:middle line:90%
the public key infrastructure,
or PKI for short.

67
02:49.947 --> 02:52.280 align:middle line:90%
So the way this work is that
if we want the server to be

68
02:52.280 --> 02:54.500 align:middle line:90%
trusted, the server
would participate

69
02:54.500 --> 02:57.860 align:middle line:90%
as a client to the PKI
go out to a certificate,

70
02:57.860 --> 03:01.250 align:middle line:90%
authority they did a certificate
have it signed by a CA
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

70
02:57.860 --> 03:01.250 align:middle line:90%
authority they did a certificate
have it signed by a CA

71
03:01.250 --> 03:04.790 align:middle line:90%
that most browsers on the
planet trust as part of PKI then

72
03:04.790 --> 03:05.800 align:middle line:84%
they are good to go.

73
03:05.800 --> 03:07.790 align:middle line:90%
Clients connect, they
hand over the cert

74
03:07.790 --> 03:09.770 align:middle line:84%
it's signed by CA server.

75
03:09.770 --> 03:11.960 align:middle line:90%
The client because it
can verify the signature

76
03:11.960 --> 03:13.910 align:middle line:90%
trust the details in
that cert and then

77
03:13.910 --> 03:16.310 align:middle line:90%
they go on to negotiating
the keys involved

78
03:16.310 --> 03:19.550 align:middle line:90%
for a private session between
the client and the server.

79
03:19.550 --> 03:22.040 align:middle line:90%
And at that moment
PC1 in this case,

80
03:22.040 --> 03:25.370 align:middle line:90%
has validated, or identified,
and authenticated the server

81
03:25.370 --> 03:26.540 align:middle line:84%
due to the certificate.

82
03:26.540 --> 03:28.370 align:middle line:90%
Now the other half
of that is the server

83
03:28.370 --> 03:30.212 align:middle line:90%
might one also
verify the client.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

83
03:28.370 --> 03:30.212 align:middle line:90%
might one also
verify the client.

84
03:30.212 --> 03:31.670 align:middle line:90%
And at that point,
the client would

85
03:31.670 --> 03:34.087 align:middle line:90%
be prompted for something like,
hey, what's your username?

86
03:34.087 --> 03:34.670 align:middle line:84%
And password?

87
03:34.670 --> 03:37.230 align:middle line:90%
Or your credentials
for authentication.

88
03:37.230 --> 03:39.750 align:middle line:90%
So servers are authenticated
via their certificates

89
03:39.750 --> 03:41.180 align:middle line:90%
while end users
are traditionally

90
03:41.180 --> 03:44.280 align:middle line:90%
verified or authenticated
using passwords.

91
03:44.280 --> 03:46.070 align:middle line:90%
Now TLS is not the
only protocol it

92
03:46.070 --> 03:48.410 align:middle line:90%
can be used to protect
traffic as it goes

93
03:48.410 --> 03:50.900 align:middle line:90%
over a network, a whole
other family and other suite

94
03:50.900 --> 03:53.930 align:middle line:90%
of protocols that we use for
cryptography, which includes

95
03:53.930 --> 03:58.340 align:middle line:90%
encryption and hashing is the
family of IPsec which we'll

96
03:58.340 --> 03:59.790 align:middle line:84%
talk about in the next video.

97
03:59.790 --> 04:01.415 align:middle line:90%
So I'll see you there
in just a moment.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
03:59.790 --> 04:01.415 align:middle line:90%
So I'll see you there
in just a moment.

98
04:01.415 --> 04:03.920 align:middle line:90%
Meanwhile, I hope this has
been informative for you,

99
04:03.920 --> 04:07.180 align:middle line:90%
and I'd like to thank
you for viewing.