We use a number of algorithms to maintain the security of our data as it flows across the network. In this video, you’ll learn about SSL, SSH, and IPsec encryption protocols.
<< Previous Video: NTLMNext: Strong vs. Weak Encryption >>
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.