In the first part of this article I introduced Public Key Encryption and SSH. In this part, we will look at how to use SSH to secure your traffic when using an untrusted network.
As previously mentioned, this was partly inspired by events from SuperHappyDevHouse. At the last event we wanted to promote the idea of encrypting your traffic. One of the ideas was to simply write out the command for encrypting your SSH traffic on whiteboards that were placed around the house for collaboration. This was a step in the right direction as people came up to the group of people I was with and asked for help. At least we brought awareness to this problem.
The code we posted was simple:
sudo ssh -l <username> -NfD <port> <ip>
This creates an SSH tunnel that acts as a SOCKS5 proxy server using the specified port. All traffic going through this proxy will be tunneled through SSH and thus be encrypted. Before we get ahead of ourselves, let’s take a look at the options we specified.
- -l – Specifies the username on the remote server
- -N – Tells SSH not to run any remote commands.
- -f – Has SSH run in the background.
- -D – This is the option that actually creates the SOCKS server.
Thank you Mike Lundy for preparing the command for everyone!
Now that we have SSH running in the background as a SOCKS proxy server, we need to configure our applications to use it. For our example we will look at configuring Firefox to send all of its traffic over SSH.
Under Tools->Options, navigate to “Advacned” and click on the “Network” tab. When you click on the “Settings” button, it will bring up options for “Connection Settings.” Here you can manually configure your proxy settings by clicking the “Manual proxy configuration” radio button and then under “SOCKS Host:” type “localhost” and the port specified in the ssh command you issued earlier under “Port.” Click “OK” and you now have all of your Firefox traffic being tunneled through SSH.
While using either an open wireless network at a coffee shop, an untrusted network, or virtually any open network, your data is exposed. Data passed around on a network is normally unencrypted which means anyone can read it. Imagine the type of data you send over the network: passwords, private messages, more passwords! Have you ever used FTP to update your site? Everytime you do your password is sent in plain text. What about checking your POP email? Again, your password is sent in plain text!
While at SuperHappyDevHouse we have many people on the same unencrypted wireless network. At SHDH13 someone was passively sniffing the network; This person posted a list of collected email address/passwords on the SHDH wiki. The post was quickly taken down and the people were immediately notified; This was a wake up call for for people using unencrypted networks. How can we prevent this from happening again? The solution to this problem is obvious: encrypt! The question is how can we easily do this?
First let’s get some background on something called public key encryption (PKE). PKE consists of two parts: the public key and the private key. The public key can be used by anyone; The function of this key is to encrypt data that is meant for your eyes only. The private key on the other hand should be protected as it decrypts any messages encrypted by your public key. So let’s say Person A, Alice, wants to send a message to person B, Bob. Alice doesn’t want a third party, Eve, to read the message so she wants it encrypted. For simplicity’s sake, let’s pretend Alice and Bob already have established trust and have each others public key (otherwise we are still open to man-in-middle attacks). Alice will encrypt her message with Bob’s public key and then send it. When Bob receives it he will decrypt it with his private key; his response will be encrypted with Alice’s public key and Alice will decrypt it with her private key. That’s the jist of PKE; we could go more in depth and look at digital signatures, but that would be beyond the scope of this article.
So now that we have some background on PKE, let’s talk about SSH. SSH or Secure SHell is meant to replace insecure protocols such as Telnet, FTP, and RCP (SSH, SFTP, and SCP respectively). SSH uses PKE to encrypt its data that is sent over the network. A problem we can see is that SSH seems to be limited in it’s scope. What about POP3 email or regular HTTP traffic? How do we encrypt that? With SSH we can setup a proxy server that will allow us to to send our data through an encrypted “tunnel.” In the next part of this series, we will look at setting up these tunnels and configuring our applications to use them.