Using TLS in Exchange based environment |Introduction |Part 1#12

The purpose of the current article series is, to review the implementation and the use of the TLS protocol in an Exchange-based environment.We will examine the utilization of the TLS protocol in two Exchange environments:

• Exchange Online
• Exchange on-Premises

The article series

The article series that is dedicated to the subject of implementing TLS in Exchange-based environment includes 12 articles.

The main reason for writing 12 separated articles, that relate to the subject of TLS in Exchange-based environment was because when I had the need to implement TLS in Exchange environment, I felt some frustration because I could not find a clear and straightforward explanation of the different options and the various scenarios of how to use and configure the TLS protocol.

My primary purpose for writing this article series is, to help you understand better the subject of the TLS protocol in Exchange on-Premises and Exchange Online environment by demonstrating common scenarios.

The TLS protocol basic introduction

TLS protocol used for two main purposes

1. Encrypt the data that passes over the communication channel between two hosts
2. Enable each of the involved hosts to identify the “other party” that involved in the communication process.

TLS and server-side certificate

The abilities to encrypt the data and the ability of the mail server to identify each other are implemented by using a certificate.

The certificate can be a “non-public certificate (self-sign certificate) or a public certificate that issued by a trusted CA (certificate authority).

Most of the time, when the TLS communication protocol implemented between two mail servers which reside on a public network, the certificate that needed to use by each of the mail servers is a public certificate.

Authentication and Mutual Authentication

As mentioned, part of the TLS protocol is the ability of each party to “demand” that the “other side” will identify himself before starting the “data transmission” process.

The authentication requirement is not a mandatory requirement. Each of the sides (the mail server) that participate in the communication channel can “decide” if he wants to identify the “other side” or not.

Also, the authentication process is not a “symmetric” process.

For example – server A can be configured to identify the other side (server B), but it doesn’t mean that server B will also need to identify server A.

TLS mail client vs. server to server TLS communication

Generally speaking, the “use” of TLS protocol can be implemented in two major scenarios.

1. Client to Server – usually, when we use the term “client” we mean: mail client and the term “server” describes a mail server.
2. Server to server – a relationship between two mail servers

In the current article series, will focus only on the “server to server” module, which describes the TLS infrastructure that exists between mail servers.

The Exchange components that are used for implementing TLS.

In brief, “activating” the TLS protocol in the Exchange bases environment implemented by using two Exchange components:

1. Exchange mail connectors
2. Exchange transport rules (supported only by Exchange 2013).

A brief introduction of – Exchange mail connectors

As mentioned, when we need to create TLS configuration in Exchange-based environment, the Exchange components that we use are:

1. Exchange mail connectors – in the current section, we will provide a basic introduction of the term “Exchange mail connector”.
2. Exchange Transport rule – the ability to use Exchange Transport rule for implementing TLS based communication is available only with Exchange 2013 on-Premises version and Exchange Online. We will review in details this option in the articles: Implementing Force TLS by using Transport rule | Exchange online | Part 10#12 and, Implementing Force TLS by using Transport rule & Conditional Mail Routing | Exchange online | Part 11#12

The purpose for creating Exchange mail connectors

We can define two major purposes for using Exchange mail connectors:

Purpose 1 – “divert” that standard mail flow to a specific channel. If we use a metaphor in which we compare the “standard” mail flow to a river that transports incoming and outgoing E-mail messages, in some scenarios, we need to “divert” a specific mail flow to a different channel.

For example, we need to “divert” a mail flow that is sent to a particular domain to the internal mail server instead of using the standard mail flow in which the E-mail sent to a public network.

Regarding the way that Exchange server uses for “locating” the destination mail server that stands on the “other side”, the locating of the target mail server can be configured by

• Using a standard DNS query, looking for the MX record of the host (the mail server) that represents a specific domain name
• By guiding our mail server to address a specific IP address or hostname. In a scenario in which we “instruct” our Exchange mail server to address a specific host (IP address) we reference the destination mail as “Smart Host”.

Purpose 2 – creating a secure communication channel (encrypted mail transport) with a “destination mail server” that represents a specific domain name.

For example, our company works with another company (partner). The business need is to ensure that mail messages that sent to this partner and, from this partner to our mail server will transferred over a secure communication channel using the TLS protocol.

To be able to fulfil this requirement, we will need to create a dedicated mail connector that will “instruct” our Exchange mail server to send the E-mail message over a secure communication link, each time that one of our organization users sends an E-mail to a recipient who belongs to our partner network.

Most of the time, we will need to create an additional mail connector that will be responsible for accepting mail from our partner mail infrastructure and verify that the communication channel is secured (encrypted).

This behavior described as opportunistic TLS. We will review the characters of opportunistic TLS in article – Exchange architecture and default opportunistic TLS settings | Part 3#12

The simple logic of mail connector and Address space

The concept of a mail connector is based on a simple logic that can be described as-

IF x Then Y

The “X” represented by an address space and the “Y”, is the “action” that needs to implemented.

In a mail infrastructure, the term “address space” describes:

• The domain name that appears in the outgoing mail that we sent out
• The domain name that is displayed in the incoming mail message that is sent from “another mail server” to our mail server.

Let’s simplify this concept by using two examples:

Example 1 – routing mail message to smart host for a specific domain name

In our scenario, the address space is the domain name – test.com

We want to define a mail flow in which each of the E-mail messages that sent from the test.com domain will be redirected to a particular destination mail server.

The mail connector that will implement this requirement based on the following logic:

If mail is sent to the domain name test.com (X) then …. redirect the E-mail message to a smart host who is represented by the IP address – 10.10.10.1

Example 2 – implementing a mandatory mail secure channel

We want to ensure that each E-mail that sent to a particular partner must transmitted over a secure communication channel (encrypted channel).

The logic of our mail rule will be:

If mail is sent to the domain name of our partner test.com (X) then …. Ensure that the “other side” (the mail server that represents the domain name test.com) support the use of TLS protocol.

This type of method described as Force TLS. We will review the concept of Force TLS in the articles 6-11

The concept of mail connector in Exchange-based environment

In the current article series, we discuss the subject of:

• Creating a secure communication link between Exchange on-Premises Server and Exchange Online server.
• Creating a safe communication link between Exchange Online server and external mail server.

Before we dive into the specific details, it’s important that we stop for a minute and start to ask basic questions such as:

Q: When we say that Exchange sends E-mail to the destination mail server (such as Exchange Online), what the “Exchange component” that is responsible for sending the mail and what is the “Exchange component” on the destination mail server that is responsible for “accepting” the mail?

A: The answer is that – in the Exchange-based environment, the “component” that sends and receives mail is implemented by using mail connectors.

In a scenario in which we want to view the TLS setting of a particular mail server or configure a specific TLS setting for creating a secure communication channel, we will need to access the Exchange mail connector or create a new mail connector that will implement our specific desired configuration.

Generally speaking, Exchange Server includes two types of mail connectors –

1. Mail connector for sending mail “out” (outbound communication).
   When the Exchange-based server needs to send E-mail to a destination mail server, the mail will be routed to the specific mail connector, which is responsible for sending out an E-mail message to external or other mail servers.
2. Mail connector for accepting incoming mail (inbound communication).

When another mail server tries to communicate with the Exchange server, the Exchange “listen” to the communication requests by using the incoming mail connector.

Exchange on-Premises vs. Exchange Online different naming convention for mail connectors

Ok, now let’s make it more complicated – Exchange Online and Exchange on-Premise server, use different terms for the mail connectors that are responsible for sending out
E-mail message and, for the connector that is responsible for accepting E-mail.

Exchange Online – mail connectors | Naming convention

In Exchange Online environment, we use the following terms:

• The connector that is responsible for accepting incoming mail requests (when other mail server address Exchange server) described as – Inbound connector
• The connector that is responsible for sending out E-mail messages (when the Exchange Online server address other mail servers) described as – Outbound connector

Exchange on-Premises server – mail connectors | Naming convention

In Exchange on-Premises server environment, we use the following terms:

• The connector that is responsible for accepting incoming mail requests (when other mail server address Exchanges on-Premises server) described as – Receive connector
• The connector that is responsible for sending out E-mail messages (when Exchange on-Premises server address other mail servers) described as – Send connector

An example of Mail flow scenario between Exchange on-Premises and Exchange Online

The concept of mail connector is implemented in a similar fashion in Exchange on-Premises environment and Exchange Online environment, but each of the Exchange environments uses different terms for describing the outbound and the inbound mail connectors.

To be able to get a sense of the mail flow that implemented in Exchange Online and Exchange on-Premise environment, let’s review a scenario which characterizes the Exchange hybrid environment.

Scenario 1 – mail that is sent from Exchange on-Premises server to Exchange Online

A scenario in which on-Premises recipient, send E-mail to “cloud recipient” (Exchange Online recipient)

The E-mail that the On-Premises recipient creates sent to the Exchange on-Premises server.

The Exchange on-Premises server, use his “outbound connector” described as – Send Connector, for creating the communication channel with the Exchange Online server.

In the Exchange Online environment, the component that “accept” the communication request is the “incoming connector” that’s described as – Inbound Connectorr.

Scenario 2 – mail that from Exchange Online Exchange on-Premises server

A scenario in which Exchange Online recipient sends E-mail to “Exchange on-Premises recipient”.

The E-mail that the Exchange Online recipient creates sent to the Exchange Online server.

The Exchange Online server, use his “outbound connector” described as – Outbound Connector, for creating the communication channel with the Exchange on-Premises server.

In the Exchange on-Premises server environment, the component that “accept” the communication request is the “incoming connector” that’s described as – Receive Connector.

A little information about the concept of TLS protocol

The two main purposes of using the TLS (Transport layer security) are:

1. Encryption – the technical term is a privacy or confidentiality and in simple words, the need for creating a secure communication channel, in which the data that transferred between two parties (mail server in our case) will encrypted.
2. Authentication – the need to verify the identity of each side that involved in the “data transfer (mail) process.

Side A want to be sure beyond any doubt that Side B Is really who he claims and vice versa.

The implementation of the TLS is quite flexible because, we have the ability to choose the “level” or the degree of the different component’s meaning – Encryption and Authentication.

Scenario 1 – using TLS only for creating a secure communication line

In this scenario, the main focus of the two parties (the mail servers) is not on the need for identifying each other, but instead, the need for encrypting the communication line which server for transferring the data between the two endpoints.

The process of – encrypting the data, will be implemented by the server certificate, but server A will not verify the identity of server B and vice versa.

Scenario 2 – using TLS only for creating a secure communication line + proof of identity

In this scenario, we “Extend” the use of the TLS protocol for two purposes: encrypting the data transferred via the communication channel + using the server certificate as a “tool” for proving the server’s identity.

For example, in a scenario in which we want to implement a mutual authentication between the two mail servers so, each server will be able to “trust” the other mail server.

When mail server A, start the communication process by addressing mail server B, Server A will verify that certificate of mail server B is valid and legitimate.

Only after server A will finish verifying the identity of server B, server A will be “willing” to start the process of securing the communication line.

In reality, the need for server authentication doesn’t need to be enforced by the “other side”.

• In a case that server B is not configured to require mail server A to prove his identity, the TLS communication channel will start.
• In case that server B is configured to – require from mail server A to prove his identity, mail server A will need to provide a valid server certificate and only after mail server B identifies server A, the TLS communication channel will start.

TLS and the use of a server certificate

In the following diagram, we can see the presentation of the TLS protocol options.

The server certificate used for encrypting the data that flow in the communication channel and also serves as a tool for the server to prove his identity.

When relating to the subject of Authentication or proof of identity, the TLS protocol enables us to implement a symmetric process in which server A must verify the identity of server B.

This method described as – Two-Way Authentication or Mutual Authentication.

Another option is to use a non-symmetric process in which only one side needs to identify the “other side” but the “other side” doesn’t pose a mandatory requirement for the identification of the other side.

For example – server A must identify server B but server B doesn’t need to identify server A.

The way that each side use for identifying himself is, by providing a server certificate to the “other side” that will serve as a proof of his identity.

The server certificate could be a self-signed certificate or, a public certificate that was created and signed by a public CA (certificate authority).

We will not get a detailed review of the certificate subject, but mention that in most of the scenarios in which the two parties that involved in the TLS session have a “public presence” such as a mail server that communicates with Exchange Online and vice versa, the server certificate will have to be a public certificate, so that side A, will be able to verify the identity of side B and vice versa.

If we want to make it even more complicated, the TLS protocol defines two options or, two “level” that relates to the certificate that one of the sides provides.

Option 1 – side A will be “satisfied” with the fact that certificate that side B provides is a public certificate that was created by a well-known and trusted CA.

Option 2 – side A will be “satisfied” only if the certificate that side B provides is a public certificate that was created by a well-known and trusted CA + the certificate needs to include a particular hostname (FQDN if we want to be more accurate) or a domain name that represents the server which provides the public certificate.

The next article

In the next article – Opportunistic TLS versus Force TLS in Exchange-based environment | Part 2#12, we will review the two flavors of TLS in Exchange environment: Opportunistic TLS vs. Force TLS