在基于 Exchange 的环境中使用 TLS |简介 |第 1 部分#12

当前文章系列的目的是回顾 TLS 协议在基于 Exchange 的环境中的实现和使用。我们将研究 TLS 协议在两个 Exchange 环境中的使用情况：

• 在线交流
• 本地交换

文章系列

专门讨论在基于 Exchange 的环境中实施 TLS 主题的文章系列包括 12 篇文章。

撰写 12 篇与基于 Exchange 环境中的 TLS 主题相关的独立文章的主要原因是，当我需要在 Exchange 环境中实现 TLS 时，我感到有些沮丧，因为我找不到清晰且直接的解释如何使用和配置 TLS 协议的不同选项和各种场景。

我撰写本系列文章的主要目的是通过演示常见场景来帮助您更好地了解 Exchange 本地和 Exchange Online 环境中的 TLS 协议主题。

TLS协议基本介绍

TLS 协议有两个主要用途

1. 加密通过两台主机之间的通信通道传递的数据
2. 使每个相关主机能够识别参与通信过程的“另一方”。

TLS 和服务器端证书

加密数据的能力和邮件服务器相互识别的能力是通过使用证书来实现的。

证书可以是“非公共证书（自签名证书）”或由受信任的 CA（证书颁发机构）颁发的公共证书。

大多数时候，当位于公共网络上的两个邮件服务器之间实现TLS通信协议时，每个邮件服务器需要使用的证书都是公共证书。

身份验证和相互身份验证

如前所述，TLS 协议的一部分是各方能够“要求”“另一方”在开始“数据传输”过程之前识别自己的身份。

身份验证要求不是强制性要求。参与通信通道的每一方（邮件服务器）都可以“决定”是否要识别“另一方”。

此外，身份验证过程不是“对称”过程。

例如 - 服务器A可以配置为识别另一端（服务器B），但这并不意味着服务器B也会需要识别服务器A。

TLS 邮件客户端与服务器到服务器 TLS 通信

一般来说，TLS协议的“使用”可以在两大场景中实现。

1. 客户端到服务器 - 通常，当我们使用术语“客户端”时，我们指的是：邮件客户端，术语“服务器”描述邮件服务器。
2. 服务器到服务器 - 两个邮件服务器之间的关系

在当前的文章系列中，将仅关注“服务器到服务器”模块，该模块描述了邮件服务器之间存在的 TLS 基础结构。

用于实施 TLS 的 Exchange 组件。

简而言之，在使用两个 Exchange 组件实现的 Exchange 基础环境中“激活”TLS 协议：

1. 交换邮件连接器
2. Exchange 传输规则（仅受 Exchange 2013 支持）。

Exchange邮件连接器简介

如前所述，当我们需要在基于 Exchange 的环境中创建 TLS 配置时，我们使用的 Exchange 组件是：

1. Exchange 邮件连接器 - 在本节中，我们将对术语“Exchange 邮件连接器”进行基本介绍。
2. Exchange 传输规则 - 使用 Exchange 传输规则来实施基于 TLS 的通信的功能仅适用于 Exchange 2013 本地版本和 Exchange Online。我们将在文章中详细介绍此选项：使用传输规则实施强制 TLS |在线交流 |第 10#12 部分以及使用传输规则和条件邮件路由实施强制 TLS |在线交流 |第 11 部分#12

创建 Exchange 邮件连接器的目的

我们可以定义使用 Exchange 邮件连接器的两个主要目的：

目的 1 - 将标准邮件流“转移”到特定渠道。如果我们使用一个比喻，将“标准”邮件流比作一条传输传入和传出电子邮件的河流，那么在某些情况下，我们需要将特定邮件流“转移”到不同的通道。

例如，我们需要将发送到特定域的邮件流“转移”到内部邮件服务器，而不是使用将电子邮件发送到公共网络的标准邮件流。

对于Exchange服务器“定位”位于“另一边”的目标邮件服务器的方式，可以通过以下方式配置目标邮件服务器的定位：

• 使用标准 DNS 查询，查找代表特定域名的主机（邮件服务器）的 MX 记录
• 通过引导我们的邮件服务器寻址特定的 IP 地址或主机名。在我们“指示”我们的 Exchange 邮件服务器寻址特定主机（IP 地址）的情况下，我们将目标邮件称为“智能主机”。

目的 2 - 使用代表特定域名的“目标邮件服务器”创建安全通信通道（加密邮件传输）。

例如，我们公司与另一家公司（合作伙伴）合作。业务需求是确保发送到该合作伙伴以及从该合作伙伴发送到我们的邮件服务器的邮件消息将通过使用 TLS 协议的安全通信通道进行传输。

为了能够满足这一要求，我们需要创建一个专用的邮件连接器，每当我们的组织用户之一发送电子邮件时，该连接器将“指示”我们的 Exchange 邮件服务器通过安全通信链路发送电子邮件。 - 发送给属于我们合作伙伴网络的收件人。

大多数时候，我们需要创建一个额外的邮件连接器，负责从我们的合作伙伴邮件基础设施接收邮件并验证通信通道是否安全（加密）。

此行为被描述为机会主义 TLS。我们将在文章 - Exchange 架构和默认机会主义 TLS 设置 | 中回顾 机会主义 TLS 的特征第 3 部分#12

邮件连接器和地址空间的简单逻辑

邮件连接器的概念基于一个简单的逻辑，可以描述为：

如果 x 那么 Y

地址空间代表的“X”和“Y”，是需要实现的“动作”。

在邮件基础设施中，术语“地址空间”描述：

• 我们发出的外发邮件中显示的域名
• 从“另一邮件服务器”发送到我们的邮件服务器的传入邮件消息中显示的域名。

让我们用两个例子来简化这个概念：

示例 1 - 将邮件消息路由到特定域名的智能主机

在我们的场景中，地址空间是域名 - test.com

我们想要定义一个邮件流，其中从 test.com 域发送的每封电子邮件都将被重定向到特定的目标邮件服务器。

邮件连接器将根据以下逻辑实现此要求：

如果邮件发送到域名 test.com (X)，则...。将电子邮件消息重定向到由 IP 地址代表的智能主机 - 10.10.10.1

示例 2 - 实施强制邮件安全通道

我们希望确保发送给特定合作伙伴的每封电子邮件都必须通过安全通信通道（加密通道）进行传输。

我们的邮件规则的逻辑是：

如果邮件发送到我们合作伙伴的域名 test.com (X)，则...。确保“另一端”（代表域名test.com的邮件服务器）支持使用TLS协议。

此类方法描述为强制 TLS。我们将在文章 6-11 中回顾强制 TLS 的概念

基于 Exchange 的环境中邮件连接器的概念

在当前的文章系列中，我们讨论的主题是：

• 在 Exchange 本地服务器和 Exchange Online 服务器之间创建安全通信链接。
• 在 Exchange Online 服务器和外部邮件服务器之间创建安全通信链接。

在我们深入研究具体细节之前，重要的是我们先停下来思考一下基本问题，例如：

问：当我们说Exchange向目标邮件服务器（如Exchange Online）发送电子邮件时，负责发送邮件的“Exchange组件”是什么？ ”在负责“接受”邮件的目标邮件服务器上？

A：答案是——在基于Exchange的环境中，发送和接收邮件的“组件”是通过邮件连接器来实现的。

在我们想要查看特定邮件服务器的 TLS 设置或配置特定 TLS 设置以创建安全通信通道的情况下，我们需要访问 Exchange 邮件连接器或创建一个新的邮件连接器来实现我们的特定所需的配置。

一般来说，Exchange Server 包括两种类型的邮件连接器 -

1. 邮件连接器用于发送邮件“out”（出站通信）。
   当基于 Exchange 的服务器需要将电子邮件发送到目标邮件服务器时，邮件将被路由到特定的邮件连接器，该邮件连接器负责发送将电子邮件消息发送到外部或其他邮件服务器。
2. 用于接受传入邮件（入站通信）的邮件连接器。

当另一个邮件服务器尝试与 Exchange 服务器通信时，Exchange 使用传入邮件连接器“侦听”通信请求。

Exchange 本地部署与 Exchange Online 邮件连接器的不同命名约定

好的，现在让我们变得更复杂 - Exchange Online 和 Exchange 本地服务器，对负责发送
电子邮件的邮件连接器和负责接受电子邮件的连接器使用不同的术语邮件。

Exchange Online - 邮件连接器 |命名约定

在 Exchange Online 环境中，我们使用以下术语：

• 负责接受传入邮件请求（当其他邮件服务器寻址 Exchange 服务器时）的连接器，描述为 - 入站连接器
• 负责发送电子邮件的连接器（当 Exchange Online 服务器寻址其他邮件服务器时），描述为 - 出站连接器

Exchange 本地服务器 - 邮件连接器 |命名约定

在 Exchange 本地服务器环境中，我们使用以下术语：

• 负责接受传入邮件请求的连接器（当其他邮件服务器地址 Exchange 本地服务器时）描述为 - 接收连接器<
• 负责发送电子邮件的连接器（当 Exchange 本地服务器寻址其他邮件服务器时）描述为 - 发送连接器

Exchange 本地和 Exchange Online 之间的邮件流方案示例

邮件连接器的概念在 Exchange 本地环境和 Exchange Online 环境中以类似的方式实现，但每个 Exchange 环境使用不同的术语来描述出站和入站邮件连接器。

为了能够了解在 Exchange Online 和 Exchange 本地环境中实施的邮件流，让我们回顾一下表征 Exchange 混合环境的场景。

场景 1 - 从 Exchange 本地服务器发送到 Exchange Online 的邮件

本地收件人将电子邮件发送到“云收件人”（Exchange Online 收件人）的场景

本地收件人创建的电子邮件发送到 Exchange 本地服务器。

Exchange 本地服务器，使用其“出站连接器”，描述为 - 发送连接器，用于创建与 Exchange Online 服务器的通信通道。

在 Exchange Online 环境中，“接受”通信请求的组件是“传入连接器”，描述为 - 入站连接器r 。

场景 2 - 来自 Exchange Online Exchange 本地服务器的邮件

Exchange Online 收件人向“Exchange 本地收件人”发送电子邮件的场景。

Exchange Online 收件人创建的电子邮件发送到 Exchange Online 服务器。

Exchange Online 服务器，使用他的“出站连接器”，描述为 - 出站连接器，用于创建与 Exchange 的通信通道 -场地服务器。

在 Exchange 本地服务器环境中，“接受”通信请求的组件是“传入连接器”，描述为 - 接收连接器。

有关 TLS 协议概念的一些信息

使用 TLS（传输层安全）的两个主要目的是：

1. 加密——技术术语是隐私或机密性，简单来说，需要创建一个安全的通信通道，其中两方（在我们的例子中是邮件服务器）之间传输的数据将被加密。
2. 身份验证 - 需要验证参与“数据传输（邮件）过程的各方的身份”。

A 方希望毫无疑问地确定 B 方确实是他所声称的人，反之亦然。

TLS 的实现非常灵活，因为我们能够选择不同组件含义的“级别”或程度 - 加密和身份验证。

场景 1 - 仅使用 TLS 创建安全通信线路

在这种情况下，两方（邮件服务器）的主要关注点不是需要相互识别，而是需要对用于在两个端点之间传输数据的服务器的通信线路进行加密。

- 加密数据的过程，将由服务器证书来实现，但服务器A不会验证服务器B的身份，反之亦然。

场景 2 - 仅使用 TLS 创建安全通信线路 + 身份证明

在这个场景中，我们“扩展”TLS协议的使用有两个目的：加密通过通信通道传输的数据+使用服务器证书作为证明服务器身份的“工具”。

例如，在我们希望在两个邮件服务器之间实现相互身份验证的场景中，每个服务器将能够“信任”另一个邮件服务器。

当邮件服务器A通过寻址邮件服务器B开始通信过程时，服务器A将验证邮件服务器B 的证书 有效且合法。

只有当服务器A完成验证服务器B的身份后，服务器A才会“愿意”启动保护通信线路的过程。

实际上，服务器身份验证的需要并不需要由“另一方”强制执行。

• 如果服务器B未配置以要求邮件服务器A证明其身份，则TLS通信通道将启动。
• 如果服务器B配置为 - 要求邮件服务器A证明其身份，则邮件服务器A将需要提供有效的服务器只有在邮件服务器B识别出服务器A之后，TLS通信通道才会启动。

TLS 和服务器证书的使用

在下图中，我们可以看到 TLS 协议选项的呈现。

服务器证书用于对通信通道中流动的数据进行加密，也是服务器证明其身份的工具。

当涉及身份验证或身份证明时，TLS 协议使我们能够实现一个对称过程，其中服务器 A 必须验证服务器 B 的身份。

此方法被描述为 - 双向身份验证或相互身份验证。

另一种选择是使用非对称流程，其中只有一方需要识别“另一方”，但“另一方”并不对另一方的识别提出强制要求。

例如，服务器A必须识别服务器B，但服务器B不需要识别服务器A。

每一方用于识别自己身份的方式是向“另一方”提供服务器证书，作为其身份的证明。

服务器证书可以是自签名证书，也可以是由公共 CA（证书颁发机构）创建和签名的公共证书。

我们不会详细审查证书主题，但会提到在大多数情况下，参与 TLS 会话的双方都具有“公共存在”，例如与 Exchange Online 通信的邮件服务器，反之亦然，服务器证书必须是公共证书，以便A方能够验证B方的身份，反之亦然。

如果我们想让事情变得更复杂，TLS 协议定义了两个选项，或者两个与一方提供的证书相关的“级别”。

选项 1 - A 方将“满意”，因为 B 方提供的证书是由知名且受信任的 CA 创建的公共证书。

选项 2 - 仅当 B 方提供的证书是由知名且受信任的 CA + 证书创建的公共证书时，A 方才会“满意”需要包含特定的主机名（如果我们想要更准确，则为 FQDN）或代表提供公共证书的服务器的域名。

下一篇文章

在下一篇文章中 - 基于 Exchange 的环境中的机会 TLS 与强制 TLS |第 2#12 部分，我们将回顾 Exchange 环境中的两种 TLS：机会 TLS 与强制 TLS