|
|
|
|
Message Security Administration Guide > Configuring Inbound Servers > Transport Layer Security for Inbound Mail
|
|
Transport Layer Security for Inbound Mail
Depending on the level of protection you have purchased, you may be able to enable Transport Layer Security (TLS), a protocol that encrypts and delivers mail securely. TLS connections are available for both inbound and outbound mail traffic.
For information on how to set up TLS with inbound mail, see Setting Up Inbound TLS
This section provides a technical overview of how TLS works on your inbound mail delivery and describes how to configure TLS in the Administration Console.
Transport Layer Security (TLS), a protocol that encrypts and delivers mail securely, helps prevent eavesdropping and spoofing (message forgery) between mail servers. TLS is a standards-based protocol based on Secure Sockets Layer (SSL). TLS is rapidly being adopted as the standard for secure email.
The protocol uses cryptography to provide endpoint authentication and communications privacy over the Internet. TLS is the email equivalent of HTTPS for web communications and has similar strengths and weaknesses.
TLS uses Public Key Infrastructure (PKI) to encrypt messages from mail server to mail server. This encryption makes it more difficult for hackers to intercept and read messages.
TLS supports the use of digital certificates to authenticate the receiving servers. Authentication of sending servers is optional. This process verifies that the receivers (or senders) are who they say they are, which helps to prevent spoofing.Expanded encryption options are available if you require further security. For more information about these products, see the Encryption Manager Administration Guide.
How Inbound TLS Works
Note: In descriptions of connections, this documents uses the term TLS to refer to the full technical definition: secure SMTP over Transport Layer Security.
For inbound mail traffic, the email protection service acts as a proxy between the sending server and your mail server. Inbound messages are received through two separate SMTP connections.The first connection is from the sending server to the email protection service. The second connection is from the email protection service to your mail server.
This diagram shows the flow of TLS messages between servers:
If a mail server sends a TLS-encrypted message and your mail server has TLS enabled, you receive a TLS-encrypted message.
You may choose not to use TLS if your mail server is not TLS enabled. You receive the message from the email protection service unencrypted via SMTP. No TLS-initiated messages are lost or bounced.
Message Processing and Encryption
The following describes message flow, encryption, and message filtering for incoming TLS connections. (Note, this is a high-level overview; please see the TLS specification, RFC 2246, or other technical reference for the complete data flow.)
Note: If your mail server is not TLS enabled, an SMTP connection can be established and the message is delivered unencrypted. This is based on your TLS settings. You can also set the email protection service to defer all messages if a TLS connection fails.
As noted above, messages are decrypted in memory for virus and junk mail processing. In some instances, mail delivered via TLS is stored unencrypted:
As part of your security policy, you may wish to disable the message links in the quarantine summary and Message Center. This ensures end-to-end secure delivery, requiring users to deliver messages from quarantine summary or Message Center to their inboxes. However, since the risk of falsely quarantining valid email is small, you may choose to retain the convenience of viewing messages through the quarantine summary or Message Center.
If you enable TLS in the administrative console, and your mail server is TLS-enabled, all notifications and alerts are delivered via TLS.
Authentication and Certificates
You need a digital certificate that includes public and private keys so that your mail server can establish TLS connections and encrypt/decrypt messages. This certificate can be an authority-signed certificate or a self-signed certificate. Your certificate is used only to negotiate encryption between the mail servers, and not to perform any disposition based the information in the certificate.
Your users do not need to configure any certificates on their mail clients to support TLS.
Following is a description of certificate processing in incoming TLS mail transactions.
When the email protection service processes your incoming messages, the sending mail server receives a Google certificate that references a wild card server (*.psmtp.com) which represents the email protection service servers.
It is possible to employ encryption up to the 256-bit level (the highest level commercially available).
For TLS connections between the email protection service and your server, you may use either self-signed or authority-signed certificates. The type of certificate doesn’t affect delivery—the email protection service uses your certificate to negotiate the encryption between the two servers, and does not perform any disposition based on the information in the certificate.
TLS-encrypted messages or messages sent from an authority-signed certificate only imply that the senders are who they say they are. Messages sent via TLS are not necessarily less likely to contain viruses or be junk mail.
Authentication Restrictions
The majority of current TLS implementations provide encrypted transactions, but do not enforce validation of authentication. Mail servers can be configured to process messages based on certificate type (authority-signed vs. self-signed), status (for example, expired or revoked), or other certificate information. With TLS, mail servers can only stop or deny messages based on certificate status or information, and most servers do not impose these restrictions.
If the sending domain restricts TLS traffic based on the receiving server’s certificate (for example, deferring mail traffic if the domain in the certificate does not match the recipient’s domain), you need to inform the sender that your mail traffic presents a security certificate from the email protection service. This should prevent mail from being held if the sending server expects a certificate referencing your domain or organization.
Other Forms of Email Encryption
In addition to TLS, earlier forms of SSL-based email security are also supported. When TLS is enabled, the email protection service attempts to connect with TLS first, but if this is not available, earlier versions of SSL email security are used, including SSL2 and SSL3.
Mail Server Performance with TLS
If you choose to enable TLS on your mail server, you may experience a performance decrease. Your server must establish an encrypted session for each TLS connection, which takes a few more processing cycles than establishing an unencrypted session. In addition, network bandwidth may be affected because of the additional data in the TLS handshake. The performance impact could be approximately 10-15 milliseconds per message; actual performance depends on your server configuration and the amount of incoming messages. In most cases, this difference won’t be noticeable to your users. If there are performance issues, you may adjust the TLS settings through the Administration Console (see Configure TLS for Inbound Servers).
|
|
