WEBVTT

00:00.019 --> 00:02.175
>> In the last section,

00:02.175 --> 00:04.365
we talked about TLS and SSL,

00:04.365 --> 00:05.820
and if you happen to jump ahead

00:05.820 --> 00:08.219
>> to this lesson on
public key infrastructure

00:08.219 --> 00:09.945
>> without going
through that lesson,

00:09.945 --> 00:12.135
I'm going to ask you to
go back and listen to it

00:12.135 --> 00:15.850
because these lessons are
best understood together.

00:16.400 --> 00:20.240
In that lesson, we
talked about SSL and TLS

00:20.240 --> 00:22.370
>> and how they use
hybrid cartography method

00:22.370 --> 00:25.590
>> in order to provide
encryption services.

00:25.599 --> 00:28.430
>> I also drew a
beautiful picture

00:28.430 --> 00:30.850
in PowerPoint that
you can see here.

00:30.850 --> 00:32.540
I want to talk about this

00:32.540 --> 00:35.074
>> a little bit more and
take it a step further.

00:35.074 --> 00:37.325
>> As we said in
the last lesson,

00:37.325 --> 00:38.540
we have a client trying to

00:38.540 --> 00:41.600
reach Bank of America's
web server securely

00:41.600 --> 00:43.774
>> and the bank provides
its public key.

00:43.774 --> 00:46.280
>> Now if we think
about this scenario,

00:46.280 --> 00:48.620
how can the client be sure
that what it is receives

00:48.620 --> 00:51.440
is indeed the public key
for Bank of America?

00:51.440 --> 00:53.390
Your DNS server would tell you

00:53.390 --> 00:55.879
>> that you have reached Bank
of America's web server.

00:55.879 --> 00:58.550
>> But what if the DNS
server has been compromised

00:58.550 --> 01:00.230
>> and you are directed
to a rogue server

01:00.230 --> 01:02.360
>> and then you send your
sensitive information

01:02.360 --> 01:03.350
>> to the rogue server

01:03.350 --> 01:06.444
>> and it's encrypted with the
rogue server's public key?

01:06.444 --> 01:08.370
>> How do you get the guarantee

01:08.370 --> 01:11.134
>> that you really are
talking to Bank of America?

01:11.134 --> 01:14.360
>> Well, long before
Bank of America

01:14.360 --> 01:16.219
>> ever provided online banking,

01:16.219 --> 01:17.870
>> a bank representative
would have gone

01:17.870 --> 01:20.874
>> to an organization called
a certificate authority.

01:20.874 --> 01:23.120
>> The bank representative
would have provided

01:23.120 --> 01:25.580
>> lots of information
in business licenses

01:25.580 --> 01:27.380
>> and other
documentation to prove

01:27.380 --> 01:29.480
>> that they truly represent
the Bank of America

01:29.480 --> 01:31.730
>> and the certificate authority

01:31.730 --> 01:34.579
>> would have given the
bank a digital certificate.

01:34.579 --> 01:36.440
>> That digital certificate

01:36.440 --> 01:38.209
>> is exactly what
it sounds like.

01:38.209 --> 01:40.460
>> It's an electronic
file that's essentially

01:40.460 --> 01:43.710
containing the Bank of
America's public key.

01:45.020 --> 01:46.940
How would you know that no one

01:46.940 --> 01:49.144
>> has modified this
digital certificate?

01:49.144 --> 01:53.520
>> Well, their certificate
authority hashes the file.

01:53.630 --> 01:56.660
How do you know that the
certificate authority is

01:56.660 --> 01:59.390
really the one that's issued
the digital certificate?

01:59.390 --> 02:02.600
Well, because the certificate
authority encrypts

02:02.600 --> 02:05.484
>> the hash with the certificate
authority's private key.

02:05.484 --> 02:07.790
>> That way, when the
bank's representative

02:07.790 --> 02:08.990
goes back to the bank,

02:08.990 --> 02:11.900
he installs that digital
certificate onto the server,

02:11.900 --> 02:15.230
>> and now, when the
client connects via HTTPS

02:15.230 --> 02:17.224
>> and requests a
secure connection,

02:17.224 --> 02:18.770
>> the bank sends its public key

02:18.770 --> 02:20.754
>> on the digital certificate.

02:20.754 --> 02:23.240
>> That digital certificate
needs to be signed

02:23.240 --> 02:25.579
>> by someone that
the client trusts.

02:25.579 --> 02:29.240
>> Trust in relationships
between certificate authorities

02:29.240 --> 02:31.250
>> means that their client
has the certificate of

02:31.250 --> 02:32.510
>> that certificate authority

02:32.510 --> 02:34.644
>> and saw it in
the web browser.

02:34.644 --> 02:37.100
>> It's the certificate
authority really

02:37.100 --> 02:39.159
>> that makes all this work and

02:39.159 --> 02:41.180
>> the certificate authority
is the heart and soul

02:41.180 --> 02:43.704
>> of a public key
infrastructure.

02:43.704 --> 02:47.270
>> You may have heard of some
certificate authorities.

02:47.270 --> 02:49.670
A well-known one is VeriSign,

02:49.670 --> 02:52.140
but there are many others.