SP-020: Email Transport Layer Security (TLS) Pattern
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.
- OpenSSL: http://www.openssl.org/docs/apps/openssl.html
- RFC 5246 - The TLS Protocol v1.2 : http://www.rfc-editor.org/rfc/rfc5246.txt
- RFC 3207 - Secure SMTP over TLS: http://www.rfc-editor.org/rfc/rfc3207.txt
- RFC 2821- Simple Mail Transfer Protocol: http://www.rfc-editor.org/rfc/rfc2821.txt
Related patterns: E-mail TLS with MTA outsourcing (Pending)
Classification: Email communication
Release: 08.02 (Last update 27th April 2010)
Author(s): Martin Sibler;
pattern was created based on the result of the SGRP Special Interest Group "Secure Information Exchange"
Reviewer(s): Tobias Christen
AC-03 Access Enforcement
AC-04 Information Flow Enforcement
AU-06 Audit Monitoring, Analysis, And Reporting
IA-03 Device Identification And Authentication
SA-05 Information System Documentation
SC-07 Boundary Protection
SC-09 Transmission Confidentiality
SC-13 Use Of Cryptography