... or leave your sensitive data out in the open

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.

Plan Your Configuration
The first step in using SSL to secure your client-server communications is a simple one: Think ahead. You need to consider several factors before you get down to the nuts and bolts of configuring your servers to support SSL.

Will you be using front-end servers? (You might choose to implement a front-end/back-end configuration when you want to provide access to many mailbox servers on the back end through only a few protocol servers on the front end.) Exchange 2000 Server lets you configure front-end servers for mailbox access (Exchange 5.5 doesn't permit this type of configuration). This front-end/back-end configuration lets users connect to protocol servers or servers that listen for client connections on the ports that Table 1 lists. The protocol server acts as a proxy connecting to the Exchange server that hosts the users' mailboxes. However, if you aren't planning to use a front-end/back-end configuration and you want to provide POP or IMAP access, users must connect directly to the server on which their mailboxes reside. When you use a front-end configuration, you need to configure only the front-end servers to use SSL. When you don't use a front-end configuration, you need to enable SSL on each server that users might connect to.

Will clients—regardless of which protocol they use—connect to your email servers over the Internet? If so, you need a firewall that can handle SSL sessions. You also need to configure that firewall so that the necessary ports permit inbound traffic to reach the servers. If you plan to use SMTP, you need to make sure that your firewall fully understands the EHLO and STARTTLS commands and can properly pass security information to the server. Some firewall SMTP proxies don't fully support secure SMTP, and other firewalls have been known to return STARTTLS in response to EHLO even when the SMTP server behind the firewall isn't configured to use SSL.

Do your email clients support SSL? You also need to ensure that your clients can support encryption. For example, versions of Microsoft Outlook Express earlier than Outlook Express 5.0 didn't support SMTP encryption using STARTTLS.

Where will you get your server certificates? A Certificate Authority (CA) issues these certificates, which are necessary to implement SSL. A CA is a third-party document that confirms the identity of those individuals or companies to which it issues certificates. For a client to trust a certificate, the client must recognize and trust the certificate's issuer (i.e., the CA). For the client to recognize the CA, you need to add a CA certificate to each user's system. When you install Microsoft Internet Explorer (IE), the program automatically installs several well-known CA certificates. To manually add other CA certificates, you can use IE's Certificate Manager (in IE 5.5, select Tools, Internet Options, go to the Content tab, and click Certificates), or you can use a registry file to import a certificate. Without the certificate that identifies a CA, your users will receive an Unknown Certificate Authority warning each time they access the server. (For information about CAs and server certificates, see "Related Reading.") For an Exchange 2000 deployment that uses front-end servers, you need a certificate for each front-end server. For installations that don't use front-end servers, you need one certificate for each mailbox server.

Have you considered how requiring SSL authentication will affect your email servers' ability to receive general SMTP communications? After you configure your server to support SSL, you should require SSL so that you can be sure sensitive information isn't passing in clear text. However, requiring SMTP to use SSL prevents delivery of SMTP mail from other servers that aren't SSL capable. To work around this dilemma, add a second SMTP server (or Exchange 2000 SMTP virtual server) to your network. Continue to use your original server (i.e., the SMTP server that your DNS server advertises) for inbound external mail transport; use the second server (i.e., the SMTP server or virtual server configured to require SSL connections) to handle outbound mail from your POP and IMAP clients.

Did you install Microsoft IIS on your Exchange 5.5 server before you installed Exchange? When you implement SSL on an Exchange 5.5 server, that server also needs to run IIS so that you can use the IIS Key Manager to generate a request for, then to install, the necessary server certificate. (You don't need to worry about this step for Exchange 2000 deployments. Internet Information Services—IIS—5.0 is a requirement of Exchange 2000 installations, and you access the certificate request and management functions through the Microsoft Management Console—MMC—Exchange System Manager—ESM—console.) The wrinkle is that you need to install IIS before you install Exchange 5.5 so that during the process of requesting and installing the certificate, the Key Manager can detect the IMAP, POP, and SMTP protocols.

Have you considered the effect that SSL will have on your network? Encrypting communications increases the number of bytes in each message that Exchange sends over the wire. This increase can affect your network bandwidth and your servers' performance. To remove some of the burden of encryption and decryption from your servers' resources, you can add an SSL hardware card to the servers, but be sure to monitor your network closely. Better yet, you might want to run a small pilot program to determine whether your systems and network can handle the extra load. You can then confer with users and management to decide whether SSL's additional security is worth the cost and overhead to your organization.

Secure the Protocols
After you've enabled the necessary protocols (e.g., IMAP) on your servers and have decided on which servers you need to install the server certificates, the next step in securing the protocols is to generate certificate requests. The procedure varies slightly depending on whether your servers run Exchange 2000 or Exchange 5.5.

Exchange 2000. For Exchange 2000 installations, open the ESM console. (Each protocol uses the same method to activate SSL; I'll use IMAP as an example.) Expand the Protocols container of the server you're configuring, then expand the IMAP4 container to display the IMAP4 virtual server.

Right-click the IMAP4 virtual server, choose Properties from the context menu, and go to the Access tab in the virtual server's Properties dialog box. Click Certificate in the tab's Secure communication section to launch the IIS Certificate Wizard. This wizard guides you through actions such as requesting, installing, and renewing certificates. On the wizard's Server Certificate screen, which Figure 3 shows, select Create a new certificate. The wizard prompts you to provide information such as your organization's legal name, country, and region. The wizard also prompts you to specify the certificate request's bit length, which determines the public-key encryption and signing strength. (I suggest you use 1024 bits because known vulnerabilities exist with 512-bit keys.) Finally, you specify a common name (CN) for the server; the CA will encode this CN into the server certificate. The CN must be the same name configured on your server, or users will receive warnings about a mismatch between the name encoded in the certificate and the host name their email clients used to locate the server. When the wizard is completed, it saves the certificate request as a text file.

Next, you need to send the text file, as well as official identification, to the CA. (Most CAs maintain a Web page through which you can upload this information. See "Related Reading," for more information about this process.) The required credentials depend on the CA, but most US CAs accept a business license, a Congressional Act establishing a government organization, or a Dun & Bradstreet D-U-N-S Number. On average, the CA takes 2 to 3 days to process your request and generate a certificate file.

When you have the certificate file, follow the steps I presented earlier to open the IIS Certificate Wizard. This time, the wizard recognizes the existence of a pending certificate request and presents a new set of options. Select the option to Process the pending request and install the certificate. To install the certificate on the server, simply specify the path to the certificate file and click Finish.

Now you need to enforce the use of SSL for the protocols. Again, open the ESM console, open the IMAP4 virtual server's Properties dialog box, and go to the Access tab. Click Communication in the Secure communication section to display the Security dialog box. Select the Require secure channel check box, and click OK. Users who access their mailboxes through IMAP must now use SSL.

Exchange 5.5. For an Exchange 5.5 server, you use the IIS Key Manager to request and install the certificate. To access Key Manager open the Internet Services Manager (ISM). Next, open the Properties dialog box for the Default Web Site, go to the Directory Security tab, and click Key Manager. You can also run Key Manager from a command line. Open a command prompt and type


As in Exchange 2000, the procedure for requesting and installing certificates is the same for all protocols, so I'll use IMAP4 as an example again. In Key Manager, which Figure 4 shows, right-click the IMAP4 object and select Create New Key from the context menu to open the Key Request Wizard. This wizard prompts you to provide the same information I described for the IIS 5.0 Certificate Wizard, as well as a name for the key request and a password (you'll need to use this password later, so don't lose it). When the wizard finishes, it creates a key request text file and a pending key request object (which Figure 4 displays as the object IMAPkey) below the IMAP4 object. As I described earlier, submit the key request file and your identifying information to the CA. When you receive the certificate file from the CA, use Key Manager to install the certificate on your Exchange 5.5 server. Open Key Manager, right-click the pending key request object, and select Install Certificate. To process a Key Manager—generated request, supply the path to the certificate file and the password you used when you generated the request. When you click Finish on the wizard's final page, the certificate will be installed and ready to use in SSL sessions.

To enforce SSL for POP, IMAP, and HTTP, use the Microsoft Exchange Administrator program to access the protocol container. Open the protocol's Properties dialog box and select the Authentication tab. Select the Basic (Clear Text) using SSL check box and clear the other five check boxes on the tab. Click OK; users of the protocol must now use SSL. To configure SMTP to require encryption, open the IMS's Properties dialog box and go to the Connections tab. In the Accept Connections section, which Figure 5 shows, select Only from hosts using and choose Encryption from the drop-down list. To enforce this setting, you need to stop and restart the IMS.

Remember that requiring SSL on your default SMTP virtual server (for Exchange 2000) or your default SMTP server (for Exchange 5.5) forces any server that attempts to connect and deliver mail to use SSL—preventing you from receiving mail from some servers.

Rest Secure
Configuring your servers to require SSL for Internet protocol—based communications with your email clients definitely helps protect your sensitive information as it moves between clients and servers. Be sure to carefully consider the relevant factors before you begin the configuration process, and monitor your network afterward to confirm that communications are running smoothly.

"SSL Demystified," http://www.iisadministrator.com, InstantDoc ID 16047
"Implementing SSL on IIS 5.0," http://www.iisadministrator.com, InstantDoc ID 16183
"SSL's Benefits on OWA," http://www.exchangeadmin.com, InstantDoc ID 15772
"Securing Web Communications with SSL," http://www.win2000mag.com, InstantDoc ID 20688
"Using Certificates for Security in IIS," http://www.iisadministrator.com, InstantDoc ID 21934
"Digital Certificates 101," http://www.win2000mag.com, InstantDoc ID 4900

Microsoft Articles
"Certificate Authorities: Using Digital Certificates for Authentication"
"How to Configure Certificate Server for Use with SSL on IIS"