Lock down an SMTP connection at the server, not at the client
Email creates a new instance of an age-old dilemma: security versus convenience. We face this dichotomy in many aspects of our daily lives. For example, when we leave for work in the morning, most of us lock our homes behind us. Although we'd prefer not to deal with keys and locks, the simple fact is that our possessions would eventually disappear if we left them continuously unprotected. So we put locks on our doors and sacrifice a little bit of convenience for the sake of security.
The reverse—sacrificing security for the sake of convenience—also occurs, specifically in some Microsoft products. Password caching in Windows and Microsoft Internet Explorer (IE) is a prime example. Although many network administrators don't approve of password caching, users' workstations can store passwords so that users don't need to remember them.
Email represents the ultimate in communication convenience coupled with a complete lack of security. The analogy that compares the security of an email message to that of a postcard is absolutely accurate. When SMTP was developed—
back when the Internet was a much more trusting environment—security wasn't a major concern. As a result, users today transmit confidential information across the Internet without realizing just how vulnerable that data is.
Suppose two pharmaceutical companies join forces to develop a revolutionary new drug. Scientists at the two companies need to share data and documents concerning their research, and they want to do this via email because doing so is convenient. But what if the scientific documents, as they travel across the Internet in an email message, fall into the hands of a competitor? If that competitor then beats the collaborating companies to a patent on a new drug, the potential lost revenue could amount to billions of dollars.
Obviously, network administrators at the two companies need to secure the email traffic that travels between the scientists. How do the administrators best achieve such security? They can rely on users to encrypt email messages, or they can configure email servers to encrypt messages.
Client or Server Encryption
Microsoft Outlook email clients (Outlook 2000 and Outlook Express) have supported encryption and authentication mechanisms for some time. When you properly configure Outlook, users can simply click a button to encrypt (and optionally sign) a message before sending it. Although this security solution is functional, it has two minor flaws. The first is that the message recipient must have the appropriately configured software (and education) to decrypt the message. The second (and more significant) flaw is that the encryption process depends on an unreliable link: end users, who must remember to encrypt their email. Just as we all occasionally forget to lock our houses and cars, users occasionally forget to encrypt confidential messages.
If you're running Microsoft Exchange Server 5.5 or later, server-based encryption is a better alternative. Exchange Server can encrypt SMTP conversations between mail servers across the Internet. This feature is surprisingly easy to set up and ensures the encryption of all messages sent to a designated domain.
To configure server-based encryption on the sending end, you define specific Internet email domains or subdomains in Exchange Server, then instruct the server to encrypt messages headed to accounts in those domains. For example, I could direct my server to encrypt all messages to the domain ntsol.com before transmitting them.
The administrator of the Exchange server on the receiving end defines a special user account for the encrypted messages. If I've configured my server to encrypt all email going to the domain ntsol.com, I need to ask the administrator of the ntsol.com domain to create an account for my Exchange server to use. Let's say the administrator at the remote site creates an account named DOUG.
At this point, I have simple one-sided encryption, in which all the email I send to ntsol.com is encrypted and all the email that ntsol.com sends me is in plaintext. However, I want encryption to work both ways, so I need to set up a user account in my domain. Then, the administrator at ntsol.com can program his or her mail server to encrypt email that it sends to my domain.
Configuring Encryption
To set up a domain and account for encryption, you must modify settings on the Exchange servers that handle your Internet email. Start Microsoft Exchange Administrator, open the Internet Mail Service Properties page, and click the Security tab, which Figure 1, page 88, shows. By default, the system secures no domains with encryption. Click Add to open the Edit E-Mail Domain security information dialog box, which Figure 2, page 88,shows.
Type the name of the domain you want to secure (in my case, ntsol.com), then select the Windows NT challenge/
response authentication and encryption option. Next, you must define the account credentials your Exchange server will use when communicating with the other Exchange server. In effect, your server must log on to the other server. To define the account your server will use, click Change. In the dialog box that opens, type the NT domain name, account name, and password to use. (I typed INTELLINET for the NT domain and DOUG for the account.) Remember that your system will use this domain name and these user account credentials when connecting to the remote system—therefore, for encryption to work, the remote system administrator must set up the user account you define in this dialog box. After you enter the appropriate authentication credentials for your Exchange server to use, you'll see the NT domain and account names in the Edit E-Mail Domain security information dialog box's Windows NT Account field.
Now, whenever my Exchange server sees an outbound message headed for any email address ending with @ntsol
.com, it will automatically encrypt the message. The address might be postmaster@ntsol.com or webmaster@ntsol
.com—Exchange Server will encrypt all @ntsol.com addresses, regardless of content. An administrator doesn't need to add new addresses for encryption or install software on workstations.
NT Challenge/Response authentication enables NT LAN Manager (NTLM) encryption for an SMTP session. The strength of the encryption depends on your OS installation. If you have the 128-bit (US-only) version of NT at both ends of the connection, you'll get 128-bit encryption. If you have the 40-bit (exportable) version of NT at both ends of the connection, you'll get 40-bit encryption. If you have a different version at each end, NT will probably negotiate down to the 40-bit level because the configuration dialog box doesn't offer an option to "require" strong encryption.
Server encryption is a great feature if you need to share confidential information with business partners who run Exchange Server. You can secure all the email traveling between your systems in just a few minutes by enabling this option.