自动发现流程和 Exchange 安全基础架构 |第 20 部分#36

本文主要讨论作为自动发现过程的一部分实现的安全机制的主题。

自动发现和安全

自动发现机制包括三个主要部分：

1. 找到自动发现端点
2. 获取自动发现信息\data
3. 使用自动发现信息

在本文中，我们涉及图中的“中间部分”，该部分处理“获取自动发现信息\数据”的任务。

自动发现流程旨在为“客户端”提供一种从“服务器”（Exchange 或自动发现端点）获取所需信息的高效且安全的方式。

“安全之路”的含义，翻译为三大强制性要求：

1.证明身份的能力

自动发现会话中的每个相关方（即客户端和服务器）都需要证明自己的身份并“证明”他的身份。

客户端和服务器必须实现一种“相互信任”的模型，客户端可以知道服务器是“可靠的信息来源”，服务器可以知道客户端是“授权”获取特定信息的。

通过使用相互身份验证实现相关各方之间的信任。

“服务器端”将通过提供证书来表明自己的身份；客户端将通过提供用户凭据来识别自己的身份。自动发现客户端验证 Exchange 证书正常并且服务器可以信任后，自动发现客户端还需要向 Exchange 服务器证明其身份。

“自动发现客户端证明”不是通过提供证书（客户端证书）来实现的，而是通过提供将使用服务器证书中的公钥进行加密的用户凭据（用户名+密码）来实现。

2.确保通信通道安全的能力

通过加密两个自动发现端点之间传输的数据来实现的安全通信通道。

3.提供数据完整性的能力

“数据完整性”的含义是使用一种机制，使各方能够确保发送的数据不被修改、损坏等。

在下图中，我们可以看到需要满足的基本要求。这一不同要求的实现由 SSL 基础设施实现。

SSL (HTTPS) 基础设施和 Exchange 自动发现

SSL 代表 - 安全套接字层。 SSL 机制由名为 HTTPS（HTTP 安全）的协议实现。

Exchange 自动发现基础结构构建在 SSL 基础结构之上。

术语“SSL 基础设施”由许多不同的部件和组件构建而成。对每个元素进行详细审查是我们当前文章范围的展望。

相反，我们将提及构建 SSL 信息的一些“部分”以及自动发现过程如何“使用”该部分。

自动发现和服务器端公共证书

HTTPS 和 SSL（Exchange 自动发现过程使用的机制）的基础结构严重依赖于“服务器端证书”。

术语“服务器”涉及向客户端提供服务的元素。

在我们的场景中，服务器是 Exchange 服务器（自动发现端点），它为其自动发现客户端提供自动发现服务。

注意 - 在当前文章中，我们将提到术语“公共证书”。从技术上讲，服务器证书不必被视为由公共 CA（证书颁发机构）创建的公共证书。
在公共环境中，强制需要公共证书。由于 Exchange 基础结构向驻留在公共网络上的外部客户端提供服务，因此我们可以看到 Exchange 服务器必须使用公共证书。
服务器端（Exchange 服务器）公共证书有两个用途：

服务器端（Exchange 服务器）公共证书有两个用途：

1.服务器向自动发现客户端提供身份证明的能力

Exchange 客户端（自动发现客户端）不会通过中继来了解他尝试通信的 Exchange 服务器是否“确实是他所说的那个人”。 ”

服务器公共证书使 Exchange 服务器（自动发现端点）能够向自动发现客户端证明其身份。

2.创建安全的通信链接

自动发现规定必须对两侧之间传递的信息进行加密。

通过使用客户端创建并用于两个端点之间的数据加密任务的会话密钥来实现数据加密。

公共证书类型

证书的一般分类可以是：

1. SAN -（主题备用名称） - 为“代表”有限数量的主机而创建的证书。大多数情况下，主机名将显示为 FQDN，这意味着包含主机名 + 域名的命名约定。
2. 通配符证书 - 代表“完整”域名而不仅仅是特定主机或 FQDN 的证书。使用名称“通配符”是因为所使用的语法基于用于表示通配符的星号字符。例如，域名的通配符证书 - com 将与域名关联为 - *.o365info.com

自动发现 |数据加密过程

快速浏览一下用于在服务器和客户端之间“构建安全通信通道”的方式。

第 1 步 - 验证服务器身份，获取公共证书，并从证书中获取公钥。

客户端请求服务器向他提供证书。客户端执行验证服务器证书是否“OK”的过程。 ”并且服务器是可以信任的。
客户端从服务器证书中“获取”公钥。

第 2 步 - 创建会话密钥、加密、发送到服务器。

如果验证服务器公共证书的过程成功完成，客户端“生成一个代码”，描述为 - 会话密钥。
会话密钥是“密码” ”，服务器和客户端使用它来加密通过安全通信链路传输的数据。

客户端使用服务器公钥对会话密钥进行加密。
“（客户端从服务器证书中“获取”公钥的值）。

客户端将信息发送回服务器

第 3 步 - 服务器提取会话密钥

只有拥有私钥的服务器才能打开加密代码并找到“隐藏”在加密数据中的会话密钥的值。

现在，客户端和服务器有一个只有他们自己知道的会话密钥（密码）。
从今天起，客户端和服务器之间传输的每条数据都将使用 会话密钥。

注意：顾名思义，会话密钥“仅适用于特定会话”。
每次客户端与服务器创建新的通信时，都会重新执行该过程，并生成新的会话密钥。

自动发现流程和安全性详细信息

在自动发现过程中，自动发现客户端的第一次尝试是检查自动发现端点是否可以使用 HTTPS 进行通信，如果答案为“是”，自动发现客户端将向自动发现端点询问其证书。

自动发现客户端将需要实施严格的“有效性检查”，以便他能够毫无疑问地确保服务器证书有效且合法。

如果服务器证书被认为有效，自动发现客户端将向服务器提供其凭据，从今天起，通过通信通道传递的所有数据都将被加密。

服务器公共证书有效性检查

服务器证书必须符合客户端执行的所有三项验证测试。为了能够说特定证书是“有效的”，所有三个验证测试都必须成功完成。

注意： 验证过程基于 HTTPS 协议“工作”的方式以及现实情况；该过程更加复杂，还包括额外的步骤，例如使用服务器数字签名验证证书数据的完整性等。

客户端实施的三个验证测试是：

1.验证证书名称。

术语“验证证书名称”有点令人困惑。
其含义是当客户端尝试使用特定主机名寻址目标主机时，或者更准确地说是 FQDN（完全限定）域名），客户端除了服务器证书都会包含这个主机名。

情况 1 - 服务器使用 SAN 证书

术语“SAN”（主题备用名称）描述了包含或与特定主机名相关的证书方法。

如果 SAN 证书包含四个主机名，则该证书可由四个不同的主机使用，或者仅由一台想要使用不同主机名“展示自己”的服务器使用。

例如，当自动发现客户端寻址名为 autodiscover.o365info.com 的自动发现端点时，即为客户端，但该名称将出现在服务器证书中。

如果服务器证书不包含自动发现客户端期望查找的服务器名称，自动发现过程将失败。

如果服务器使用 SAN 证书，则自动发现客户端使用的主机名与需要出现在服务器证书中的名称之间的匹配是强制要求。

情况 2 - 服务器使用通配符证书

通配符证书与特定主机名（FQDN 名称的“左侧部分”）无关，而仅与域名（FQDN 名称的“右侧部分”）相关。

在这种情况下，证书仅包含域名。

使用 FQDN 名称（其中域名部分与通配符证书上显示的域名相同）的每个主机都可以使用此证书。

例如，如果特定 Exchange 服务器的自动发现主机名是 - autodiscover.o365info.com，则该服务器提供的通配符证书是代表该服务器的证书。域名 - o365info.com 而不仅仅是特定的主机名。

现实生活中的例子

公共证书类型

1. SAN证书

在下面的屏幕截图中，我们可以看到 SAN 证书的示例。

我们可以看到，一个证书链“托管”多个主机名，甚至多个域名。

2.通配符证书

下一个示例是 Office 365 通配符证书。

在下面的截图中，我们可以看到一个有趣的现象——所有庞大的Office 365和Exchange Online基础设施，都是由一个非常简单且“瘦”的证书来代表的。 ”

Office 365 使用包含域名的通配符证书：
*.office365.com 和 *.outlook.com

“属于”这些域之一的所有 Office 365 和 Exchange Online 服务器都可以使用此证书。

我们可以将通配符证书视为 FQDN 名称中包含该域名之一的所有主机的“逻辑保护伞”。

证书CA

在下面的屏幕截图中，我们可以看到由公共 CA - GoDaddy 创建的公共证书的示例

CA 的名称出现在“发行人”字段下。

证书信任链。

在大多数情况下，提供证书的 CA 是链条中的最后一环。

很多时候，有一个额外的 CA“注册”其他 CA 作为可以“注册”其他服务器的权限。

在“安全”的世界里，客户端必须确信服务器提供的证书是合法的、可以信任的。

因此，服务器向客户端发送证书后，客户端需要从证书信任链中“拉取 Outlook”。

下一步将验证证书信任链中出现的任何 CA。

问题1：客户端（自动发现客户端）如何信任服务器（自动发现端点）提供的证书？

A1：服务器提供的证书由公共 CA“盖章”。

Q2：客户为什么要信任这个“CA”？

A2：基本假设是客户端桌面包含一个证书存储，其中包含客户端可以信任的“已批准”公共 CA 列表。

答案非常简单：每个“基于窗口”的操作系统默认都包含一个名为：证书存储的数据库。

证书存储区包含这些“上市公司”（例如 GoDaddy、GTE Cyber Trust、DigiCert 等）的证书。

在下面的屏幕截图中，我们可以看到 Windows 操作系统证书存储和 CA 证书的“内部”示例。

术语“证书信任链”描述了实体之间的“信任层次结构”。

为了简单起见，很多时候，通过向特定服务器提供公共证书来“授权”该服务器的 CA 是授权该服务器的其他 CA 的“子级”或下级。

当客户端获得服务器公共证书时，除了验证提供证书的特定服务器的详细信息之外，客户端还必须验证所有“信任层次结构”，即整个过程中涉及的所有 CA。

有关证书信任链的信息必须作为证书的一部分出现。

现实生活中的例子：让我们以我拥有的公共证书为例。

在证书路径选项卡下，我们可以看到清晰的层次结构图。

该证书是由 GoDaddy 的 CA（证书颁发机构）为名为 - o365info.com 的主机提供的。

提供此证书的 CA 名称是 - GoDaddy 安全证书颁发机构 G2（编号 2）。

正如我们所看到的，GoDaddy 安全证书颁发机构 CA 并不位于“链的顶端”。

注册服务器证书的权限是由名为“Go Daddy 根证书颁发机构 - G2”（编号1）。

在下图中，我们可以看到证书信任链流程的描述。

步骤1+2：客户端访问服务器并要求他提供证书。
当客户端获得服务器证书时，他会验证服务器名称是否出现在证书中，以及该名称是否存在看来客户端正确地进入下一步。

现在，客户端将尝试与 CA 服务器（在我们的场景中是 GoDaddy 安全证书颁发机构）进行通信，并要求他提供他的公共证书。

如果 CA 提供其公共证书，客户端将检查这是否是“层次结构的末端”。

如果答案是：“是”，客户将进入下一步。

第 3 步：客户端访问其本地证书存储，并查找 CA 证书（层次结构中的最后一个 CA）。

如果 CA 证书出现在客户端证书存储中并且该证书有效，则这对于客户端来说是一个“标志”，表明他可以信任他想要与之通信的服务器。

3.验证证书日期是否有效

这是“证书验证过程”中最简单的部分。 ”

每个证书都有“有限的生命周期”。最常见的“公共证书，有效期”是1-4年。

数字签名

Q3：客户如何确定证书是合法的而不是假的？

A3：公共证书包含数字签名。客户端“知道”如何实现一个过程，在该过程中他可以验证服务器提供的证书是否是他从 CA 获得的“原始证书”。

证书公钥
在下面的屏幕截图中，我们可以看到证书中出现的公钥值的示例。

公共证书场景故障排除

在下一节中，我想回顾一些可能干扰自动发现过程的可能场景。

众所周知，自动发现过程首先查找根域名。

在我们的场景中，公司公共域名是 - o365pilot.com

名为 Bob 的用户的电子邮件地址为 [email protected]，想要创建新的 Outlook 邮件配置文件。

由 Outlook 客户端初始化的自动发现进程将尝试查找名为 - o365pilot.com 的主机，如果找到，则尝试创建 HTTPS 会话并请求自动发现所需信息。

场景 1：没有“映射”到该域名的公共网站。
在我们的场景中，该公司没有将域名发布或“映射”到公共网站。

注意 - 可能存在一种不同的情况，即该公司有一个网站，并且根域名在 DNS 中映射到该网址的公共 IP，但该网站不支持 HTTPS。

当自动发现客户端启动该过程时，他将联系 DNS 服务器，查找有关 - o365pilot.com 的公共 IP 的信息

因为，在我们的场景中，没有此类信息，自动发现客户端“理解”他应该开始使用使用命名约定的自动发现主机名的第二种方法 - autodiscover.o365pilot.com

如果Exchange服务器配置正确，自动发现客户端将查找主机的IP地址，检查主机（Exchange服务器）是否支持HTTPS，要求提供服务器证书等。

场景2：公共网站+公共证书
在这个场景中，公司有一个网站。
网站的公共IP在DNS服务器中“映射”到公司公共域名 - o365pilot.com

此外，该公司网站支持 HTTPS 并拥有证书。
为了能够演示此场景中可能出现的问题，我们将模拟两个与 Web 服务器证书相关的适当问题。

问题 1：服务器证书不是由公共 CA 提供

在这种情况下，公司网站使用由非公共 CA 创建的证书。

为了能够获得有关“Web 服务器”证书的更多信息，让我们看一下证书内容：

在下面的屏幕截图中，在常规选项卡下，我们可以看到证书图标带有红色停止标志。警告通知是——

证书无法由受信任的证书颁发机构验证。

请注意，服务器证书包含主机名 - o365pilot.com，并且证书日期有效，但“受信任的 CA 未创建服务器证书”，因此，验证检查将失败。

在证书路径选项卡下，我们可以看到没有“证书链”的含义——我们找不到提供该证书的“元素”（公共CA）。

使用 ExRCA 分析自动发现工作流程

为了能够更仔细地了解此场景中的自动发现流程，我们将使用 ExRCA 测试的结果。

在下面的屏幕截图中，我们可以看到自动发现过程的第一部分成功完成（数字1 + 2）。

自动发现客户端设法获取自动发现端点 (o365pilot.com) 的 IP 地址，并设法验证自动发现端点是否可以使用 HTTPS 协议进行通信。

（返回的 IP 地址：85.250.113.157 并测试主机 o365pilot.com 上的 TCP 端口 443，以确保其正在监听并打开）。

自动发现客户端请求服务器证书，并且证书
已成功发送到自动发现客户端（编号3）：
Microsoft Remote Connectivity Analyzer 已成功获取远程 SSL 证书。

证书验证阶段开始。
自动发现客户端执行的第一个测试是验证自动发现端点名称是否出现在证书中（编号4）。

在 ExRCA 结果中，我们可以看到服务器名称 (o365pilot.com) 显示正确 -

正在验证证书名称。证书名称已成功验证。在证书主题通用名称中找到主机名 o365pilot.com。

自动发现客户端执行的下一个验证测试是“证书信任”（数量5）。

在测试结果中，我们可以看到此测试未成功完成（数字5），因为服务器证书不是由“受信任的CA”创建或提供的：

正在验证证书信任。证书信任验证失败。
Microsoft 连接分析器正在尝试为证书 CN=o365pilot.com 构建证书链。无法为该证书构建证书链。

如果主机的有效性检查失败，自动发现客户端将“前进”到下一步，开始寻找与主机名通信的可能性 - autodiscover.o365pilot.com（数字6）。

问题2：服务器证书不包含服务器主机名

在下面的场景中，我们遇到了不同的问题。

服务器证书不包含客户端“期望”的自动发现端点的名称。

在我们的场景中，自动发现客户端通过查找名为 - o365pilot.com 的主机来开始搜索

通过查看服务器证书，我们可以看到证书上出现的名称不同。在我们的示例中，从证书中可以看到的服务器名称是 -
我们可以看到，由于证书不是由公共 CA 提供的，因此存在额外的可选问题。

因此，即使在自动发现客户端尝试检查\测试证书信任路径之前，有效性检查也会失败（并且不会继续）。

在下面的屏幕截图中，我们可以看到自动发现过程的第一部分成功完成（数字1 + 2）。

自动发现客户端设法获取自动发现端点 (o365pilot.com) 的 IP 地址，并设法验证自动发现端点是否可以使用 HTTPS 协议进行通信。

自动发现客户端请求服务器证书，并且证书
已成功发送到自动发现客户端（编号3）。

证书系列验证检查开始。
自动发现客户端执行的第一个测试是验证自动发现端点名称是否出现在证书中（编号4）。

验证测试失败，出现如下信息——

正在验证证书名称。证书名称验证失败。主机名 o365pilot.com 与服务器证书 CN=EX01.o365info.local 上找到的任何名称都不匹配。