Summary: Want to encrypt an otherwise cleartext transmission? SSH Tunneling may be the tool for you.

Over the last two weeks I've shown the syntax of SSH tunnels. Either can be created using command line arguments or via entries in ~/.ssh/config, as follows:

Local Forward specified on the command line

-L port_on_client:destination_host:destination_port

Local Forward defined in ~/.ssh/config

LocalForward port_on_client:destination_host:destination_port

Remote Forward specified on the command line

-R port_on_server:destination_host:destination_port

Remote Forward defined in ~/.ssh/config

RemoteForward port_on_server:destination_host:destination_port

Most frequently, people use SSH tunnels when the tunnel's endpoint is either the SSH client or server. For example they may have an account on the IMAP mail machine at their ISP so they would SSH to it and point the forward at localhost (the IMAP server):

  # set up forward
  home_desktop$ ssh mail.my_isp.net -L 1143:localhost:imap
 
  # read email via the encrypted tunnel
  home_desktop$ mutt -f imap://user@localhost:1143/

Or they're doing a remote forward in a similar way, for example this firewall-traversing, security policy-violating version:

  # connect out to our home machine before going home for
  # the evening
  work_mailserver$ ssh home_machine -R 1143:localhost:imap
 
  # read our work from home through the tunnel
  # without using the corporate-mandated PPTP VPN.
  home_machine$ mutt -f imap://user@localhost:1143/

However, there is no reason the endpoint of the tunnel need to be the SSH client or server machine. For example if you did not have shell access to the work_mailserver machine in the second case above[1] then you could still create a functional SSH tunnel as follows:

  # From your Linux desktop at work, you SSH to your machine
  # at home.  Connections through the tunnel from home will
  # get forwarded to work_mailserver, which is a different
  # machine at your office.
  work_desktop$ ssh homemachine -R 1143:work_mailserver:imap

In this case the IMAP connection is *not* encrypted end-to-end. It is encrypted inside the SSH tunnel from home_machine to work_desktop, but is cleartext from work_desktop to work_mailserver. This means that your email content and your mail password is being sent over the work network in the clear.

Is this a problem? It depends on how much security you need. If you normally read your email from work_desktop using plain unencrypted IMAP, then your password is already going across the work network in the clear. The only parts of this connection that are unencrypted are the same parts that were already unencrypted when you checked your email at the office. So, you have successfully enabled yourself to check email from home in a no-less-secure way than you do being in the office itself. Excellent.

So let's revisit the first example above. Say we have don't have SSH access to mail.my_isp.net. This means you can't directly log into mail.my_isp.net with a LocalForward and have your IMAP connection encrypted end-to-end. However if you have a shell account on shell.my_isp.net that is available via SSH, you can do the following instead:

  home_desktop$ ssh shell.my_isp.net -L 1143:mail.my_isp.net:imap

Your IMAP connection will only be unencrypted between the ISP's shell server and mail server - the rest of it will be completely encrypted. You could do this from anywhere, from work, a friend's house, or an Internet cafe.

Again, is this safe? Well, the only people who can read the cleartext traffic between the shell machine and the mail machine are those folks who have root access on one of the two machine, or a machine that can sniff the network traffic between those two machines. Hopefully, that would only include the legitimate administrators of the ISP, who would have several other ways of reading your email or resetting your password anyway. If an attacker has this level of access on the ISP's machines, your data was already in trouble. So again, setting up an SSH LocalForward allows you to check email from anywhere with encrypted connections except for that last leg which was never crypto-enabled anyway.

This was, in fact, the very setup that Alice was using to check her email.[2] Alice didn't have shell access on her ISP's mail server, but was using a LocalForward from home and/or work to access the mail server (via POP in her case) with an encrypted connection for all but that last leg.

Bob said it wasn't secure. Alice said it was. Both Alice and Bob understood that the last bit of her connection was not encapsulated in any encryption, so I did not need to clear that up for them, which was the point of contention I imagined they had. So, to their original question "is Alice's email access secure" I had to reply "As secure as the link between the shell server and the mail server." I don't think they were happy with my response. After much debate, we decided that they both knew the facts, and that her threat model considered the short unencrypted connection to be secure enough, and his did not. They agreed to disagree, and I decried that they both needed to buy each other dinner.

Tunnel Forwarding Examples

Some time next month[3] I'll dedicate an issue of the newsletter to many sample SSH tunnels. Most uses of tunnels are variants of the examples I've already given - tunneling POP, IMAP, or SMTP, getting into your office from home by using a RemoteForward back through your firewall for SSH or a web proxy, etc. If you have any weird useful tunnels you like to use, drop me a line and I'll include them.

Happy Birthday Results

Thanks to all 50ish people who wished my sister a Happy Birthday. You guys confused and amused her more than I would have imagined. What an excellent turnout.[4]

And congratulations to Jennifer Welch, who was person #20 and gets a free signed copy of "Building Linux VPNs."

NOTES:

[1] Say they're running Exchange, god forbid.

[2] Yes, believe it or not, I'm finally getting back to the question that started this whole topic. Luckily I contacted Alice and Bob before I started writing it.

[3] I think I need to give everyone a break from crypto-related issues before they kill me.

[4] I suspect that the possibility of free stuff might have helped -- I'm always willing to bribe.

Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He's really going to try to stop talking about crypto for a while. Promise. Well, with the exception of the upcoming Easter Egg Hunt. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2003

This is the March 16, 2003 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.