Let's take a look at Transport Layer encryption VPNs.
If we were to do a brief take on the history of SSL/TLS,
we would find that the first usable version of SSL, 2.0, was
designed by Netscape and released in 1995.
As there were vulnerabilities found in SSL 2.0, this
required Netscape to design a better,
more secure version, so they came out with TLS 1.0, or what's called SSL 3.0.
SSL 3.0 was still widely used until 2014 when a major security
vulnerability was found by a Google team.
Then you moved from SSL to TLS, and the first iteration of it was
1.1. Currently, at the publishing of this clip,
TLS 1.2, even though it was released in 2008,
is still the dominant version that's out there.
TLS 1.3 is the one that we should be scheduling to replace TLS 1.2.
If you were to look at the TLS 1.2 process,
it is the VPN client and the VPN system that are having a
communication that begins with what is called the client hello. In
the client hello, the client specifies the version of TLS that
they're using, what the cipher suite is.
Maybe it looks like aes_ecc_sha256, which would be a symmetric key,
an asymmetric key, and a hashing algorithm that could be selected.
The client random will be a random set of data based upon
all of the information in a hashed form. Then the VPN would
respond with a server hello, which would say, okay,
this is the protocol version that we are agreeing to and
the cipher suite that we can use, along with their own
random and the X.509 certificate.
The VPN client would then consume the public key that's found in the
certificate, and by means of a modulus mathematics problem,
if you're using something like Diffie‑Hellman,
you would then be able to agree upon a shared secret,
which would mean making use of a symmetric key in order
to encourage and support speed.
TLS 1.2 and all of its predecessors use some form of
asymmetric and symmetric keys working together.
The symmetric keys are typically ephemeral, or only temporary, for that session.
TLS 1.3 is designed to actually address a number of issues with TLS
1.2. One of them is getting rid of all symmetric encryption capability,
which would mean dropping old algorithms.
There's also something introduced that's called Authenticated Encryption
with Associated Data, which would be an amalgam of all approved symmetric
encryption keys that are used going forward.
The cipher suite is also modified in order to strengthen the kind of
encryption algorithms that are allowed. For instance,
your older RSA and Diffie‑Hellman cipher suites have been removed.
There's also something called a zero round trip that has
been at it, saving round trip of connection setup for some
specific application data.
There is the static asymmetric capabilities are removed.
This is now done dynamically. And also, ECC, which is a prime
candidate to replace RSA, is introduced.
You need very few bits for the same amount of security inside of RSA if
you're using ECC. The handshake process, when we're talking about TLS 1.3,
has three phases. You immediately have a key exchange of shared key material
and parameters initiated by the client.
Therefore, all communications after that point are going to be secured.
Then the client goes through the process of verifying
authentication with the web server, and the web server can
correspondingly do the same with the web client.