Skip to content

Opportunistic TLS vs. Force TLS in Exchange based environment |Part 2#12

In the current article, we will review the two “flavor” of TLS in the Exchange-based environment.The two options for implementing TLS are opportunistic TLS and Force TLS.

Exchange-based server (Exchange on-Premises and Exchange Online) are configured by default to use the option of opportunistic TLS.

The meaning is that given that the “other side” also supports the TLS, the mail communication protocol that will be used is TLS.

The option of opportunistic TLS is unsuitable for a scenario in which we want to set a mandatory need for using TLS. For example, in case that the other side doesn’t support TLS, we are not willing to continue the mail flow over a non-secure communication line.

Additional scenario in which the option of opportunistic TLS is unsuitable is – a scenario in which we want to define a specific rule for the identification process such as – the requirement from the “other side” to identify himself by providing a public certificate or a certificate that includes a specific host\domain name.

Note: As far as I know, the option of opportunistic TLS serves only for encrypting the communication channel but, not for implementing a process of identifying the other mail server’s identity.

The two flavors of TLS in Exchange environment

The use of TLS for encrypting the communication channel between two mail servers can be implemented in two ways:

1. Opportunistic TLS

A method which can described as “best effort”.
When we configure our mail server to use the option of opportunistic TLS, each time that the mail server will try to send E-mail message to another mail server (outgoing mail flow), our mail server will try to verify if the other side supports TLS.

If the destination mail server supports TLS, our mail server will send the mail over a secure communication channel using the TLS protocol.

If the target mail server doesn’t support TLS protocol, our mail server will “agree” to use non-encrypted communication channel using the SMTP protocol.

The same logic is implemented regarding a scenario of incoming mail – when another mail server is trying to communicate our mail server (incoming mail flow), our mail server will try to offer the use of TLS.

2. Force TLS – a mandatory need for using TLS.

When we configure our mail server to use the option of Force TLS, we define a mandatory need of using TLS for mail communication.

Each time that the mail server will try to send an E-mail message to another mail server (outgoing mail flow), our mail server will try to verify if the other side supports TLS.

If the destination mail server supports TLS, the E-mail will be sent, over a secure communication channel (using the TLS protocol for encrypting the channel).

In the case that the destination mail server doesn’t support TLS, the mail communication will not continue.

Two flavor of TLS

To be able to understand better the logic of opportunistic TLS and Force TLS, let’s use a more detailed description about each of the optional scenarios and the specific steps that are included in each of the scenarios.

1.Opportunistic TLS

A method in which the mail server will prefer to implement a secure communication channel with another mail server but in case that the “destination mail server” doesn’t support TLS protocol, the source mail server is willing to “compromise” and agrees to use non-secure communication channel using the SMTP protocol.

The method of opportunistic TLS is implemented by using negotiation between the source and the destination mail server.

Note: The following diagrams, describe the different mail flow scenario that implements the option of opportunistic TLS and Force TLS.

We refer to the Exchange Online mail server as “the organization’s mail server” but, It’s important to emphasize that the TLS concepts are relevant to any mail server such as Exchange on-Premises server or any kind of mail server.

The method of opportunistic TLS implemented in two mail flow “directions”:

1. Outgoing mail flow

When the source mail server addresses the destination mail server, the source mail server will start with a “proposal” to use encrypted mail communication using TLS.

Case 1 – in event that the destination server agrees to use TLS, the communication link between the mail servers will be implemented by using the TLS protocol.

Scenario 1 - Opportunistic TLS - Exchange Online communicating with external mail server using TLS

Case 2 – in case that the destination server doesn’t agree to use TLS (doesn’t support the TLS protocol or have any problem such as an issue with the server certificate and so on), the source mail server is willing to “downgrade” the mail communication protocol to a non-secure communication protocol meaning – SMTP protocol.

Scenario 2 - Opportunistic TLS - Exchange Online communicating with external mail server using SMTP

2. Incoming mail flow

When a mail server that supports opportunistic TLS is “addressed” by other mail servers, the communication protocol that will be implemented, depending on the “source mail server” that initializes the communication.

Case 1 – in event that the source mail server “declare” that he wants to use the TLS protocol. The destination mail server will inform the source mail server that he supports the TLS protocol.

The outcome is that the mail protocol that will be used for mail communication will be – TLS protocol.

Scenario 3 - Opportunistic TLS - external mail server communicating with Exchange Online using TLS

Case 2 – in case that the source mail server doesn’t “mention” the need to use TLS protocol, the destination mail server (Exchange Online in our scenario) will try to negotiate and offer the use of the TLS protocol.

In our particular scenario, the source mail servers don’t support TLS.

The destination mail server that supports opportunistic TLS, will not “insists” about using the TLS protocol and will agree to “downgrade” the communication channel to a protocol without encryption.

The outcome is that the mail protocol that will be used for mail communication will be – SMTP protocol.

Scenario 4 - Opportunistic TLS - external mail server communicating with Exchange Online using SMTP

Force (Mandatory) TLS

The term “Force TLS”, relate to a specific TLS configuration, in which the source mail server or the destination mail server is willing to start a communication channel with another mail server only if the communication channel considers as a secure communication link meaning – using the TLS protocol.

When the source mail server addresses the destination mail server, the source mail server will start by offering to use an encrypted mail communication using TLS.

Scenario 1 | Source server use Force TLS | Destination server doesn’t support TLS

In case that the target server doesn’t agree to use TLS (doesn’t support the TLS protocol or have some problem such as an issue with the server certificate and so on), the source mail server will not continue the mail session and will disconnect the session with the destination mail server.

Scenario 1 - Source server use Force TLS - Destination server doesn’t support TLS

Scenario 2 | Source server use Force TLS | Destination server support opportunistic TLS

In the case that the destination mail server supports the option of opportunistic TLS, the communication link between the mail servers will be implemented by using the TLS protocol.

Scenario 2 - Source server use Force TLS - Destination server support opportunistic TLS

Scenario 3 | Source server use Force TLS | Destination server support Force TLS

In this scenario, the destination mail server supports the option of Force TLS. The communication link between the mail servers will be implemented by using the TLS protocol.

Scenario 3 - Source server use Force TLS - Destination server support Force TLS

Using a mixture of mail communication protocols – SMTP, opportunistic TLS + force TLS

By default, each Exchange server who has a certificate will support, the option of opportunistic TLS.

To be able to implement the option of Force TLS, we will need to create a dedicated mail connector (or update existing mail connector) that will “enforce” the use of TLS.

Most of the time, the option of Force TLS will not be implemented for all types of communication with any mail server, but instead, will be applied to a specific mail domain.

In the following diagram, we can see the concept of using a mixture of mail communications protocols – SMTP, opportunistic TLS + Force TLS

  • Exchange mail server will always try to offer the option of using TLS (opportunistic TLS). In case that the destination mail server doesn’t support TLS, the Exchange mail server will use standard SMTP mail communication with mail servers who doesn’t support TLS (domain-A.com)
  • Exchange mail server will always try to offer the option of using TLS (opportunistic TLS). In case that the destination mail server support TLS the mail communication channel will be implemented by using TLS (domain-B.com)
  • Regarding the relationship with the domain-C.com, Exchange uses a dedicated mail connector that is configured the user the option of Force TLS. The exchange will agree to send an E-mail message to a recipient from domain-C.com, only in the case that the mail server that representative domain-C.com support also TLS.
Using a mixture of mail communication protocols – SMTP, opportunistic TLS and force TLS

Next article

The next article –Exchange architecture and default opportunistic TLS settings | Part 3#12 , is dedicated to reviewing the default option of opportunistic TLS in Exchange on-Premises and Exchange Online-based environments.

o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 2 Comments

  1. Fantastic article. I was looking for a scenarios-based document calling out what happens to TLS communications in force and opportunistic – and this article really helped.

Leave a Reply

Your email address will not be published. Required fields are marked *