Transport Encryption Algorithms – CompTIA Security+ SY0-401: 6.2

Transport Encryption Algorithms – CompTIA Security+ SY0-401: 6.2


One of the most common
encryption methods on the internet revolves around
this trio of algorithms SSL, TLS, and HTTPS. And we often refer to them
as exactly the same thing, which is the encryption
that we use in our browser. But really these
are different types of algorithms that were
created at different times. But there is a
relationship between them. SSL stands for
secure sockets layer. It was one of the very
first encryption mechanisms that we had in our browsers
when we were using the internet. It was created by Netscape. So that was built into one of
the very, very early browsers that we were using in 1996. What we found was
that there were a number of things that
could be improved upon. And we created a new version
that was more public, one that was a
standard, one that wasn’t specific to Netscape. And we called this
transport layer security. It was derived from SSL. It is the newer version,
if you will, of SSL. But now it’s a standard. It’s a worldwide standard. And you can find it in RFC 2246. And when you start
combining TLS, this mechanism for
security encryption, inside of a browser or
inside of the protocols that go back and forth
between your browser and the web server
that would be HTTPS, or your HTTP protocol
that is secure. The s stands for security. And that uses this TLS, which
we often just generically refer to as SSL, to encrypt
all of that communication that takes place between your browser
and between the web server. If you looked at
the protocol itself it would run over TCP
port 443, by default. Obviously it doesn’t
have to use that. But that’s where we
most commonly see it. It’s built into every browser
you’ll find these days so that we can have these encrypted
methods sending information back and forth. We can put our credit
card in a browser. We can send private
information back and forth to our health care
company over the web. And we can really be
assured that nobody can look into that data and see
the information that’s inside. SSH stands for secure shell. And this is a very
common encrypted method of communicating to a server
through a terminal screen. Being at the command line
typing in information you’ll very often see this
communicating over TCP port 22. Now the SSH, or secure
shell mechanism, is one that we can also
apply to more than just typing things in at a
terminal screen like this. We can use this
to be able to do, of course, the remote
administration. We can also do
file transfers with this encrypted
methodology, what we call SFTP for secure
file transfer. And we can do SCP,
secure file copy, to send information
back and forth. But when we need to have
that access to a computer but we’re not really going
through a web browser, we’re not using HTTP, we’re
not using that SSL TLS type configuration we can use
secure shell to make sure that all of our communication
is absolutely encrypted. The SSL, TLS, or the
HTTPS in our web browser is good encryption. The SSH that we might
use in a terminal screen provides us even other
types of encryption. But what if you needed any
type of data to be encrypted? What if it wasn’t
necessarily in a web browser? What if it wasn’t necessarily
at a terminal screen or doing file transfers? What about all the other
things that we do online? What about all the other things
that we do on the internet? Well for situations
like that we have another type of
encryption mechanism. This is called IPsec. This is a type of security
that was built specifically for TCPIP. And it’s designed to
work at that Layer 3, to work with IP packets. This IPsec mechanism allows
us to have confidentiality and integrity in
the communication that we have between devices,
or between hosts, on both sides. We have built in
encryption into IPsec. There’s the ability to even
sign every packet in IPsec. So when we receive
a packet we can be assured that is exactly
the same packet that was sent from the other side. This is an extremely
standardized mechanism of transportation. You will see this on
routers, on firewalls, on the clients that move
between those devices, communicate between
those devices. It’s something you’ll find
in RFC 4301 through RFC 4309. There are many, many standards
built into the IPsec mechanism. There are two core
protocols we can look at within IPsec that
make all of this work. The first one is called
authentication header. You’ll see that
abbreviated as AH. The other protocol is one called
encapsulation security payload. We almost always
refer to that as ESP. One of the challenges
in setting up communication between two
devices across a network is making sure that both sides
can understand each other and both sides are
using the same keys. And that’s, of course, our
challenge is making sure that we’re able to
communicate what key we’re using without actually sending
the key information back and forth, especially not
over the network or someone would be able to see that. So there are two phases in
setting up a communication back and forth between two
devices via IPsec. The first is called phase one. And in phase one we do something
called internet security association and key
management protocol, which is abbreviated ISAKMP. We often just abbreviate this
as the internet key exchange. You’ll see it abbreviated
if you’re configuring an IPsec client or an
IPsec device you’ll see it abbreviated
as IKE, or Ike. This is the process where both
sides identify themselves. They recognize each other. There may be some
security built in to what we’re looking at on both
sides of the communication. And they exchange
keys back and forth. There’s a couple of mechanisms
that can be used to do that. This is usually
a protocol that’s running over UDP
and port 500 on UDP. If you’re looking
at a network decode you’ll be able to see it in
there with those packets going back and forth. Once phase one is in place,
the keys to being exchanged, now the second phase can begin. In the second phase,
which we call quick mode, we’re simply setting
up and communicating to each device what
ciphers we understand, what protocols and
key sizes we would like to use to be able
to talk back and forth. Both sides will
coordinate that process. They’ll decided on which
ones they would like to use. And then after phase
one and phase two are up and running
the communication is now built between
those IPsec in points. And they can communicate
securely between them. As we mentioned earlier, there
are two protocols in IPsec. The first one we’ll look at
is the authentication header. This is a hash that is
created that’s based on the packet and the
shard key that both sides of the IPsec communication
are aware of. They usually will use something
like MD5, SHA 1, or SHA 2 as common hashing mechanisms. And what it does is,
in the normal packet, where you have an IP header,
you have a TCP UDP header, and then there’s data, it’ll
stick this authentication header right here in the
middle and send the packet to the other side. On the other side
the same hash is done of this data
and the shard key. And it compares what it comes up
with versus the authentication header that was sent. This is that digital
signature I mentioned that’s created in every packet. So when the other
side gets this packet it knows it’s
received exactly what was sent to it to begin with. Of course, with IPsec
the encryption piece is what a lot of
people are looking for. And it’s that second protocol
of the encapsulation security payload that provides
that encryption. This is providing both
a hash and an encryption of this data, the hashing done
with MD 5, SHA 1 or SHA 2. The encryption part is usually
done with Triple DES or AES to make that happen. You’ll see included to
the packet a header, a trailer, and what we call an
integrity check value to this. So you’ll see in the ESP packet
there will be your normal IP header. There will be your ESP,
the encapsulation security payload header. There will be your TCP UDP
information, some data, then the trailer, and the ICV. This capsulates
everything together sends it across down the line. And we know at
that point not only is the data encrypted but
we’re able to do integrity checks for it as well to
make sure that we receive it in exactly the form
that it was sent. Some uses of IPsec are
between a client and a server, where we’re simply
talking back and forth. And we’re taking our
existing IP packets. And we’re putting the
secret IP information inside of our existing packet. And that is a
transport mode of IPsec where we’re using our existing
header, our existing TCP UDP, and data header,
and information. And we’re simply adding
the transport information around that. So we’re sending the
packets back and forth in the normal way. It’s just everything
within the packet now gets encrypted and
protected using IPsec. But there are some
connections with IPsec that are what we
call tunneled mode, where we will have two devices. This is usually done with two
end points, like two firewalls. And an encrypted tunnel will be
built between those firewalls. And all information
between point A and point B will be encapsulated
inside of this tunnel and sent to the other side. And on the other side it’s
pulled out of the tunnel and placed back
on to the network. And that is one where there is
a new IP header that’s built. Everything is jammed into that
packet, encrypted with IPsec, and sent across
to the other side. So whether you’re using
a transport mode IPsec or a tunneled mode
IPsec the result is that you’re going to get
information across the network. It’s going to be encrypted. You’ll be able to check
the integrity of that data and be assured that everything
you’re sending back and forth is protected.

Leave a Reply

Your email address will not be published. Required fields are marked *