Secure Client Communications with SSL

When Microsoft released Exchange Server 4.0, the only available client was Messaging API (MAPI)—based. But as Exchange has evolved, Internet protocols—POP, IMAP, SMTP, and HTTP—have been integrated more and more into the product. As an administrator, you can now provide users with quite a few client options.

I've found that POP- and IMAP-based clients are becoming much more popular than MAPI-based clients, especially for companies that support many remote users. But misconceptions abound about the capabilities of each protocol and about how to use Internet protocols to provide secure email services. Many administrators are unsure about which protocol to use, and many administrators who already use these protocols haven't configured their email servers for optimal data and systems security. If you haven't done so already, I suggest you consider configuring your servers to take advantage of the Secure Sockets Layer (SSL) protocol. (For more information about SSL, see "Related Reading," page 3.)

Know Your Protocol Options
POP and IMAP are the primary Internet client email protocols that define how users access and retrieve the messages waiting in their mailboxes. One misconception is that you use these protocols to send email messages. To send messages, the protocols must be paired with SMTP.

POP is the older of the two protocols. By default, POP moves new messages from the server to the client's local machine. Therefore, this protocol is best suited to users who use only one workstation to access email. POP isn't an optimal solution for users who work from several locations (e.g., from the office 3 days per week and from home 2 days per week) because a portion of those users' email will always be inaccessible from one or the other of their workstations.

IMAP is more feature-rich than POP. IMAP lets users leave their messages on the server and mark them as Read or Unread (users can download messages, but IMAP lets the users select which messages to download and which to read but leave on the server). Therefore, this protocol is better suited to users who access their mailboxes from more than one workstation. To be fair, POP-client users can also leave messages on the server, but the protocol doesn't have IMAP's mailbox and message manipulation capabilities (to permit distinction between read and unread messages). POP downloads in their entirety all messages in the Inbox, whereas IMAP downloads only a list of message headers (IMAP transmits the entire message only when a user elects to open and read the message or copy it to a local storage point). IMAP also lets users create folders on the server and move messages between those folders. POP doesn't have those capabilities.

HTTP is another protocol that's increasing in popularity as an option for email access. A browser provides the UI, and code on a Web server uses MAPI to access and manipulate a user's Exchange mailbox. Unlike POP and IMAP clients, HTTP clients require almost no configuration. Users simply connect their browsers to the proper Web server and supply a mailbox address to send, receive, and manipulate messages. However, HTTP-client users can't download email messages to read offline. Users must maintain a connection to the Web server to access their mailboxes.

SSL to the Rescue
Standard configurations of POP, IMAP, HTTP, and SMTP all have the same security vulnerability: The protocols use clear text to transmit information —including usernames and passwords—between client and server. For example, I configured an IMAP client in my testbed to use a domain account (test\joe) and a password (myPassword) to access Exchange. Using Windows NT's Network Monitor tool, I was able to capture all the traffic on the network segment between my Exchange server and the IMAP client. The protocol passed both my username and password in clear text, so both were easily readable, as Figure 1 shows.

To overcome the vulnerability of clear text, each protocol supports the use of SSL or, less commonly, Transport Layer Security (TLS) to secure client-server communications. Each protocol has an Internet Engineering Task Force (IETF)—assigned standard port and SSL port (Table 1 lists these ports); services such as protocol virtual servers, the Internet Mail Service (IMS), and the Information Store (IS) use these ports to listen for client connections. When a client connects through a standard port, the communication proceeds in clear text. Figure 2 shows the steps that take place when a client connects through an SSL port.

When the connection first occurs (Step 1), the server and client begin a dialog to establish a means of using public-key technology to encrypt subsequent communications. The client receives the server's public-key certificate, information about the available encryption algorithms, and a set of random data (Step 2). The client and server negotiate the algorithm and encryption strength—40-bit versus 128-bit (Step 3). After negotiations are completed, the client uses the server's public key to send a digitally encrypted message to the server (Step 4); this message contains a session key that the client generates. The server's ability to use its private key to decrypt the message confirms the server's identity. The client and server then use the session key to secure the communications channel between them (Step 5).

For POP, IMAP, and HTTP, this process is straightforward. For SMTP, the process includes a few additional steps. As Table 1 shows, SMTP uses port 25 for both secure and unsecured communications. Therefore, when a client system connects to an SMTP server and intends to use encrypted communications to send a message, the client first issues the Extended SMTP (ESMTP) EHLO command to the server. If the server supports encryption, it sends the STARTTLS command in response. To initiate an SSL session, the client replies with another STARTTLS command.