Last time in Part 1, we began taking a look at SSH the protocol. We talked about how SSH establishes a way for two computer systems to communicate with each other in a secure way over an “insecure” line of communication. In this part, let’s drill into this concept of “insecure” communication.
When working with SSH, there is a lot of discussion about “securing” the information that you transmit to protect it from prying eyes as it travels from system A to system B. This begs the question, how are these “prying eyes” able to intercept and read the messages you transmit anyway?
In order to think through this, let’s consider a model: the postal system.
The Postal System Model
Imagine you just visited Florida and you want to send a post card to a friend in Nevada.
You write out your message on the post card, address and stamp it, then drop it into a large mail collection box at your local post office.
Your post card has now entered the postal system. There are a couple of things we need to think about now that your message has entered the postal system.
An Insecure Communication System
Except for an added mark or two to indicate processing, the post card will be moved around in the same form it was in when you first dropped it in the mailbox. The postal system does not concern itself with hiding the contents of messages that come into the system on post cards. It will deliver whatever comes into the system as is. That being the case, we can say that the postal system is an insecure communication system.
Sending Insecure Messages Through the Postal System
As your post card travels from Florida to Nevada, it will make multiple stops along the way. At each stop, the post card will undergo some type of processing so that it can be routed to the appropriate next stop.
At any point here, your post card message could be read by anyone at one of the postal facilities because it is clearly written. Let’s say your card has to go through Kansas on its way to Nevada. One of the post office employees in Kansas takes the box that contains your post card off of one truck so he can load it onto another truck. Your card happens to be at the top of the pile of letters he’s carrying.
The postal worker casually glances at your card while he walks over to the outgoing truck. Your message is written out in such a way that it can be easily read and comprehended. When a message is written out this way, it is called plaintext. Because your message is written in plaintext, the worker quickly reads your nice message about Florida vacations and begins daydreaming about his next vacation.
No harm here technically, but now you see what can happen when you write a message out in plaintext. What would happen if you needed to mail a message with information on it that you did not want anyone else but the recipient to see? Not only is the communication system (the postal system) insecure, but so is the message itself.
Sending Insecure Messages Between Computers
So what does this look like when we’re dealing with actual computer systems? Let’s send an insecure message from Computer A to Computer B over an insecure communication system. To do that, we will use an insecure communication protocol, HTTP, to send an html document over the Internet from Computer A to Computer B.
The message will be formatted based on the rules of the HTTP protocol. These rules allow the content of the message to be transmitted in plaintext, just like our post card. The message will also need to go through several intermediary servers on its way from Computer A to Computer B, similar to how our post card moved through the postal system.
Setup
In order to send our insecure message and analyze what happens when the message travels over the network, we will use a couple of tools. The first tool is an application called curl that allows us to send and receive HTTP requests and responses.
The second application is a packet analyzer tool called wireshark that allows us to monitor the chunks of data coming across the network card of whatever system it is installed on.
Go ahead and get wireshark set up on your system if you do not have it. Here is a tutorial for doing that on a system running Ubuntu: Click for tutorial
Once you have the application running, you want to click on the blue shark fin in the upper left-hand side of the tool’s interface to start collecting network traffic information.
Sending HTTP Messages
Now that we are monitoring network traffic, let’s get some HTTP traffic flowing. To trigger an HTTP message to be sent over the internet, we will make an HTTP request to a site called example.com. This website serves files to systems that make requests of it using the insecure HTTP protocol.
Open up your terminal and use curl to make a request to the example.com site by typing curl example.com
You will see the body of the response to this request print out on your terminal.
Reading HTTP Messages In Transit
Now that we’ve both sent and received messages between two computer systems using the HTTP protocol, let’s see what those messages looked like as they crossed our local computer’s network card.
In the wireshark application, you can click the red square button to the right of the blue shark fin to stop monitoring the flow of network traffic on your system. From there, you can filter out the display of network activity by protocol. Here we have typed in “http” as a filter.
Then, we sorted the list of packets by the source. The highlighted line above is a packet of HTTP traffic that went from the example.com server to the local system.
We can get a print out that follows the flow of HTTP messages sent back and forth by right clicking on the highlighted HTTP packet line pictured above. Once you right click, a menu will pop up that has a Follow menu item. Scroll down to Follow and from there click on HTTP Stream.
In the image above, you will see an excerpt of the HTTP conversation between the local server and the example.com server that occurred when we ran the curl example.com command. The red text is the HTTP request that the local system sent out, and the blue text is the response from example.com.
Notice that these messages are insecure because they are written in plaintext, like our post card. Furthermore, just as the postal system worker in Kansas was able to read through our post card, we have now read through these insecure digital messages as they traveled to their destinations.
Why Use An Insecure Communication Channel?
You may wonder why we use an insecure system of communication if we do not want our messages read by any unintended readers? It may help to think about the postal system model again here.
When it comes to sending letters, it makes sense to leverage the infrastructure of the postal system. Even though you might prefer that the postal system take added steps to secure messages on all post cards, you have to work with the system as it is. It would be a very expensive endeavor to try to create your own mail delivery system. So instead of doing that, you have to find ways to work around characteristics of the existing system that you do not like.
When it comes to delivering messages from one computer system to another over the Internet, you are dealing with a communication system that is even more massive and complex than any postal system. It is a massive network of networked computer systems whose infrastructure relies on standards from decades ago.
Even though Internet users’ security standards increase as time goes on, everyone still has to leverage a system that was built when those security standards did not exist. We find ourselves in a situation wherein we need to take advantage of a powerful channel of communication despite its lack of native support for our ever increasing standards for communication security.
Up Next…
In the next part of this series, we will look at the role SSH plays in tackling the problem outlined above. We will see how SSH aims to secure the message itself before it is sent across an insecure communication system.
Articles in the What Exactly is SSH?? (The Secure Shell) Series