Top

Securing E-Mail on Mac OS X with SSH

July 26, 2004

What can be more expensive than ordering a venté mocha latté with a triple shot at your average wi-fi hotspot?  It might just be checking your e-mail.

Most passwords for retrieving and sending e-mail are sent in the clear (i.e. unencrypted plain text.) This isn’t that big a deal when you’re connected to your network with a physical wire, as in order to “sniff” that plain text password, someone would have to get physical access to the network.  On most modern switched ethernet networks, they’d not only have to have physical access, but they’d have to have it at the right place.

When you use wi-fi, though, all bets are off.  It only takes a few minutes of Googling to find off-the-shelf programs that will let you sit on a wi-fi connection and collect passwords and entire messages as you suck on your caffine fix.  (You’re not using that e-mail password for anything else, are you?)

One method of avoiding this problem is to use a Virtual Private Network (VPN) to tunnel your connection onto the net in a safer spot.  If you’re not up to rolling your own VPN, a lot of people have said nice things about HotSpotVPN, a relatively inexpensive (about $9 a month) service offered to address this specific problem.

Unfortunately, I had real mixed results trying to get it working on OS X (your mileage may vary—when I gave up the trial, the HotSpotVPN folks said they were working on a re-write of the instructions for OS X.)

Fortunately, if you don’t have luck with that (or you’re a cheapskate, like me), and have access to a Secure Shell (SSH) connection, here’s another way.


SSH is the secure and encrypted replacement for Telnet—it’s a way to log into the console of a remote machine (usually a Unix/Linux/OS X box) through an encrypted connection.  If you have a web hosting account on a Linux server somewhere, you probably have an SSH account along with it.  It might be worth checking with your web host to see if they mind you doing this, however…

At any rate, one of the niftier things about SSH is that along with offering secure console connections, it can actually tunnel other connections over it.  Not only remote connections, but local ones—this means that you can redirect your IMAP or POP3 and SMTP connections through SSH, and the connection to your mail server will be made from the other end of the tunnel (the server end)—even if your mail server is somewhere else entirely.  At the point that the connection pops out of the tunnel, your passwords and e-mail are once again in plain text, but hopefully that will be on a server with a lot better physical security than your average wi-fi hotspot. Anyone sniffing locally isn’t going to see anything useful.

Basically, what we want to do is redirect our e-mail ports (110 for POP3, 143 for IMAP, and 25 for SMTP) through the tunnel.  Unfortunately, we can’t easily do this directly on OS X, as by default ports lower than 1000 can only be redirected with root access (which isn’t undoable, but it’s a pain to automate).

Fortunately, we don’t really have to use those ports.  Most mail programs (such as Mail.app or Entourage) will let us specify what port we want to use for each service (look under “advanced” or “server” settings).  We can use a non-standard port that’s easier to redirect, and simply map it to a different port at the other end of the tunnel. 

You can use whatever you like, but for illustration we’ll simply append “40” to each port number—giving us 40110 for POP3, 40143 for IMAP, and 4025 for SMTP.

To prepare your e-mail application, go in and modify your account settings (or set up a new account to test with) to connect to 127.0.0.1 as the server (this is the “localhost”—your own machine), and the appropriate port number as above—40110 for POP3, 40143 for IMAP, and 4025 for SMTP.  All other settings should stay as they normally would.

Now to set up our tunnel.  We could do all of this through the OS X terminal command line, and even automate it with a shell script, but that’s a pain.  A much more simple approach is to download and install the freeware SSH Tunnel Manager.

Once you have SSH Tunnel Manager installed, launch it and click on “Configuration”.  Click on the “+” button to add an tunnel.  Give it an appropriate name, such as “Mail” or the name of your mail server.

The login is your username on the SSH server, and the host should be the DNS name of your SSH server.  The port should be 22, the standard SSH port, unless you’re required to use something else.

Now, under Local Redirections, click the “+” button to add a new entry.  If you’re using POP3 (and the port numbers above), the port on the left would be 40110, the Host is the DNS name of your mail server (mail.mydomain.com, or whatever), and the port on the right side is 110.  If you retrieve your mail via IMAP, substitute 40143 for the left port, and 143 for the right port.  Add an additional entry for SMTP, using 4025 for the left port, and 25 for the right port.

Now, highlight your first entry and click “Options”.  Unless you have a reason to set things otherwise, you probably want “Auto connect”, “Handle authentication”, and “Compress”.  For the moment, leave the rest unchecked, and set the Crypt method to the SSH 2 standard “3des”.

Note the command line it shows at the bottom.  Launch your terminal window, and type the command line in exactly as shown (case counts, remember).  If you receive an error, try varying the settings (most likely Comress, Crypt Method, and possibly Force v1) and re-enter the command line until it is accepted without errors.

Once you’ve got a command line that works in Terminal, leave it running and bring up your Mail program.  Try the protocal you just configured (i.e. check your mail if you were working on IMAP or POP3, send a test message if you were working on SMTP).  If it works, great—you’re done with that one (but be sure to configure and test both the send and receive sides).  If it fails, Quit (cmd-Q) the terminal, re-open it, and try adjusting the settings as above.

Once you’ve got them working, Quit the terminal, and close the preferences window on SSH Tunnel Manager.  You should now have a small SSH Tunnels window with the name of your connection, and a right-pointing triangle at the right.  Click the triangle to connect.  If all has gone properly, you should be prompted for your SSH password in a few seconds.  Enter it, and your connection should be live.  Try sending and receiving mail.

If all of that has gone well, you’re now set to send and receive mail securely.  You could use a seperate account in your mail program for this only when you’re on a public wi-fi connection, but unless you’re on a dial-up connection (where the encryption overhead can make a big difference), you may want to consider using it all the time.

This is particularly true if you use wi-fi at home—even a normal low-power wi-fi access point can be accessed from surprising distances by someone with an inexpensive or homemade antenna.  If someone has time to kill and access to your wi-fi, WEP, WPA, and MAC code filtering can all be handily broken, and someone could be listening in when you least know it.

Another bonus is that if your ISP blocks SMTP on port 25, this gets around it—everything you do actually runs over port 22, which should be open in most cases.

Once you’ve gotten your e-mail secured, it’s worth giving some thought to what else could use a little security.  FTP passwords, in particular, are also sent in clear text.  Now you may not be working on your web site from the coffee shop (although you might be at home), but it’s easy to forget that things like blogging clients, mobile IP address updaters, “I’m online” indicators for chat and other utilities may use FTP to log into your website and do their thing.  You can add another tunnel using the procedure above for FTP, using port 21 as the “right hand” port.

Related: Securing Mac OS X

—–

Be Sociable, Share!

Comments

One Response to “Securing E-Mail on Mac OS X with SSH”

  1. Craig Bailey on July 12th, 2005 5:27 am

    I’ve experimented with SSH Tunnel Manager, and have noticed that to establish the tunnel, the software asks me for my password. Is _this_ password flying through the air as clear text? Or is it encrypted? If it’s clear text, doesn’t that render the whole system fruitless?

Got something to say? [privacy policy]

You must be logged in to post a comment.

Bottom