Secure wireless email on Mac OS X

After more than a year of implementing my own measures, I think it’s time to help raise awareness of email security. And in doing so, document the way I use SSH to secure email when I’m on a wireless network. If you’re concerned about strangers having open access to your usernames and passwords, and all the email you send and receive while connected to a public wireless network — whether you use a Mac or not — you’ll want to read this.

Who’s reading your email?

Know what happens to your usernames, passwords, and personal email messages when you use public wireless networks? Know that this data often travels freely through the air in clear text? And do you know how dead simple it is for anyone else on that same network to intercept your information and use it against you? On the flip side, did you know you can scramble this data to make it completely unintelligible, even if someone else does intercept it?

With SXSW Interactive and several other upcoming conferences looming on the horizon, I’m reminded once again that I’ve promised quite a few people that I’d write out my steps for securing email on the Mac as it passes from my computer over a wireless network.

There are many means to an end when it comes to security. No one solution is the best for everyone. I am, by no means, a security expert. I don’t claim to know all the answers, nor the best means of securing your data and communication. Some of the tips below are Mac-specific, and will only prevent other people on a wireless network from easily sniffing your information. Not all of them may be relevant to you. It shouldn’t take someone longer than 15-30 minutes to configure a Mac, once they understand what needs to be done.

Why should I secure my email?

I’m amazed when I see friends naively checking email wirelessly without using some type of secure connection. They open up their laptop in a public setting, select any available wireless network, and immediately pop open their email client to start sucking down their messages.

Many conferences are now widely known for having open wireless networks available to hundreds of attendees at once. The network may be sanctioned by the conference organizers, or not. Cafes, bookstores, and public libraries offer free or pay-per-use wireless hotspots. The amount of data and personal information traveling freely though the air is at an all-time high.

The majority of these wireless networks are configured with the lowest possible security settings, so that customers can connect to the network as easy and trouble-free as possible. This allows just about anyone with a wireless-capable laptop computer to walk into a cafe, grab a cup of coffee, and start browsing or checking their email immediately.

What you may not realize is how easy these low security settings allow someone else on the same network to spy on the data passing around on that network. Just because you’re the only person who can see your laptop screen, doesn’t necessarily mean you’re the only one who can see the email message you just got from a friend. Just as easily as someone could sit near you in a quiet cafe or library and overhear your entire verbal conversation with another person, so could they “listen in” on all the usernames, passwords, and messages passing to and from your computer. (And everyone else’s computer for that matter.)

The art of interception

How can a stranger “intercept” my personal info?

Easier than you think, if you’re not being careful.

If you’re not doing something to secure your email, your usernames, passwords, and messages are most likely traveling through the air as clear text. Plain, unscrambled, unencrypted, easy-to-read-by-anyone text. Anyone connected to the same network can “sniff” for data passing through the air, then grab and log that data on their computer. All without you even knowing it. You have no idea how much of your digital conversations are being overheard.

Information is traveling to and from your computer in the form of small packets. Each time your computer receives those packets, it reassembles them, and displays the email you received, or the web page you’re trying to view. Utilities called packet sniffers can detect or “sniff” these packets of information flying around on the network, collecting it for analysis. SysAdmins use packet sniffers and network utilities to monitor and troubleshoot their own networks. Now, packet sniffers are widely and freely available, and are easy for anyone to use.

If you’re concerned, you have a reason to be.

The important thing to note is that packet sniffing doesn’t modify the information being sniffed in any way. So you can’t tell whether your information has been seen by anyone else or not. There’s no stamp on the data that says it’s been collected by another machine. There’s no open-envelope icon on your email message to let you know that someone else already read it. Again, it’s like someone listening in on your conversation, but without you knowing they’re doing so.

Another person or machine doesn’t need to be near you to sniff your passing data. As long as you and the sniffer are on the same network, your data can be sniffed.

Easy methods for anyone

So how do you secure your email and keep it private from curious eyes? What does it mean to read my email “securely”?

As mentioned above, there are many means of safeguarding email communication. They each have varying degrees of security and capability. Methods range from access to a trusted VPN, to certain secure web-based email applications (webmail), to allowing connections over SSL, sometimes known as POPS or IMAPS.

If any of the above options are available to you, you should investigate them further before taking any of the steps below. Setting up a connection over SSL is often as easy as checking a box or two in your account preferences, and never needing to think about it again, let alone deal with anything below.

SSH tunnels

If a VPN or POPS/IMAPS isn’t accessible to you, and if you want use of your regular email client rather than using webmail, you may want to look into SSH to protect you when you’re on a wireless network. If you have access to a server that supports SSH, you can create a “tunnel” directly to that server, and pass all your information through the tunnel to the server as encrypted, unintelligible data.

The SSH tunnel acts as a two-way private channel between your computer and the SSH server. Only your computer (the SSH client) and the SSH server can make sense of the encrypted data. Once incoming data safely reaches your computer, it is then safely decrypted, and reassembled for you to see as normal. The opposite happens for outgoing data: the client software on your computer encrypts the data, sends it though the tunnel, then the SSH server decrypts it and passes it along as normal to its intended destination. Once your data is passed on from the SSH server, it’s then traveling unencrypted (unprotected), albeit almost always over a wired network. It’s much easier to sniff your data while it’s traveling through the air on a wireless network — this is the portion that can be protected by using SSH to create a tunnel, bypassing the lack of security with wireless connections.

The process is transparent and seamless to you and to anyone you send email. Even though information sent through an SSH tunnel can still be sniffed by someone else mid-stream, it appears as garbled and unreadable to those outside the tunnel.

SSH tunnels need to be created each time you join a new network, and before you start passing any data back and forth. The tunnel is used for multiple data transfers for as long as you need it. Once you disconnect from the SSH server, the tunnel is “destroyed” and never usable by anyone else.

Passwordless SSH access

If you use your own computer, use it often, and you’re the only one who access it, you may want to set up “passwordless SSH access”. Typically, each time you ssh into a server, the account password needs to be provided manually. However, another means of handling authentication can eliminate the need for a password, simplifying the connection in terms of what you need to do and see.

The entire process of creating public/private keys for passwordless SSH access is described about halfway down on Page 2 of Jason McIntosh’s “Secure Mail Reading on Mac OS X“. It may sound a little tricky on first read. But it’s really not very difficult. Setting up public and private RSA or DSA keys can be as simple as the execution of a few Terminal commands. Alternatively, if you don’t want to do the whole thing in the Terminal, you need the temporary ability to view hidden file locations on your Mac (for editing) and to transfer files to your server.

Once enabled, you’ll be able to SSH into the server from that computer without storing a password, or without typing a password each time you want to connect. I automate as much of this process as possible, so that I use it every single time. If it’s a pain to secure my email every time I want to use it, I’ll eventually stop securing it.

Port forwarding

The process of receiving and sending email needs to be redirected through the SSH tunnel to take advantage of its security. This is done by using port forwarding. Every type of network data transfer uses a certain port, identified by a standard port number. POP mail usually travels over port 110, while IMAP usually uses port 143. Sending mail via SMTP uses port 25. Remaining network services on your computer use other ports.

Typically, port forwarding is set up and controlled though the Terminal with long command-line instructions that intimidate a designer like myself. Fortunately, there’s a GUI tool available to automate the creation of tunnels and custom forwarding of any ports we want to use…

SSH Tunnel Manager

SSH Tunnel Manager (hereafter, SSHTM) is the convenient connection between SSH and your email client. It’s a FREE Mac OS X utility that helps create SSH tunnels and automatically sets up all the ports that need forwarding. It’s simple to configure, once you know what you’re doing.

The only downside of using SSHTM is the current documentation. It’s written for Version 1 of the software, and its instructions were still a little cryptic to me. I (and the developer) recommend using the latest beta build (2.0b3, as of right now) rather than Version 1. The steps and screen captures below relate to Version 2.0b3 of the software. Other newer or older versions may be slightly different.

Windows users, note: Several options are available for GUI-based SSH tunnel managers. One possibility might be Han-soft’s Internet Secure Tunneling, which appears to do similar things as SSHTM.

SSHTM setup

In SSHTM’s main window (SSH Tunnels) click Configuration to add a new tunnel. The Preferences window opens. Click the [+] button below the tunnel list to configure the first tunnel. Enter a name for this tunnel, your ssh user name, and the server location. The standard port for SSH is 22 — most likely, your server uses port 22 as well.

Next, you’ll need the mail host and port number for each server to which you’ll be connecting. For instance, my main mail server is mail.stopdesign.com. If I want POP mail, I’d connect to port 110 on the server. IMAP would use port 143.

You also need to choose a unique local port number to correspond the server’s port number for each connection you want to make. Use a unique local port number for each mail server and its mail protocol. Local port numbers need to be greater than 1023, and shouldn’t conflict with anything else running on your machine.

My system for choosing local port numbers is simple. I take the server’s port number for that protocol (110 for POP) and add a 0 to it for the first POP connection, making the local port number 1100. Since I have more than one POP connection, I iterate that series to 1101, 1102, etc for each additional POP connection. For instance:

Local port

Mail server

Remote port

1100

mail.stopdesign.com

110

1101

pop.sbcglobal.yahoo.com

110

1102

mail310.pair.com

110

1103

mail.dbowman.com

110

You can also send all outgoing mail through the SSH tunnel if you wish. Remember: outgoing mail usually uses a different server or port number, so you’ll need to configure an extra forward in SSHTM. For outgoing mail (port 25) I add two 0s, using 2500 for the local port number.

Since you want the redirects through the tunnel to happen locally on your computer (before the data leaves your computer) you’ll use Local port forwarding. In the Preferences window, under “Local redirections”, click the [+] button to add a new forward. The local port number you chose for this server/protocol goes first on the left side, then the server/host name, then the server’s port number on the right. Enter as many forwards as you need. My Preferences window looks like this:

The last thing you may want to change is to have the tunnel you just configured automatically connect each time you open SSHTM. Click the Options... button and ensure the “Auto connect” option is checked in the options drawer. Other options for the tunnel are available here, and the command line used to create the tunnel is visible in this drawer:

Close the Preferences window. Once you have one or more tunnels configured, the SSH Tunnels window shows your available tunnels, with a gray start button to the right of each one. Test the configuration by clicking the start button. You’ll see a couple of simple status messages flash below the tunnel name. Hopefully, after a few seconds, the tunnel will be successfully created, and you’ll have a window that looks like this:

Click the stop button to kill the connection and destroy the tunnel. If you didn’t get the “Connected” status message, recheck your tunnel configuration, or verify that you really do have SSH access to the server you’re using.

Note: If you didn’t select “Auto connect” in the tunnel’s options, you’ll need to click this start button to create the tunnel each time you open SSHTM.

Email client setup

One last step to securing your email. To take advantage of the Local port forwarding of the SSH tunnel, the settings of your email accounts need to be tweaked slightly. These steps are specific to Apple’s Mail application (Version 1.3.9 at the time of this writing). But the same changes should be possible to make in other email clients.

Caution: As with any significant change, it’s always a good idea to back up before proceeding. In this case, backing up your Mail preferences file is a good idea. The preferences file should be located here:

~/Library/Preferences/com.apple.mail.plist

Open Preferences in Mail, and go to Accounts. Under Account Information, change “Incoming Mail Server” to localhost.

If you’re running outgoing mail through the tunnel, you’ll also want to change the SMTP settings for this account. If localhost already exists as an option in the pull-down menu, select it. Otherwise, click on the Server Settings button under “Outgoing Mail Server (SMTP)”. Change “Outgoing Mail Server” to localhost, and “Server Port” to whatever local port number you chose for outgoing mail. (I used 2500.) If your SMTP server requires some type of authentication, change the settings here to match those requirements. Otherwise, leave “Authentication” set on None.

Finally, go to the Advanced tab of the Accounts pane. Change the port number to the local port number you chose for this account’s server/protocol. This number should match up with the number you entered for this server/protocol on the left side of the “Local redirections” section in SSHTM’s Preferences window. (For my first POP connection, I used 1100.)

You’ll need to make those changes for each Mail account you want to run through the SSH tunnel. Save your changes after modifying each account, then quit Mail.

You’re done

Launch SSHTM. Allow your tunnel to automatically connect, or click the start button to manually connect the tunnel. Then launch Mail again. Assuming everything is configured and working correctly, your email should automatically be encrypted, garbled and safe from spying eyes on the same wireless network. All your incoming and outgoing messages will look and read exactly the same to both you and your recipients. You shouldn’t notice any visible differences to your email at all.

This one small extra step of launching SSHTM (allowing the tunnel to be created) is the only extra thing you need to do each time you want to connect and use Mail.

If you ever Command-Tab over to Mail, and see a grayed out “In” box, it might mean that SSHTM somehow disconnected from the server, destroying the tunnel. Usually, your SSH client will automatically disconnect from the tunnel if your computer shuts down or goes to sleep. Brief outages in your wireless connection can also cause a disconnection. To receive or send email again, just go back to SSHTM and create the tunnel again.

If you choose to enable passwordless SSH access, you may want to split up the task of securing your email into two chunks. Set up the public/private keys one day. And continue with the SSHTM portion another day.

That’s it! You’ve protected your email account from wireless sniffing through SSH tunneling and port fowarding. These steps should help keep your email more private than you thought it was. Work for you?

74 comments

My first post here, but this is a topic that I have thought about for a long time.

As an advice to anyone reading – if you attend a university, particularly one with lots of commuter students, they typically have a VPN that anyone can use. Talk to your IT department and see if they have any tips for you.

For those who use the command line a bunch, I would also recommend SSHKeychain. It is another free utility for OS X that manages your keys for you and securely stores passwords in the Apple Keychain. It also does automatic SSH port fowarding and will close the connection when you put a laptop to sleep and reopen it when you come back. I use it all the time. Works like a charm.

That is a really great user-friendly way to set up mail encryption and a person does not need to be real skilled with computers to set that up. I will definitely pass that article on to a few of my friends.

Nice write up, Doug. I would re-emphasize to readers that you ought to first check with your ISP and see if they offer IMAPS and/or SMTPS before doing this.

Still, though, this would be a great option for someone who can’t get SSL through their ISP!

Daniel Von Fange

7:57 pm, Feb 7, 2005

Yes, I was about to ask, what about IMAP over SSL? (It can be a lot simpler.)

Thanks for the tutorial though!

Adam

8:03 pm, Feb 7, 2005

For Windows SSH tunnel management, I’ve used both the Internet Secure Tunneling tool that was mentioned (which requires registration), and also SSH Tunnel Client, which is freeware and can be downloaded from the address below. In addition to starting tunnels automatically with Windows, it also allows you to group several tunnels together and connect/disconnect them as a unit.

This is a great write up, thanks. However, it only secures your data to and from your mail server. This is certainly useful, but if its not encrypted from sender to receiver, it doesn’t really matter if it’s encrypted from your mail server to you. Your write up does help to keep someone from sniffing your email off of an open WiFi node.

If you’re interested in securing mail end to end, I wrote up a how-to for using GnuPG encryption with Apple Mail. However, it has the downside of needing the other person to have encryption abilities, too. Maybe one day everyone will have public/private keys, but I’m not holding my breath. But it works in the biz environ where people would go through the trouble of setting keys up.

bc: Yes, the whole point here is to provide a means of preventing sniffing when you’re on a wireless network. This prevents strangers from getting usernames and passwords, since those only travel between your computer and the mail server.

And yes, the messages themselves could be intercepted after it leaves your mail server and is on its way to the recipient. But, to my knowledge, this requires a little more knowhow, and access to one of the relaying servers. The same is true of any of the solutions above (VPN, SSL, secure webmail) if the message travels outside a corporate network. What all of the above methods do well is prevent anyone else on the local network from seeing your email and data as clear text.

And as you say, the method you document requires that everyone you send mail also have PGP properly set up for it to work all the way to the recipient. Very few people will do this by themselves, because of that. So yes, we’d need to wait until public/private key authentication is seamless and invisible to everyone.

Daniel Stockman

9:42 pm, Feb 7, 2005

Excellent post! Now the herculean task of translating it for my new-iBook-toting sister… (No longer titanic, thanks to you ;D)

Indeed, great post. Unfortunately, there are many, many services still out there that simply do not supply any means of securely accessing one’s email at all.

One very notable service is Time Warner Cable’s Road Runner who offer neither SSH access or POP3-over-SSL (POP3S) communication via their servers and our mail. I actually had a conversation about this with Road Runner (and later blogged about it along with some comments) and their response was simply that they “do not offer such a service at this time.” Needless to say, I immediately stopped using my @*.rr.com accounts for anything.

I can not for the life of me figure out why this would be so hard to do, either. Until big ISPs can do this, nobody’s going to be hitting their “Use SSL” checkboxes. That’s a shame, really, since it would be so easy to do.

I have also since gotten my mother and other select few automatically encrypting their mail to me with GPG. I think the GPGMail plugin for Apple’s Mail.app was linked to in a previous comment; that’s what I use. But as was mentioned earlier, this isn’t helpful at all for keeping the username/password secret. *Sigh*….

This relieves the user from having to remember to open SSH Tunnel Manager before checking one’s email, which is sure to trip up dear ol’ Mom. (Of course, if Mail starts up really quickly, it may need to wait for SSHTM to make the tunnels first.)

Anyway, great article, and I’m really glad that you’re helping to bring this security topic out into the open.

Albert

1:18 am, Feb 8, 2005

Luckily my own mail provider uses mandatory STARTTLS for IMAP. I have to provide username and password if I want to send mail to someone not local to the SMTP-server. Ofcourse STARTTLS is mandatory there too. Works great.

Any idea if a similar thing can be done, or is necessary, for web browsing? Or does an HTTPS URL sort this out?

Riot Nrrrd

9:08 am, Feb 8, 2005

I would’ve thought this was all common knowledge by now.

Anyone that gets (and sends) e-mail via any means other than using IMAP over SSL/TLS (and ESMTP with authentication+SSL/TLS for outgoing) is retarded. Any decent e-mail client these days does this stuff – Mail.app, Eudora, Thunderbird, Entourage, etc. There’s really no excuse. POP and non-SSL’ed connections are sooooo 20th Century.

AK

9:10 am, Feb 8, 2005

Am I being too paranoid when I get freaked out by all these “ways to protect your privacy” posts? Makes me want to unplug forever.

Rather than going on a rant here… does anyone know where one could get more information on securing your communication? What would help greatly is a letter I can send non-techy people that would educate them without causing a panic or making them look stupid.

My email address I have from the CS faculty can only be used through IMAPS (IMAP4 with SSL)… I think thatâ€šÃ„Ã´s a nice step (IMAP rules, and so does SSL :)). It works in pretty much every email client, but it used to be kinda hard to find an email notifier which understands SSL. When I couldnâ€šÃ„Ã´t find any, I mailed one programâ€šÃ„Ã´s author and helped him getting SSL working in his software (and got a free license for that ;p), and thereâ€šÃ„Ã´s a plugin for Trillian which can do it as well.

What I wonder about though… This of course prevents anyone from seeing my login information, which is nice, but is the mailâ€šÃ„Ã´s content itself secured? The way internet works, mail passes through a couple of servers, and I wonder if the mail servers use SSL for communication. Even if the sender as a secure connection to his SMTP… I donâ€šÃ„Ã´t have a secure SMTP btw.

In any case, I guess the interception of email as it travels over the internet to its destination is a much more unlikely thing to happen, while on local networks and especially wireless LANs basically *anyone* can tap in on the data communication.

Keep in mind… the only part of the traffic that is secure is the connection made from the client that issues the ssh command and the ssh server that the client connects to. Many ISPs do not give SSH server access, so the next best thing is to ssh into your home server. I wrote a related article on my website last year. Any comments appreciated.

Danny

12:45 pm, Feb 8, 2005

Fortunately, my ISP allows me to use the SSL option in Mail. It blows my mind that 99% of the population walks into a public wireless hotspot and communicates with clear text. There is NO public education on this matter, and there needs to be.

It’s not just e-mail, either. You are probably revealing more than you want to on a public network if:
* Your first and last name are your Computer Name in the Sharing pref, because that shows up in network traffic.
* You left Sharing on, which lists you in the Network icon in the LAN.
* You left your Bluetooth “Discoverable” mode on, so your name turns up during a Bluetooth browse.
* You are sharing your iTunes music library and your name is on the shared library.
* You use ANY login that is not HTTPS in your browser.
* You are using iChat/IM, 99% of which is also sent plain text. Ever heard of AIM Sniffer? No? Then read this:Wardating

For those of you asking about the security of your connection, you can always check what you’re sending over the network by using something like MacSniffer. I use it to verify that my secure connections are actually unreadable gibberish to eavesdroppers.

Some SSH servers and clients support “dynamic” proxying — they expose a SOCKS5 proxy on a local port. Local applications can use that to speak to whatever servers they need — that way if whatever apps you’re using support SOCKS you can easily tunnel their traffic through SSH without needing to set up a local port forward for every one.

Great writeup Doug! I have mine all set up already, but it is amazing how few ppl do because for the basic user it can seem quite complicated. For all you web developers, don’t forget secure FTP as well! Dreamweaver isn’t secure… I use Cyberduck (FTP program) if I’m at a cafe.

Nate

5:21 pm, Feb 9, 2005

Just a reminder that if your e-mail provider supports SSL/TLS encryption then securing your mail connection is as easy as checking a couple boxes in Mail Preferences (the ‘use SSL’ box on the Advanced tab of your account settings; and the SSL box in the outgoing mail server Server Settings). If your provider doesn’t support that, the SSH Tunnel Manager is your ticket.

This creates a secure SOCKS4 proxy over an ssh connection. I have added an alias to this command in my .bash_profile for quick access. A variety of apps on OS X support this ssh-specific SOCKS4 implementation. I use it regularly with Proteus, MSN Messenger, Firefox, and Thunderbird. Simply configure the proxy preferences for each app to use 127.0.0.1:8080 as a SOCKS4 proxy and you should be all set. See ‘man ssh’ for an explanation for what the -CNvv parameters do.

Brendan

2:50 am, Feb 10, 2005

excellent post, cheers. I’m to new to all of this so slowly trying to work my way through it all.
I’m behind a proxy4 server here at work, we use LotusNotes, and it seems they’ve blocked the standard pop3 ports as when I have my Powerbook on the network I cant get my email.
So i was thinking that by setting up a SSL connection, then maybe I can get port forwarding and the like to work and get my email here at work? Is this the wrong train of thought?
Anyways, have tried the setup as described, but cant get a connection to work. Apparently my web host supports SSL, albeit a ‘shared’ SSL. Does this matter, should I get a private SSL cert sorted? I’ve asked my host for the SSL settings, and also how I can get IMAP sorted out as it now looks like they support that.
Any hints/tips/links to try and get this working, or am I barking up the wrong tree?
PS I’m the only Apple on our work network, so no support AT ALL there.

james

7:52 am, Feb 10, 2005

… this gets me thinking about my wireless security habits in general. I got Matt’s suggestion above about SOCKS4 proxies and that works. Is there a similar, system preference-level setting I can use to secure my surfing in Safari?

Wow, good article. Thanks for taking the time to share your methods. Quick question for whomever may care to answer: I’ve started implementing this solution on my Powerbook, and I’ve got incoming mail working perfectly through the SSH tunnel. However, I’m having problems getting outgoing mail to work properly through the tunnel. Is there a specific server port that is required for outgoing mail via SSH? I was using port 25 before, but perhaps I have to change it? It’s just POP mail through an SMTP server. Thanks in advance for any suggestions…

Alex: Check with your ISP or host about their SMTP server. Some SMTP servers require password authentication (briefly mentioned in the entry). Othertimes, SMTP servers are set up with POP-before-SMTP or IMAP-before-SMTP Authentication, which means to authenticate, you must first execute a check mail through POP or IMAP before the SMTP server will authenticate you and relay your outgoing mail.

If the second case is the issue, you may have trouble using ssh for SMTP if your ssh username is different from your mail username.

For anyone using Pair as their host, this type of SMTP authentication is definitely what Pair uses. (I know, they were my previous host.) There’s a workaround for this. It’s described somewhere in their support forums on usenet. But it’s been a while since I did it, so I forget what the exact steps are. I think it involves setting up another POP/IMAP account to check mail for the main account username (usually same as the ssh username) which then authenticates you to use SMTP through ssh as well.

Convoluded, I know. As mentioned above in several of the other comments, if your ISP/host supports SSL connections, use them! They’re often as simple as checking a box in your email client.

Another issue I just thought of for Alex. If you use the SMTP servers provided by your ISP (SBC, Earthlink, Comcast, etc.) but you SSH into a server somewhere else, the SMTP server may block you because your email (as far as it can tell) is not originating from within the ISP’s network.

If this is the case, you may want to see if the same server you use for SSH also provides SMTP.

There are all kinds of possibilities for SMTP problems. Sysadmins use multiple ways to restrict access to SMTP to prevent spamm3rs from using their servers to relay messages. It still happens, but it’s better than leaving SMTP wide open.

Thanks for this great tutorial. I use Pair and just discovered this on their support site:

pair Networks has now made IMAPS and POPS available on all its mail servers. IMAPS and POPS are IMAP and POP3 mail servers that use SSL (Secure Socket Layer) to transparently encrypt your e-mail session.

Nice writeup Doug, it’s nice to see someone who is not a sysadmin by profession taking note of this issue with unsecured wireless networks.

I did want to make note of one thing that a few people have mentioned here, which is the relative security of the email you send between your server’s mailserver and the destination mail server. In the vastly overwhelming percentage of the time, this all happens over wires. Ethernet, fibre, and etc. You can’t sniff these the same way that you can sniff an unsecured and unencrypted wireless communication, unless you have root (or equivalent) access on the sending or receiving machine, or one one of the intermediary routers. These machines and routers are typically controlled carefully by various ISPs and are about as far as you can imagine from being publically accessible the way that a coffee shop wireless setup is. So, as Doug notes, it is not the same sort of security risk.

And, FWIW, Doug’s server does natively support IMAP and POP over SSL. ;) But these are still excellent tricks to know since they don’t require that dependency on your ISPs setup.

If you don’t do the above, you are surely doing absolutely nothing to protect anything?

Andreas F. Bobak

3:58 am, Feb 17, 2005

No, the port forward is correct as you basically SSH into the mailserver directly and do “telnet” on the mailserver to the pop/imap4 port: Mail Client -> (unsecure) localhost:1100 -> ssh to mailserver:22 (secure) -> accessing mailserver:110 on mailserver itself (unsecure)

mr_mojo

6:29 am, Feb 17, 2005

What? That isn’t right. Hardly any mail servers run SSHd, and even if they did, they wouldn’t have accounts set up for every mail user.

@mr_mojo: It is assumed that you have an SSH-server running on another machine than the Laptop that is connected to the Wifi-network. Take a look at the screenshot, there is the ssh-command in plaintext – the connection is being made to stopdesign.com, where an ssh-server is running. The “Tunnel-Manager”, is just a GUI for the command-line ssh-client.

If you do not have your own Hosted-server (for your websites etc.), you at least have to have your home-computer running and using some kind of dyndns-service – to be economical this requires that you have flat-fee internet-access at home. So this tutorial might not be for everyone, but given the audience of this site, I assume these are reasonable asumptions for a large part of the readers.

So essentially, you make a secure tunnel to some other machine. From then on, you are NOT secured unless using another secure connection like SSL to your mail server. SSH Tunnel manager does the job of opening the tunnel and securing the connection (with ssh). Once your laptop is connected to the other computer, you are basically using the other computer’s ports you specify as your own.

The key thing to get here is that we are NOT trying to get an end-to-end secure connection between the laptop on wireless and the mail server. We are ONLY concerned about going from the wireless connection to an intermediary (Other computer in this example, something you trust) securely. Once we are at the other computer, we should hopefully be on a wired connection that we can mostly trust to talk to our mailserver.

Using SSL, as proposed in many posts above, allows complete end to end security, but you wouldn’t need ssh tunnels if you could communicate that way.

SSH is only being used to secure your wireless communications from an untrusted wireless network where your traffic could be sniffed to a “secure” network that you yourself trust.

If you need some more explanation, I can draw up a little picture of what this looks like.

Thanks Joe H. You explained it better than I could. I was starting to wonder if I was going crazy.

And to echo lots of comments above: yes, if you have the ability to use SSL for your connections, USE IT! Using SSL will secure mail all the way to your mail server. You don’t need SSH, or SSHTM, or any of the steps in my original post if that’s the case.

My SSH server and my mail server happen to be on the same machine — everything is self-contained on one box. So, [I think] in my case, I’m essentially getting the same extensiveness of security that SSL would provide. Other people may SSH into a different box than their mail server. As Joe says above, once past the SSH server, hopefully at that point, your mail is passing along on a trusted wired network, where sniffing isn’t as much an issue, nor possible without root (or similar high-privilege) access to one of the destination or intermediary relay servers.

mr_mojo

2:00 pm, Feb 17, 2005

Yes, that’s what I thought. I just didn’t see anything about the intermeditary in the article, I thought I misread it; and I did.

David: there definitely is a way to do this. I couldn’t walk you through it myself, but look around out there.

Sahil

2:54 pm, Feb 21, 2005

This does not work for me. I configure the tunnel as per the post (thanks for taking the time out to explain!) but keep being rejected at Mail’s password prompt. I know the password is correct because I can get in via webmail. The mail server does *NOT* allow plaintext passwords. But I figured setting the tunnel to connect to port 143 would not make a difference even though otherwise plaintext connections to 143 are rejected, because doesn’t the tunnel pre-authenticate? I tried to set a tunnel to 993 on the mail server, in which case I don’t even RECEIVE a password prompt.

Doug, I’ve printed out everything here, read it thoroughly, yet I’m still confused. I understand the risks of using wireless, but I know so little about what I can and can’t do with my email that I don’t know if I can use any of the advice here. Basically, all of my web ‘ventures’ make (almost) zero money , and hence all my hosting is cheap and (sometimes) cheerful. I use Yahoo mail extensively, using the POP forwarding so I don;t have to use webmail. I’ve checked all the comments so far, but have not seen any mention of this kind of usage. Could I secure my wireless accesss at SXSW this year using this technique with Yahoo-based mail accounts? Please, if anyone can add any extra infor for this dullard right here it’d be appreciated!

Doug, thanks again for your helpful suggestions about outgoing SMTP emails through tunnels. I’ve been poking around for a while, but didn’t find a way to make outgoing SSH play nice with my server.

However, I (hopefully) found another solution for securing outgoing mail from my Powerbook. I downloaded a program called Postfix Enabler that allows you to set up your powerbook as its own localhost SMTP server. Not only this, but it creates local SSL certificates so that you can turn SSL on in your outgoing mail settings in Mail.

I’ve just sent a few emails using this method, and it seems to work quite well. Does anybody know if this is actually a reliable way of sending email securely? I’m not an expert at this stuff, so if anybody has any cautionary notes, I’d be glad to take heed. Thanks!

I’m hard-pressed to think of a provider that doesn’t fall into one of these three classes.

On the receiving end, again, “most” POP3 servers support either APOP authentication or POP3-over-SSL (both of which are supported by Apple’s Mail client). And most modern IMAP servers support SSL connections.

Mind you, I use SSH tunnelling for all kinds of other stuff (VNC, MySQL, …). Just not for mail …

Roger H.

4:49 pm, Mar 5, 2005

Thanks for the instructions.

I had been searching for a solution to having port 25 blocked by wireless hotspots, bt I also like the idea of securing my e-mail and ftp transmissions in general.

Unfotunately, whils I can create a tunnell into my domain, I cannot access either the POP server or the SMTP server. This may be because I host on a server farm, and the mailservers are actually at a different domain than my own, and I can’t get direct SSH access to them. Is there a way around this (for a not too proficient unix newbie)?

I’m already doing this with a Yahoo email account, as you might be able to tell above in the post where I show my local/remote port equivalents table. Works the same as any other email account, as long as you already have POP access to your Yahoo account (a paid feature, I believe, but it also comes with SBC/Yahoo DSL).

If you don’t get it working for some reason, find me in Austin before the conference gets going. I’ll be there Friday night onward.

There is documention on ssh under Mac OS X. The two places that I know of are: the ssh man pages and “www.openssh.org” the homepage for the version of ssh that Mac OS X uses. The man pages for ssh are: scp, sftp, ssh, ssh_config, sshd_config, sftp-server, ssh-add, ssh-agent, ssh-keygen, and ssh-keysign (the presence of some of these man pages depends on what parts of openssh is installed on your system). To read the manpage ssh type “man ssh” at the commandline. There are several other programs that can read man pages. I personally use pinfo (http://dione.ids.pl/~pborys/pinfo) to read man pages. You can find more programs to read manpages at “freshmeat.net” (freshmeat is a website that lists a lot of different software).

There is a configuration file for the ssh client called “config”. It is located in the “.ssh/” directory under your home directory. Below is a slightly munged and pared listing of my ssh config file:

You can read about the options used here in the “ssh_config” man page. The entry for “uncensored” is worth noting as it allows me to simply type “ssh uncensored” at the commandline to login into “uncensored.citadel.org” as the user “bbs”, setup some tunnels, and turn on compression (compression is usefull on slow links like dialup internet access).

The reason I specify the order of ciphers to use when logging into some machines is because they are slow. Specifying this order lets me use a faster cipher for these machines which makes ssh work faster on them.

Finally let me mention that while I don’t have a mac myself I have read enough about Mac OS X to know that it uses OpenSSH which I have lots of experience with. As for the OSes I use they are linux, Solaris, OpenVMS, and NetBSD. Most of my working computers are non x86 architecture stuff.

For those who are (after all this while) having difficulty with outgoing mail via SSH, another alternative is to grab a tool such as Postfix Enabler http://www.roadstead.com/weblog/Tutorials/PostfixEnabler.html for OSX. This allows you to use localhost for sending mail. Additionally, it’s default configuration prevents other users from using your postfix installation, keeping it nice and secure. It also handles setup of your config file for SASL Authentication. Just another road to consider of course, and the more options for email security, the better everyone will be.

Here’s a very good article on SSH and keys, which is a bit more thorough than the MacDevCenter article, and a tutorial on using ssh-agent, which is a simple commandline “keychain” that’ll stop you being prompted for your passphrase every time you SSH to a host, and it’s standard on most *NIXes. (Handy if you can’t/don’t want to use SSHKeyChain.)

This is an important topic and the information posted by various people is quite interesting. I think I have some things to mention here as well.

One, any wireless links you use for anything should be encrypted with a WEP key. Not just email and not just for sensitive information. An exposed home wireless router will allow any intruder to use your bandwidth, even if your information is no use to them.

Two, any sensitive-information email should be encrypted with a personal certificate and the receiver must use your public certificate to decrypt it. Otherwise, whether you use SSH or not is irrelevant once the email is in route to the receiving SMTP server. Many people (including corporations) are taking great lengths to protect their systems, but no effort is made to educate the end-user as to encryption usage and privacy requirements. I’ve also blogged about this serious omission related to today’s IT environments:

Three, if you are an ISP or hosting email provider or IT manager, you should absolutely set up SPF records for the sending domains you’re responsible for, backup storage for emails (European law requires 10 years of emails to be saved for corporations), updated working anti-spam filtering (EU law also requires this), and intelligent anti-virus protection (not just blocking attachments).