WEBVTT

00:00:00.630 --> 00:00:05.490
Let's take a look at Transport Layer encryption VPNs.

00:00:05.940 --> 00:00:10.760
If we were to do a brief take on the history of SSL/TLS,

00:00:10.770 --> 00:00:15.310
we would find that the first usable version of SSL, 2.0, was

00:00:15.310 --> 00:00:19.160
designed by Netscape and released in 1995.

00:00:19.240 --> 00:00:22.910
As there were vulnerabilities found in SSL 2.0, this

00:00:22.910 --> 00:00:25.000
required Netscape to design a better,

00:00:25.000 --> 00:00:31.840
more secure version, so they came out with TLS 1.0, or what's called SSL 3.0.

00:00:31.850 --> 00:00:37.080
SSL 3.0 was still widely used until 2014 when a major security

00:00:37.080 --> 00:00:40.300
vulnerability was found by a Google team.

00:00:40.350 --> 00:00:46.970
Then you moved from SSL to TLS, and the first iteration of it was

00:00:46.970 --> 00:00:50.890
1.1. Currently, at the publishing of this clip,

00:00:50.900 --> 00:00:54.730
TLS 1.2, even though it was released in 2008,

00:00:54.740 --> 00:00:57.360
is still the dominant version that's out there.

00:00:57.440 --> 00:01:03.560
TLS 1.3 is the one that we should be scheduling to replace TLS 1.2.

00:01:03.640 --> 00:01:07.190
If you were to look at the TLS 1.2 process,

00:01:07.200 --> 00:01:12.390
it is the VPN client and the VPN system that are having a

00:01:12.390 --> 00:01:16.070
communication that begins with what is called the client hello. In

00:01:16.070 --> 00:01:20.860
the client hello, the client specifies the version of TLS that

00:01:20.860 --> 00:01:22.970
they're using, what the cipher suite is.

00:01:22.980 --> 00:01:30.010
Maybe it looks like aes_ecc_sha256, which would be a symmetric key,

00:01:30.020 --> 00:01:35.500
an asymmetric key, and a hashing algorithm that could be selected.

00:01:35.730 --> 00:01:39.520
The client random will be a random set of data based upon

00:01:39.530 --> 00:01:43.740
all of the information in a hashed form. Then the VPN would

00:01:43.740 --> 00:01:47.390
respond with a server hello, which would say, okay,

00:01:47.400 --> 00:01:50.720
this is the protocol version that we are agreeing to and

00:01:50.720 --> 00:01:54.360
the cipher suite that we can use, along with their own

00:01:54.360 --> 00:01:57.890
random and the X.509 certificate.

00:01:58.020 --> 00:02:02.980
The VPN client would then consume the public key that's found in the

00:02:02.980 --> 00:02:07.380
certificate, and by means of a modulus mathematics problem,

00:02:07.380 --> 00:02:09.620
if you're using something like Diffie‑Hellman,

00:02:09.630 --> 00:02:14.180
you would then be able to agree upon a shared secret,

00:02:14.190 --> 00:02:18.940
which would mean making use of a symmetric key in order

00:02:18.940 --> 00:02:21.660
to encourage and support speed.

00:02:21.670 --> 00:02:26.600
TLS 1.2 and all of its predecessors use some form of

00:02:26.610 --> 00:02:29.820
asymmetric and symmetric keys working together.

00:02:29.830 --> 00:02:34.860
The symmetric keys are typically ephemeral, or only temporary, for that session.

00:02:34.940 --> 00:02:41.940
TLS 1.3 is designed to actually address a number of issues with TLS

00:02:41.940 --> 00:02:48.380
1.2. One of them is getting rid of all symmetric encryption capability,

00:02:48.940 --> 00:02:52.430
which would mean dropping old algorithms.

00:02:52.590 --> 00:02:56.230
There's also something introduced that's called Authenticated Encryption

00:02:56.230 --> 00:03:02.080
with Associated Data, which would be an amalgam of all approved symmetric

00:03:02.090 --> 00:03:04.990
encryption keys that are used going forward.

00:03:05.380 --> 00:03:10.310
The cipher suite is also modified in order to strengthen the kind of

00:03:10.310 --> 00:03:13.380
encryption algorithms that are allowed. For instance,

00:03:13.390 --> 00:03:18.860
your older RSA and Diffie‑Hellman cipher suites have been removed.

00:03:18.880 --> 00:03:22.370
There's also something called a zero round trip that has

00:03:22.370 --> 00:03:26.680
been at it, saving round trip of connection setup for some

00:03:26.680 --> 00:03:28.560
specific application data.

00:03:28.640 --> 00:03:32.730
There is the static asymmetric capabilities are removed.

00:03:32.740 --> 00:03:38.260
This is now done dynamically. And also, ECC, which is a prime

00:03:38.260 --> 00:03:41.280
candidate to replace RSA, is introduced.

00:03:41.290 --> 00:03:47.140
You need very few bits for the same amount of security inside of RSA if

00:03:47.140 --> 00:03:52.920
you're using ECC. The handshake process, when we're talking about TLS 1.3,

00:03:52.920 --> 00:03:59.670
has three phases. You immediately have a key exchange of shared key material

00:03:59.680 --> 00:04:01.690
and parameters initiated by the client.

00:04:01.700 --> 00:04:08.650
Therefore, all communications after that point are going to be secured.

00:04:08.840 --> 00:04:11.960
Then the client goes through the process of verifying

00:04:11.970 --> 00:04:15.560
authentication with the web server, and the web server can

00:04:15.560 --> 00:04:18.459
correspondingly do the same with the web client.