TLS, Transport Layer Security, is a means of securing the transmission of email between two MTAs (mail transfer agents). It prevents an eavesdropper from capturing the headers and body of an email in clear text. TLS is a near-universal feature of MTAs (there are some MTAs that privilege speed over security that lack the feature), and mail administrators usually have it enabled such that anyone attempting to send an email can request its use and negotiate a TLS session. In this column, I’ve highlighted some of the other things that can be done with TLS besides this opportunistic encryption of email. 
They include:
- Setting policy on the strength of encryption used
- Verifying identities of machines
- Authenticating permission to relay email
These address various business problems that might otherwise be solved with another technology, may reduce the risk a specific vulnerability, and comply with regulations and industry best practices.
Setting encryption policy
Under the TLS standard, the SMTP server decides the cipher suite (a key exchange algorithm, an encryption algorithm that includes a key size, a message authentication code, and a pseudorandom function for creating the master secret to use between the sever and the client) that will be used. When a TLS session is being negotiated the client sends a cipher suite list to the server. The server then picks from the list the preferred method to be used. The client is free to decide whether it is acceptably strong or not. A sender that is concerned about securing the connection from eavesdropping will want a large (128 bit or greater) key, which will put the content beyond the capabilities of most nefarious persons from brute-force decrypting the content. For example, AES-256 (Advanced Encryption Standard with a 256 key length) is a cipher suite that has been approved by the NSA for use in securing Top Secret information. Several financial services firms require the use of AES-256 for customer communications that contain financial information. They configure their outbound MTAs to require a negotiated TLS session with AES-256.
Verifying identities of machines
During the TLS negotiation an SMTP server can request an X.509 certificate from the SMTP client. This may be used to establish the identity of the sending machine. When the server receives the certificate from the client, the server may then verify the chain of authority of the certificate to determine that the certificate is valid and the SMTP client is who they say they are. This permits an organization to construct essentially a VPN for email, where receivers can know that a message is coming from where it claims to come from and is not being spoofed. For example, military supply chains are very complex with prime contractors sourcing parts from many different sources and there is a lot of collaboration between firms. They can exchange CA certificates or use client certificates from well-known CAs, like Verisign. Once client certificates can be verified the firms may establish TLS policy such that TLS is required and a valid certificate be presented, when communicating amongst themselves.
The MTAs used for external relay by external agents should be separate from the main inbound MTA infrastructure for the organization. The reason is that under the Internet standards, a primary Internet mail exchanger cannot require authentication in order to accept email.
Authenticating permission to relay
Many companies face the problem of permitting external relay of email for remote employees, contractors and independent agents. They need to allow an external person to send email as if they are from inside the organization when they are not. One solution is to grant external users VPN access to effectively become part of the internal network in order to send email. This has the drawback of requiring client-side software to be deployed and maintained to the external machines. It also requires authentication credentials be maintained. An organization could use SMTP authentication to permit relay, but here again, authentication credentials need to be maintained. A sender needs to remember to use a password to relay email. It leaves the organization vulnerable to end users choosing poor passwords that could easily be guessed. An alternative is to authenticate permission to relay with certificates presented as part of a TLS session rather than using SMTP authentication. The organization issues certificates to the end users that they install in their email clients. Then, when they connect to send email off the organization’s DMZ email servers, the DMZ email server can require TLS and a certificate and validate that certificate to permit relay. This way, passwords are not required any longer.
Leveraging existing infrastructure
TLS provides these features that many organizations don’t take advantage of when they could. They have access to military-grade encryption and authentication that is built into the way Internet email works and could effectively reduce cost and complexity of alternative VPN solutions. When deployed internally, TLS helps deal with internal threats of disclosure of sensitive and secret information in military, intelligence, and financial services in particular. Furthermore, it can radically improve the communication security with external representatives prevalent in the mortgage and insurance industries.
