Authenticating and encrypting MAPI, POP3, and IMAP clients and messages
If you're like me, you probably send and receive a lot of email every day. But did you ever stop and wonder how many of these messages are secure from outside attacks? In the June 1998 and July 1998 issues, I described how Microsoft's Exchange, Outlook, and Outlook Express email clients use remote procedure calls (RPCs), Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP) 3, and Internet Message Access Protocol (IMAP) to access mailboxes on an Exchange server (for more information, see "Related Articles in Windows NT Magazine," page 140).
The default installation of each of Microsoft's email clients is not as secure as you might like, and your correspondence might be more vulnerable than necessary. Fortunately, you can take several steps to help secure your email system. In this article, I'll describe the security and privacy features of these Exchange email clients and show you how to protect your account information and encrypt the messages you send.
Vulnerable Assets
In the process of securing Exchange email clients, you must protect two types of assets: logon credentials and message data. When you attempt to open an Exchange mailbox or browse a public folder, your client software provides logon credentials to the Exchange server. The Exchange server uses this information to decide whether you have the authority to access the requested information. The logon credentials are in the form of an account name and password or a secure hash (i.e., an encrypted string derived from a username and password--for information about hash algorithms, see "Related Articles in Windows NT Magazine," page 140). You need to protect the logon credential information; otherwise a hacker might gain access to your internal mail system or other NT resources. Each Exchange email client has configurable options that control how the client presents the logon credential information.
After the Exchange server validates your logon credentials, your email client can start transferring mail messages. The message content might be innocuous or highly confidential. Regardless of the message content, you need to know what level of protection the systems are providing the message when it is in transit between the Exchange email client and server or stored on the Exchange server. Each Exchange client has configurable parameters that let you control this level of protection. To protect the message content, you need to apply some degree of encryption by using algorithms such as Data Encryption Standard (DES), 3DES, or CAST (a proprietary algorithm that Carlisle Adams and Stafford Tavares devised) to the message before transmission.
Data Transmission
When you send an email message from your desktop to the recipient's home server, the message can travel over LAN links, remote access (asynchronous) links, WAN connections, and even across the Internet. Each link along the way has different vulnerabilities and security features. You can't control all the vulnerabilities and configure all the features, and you usually can't predict which path the information will take from the client to the destination server.
You need to examine data transmittal security from several points of view. For example, some security options that you can configure on your client system depend on the message transfer protocol running at the application layer of the Open Systems Interconnection (OSI) stack (e.g., POP3, Messaging API--MAPI, IMAP, and HTTP). As I discussed in my previous articles, you can use any of these protocols to submit a message from your desktop to an Exchange server.
Similarly, at the transport layer, you can configure some security features such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), and IP Security (IPSec--for information about IPSec, see "Related Articles in Windows NT Magazine"). Although security at this layer is independent of what happens at the application (Exchange) layer, the Exchange client or server can call the stack and request that the sending and receiving systems negotiate the use of an encrypted connection to transfer the message.