Skip navigation

Secure Messaging Solutions for Exchange

Last week, the US Postal Service (USPS) announced its PosteCS service. The PosteCS service lets you quickly, reliably, and securely send any type of electronic file over the Internet to anyone with an email account and a Web browser. Currently, this service uses only basic technologies such as 128-bit Secure Sockets Layer (SSL) encrypted connections, but in the future, the USPS promises full support for digital signatures and content encryption through public key/private key digital certificate technology. If you're thinking of offering similar services for your Exchange Server users, do you know what's available? In this special report, we'll look at the different approaches to secure email with Exchange.

First, let's separate secure messaging for Exchange into three basic categories: Secure MIME (S/MIME), network-based, and SMTP-based. S/MIME provides the highest levels of protection against intrusions such as message-content tampering, spoofing, and unwanted viewing of message content. S/MIME uses public and private key pairs maintained for users involved in the secure communication. A sender can add a digital signature (to assure the recipient that the message is authentic) or encrypt the message (to protect content from unwanted viewing or tampering) using X.509v3 certificates. S/MIME lets you offer your Exchange users the ultimate in secure messaging, but it also presents some deployment obstacles. One obstacle is certificate and directory access. If you're sending messages to users in your own organization, this obstacle isn't much of a concern because you share a directory service and a certificate authority. However, S/MIME is most useful for communications with business partners. How do you share directory and certificate information without having these partners on your internal network? Most often, this problem results in organizations needing to replicate certificates back and forth and presents quite a management nightmare (in addition to the overhead of managing the Exchange Key Management Server).

S/MIME is not without its security caveats either. Suppose a user simply signs a message (which adds a copy of his public key to the message). This message now contains a copy of that users public key, which someone could extract from the message, posing a potential security threat. For this reason, many organizations don't allow message signing without encryption (this approach protects the public key from being extracted). Although not perfect, S/MIME is the most desirable method of secure messaging but often is the most difficult to implement.

Another method to ensure secure messaging with other users or business partners is to establish a secure network connection between them. This method establishes a secure channel to a business partner using a network-level security scheme such as IP Security (IPSec—available in Windows 2000). IPSec lets users and their servers engage in secure communications and protects messaging against many security threats. Of course, this approach requires the additional expense of a private network connection between your organization and the organization with which you want to communicate. Many organizations establish extranets for this purpose. Keep in mind that a secure network connection secures only the conversation; it doesn't protect the message content or authenticity.

The last method (and perhaps the most popular) for securing messaging communications between organizations is SMTP-based security. SMTP servers (which transfer mail across the Internet) engage in secure conversations with each other using methods such as Transport Layer Security (TLS) or SSL. You can also use TLS and SSL in non-SMTP conversations as in the case of the USPS PosteCS service, in which users communicate with the server via browser-based SSL connections. SMTP-based communication with TLS or SSL security also has some problems that have led most organizations to use this method only on private networks (similar to the IPSec example above). Also, SMTP/TLS has limited support in Exchange 2000 and Exchange 5.5.

None of the secure messaging solutions are perfect. The most secure solutions seem to be the hardest to manage and deploy, and the easiest solutions to deploy seem to be the least secure. However, as electronic messaging becomes more and more a business-critical tool, we'll have to find ways of securing it. It might be worthwhile to investigate your options for providing this service to your Exchange users.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.