Secure Protocols – CompTIA Security+ SY0-501 – 2.6

For our applications to be sure, our network communication must be secure. In this video, you’ll learn about the most popular secure network and application protocols.

<< Previous Video: Mobile Device Deployment Models Next: Compliance and Frameworks >>


If you’re making phone calls or sending video calls over your network, you want to be sure that communication is secure. And to be able to do that, you might use a secure protocol such as SRTP. That stands for Secure Real-time Transport Protocol.

SRTP is the secure version of the Real-time Transport Protocol that you may have seen with other voice over IP technologies, but it adds encryption using AES to make sure that all the video and audio is confidential as it goes through the network. SRTP also includes authentication integrity and replay protection by including HMAC-SHA1 as a hashing function.

With this in place, you know that you’re receiving the original audio or video stream and there’s nobody sitting in the middle with a man in the middle attack listening in on your conversations. We use network time protocol, or NTP, as a way to synchronize all the clocks on all of the devices that are connected to our network.

But NTP has been around since 1985, and it doesn’t have any type of security features built into it. As we’ve seen previously, the bad guys have found ways to use NTP in denial of service attacks. There’s an effort underway to make NTP more secure by creating a new protocol called NTPsec.

This is the secure network time protocol, and the effort to make this more secure started around June of 2015. The code base of NTP has been updated in NTPsec. A number of vulnerabilities have been patched, and we expect that NTP will become much more secure through the implementation of NTPsec.

Many people have started to implement more security in their email communication, and one way to do this is by using S/MIME. This is the Secure Multipurpose Internet Mail Extensions. It’s a way that you can digitally sign and encrypt the information you’re sending right in your email client. This is something that does have to be initially configured. It requires a PKI or at least a way to manage keys so that you’re able to provide a public and private key to use in this S/MIME communication.

There is also a concern about the email as it’s being transferred across the network. To address those, we have the protocols, secure POP and secure IMAP, which take the existing POP3 and IMAP protocols and add SSL encryption on top of that network communication. And of course, if you are communicating to your email inbox through a browser, you can simply use HTTPS using SSL or TLS to be able to encrypt the entire communication between your browser and the email server.

Of course, all communication in your web browser can use the same form of encryption using SSL or what’s now called TLS. SSL stands for Secure Sockets Layer. TLS is the updated version of SSL, and that stands for Transport Layer Security. We usually see SSL implemented as HTTPS. This is HTTP over SSL. Usually, you’ll see HTTP secure, and you’ll see in your browser there will be an HTTPS with a little lock next to it to signify that this communication is encrypted.

SSL uses a combination of asymmetric encryption and symmetric encryption to be able to provide this level of confidentiality. It’s able to transfer a symmetric key by using asymmetric encryption, and by using the symmetric key, we can have a very fast and very secure communication between your browser and the web server.

If you’re transferring files, you don’t want to use a protocol that will transfer the information in the clear. Instead, use an encrypted protocol such as FTPS. FTPS stands for FTP over SSL. Just as we have HTTPS, which sends HTTP traffic over SSL, we have FTPS that does a similar function. This is a different protocol than SFTP.

SFTP is SSH file transfer protocol, which is also a way to transfer files over an encrypted channel, but it’s using SSH instead of SSL. SFTP also provides file system functionality. So you can restart a file transfer if it’s been interrupted. It can provide directory listings, remote file removals, and other file management functions by using this SFTP protocol.

If you on a large corporate network, there may be thousands of users and hundreds of file servers and printers. One way to manage all of these different devices and keep everything in one central repository is by using LDAP, or Lightweight Directory Access Protocol. This is a protocol that’s used to read and right directory information over an IP based network.

LDAP uses a standard from the International Telecommunications Union called X.500. This means that we’re able to use different types of operating systems and technologies, and they’ll all still be able to talk to each other using this LDAP protocol. LDAP started as the Directory Access Protocol on the OSI protocol stack, and it was updated to make it more lightweight and to work with TCP/IP, and we have today’s protocol, LDAP.

If you’re using Windows Active Directory, Apple’s Open Directory, or you’re using open LDAP, then you are using this LDAP protocol to be able to query and gather information about other devices that are on your network. One way to make LDAP more secure is by enabling LDAPS, which stands for LDAP secure. It’s a nonstandard implementation of LDAP that effectively uses LDAP over SSL.

Another way to add security to an LDAP communication is to implement SASL. This is the Simple Authentication and Security Layer. SASL is a framework that allows you to take an existing protocol, like LDAP, and provide additional authentication and security to these existing protocols.

If you’re communicating to a device at a command line, then you probably don’t want to use Telnet, which communicates in the clear. Instead, use SSH, which stands for Secure Shell. This is an encrypted terminal communication that looks exactly like a Telnet communication, but all of the network communication back and forth between you and that other device is all encrypted.

The original implementation of domain name services did not include any type of security. There was no way to verify if the information you retrieved from a DNS server was legitimate. Because of that, the industry implemented DNSSEC. This is the Domain Name System Security Extension.

This allows you to verify the responses that you’re getting from a DNS server. You can make sure that it’s really coming from the correct origin, and you can make sure the information that you’re receiving is exactly what was sent from the DNS server. DNSSEC does this using public key cryptography.

The records within DNS are effectively digitally signed by a third party. The signed DNS records are stored on the DNS server, and when you receive the DNS information, you can verify the digital signature. If you’re a network administrator and you need to manage a switch or router, you can communicate to those devices over a command line using SSH, or Secure Shell.

There are also ways to manage these devices using SNMP, and if you want to add security to that protocol, you would use SNMP version 3. This is the Simple Network Management Protocol version 3. It’s this version 3 of SNMP that includes confidentiality, it encrypts the communication back and forth between you and that remote device, it adds integrity so you know the data was not changed as it went through the network, and we have authentication, which verifies the source of this information.

Some switches and routers also allow you to manage the device through a browser, and in those cases, you may decide to use the encrypted protocol for browser communication, HTTPS. The allocation of IP addresses can be done automatically using a protocol such as DHCP, the Dynamic Host Configuration Protocol.

But, DHCP does not have any type of security built into the protocol itself. There is not a secure version of DHCP that you can opt to use in your environment. One of the biggest challenges with the DHCP is that someone could then start their own DHCP service and begin offering IP addresses as a rogue DHCP server.

In a Microsoft environment, DHCP servers must be authorized in Active Directory. So Microsoft has added an additional layer of security on top of the DHCP process. Some switches have operating systems that allow you to define a trusted interface in the switch, and if DHCP communication is coming from a trusted interface, then it’s allowed to communicate through that switch.

There are many manufacturers that have implemented this type of functionality. If you’re using a Cisco switch, you’ll see this referred to as DHCP snooping. Another security challenge that we have with the DHCP is that someone can spoof a MAC address and constantly request DHCP addresses from the DHCP server. This will very quickly cause the server to run out of IP addresses we call this a DHCP starvation attack.

This is another example where we can configure a switch to look for these particular situations, and it’s very common to configure switch interfaces to limit the number of MAC addresses that could be associated with an individual interface on the switch.

A number of the security applications and tools that we have on our network rely on subscriptions. Our anti-virus and anti-malware applications use a subscription to download and update their signatures. We have intrusion prevention systems on our network that are constantly updated through a subscription. And many of our firewalls have a list of known malicious IP addresses, and those databases are also updated through a subscription.

One of the challenges that we have is each one of these different services uses a completely different method to provide the updates. One of the things that we can do from a security perspective, then, is to add additional security controls. Perhaps we can limit the IP address where these subscriptions might come from, or if the application supports it, we can add additional security controls, such as certificates, to verify both sides of the conversation.