Just as TCP/IP was built without security in mind, many common protocols that we rely upon today do not have built-in encryption and require modification to support encryption technology. Learn the use of secure protocols, such as HTTPS, FTPS, SFTP, SSH and SCP to replace their insecure counterparts.
- [Instructor] Just as TCP IP was built without security in mind, many common protocols that we rely upon today do not have built in encryption and require modification to support encryption technology. The most common example of adding encryption to a standard protocol is securing web communications. You may already be familiar with the hypertext transfer protocol, or HTTP. This protocol is used to deliver websites to browsers over the Internet. It's where the HTTP and a full website URL comes from.
For example, let's go visit the website for the U.S. House of Representatives. I'm going to type in HTTP colon slash slash www.house.gov, the full URL, and hit enter. And the website quickly loads. If I click this sheet of paper icon here right next to the URL in Chrome, notice that it says your connection to this site is not private. That's because it went over the standard HTTP protocol, it was not encrypted. Someone eavesdropping on a network connection could have seen that I visited this website and also the contents of our communication.
Now let's try a different website. This time I'm going to type in HTTPS colon slash slash white house dot gov, and go visit the White House website. This sight also loads fairly quickly, but notice now, there's a green lock and the HTTPS is apparent here in the URL. This means that HTTPS, the encrypted alternative to HTTP, was used for this connection. If I click on this lock icon I can see that the text has changed and says now, your connection to this site is private.
The HTTP secure, or HTTPS protocol, is almost identical to the HTTP protocol, with one added twist. HTTPS adds transport layer security, TLS to the process. So when I visited the White House website, a whole lot of different things happened in the background. First, my computer retrieved the digital certificate from the White House server, it verified that certificate's authenticity, and then it created an ephemeral session key to encrypt all of the communications sent back and forth between my computer and the White House server.
It then encrypted that ephemeral key with the White House's public key and sent it back to the White House server. That ephemeral key provided security for the entire communications session. So someone eavesdropping on my network connection would not have been able to view the content of the communication. The administrators of Linux systems often need to connect remotely to their systems using the command line. Early versions of Linux and Unix provided a utility called Telnet to allow these communications.
They simply gave the user a prompt on the remote server that allowed them to execute commands. Unfortunately, Telnet is an extremely insecure protocol because all of the data sent back and forth between the client and the server is unencrypted. This includes the username and password used to establish the connection. Anyone eavesdropping on a Telnet session can steal the user's password and use it to gain access to the system. The secure shell, or SSH protocol, solves this problem by providing the same functionality as Telnet with the added benefit of encryption.
SSH runs over TCP port 22 and uses public key cryptography to exchange an ephemeral session key in the same manner as TLS. Let's take a quick look at SSH in action. This is a terminal session running on a Macbook, and I'm going to use the SSH protocol to connect to a server that I have running in an Amazon web services data center in Virginia. I'm just going to go ahead and type the SSH command, and then I need to tell it the location of my private key.
So I'm going to use the minus I flag to tell SSH where to pull the private key from and then I'm going to give it the name of the file containing my private key. Then I type in the username on the remote server that I'm going to connect to, which is EC2 dash user. Then the at symbol, and the IP address or the fully qualified domain name of the server that I'm connecting to. So I'll go ahead and type that in and hit enter. And then I get a command line right here on my remote server. Notice the prompt changed and I can go ahead and run any command I want, just as if I'm connected to this server.
I can go browse directories, look at the contents of those directories, make changes to files. I have a remote prompt on this server and because I'm using SSH to make this connection, all of the contents of this communication are fully encrypted. When my username and password were sent back and forth to the server, they were done so in a protected manner so that someone eavesdropping on the communication isn't able to steal my password. Similarly, all of the commands that I execute on this server and the results sent back to my terminal session here are fully encrypted.
This is a secure way to remotely access a command line on a server. Administrators also often need to transfer files between systems. The file transfer protocol, FTP, allows file transfer sessions between two systems, but as you might have guessed, it doesn't encrypt the session, creating a significant security vulnerability. Users who need to transfer files securely between two systems have a few options available to them.
The FTP secure, or FTPS protocol, adds transport layer security to the standard FTP protocol that adds encryption and confidentiality. The secure FTP or SFTP protocol, uses the SSH protocol instead of TLS to establish a connection and then transfers files over that SSH session. The secure copy, or SCP protocol, also uses SSH and makes it easy to transfer files securely from the command line.
One exam tip for you. There is another version of FTP known as the trivial file transfer protocol, or TFTP. This protocol is also insecure and it's not very commonly used. Just be sure that if you see it on the exam you recognize TFTP as an insecure protocol.
Learn about communication and networking best practices, including TCP/IP networking, network security devices, and secure network design and management. Instructor and cybersecurity expert Mike Chapple also includes coverage of converged protocols, network encryption, and wireless networking. You can find Mike's companion study books for this series at the Sybex test prep site and review the complete CISSP Body of Knowledge at https://www.isc2.org/cissp-domains/default.aspx.
- IP addressing
- Switches and routers
- Content distribution networks
- Designing secure networks
- Specialized networking
- Managing secure networks
- Working with virtualized networks like SDNs
- Detecting and preventing network attaches
- Transport encryption
- Wireless networking
- Host security