Understanding Transport Layer Security (TLS) in FOPE
Applies to: Office 365 for enterprises, Live@edu, Forefront Online Protection for Exchange
Topic Last Modified: 2012-05-02
Transport Layer Security (TLS) is a protocol that encrypts messages and delivers them securely, working to prevent eavesdropping and “spoofing” between mail servers. TLS works in two basic ways to ensure email security:
Encrypting messages: Using Public Key Infrastructure (PKI), TLS encrypts messages from mail server to mail server. This makes it difficult for hackers to intercept and view messages.
Authenticating messages: Using digital certificates, TLS authentication verifies that the servers sending (or receiving) the messages are indeed what their ID indicates what they are. This helps prevent spoofing.
All messages processed by Forefront Online Protection for Exchange (FOPE) are encrypted using TLS. To help ensure privacy and message integrity, the service will attempt to send and receive messages to/from servers using TLS, but will automatically rollover to SMTP if the sending or destination servers are not configured to use TLS.
If TLS is configured with a certificate on your server, including those that have been generated by your own certification authority (CA) server, all incoming and outgoing traffic between the FOPE datacenters and your network will be TLS-encrypted. The FOPE service supports opportunistic TLS, meaning that it first attempts to deliver TLS, but if it is unable to establish a TLS connection with the destination server, then it delivers via regular SMTP.
Mail servers may or may not "stamp" a message indicating it was TLS encrypted. If it was "stampede" you will see a line in the message headers similar to the following example:
"using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)"
The above example shows which algorithms and bit sizes were used to encrypt the message.
The FOPE service allows you to create policy rules, using the Action section of the Policy Rule Settings pane, that enable Force TLS. This policy rule setting enforces TLS between your outbound mail transfer agent (MTA) and your recipient’s MTA. When you configure this Policy Rule, the Force TLS restrictions are applied to matching outgoing emails and are enforced across your whole domain.
|If a TLS connection cannot be established between your outbound services and the recipient’s messaging environment, the message will be deferred for 24 hours. If message delivery fails, a bounce message will be sent to the sender. In order to receive the bounce message, your server must have a valid, known certificate.|
When you create a policy rule that enables Force TLS, you have the option to enable Opportunistic TLS for unspecified recipients (in the Recipient area under Match – New Policy Rule). Checking this box will still enforce authenticated TLS on the recipient who matches the rule, but also allows all other recipients to be transmitted using Opportunistic TLS if all attempts to enforce TLS fail. The FOPE service will always use the highest level of encryption available for transmission of the messages and if not available step down. If the Enable Opportunistic TLS for unspecified recipients box is unchecked, then outbound messages will not be bifurcated. This means that authenticated TLS will be enforced for the delivery of all recipients on the message, where any of the recipients match the Policy Filter rule and the recipient mail transfer agent (MTA) is configured to accepting TLS-based connections (including valid public certificates). If one of the recipients has an MTA that does not supporting TLS connections, then the message to this recipient will be rejected. For more information about this policy rule and its settings, see Understanding Policy Rule Settings.
The FOPE service requires the standard X.509 TLS/SSL certificate. You must have the most current GTE Cybertrust Root certificate installed along with your certificate. Certificates should be purchased directly from a Certificate Authority (CA) or from an authorized certificate reseller. FOPE supports many popular root CAs. As a policy, FOPE will only support currently valid root CAs that are part of the Microsoft Root Certificate Program. If you’re considering a digital certificate for use with FOPE get a current one from a member of the Microsoft Root Certificate Program. If your preferred CA is not listed, see Microsoft Root Certificate Program for information on how they can apply to the program.
Occasionally, FOPE customers experience TLS handshake failure. A TLS handshake can fail for several reasons; the more common scenarios are as follows:
The TLS/SSL certificate used in the handshake has expired or been revoked.
Your MTA may not have TLS enabled. Check to make sure that your MTA has TLS enabled.
The firewall handling the connection may not be configured to allow TLS communication through port 25.
Also, the extensive error reporting used in TLS is an excellent way to troubleshoot any handshake or connectivity problems you may encounter.
The following are some of the most common questions FOPE service customers have about TLS.
A. Your mail server must have the TLS/SSL protocol stack installed (installed by default with most new operating systems) and it must be setup to initiate SMTP connections using TLS. Also, you must have a current certificate installed.
A. Most firewalls are pre-configured to allow TLS/SSL traffic on port 25. Please consult your firewall vendor if you are unsure if your firewall supports this or if it needs to be configured.
A. There are two basic ways to tell if a server is TLS capable:
Send and receive a message from the server and then to examine the headers on the message. If you see anything TLS related, the server more than likely is TLS enabled.
Test the server by using a Telnet connection.
Following is an example of a Telnet session into a FOPE datacenters that shows the STARTTLS option. You may perform this test on any mail server. The following example was taken from FOPE servers:
CMD: telnet mail.global.frontbridge.com 25
220 mail77-red.bigfish.com ESMTP Postfix EGGS and Butter
CMD: ehlo test
220 Ready to start TLS
“220 Ready to start TLS” indicates that the server is ready to start a TLS connection.