MacDevCenter    
 Published on MacDevCenter (http://www.macdevcenter.com/)
 See this if you're having trouble printing code examples


Secure Mail Reading on Mac OS X

by Jason McIntosh
03/19/2002

Apple has been evolving Mail.app, OS X's bundled email client, at about the same pace as the rest of the system.

I've always appreciated the program for its solid IMAP support (rather a rare attribute among mail clients in general). But recently I've started to like it even more since it began supporting super-secure mail-reading protocols that help to stop bad guys from nabbing my passwords.

In this article I describe a danger inherent in most mail-reading methods, and ways to work around it on OS X, using the Mail program. I'll also give you a brief tour of some SSH client tools that subtly stow away in the Mac OS X distribution.

Cleartext Passwords: Bad Thing

If you've hung out around paranoid hackers as long as I have (which is to say, enough to become one yourself), then you're likely familiar with the distinction between cleartext and ciphertext. "Cleartext" refers to any information devoid of encryption. Transmitting cleartext over a network, especially the all-seeing Internet, can result in tragedy if that information falls in the wrong hands.

Security-conscious folk know that any snoop with the will and the resources can listen in to your outgoing network traffic (be they the unscrupulous dudes in that white van parked across the street while you use your wireless network, or shadowy G-men with a tap on your ISP's routers) and reconstruct all your online activities. Any text you send shows up clear as day -- unless you encrypt it. In this case, your intended recipient has some way to turn your message into something readable, but during transit it's unreadable gobbledygook, and that's all any eavesdropping party, listening in the middle, will get.

Related Reading

Mac OS X: The Missing Manual
By David Pogue

Unfortunately, it's likely that you place your own network security at risk several times a day, by tossing one of your passwords around in a distinctly non-gobbledygooky fashion. If you use a mail client such as Mail.app to download and read mail from another server, chances are that the username and password you use to authenticate these transactions travel over the Internet as cleartext every time that your client opens a new session with that server. Should a shady entity choose to capture this information, the consequences to your network identity can turn tragic.

Not even high-profile mail encryption technologies like PGP can defend against this sort of attack. While they do a nice job mangling the text that makes up the actual email, they hold no sway over the lower-level communication between your Mac and your mail server. You instead need to encrypt your entire online session with the mail server. This can prove a tricky business, but for Mac OS X users it's becoming a progressively easier exercise with each revision of the operating system.

Mac OS X and Encryption

In the year or so that OS X has been on shelves, Apple has been gently nudging the OS (and its users) to favoring secure, encrypted communication protocols over clear ones. This has perhaps been most obvious in Mac OS X's increasingly warm relationship with SSH, the secure shell, a protocol for using key-based encryption to allow all sorts of secure communication with other machines. It's most commonly used for interactive sessions to shells on remote machines, making it an easy and very attractive alternative to the venerable but outrageously insecure Telnet.

With system version 10.0.1, Apple began including OpenSSH software with the distribution, both its client (which you can invoke with a simple 'ssh' on Terminal's command line) and its server (sshd, the SSH daemon). As of version 10.1, checking the "Allow remote login" checkbox under the Application tab of the Sharing preferences pane launches an SSH daemon on your Mac to accept logins from afar, instead of a Telnet daemon. (You can still set up your Mac for Telnet access, of course, by groveling over it on the command line, via Terminal. Apple simply displays its silent, matronly disapproval of such activity by not giving you any easy way to do it. And, granted, it has a point in this case.)

Relatedly, with OS X 10.1.3 Apple has upgraded Mail.app to allow connections over SSL, the secure socket layer, another sort of encryption technology (and one you may have heard of in other contexts, particularly with Web pages). Both of the major mail-reading protocols that Mail supports, POP and IMAP, have SSL-enabled variants (sometimes known as POPS and IMAPS), and more clue-in ISPs have mail servers that can speak one or both of these more obscure protocols.

Mail Fetching Over SSL

Before you can start using these secure protocols, you've got to find out if your mail host supports them. You can always just ask your ISP about it, of course. The nerdier way (and perhaps the only one available after business hours) involves poking at the mail host's ports by hand, and seeing if they bite back. If you're not shy about using Terminal, try these commands (naturally replacing my-mailhost.net with the address of your mail host):

% telnet my-mailhost.net imaps

% telnet my-mailhost.net pops

Comment on this articleLet's talk about secure mail and how to enable it on Mac OS X.
Post your comments

If you get any response beyond flat refusal, things are looking good; you can probably continue with the instructions in this section, using the default port numbers. Otherwise, ask your ISP if they support POPS or IMAPS, and if so, what port numbers these services run on.

Configuring Mail for SSL

The only tricky business on the Mac's end of things lies in the fact that Mail doesn't really advertise its capability for SSL connections, nor does it use it by default with any mail account. Activating SSL for any existing POP or IMAP account is pretty easy, though: just call up the "Account Options" tab in that account's setup dialog (which you can invoke via Mail's Preferences) and check the "Use SSL" checkbox.

Use SSL

If the value of the "Port" text field was already the default port number or POP or IMAP (110 and 143, respectively) then it will snap to the SSL-flavored default port for the same type of protocol (995 for POPS, 993 for IMAPS). If the field held any other value, though, Mail will figure that this mail server must have a penchant for unusual port numbering, and won't try guessing it. With most any mail server, the defaults should do nicely, but it may behoove you to get the port numbers from the mail services you'd like to use from your ISP.

SSH Tunneling

It may happen that you must retrieve mail from a server that supports POP or IMAP, but not their more secure SSL-enabled counterparts, and you can't (or perhaps would rather not) set up server-side mail forwarding that would push all received mail to a more security-conscious mail host. Fortunately, with a little extra work, you can set up a peculiar structure known as an SSH tunnel from your Mac to the server. Think of it as a rabbit hole with one opening in your machine, and the other at the mail server. You and your password can travel from point to point freely, while being invisible to airborne predatory sorts.

(This section assumes some experience in wrangling with your Mac's Unix command line, by way of the Terminal application.)

Using SSH

Programs that implement SSH, such as the OpenSSH family, are primarily used to log in remotely to other Unix systems. However, unlike Telnet, these programs encrypt every packet that travels between the client and the server, so that eavesdroppers don't see a pretty stream of cleartext, but rather a string of scrambled such-and-such. These nosey folk lack the keys, residing on either machine, necessary to decode (and encode) these transmissions.

In order to build a tunnel -- or, indeed, engage in any SSH shenanigans -- between your Mac and your mail server, it must have an SSH server running, and allow you to log into the machine from it.

As a Mac OS X user, you already have all the client software you need to pull off your end of this trick, through the ssh command-line program, and you can read all about it by consulting your Mac's ssh man page. But for now, let's simply test your mail server. Open up Terminal and try this command (once again using your mail host's actual address):

% ssh my-mailhost.net

If, after a pause, you get a prompt asking you for a password, congratulations; the server is SSH-savvy. (Type Control-C and then return to kick out of the program for now, or proceed with your password if you want to log in to that machine. (And consider using ssh for all subsequent logins to that server!) If you get a "Secure connection to my-mailhost.net refused" message (and you're sure that your network connection is functioning properly), you'll need to ask your mail-hosting facility if they have SSH services available at all -- they might be running it on a different port than the default one (port 22) for some reason.

If you're good to go with SSH, read on.

Enabling Passwordless Access

Since this method involves automating ssh connections, our first step involves setting up passwordless access to your mail server. This way, you don't have to let your tunnel-digging script know what your password is, making things a little more convenient and safer for you. (After all, keeping passwords stored in unencrypted text files, even within program code, is a fine example of cleartext that's dangerous without needing network transmittal.)

First, in Terminal, run this command:

ssh-keygen -t rsa

This program creates a pair of encryption keys, public and private, using the RSA encryption scheme. It will prompt you for a filename where it will save the private key. (The public key will be created with the same filename, but with an additional .pub extension.) By default, it will want to save the key as ~/.ssh/id_rsa, which, being one of the default filenames for keys that the OpenSSH client recognizes, would be grand if you meant to make this your principal key for all future SSH use. However, we're going to use this key for the specialized purpose of port forwarding, so we'll save it under a different name. I call mine tunnel.

Related Reading

SSH on Mac OS X for Worry-Free Wireless


Using SSH Tunneling


When it asks for a passphrase just hit return twice, thus specifying a blank passphrase. We'll make up for the insecurity of this maneuver by constraining the usefulness of this key in the following step.

Now make a small edit to the public key from the pair you just made. Open it in any text editor and add the text command="exit", followed by a space, at the very start of the file. For example, here's a public key I just made and modified:

command="exit" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA0Ne0dfmcIc+5/Uonqd2lftpEmN/
w2pophH0mmxQESt76yM6o4PA9TZgHvdL+doMjhIRBUSm8pKZlycla
WbytTY0oxESds8bHQgzFedg2x9KurgUJZw2LXDpzIdPQQbCA+0ksH
ZsxugFGvy1OjxKyHmkbZ8MBdMtgxm30I8UXYqk= jmac@endif

(Everything after the "ssh-rsa" part in your key will be different than mine, of course.) This addition hobbles the key so that if someone, heaven forbid, manages to swipe your private key and then tries to use it to start an interactive shell session with this server -- hence getting access to all your mail and more -- it will successfully authenticate and log in, only to immediate log out again! Since the tunnel we're building isn't going to use a shell at all, this is fine with us, and makes our operations all the more secure.

Next, log into your mail server (using ssh in the usual fashion) and in your home directory create a directory called .ssh if one isn't there already. (Note the leading period, qualifying this as a "dotfile", and thus invisible to normal ls calls; try ls -a or just ls .ssh.)

Now you must copy the public key (the key file you generated that ends in .pub) to your mail server, so that it resides in a file called authorized_keys2 within that .ssh directory. (The '2' specifies that this key collection is for use with SSH.

If it happens that you already have not only an .ssh directory but also an authorized_keys2 file within it -- hmm, have you done this before? Well, regardless, you'll have to copy the public key over to the server, and then concatenate it onto the existing file using the method of your choice, be it a text editor or the cat program.

Otherwise, you can copy it over in one step via scp, yet another useful member of the SSH program family:

% scp my_key.pub my-mailhost.net:~/.ssh/authorized_keys2

Finally, try sshing into the server. If you find yourself suddenly logged into a remote shell without any password prompt, the operation was a success. (If you still get a password prompt, you can try tracking down the problem by running ssh in verbose mode, with the -v flag.)

Setting up the Connection Script

Now that your Mac is ready to make easy SSH connections, we'll fashion a way to ensure that a tunnel exists whenever you're ready to check your email. Instead of simply launching Mail ourselves, we’ll create a script that launches Mail for you after it makes certain things are set up properly.

First, if you haven't already you'll want to install Apple's Script Menu. This handy menulet provides a way to launch not only AppleScripts, but any Perl or Shell executable existing in special folders on your Mac. Consult Apple's Script Menu Web site to get the software and installation instructions.

One of these special folders exists in your own home directory, under Library/Scripts. Create the following piece of Perl via the text editor of your choice, (customizing its variable values as appropriate) and drop it in that folder when you're done. Once moved there, rename it "Secure Mail" (or whatever you'd like to see it called inside the script menu).


#!/usr/bin/perl

use warnings;
use strict;

# Change the value of $mailserver to your mailserver's address
my $mailserver = "my-mailhost.net";

# $server_port should be set to whatever TCP port on your mailhost that
# your mail program connects to.
# Typically, IMAP connects to port 143 and POP uses port 110.
# If your mailhost is Very Silly they might use some other port for these services,
# but this is likely not the case.
my $server_port = 143;

# $local_port is the port on your Macintosh that will serve as the near end
# of the SSH tunnel. It has to be a number greater than 1024 (anything less
# than that is reserved for system use). Here, I'm just tacking a '0' onto
# the server's port number.
my $local_port = 1430;

# Set $identity_file to the private RSA key to use for authentication.
my $identity_file = "~/.ssh/tunnel";

# You shouldn't need to change anything after this line.
my $ssh_cmd = "ssh -i $identity_file -C -f -N -L
$local_port:localhost:$server_port $mailserver";
my $ssh_count = "ps ax | grep '$ssh_cmd' | grep -v grep | wc -l";

print "Command is:\n$ssh_cmd\n";

# Only start a new ssh tunnel if we don't have a previous connection
if (`$ssh_count` == 0) { system($ssh_cmd) }
system("open /Applications/Mail.app");

As soon as the file is in place, it should automatically appear as a choice in the Script menu, as in the above illustration. When run, the script opens a tunnel to your server if one does not already exist, and then launches your Mail application (or brings it to the foreground if it's already launched).

(All the thingies you see above it represent Apple's default and demonstration scripts living in /Applications/AppleScript/Scripts, which is where scripts available to every user of this Mac go. Scripts you place in your personal Library folder, however, are visible to you alone.)

Setting up Mail

Now we turn to Mail, which we shall configure in a counterintuitive fashion to suit our needs. (I will note at this point that any good mail client will work here; before Mail, I pulled this same trick with Eudora. During those pre-version 10.1 days, in fact, it was the best client I could find, but since then Mail has given me more reasons to appreciate it. Anyway, if you do use a different client, adapt the specific instructions below as necessary.)

Select Preferences... from the File menu, and create a new account. Set it up in some fashion resembling this illustration. The key point is the field for your mail host; instead of filling in the name of your mail host, stretch the truth and type localhost here. (Localhost, in case you didn't know, is the traditional first-person pronoun for Unix machines. It maps to the IP address 127.0.0.1, aka the loopback address, which every Unix machine attaches to itself.)

Mail Preferences

Note: I happen to have my SMTP host defined as localhost as well, since I have Sendmail running on my Mac, allowing me to use it as an outgoing mail server. However, you can use your mail host here instead -- just don't use authentication with it (by checking that checkbox and filling out those bottom two fields), as that would send your password to it out in the open, and render all our work here rather pointless. (If your mail host insists on using SMTP authentication, well, that's a good excuse for you to set up Sendmail locally, isn't it?)

Now click the "Account Options" tab and supply the same port number you decided on earlier -- that would be port 1430, if you chose to follow this example exactly.

Using Port 1430

If all goes as it should, checking mail at this account will cause your Mac to reach into its own bellybutton and somehow pull out email from your remote mail host. Neato! (You may want to test this by sending some mail to yourself.)

So these are a couple of ways to read your email without letting the questionably scrupled read your login information. Speaking as one who has learned the hard way about security, I can confidently say that a little paranoia goes a long way on today's Internet.


References

SSH

<shill>For an exhaustive SSH reference, consult the O'Reilly & Associates book SSH: The Secure Shell (the snail book), available in fine online and dead tree editions.</shill>

Your Mac also has man pages dedicated to the topics we bring up here, under ssh, scp, and ssh-keygen. You can also peek at the sshd man page to learn about running SSH services on your Mac. (You can read man pages via the man command in Terminal, or through third-party software such as Carl Lindberg's ManOpen.

PGP

As noted in this article, PGP is a popular program for encrypting the actual text of email messages. Unencrypted email is much easier to intercept and read; even if you use methods such as described in this article to fetch it securely from your mail host, it still probably traveled as cleartext between the sender and your server. You may want to check out The OS X port of GnuPG (an open-source PGP clone), as well as the International PGP Home Page. There's also Simson Garfinkel's O'Reilly book about PGP.

Copyright © 2009 O'Reilly Media, Inc.