Encrypting Incoming Email
As with file transfers, we want to encrypt the email login session as well as the content. There are several complementary options for doing this. Some ISPs support SSL or Secure Sockets Layer email access. SSL email uses the same approach as SSL web serving. The email client has a unique SSL certificate hidden inside and the email server has an authorized certificate registered by a third-party. This is an acceptable form of email security that shreds your password and your message. However, not all email clients support SSL email, while SSH does not depend on email client support.
When securing your email, one question to ask is, "What happens to my email message after I securely send it?" Well, from your ISP it gets sent "in the clear" to the recipient's email server which may or may not be implementing the same security. In addition, the recipient may login "in the clear" and retrieve your message. So, you are only protected on one leg of the journey, which is to say not at all. This is similar to the reprehensible process of securely collecting a credit card online for a purchase and then emailing it in the clear to the order processing department. Sure, the little lock on your browser was shut, but the back-office process is wide open.
Shredding the email message for the complete trip to the recipient requires a file-based security mechanism like Pretty Good Privacy (PGP). PGP encrypts the email message as if it were a file before it leaves your computer. Thus, as the message goes from your computer to your ISP to the recipient's ISP to the recipient, it is encrypted the whole way. Using PGP for encrypting email messages is the topic of an upcoming article. PGP will not encrypt the username and password; thus, SSH (and SSL) are complementary to PGP.
Using SSH to encrypt the retrieval of your email requires a process called port-forwarding or tunneling. Worry not, it is not that hard if you have made it this far in the examples above. Basically, we want to take the information being sent through the port (a hole on the back of your computer) and send it to a different hole. This new hole is a special hole that has a shredder attached to it that shreds all information before it enters the hole. Another way of looking at it is that we create a private tunnel through which our information travels, but no one can look in the tunnel. Can you see a car in the chunnel (the tunnel under the English channel) from outerspace? No! Same deal with an encryption tunnel. This is what was happening in the second tcpflow example above.
Recall, we saw email retrieval information traveling through the encrypted tunnel of port 22 and not 110. So, what we do is tell our computer to send POP incoming email commands to port 22 instead of the default port 110. To do this there are two setup steps: tell our email client to send POP commands to an unused local port on your computer (as opposed to port 110 on the remote email server) and tell SSH to pick up or intercept the information on this new local port and forward it through our encryption tunnel (on port 22) to port 110 on the remote computer. Voila, a tunnel. Just a little bit of traffic routing. Okay, let's do it.
The following figure shows the POP incoming mail setup for Microsoft Entourage (this process is similar for most email client programs). In Microsoft Entourage, this configuration is found under the "Tools->Accounts->Mail" option.
Instead of putting "pop.myisp.com" in the "POP Server" field under the "Receiving Mail" section we put "localhost" or "127.0.0.1". Both of these latter values are the default internally referenced name and IP number of your computer. This tells Entourage to send the POP email commands to port 110 on the local computer (as opposed to the remote computer). If we stopped here the process would not work because our computer is not an email server. While on this screen click the button "Click here for advanced receiving options". We want to check the box for "Override default POP port" and enter a port number greater than 1024 (ports 1-1024 are reserved) and less than 65535. Let's use 2003 for this example as this is the current year. Figure 2 below is a screen capture of this advanced option.
Now our email client will send POP information to the local computer at port 2003. Our next step is to tell SSH to intercept this information.
Now we need to tell SSH to grab the information on the local port 2003, send it through the shredder on port 22, and then send it to port 110 at POP incoming mail server at our ISP. To tell SSH all this we need to create a configuration file. Recall that when we first used SSH to login to a remote server it created a file called known-hosts in the .ssh directory within our home directory (e.g., ~/.ssh/known-hosts). The configuration file we want to create goes in this directory and is called config by default. Because we want to tell SSH several things and make life easier on ourselves, it makes sense to put it in a file instead of trying to remember the growing list of command line options. Using your favorite text editor, create a config file in the ~/.ssh/ directory and add the following lines but use the domain name (i.e., myisp.com) and username (i.e., chris) specific to your account:
Host incoming_mail #define a nickname or alias #for use with command line ' #ssh incoming_mail' Port 22 #use the SSH default port 22 User chris #username for email account HostName myisp.com #Hostname mapped to nickname above. LocalForward 2003 localhost:110 #Grab information on local port 2003 KeepAlive yes #keep the session alive even while idle
The comments on the right (after the '#') briefly describe what each line is for. Basically, this sets up an alias or nickname called incoming_mail. If we connect with this alias (shown below) we tell SSH to watch for traffic on local port 2003. Once this is done we can transparently retrieve email securely all day long as long as our Internet connection remains alive. If the connection goes down (which my DSL line seems to do once per day) your SSH session will end and will require restarting to retrieve email.
We can start the SSH tunneling session by referring to the nickname we created in the config file with the following command,
[tibook:~] chris% ssh incoming_mail email@example.com's password: Last login: Tue Apr 15 14:18:16 2003 from your.ip.number.here FreeBSD 4.4-RELEASE (VKERN) #9: Thu Jan 2 10:23:51 MST 2003 chris%
The above output is from connecting to a FreeBSD server at a national
ISP. The above has also been tested with Red Hat Linux 6.2 at a major
managed hosting company. If you have been successful thus far it is
unlikely that you will run into trouble here. If you do encounter a
problem, try running the above command with
ssh -v to see
where the problem arose, discuss your problem with technical support at
your ISP, and experiment with the configurations, making small incremental
changes each time.
Experimenting is a big headache when you want it to "just work" but you will learn a lot in the process. The book SSH, The Secure Shell: The Definitive Guide by Daniel J. Barrett and Richard Silverman is an invaluable companion to this experimentation and will lead you to more cool options that will help you implement SSH security in other aspects of your personal computing.
Personal Security Resolution
It took me quite a while from the time I recognized SSH as something I had to do to the time I actually implemented it. There is a lot of inertia to doing this sort of thing. That's just human nature, so don't be too hard on yourself for not doing it right away. Go get your exercise so you can have a clear head and make good on your New Year's resolution, then do it. Once you do it, make it a habit and live a healthy, fit and secure life. I hope that this article has made implementing personal security (almost) as easy as buying a paper shredder for your office.
Where to go from here?
If this is not enough for you then experiment with the commands. Create other client configurations, setup another Mac as an SSH server, or script SSH with Perl or AppleScript to startup the tunnel when your email client starts up. There are many possibilities and four more Stealth Meter levels to go. If you create a good script or have an idea, please join the TalkBack below. I'll do my best to respond. More importantly, there are many people out there with a wealth of experience and knowledge to draw from. We will all learn something from your questions, ideas and comments.
In this article we have used the OpenSSH program included with Jaguar to secure our local-to-remote working environment by encrypting remote command line sessions, remote file transfers and email retrieval. While this is not the end of the story we are certainly more secure than before. The next big step (look for the next article) is to use pass-phrase authentication integrated with an ssh-agent (a keychain-like piece of software) and a scripting language like Perl or AppleScript to automate and ease our security process even further.
SSH, The Secure Shell: The Definitive Guide by Daniel J. Barrett and Richard Silverman
PGP: Pretty Good Privacy By Simson Garfinkel
Practical Unix & Internet Security, 3rd Edition By Simson Garfinkel, Gene Spafford, Alan Schwartz
Web Security, Privacy & Commerce, 2nd Edition By Simson Garfinkel with Gene Spafford
Web Resources: SSH
VersionTracker.com--Search on "ssh" and "sftp" to get the latest info on Macintosh SSH/SFTP applications.
Web Resources: PGP and GnuPG
Mac OS X GnuPG (Public License version of Pretty Good Privacy)
Return to the Mac DevCenter.
2003-11-20 10:42:11 anonymous2 [View]
2003-12-11 15:28:33 cochella [View]
2003-08-28 08:51:20 anonymous2 [View]
2003-06-16 01:49:17 anonymous2 [View]
Excellent article... and when will we see Part 2?
2003-06-30 08:56:43 anonymous2 [View]
2003-05-22 06:40:11 immoreel [View]
2003-05-02 10:28:13 anonymous2 [View]
SSH for mail
2003-05-02 16:09:37 anonymous2 [View]