MTA Encryption

Government regulatory requirements such as the healthcare industry's HIPAA and the finance industry's Gramm Leach Bliley Act (GLBA) increase the pressure on systems administrators to protect communications that may contain sensitive client information. Even organizations without these specific needs are interested in e-mail security to better protect their intellectual assets. Using TLS as outlined in RFC 3207, e-mail between facilities can be encrypted without the use of expensive VPN software or hardware, guaranteeing the safety of sensitive corporate information contained in e-mail while in transit between offices.

Many multifacility e-mail implementations often result in disparate e-mail servers (Microsoft Exchange, Lotus Domino, Cyrus, Sendmail, and others) being maintained in each location. E-mail destined for the specific locations, whether it is originating outside or inside the corporate network/firewall, is transmitted between the servers over cleartext SMTP, leaving its contents open to inspection. Even worse , when the locations are connected via the Internet instead of a private-line corporate network, the e-mail traffic may be inspected by other Internet users, including your Internet service providers and telecommunications carriers . This type of inspection is generally done to check line quality and other quality of service but does not preclude providers from viewing data (purposefully or inadvertently). The Electronic Communications Privacy Act states the following:

"(2)(a)(i) It shall not be unlawful under this chapter for an operator of a switchboard, or an officer, employee, or agent of a provider of wire or electronic communication service, whose facilities are used in the transmission of a wire or electronic communication, to intercept, disclose, or use that communication in the normal course of his employment while engaged in any activity which is a necessary incident to the rendition of his service or to the protection of the rights or property of the provider of that service, except that a provider of wire communication service to the public shall not utilize service observing or random monitoring except for mechanical or service quality control checks."

More importantly, organizations need to worry much more about crackers and competitors than the ISPs and carriers. There are much higher risks involved with attacks or network "sniffing" as a means of data being unknowingly viewed and/or compromised.

With the use of TLS, e-mail can be protected inside and outside an organization's network without procuring expensive VPN equipment or installing any client-side encryption system such as PGP or S/MIME. While client-based encryption systems provide end-to-end security, they are generally a major headache for systems administrators and helpdesk operators. The following illustration shows an example of how TLS can be used within an organization.

The key to using TLS is to ensure all clients and e-mail servers are configured to use it. Ultimately, the initial connection handshake determines whether TLS will be used or not. As long as all clients and e-mail servers within an organization are configured to use TLS, this should not be a concern. On the other hand, an organization will most likely not be able to require TLS for its public MTA, as this will limit accepted connection to only those negotiating TLS. Some organizations use TLS publicly , but the vast majority do not. An organization can offer TLS and, if available, negotiate the encrypted connection (that is, opportunistic encryption); however, requiring it would severely limit the successful public connections to the MTA. The following mail headers are from an actual e-mail message between a United Parcel Service (UPS) e-mail server and one of Vostrom's MTAs demonstrating opportunistic encryption through the use of TLS.

 Received: from ups.com (magma4.ups.com [153.2.232.13])         sing TLSvl with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))       (No client certificate requested)       by mx.vostrom.com (vostrom) with ESMTP id 3F4A66C00C       for <[e-mail]>; Mon, 23 Aug 2004 11:15:53 -0700 (PDT) Received: from ([153.2.2.219])       by magma4.ups.com with ESMTP id KP-VXL51.32259898;       Mon, 23 Aug 2004 14:22:28 -0400 From: [e-mail] To: [e-mail] Reply-To: [e-mail] 

In the example above, a message sent from the "http://ups.com" domain to the "http://vostrom.com" domain was done in an encrypted fashion with no partner or vendor connection required (such as VPN tunnels and so on). The two MTAs simply negotiated the connection between them over TLSvl so that the communication during that session was encrypted. This example shows the flexibility and increased security possible for data communications with encryption-enabled MTAs.