SP-020: Email Transport Layer Security (TLS) Pattern
Diagram:
Legend: Transport Layer Security (TLS) pattern for Email communication between companies particularly where the
company has connections with many partners.
Description: Companies have to assess the methods used to exchange sensitive information with business partners.
Based on current legislation in many countries, they must ensure that sensitive information is exchanged with business partners
via a secure communication channel. One of the most user friendly and very efficient/secure ways to secure e-mail
communication is to activate TLS (Transport Layer Security) on the mail gateways of both communication parties.
This method is fully transparent to the end-user and protection is applied on the mail gateway / infrastructure level.
Processes to consider:
TLS set-up process depending on selected TLS mode
TLS operations process – monitor that Enforced TLS connections are operational
TLS monitoring process to verify level of encryption of Opportunistic TLS connections
An initial set-up effort is required to configure TLS protection on the mail gateway (MTA) of both business partners.
Additionally, processes need to be defined to monitor continuous protection of such a connection.
Two different modes of TLS are available, Opportunistic TLS and Enforced TLS, with the following characteristics:
Characteristics
Enforced TLS
Opportunistic TLS
Encryption principle
Encryption likely
Encryption ensured
E-mail transmission
E-mails are sent encrypted if TLS is supported
E-mails are only sent if encryption is possible
Encryption failure(1) behavior
If encryption fails, e-mails are sent unprotected
If encryption fails, no e-mail will be exchanged
TLS direction support
TLS could only be supported in one direction (eg outbound) or both
TLS must be supported in both directions (out- and inbound)
TLS requirements
No special TLS set-up required, even self-signed certificates are supported
TLS requirements must be met and only certificates issued by official CA (eg Verisign) are accepted. The “Common Name” field on the certificate must be set to the name that the mail gateway
Configuration efforts
Default configuration and activated for all e-mail domains supporting TLS once set-up
Every business partner domain requires configuration, testing and monitoring
Costs
No additional costs once set-up
Additional costs to set-up and operate an Enforced TLS connection might apply
(1) An encryption failure of the TLS connection is not very likely. Most encryption failures are caused by events that have
an impact on the TLS server certificate. For example, it could be triggered by a change of e-mail infrastructure configuration
(eg server name) or a change of the server certificate (eg expiration of certificate).
Additional aspects have to be considered in the design approach if the mail gateway (MTA) is outsourced to a third party
(eg Postini, MessageLabs). In this case certain requirements of the outsourcing partners have to be met for Enforced TLS connections.
For example, certificates used have to be issued trusted CA’s and meet requirements concerning the “Common Name”.
Additionally, it also has to be ensured that TLS protection is ensured in both directions from an internal MTA of one company
to the internal MTA of the other company. Often, TLS protection is only provided from one company to the e-mail outsourcer of
the other company and reply e-mails sent are not TLS protected at all. This is the case because the outsourcer’s MTA provides
TLS per default but the company’s internal MTA does not have TLS activated.
Assumptions: Protection of the e-mail communication at the infrastructure level (gateway-to-gateway) provides
sufficient protection. No end-to-end protection is required.
Typical challenges: Not every mail gateway (MTA) of communication partners support TLS (Transport Layer Security).
Furthermore, TLS might be supported but is not configured properly. Additional challenges exist if an e-mail outsourcer is
involved in TLS connections. Not all MTA’s are able to meet the additional requirements that outsourcers might have in order to establish an
Enforced TLS connection.
Indications: Transparent solution that requires no end-user interaction in order to have protection of
the e-mail communication.
Contra-indications: E-mail communication must be protected from the senders computer to the receivers
computer (end-2-end protection) to ensure that only the intended recipient has access to the information.
Resistance against threats: E-mail communication is protected over the Internet in order to prevent
eavesdropping of confidential information. No end-2-end protection. A number of residual risks remain with this pattern:
Confidentiality for e-mail communication is not guaranteed inside the company’s intranet. In addition confidentiality
in an end-2-end communication can not be ensured if a third party (outsourcer) is providing the e-mail gateway functionality (MTA).
In this case the TLS communication is terminated at the mail gateway of this third party and the e-mails can be read by the
third party. It has to be ensured that e-mail communication is also protected from the third party to the companies internal mail server.
Loss of availability- The risk that e-mail communication is blocked between business partners exists for Enforced TLS
connections if encryption is not possible. Continuous monitoring of Enforced TLS connections is required to identify encryption
failures. Procedures have to be in place to temporary remove the Enforced TLS policy in order to re-establish the e-mail
communication until the technical difficulties have been resolved which caused the encryption failure.
No 100% encryption guarantee. Opportunistic TLS does not guarantee 100% security – if encryption is not possible e-mails
are sent in clear text. Therefore, monitoring of such connections is required to prove that appropriate protection is
provided by Opportunistic TLS.
TLS stack vulnerability- E-mail communication could be eavesdropped due to vulnerabilities in the TLS communication stack.
Identification of MTA- In case of Opportunistic TLS the authentication of the receiving mail server (MTA) cannot be
guaranteed as self-signed certificates are accepted.
