支持服务中的针对验证的扩展保护 (EPA)
| 功能 | 适用于 |
|---|---|
| EPA | 所有支持的 Windows OS |
| EPA 审核模式 | Windows Server 2019 Windows Server 2022 Windows Server 23H2 |
遇到了什么问题？
有一类针对经身份验证的服务的攻击，名为转移攻击。 利用这些攻击，攻击者能够绕过身份验证并假冒另一个用户。 由于这些攻击针对的是服务而非身份验证协议本身，因此对转移攻击的遏制取决于进行身份验证的服务。
转移攻击的工作原理是什么？
当服务或应用程序调用 API AcceptSecurityContext 对客户端进行身份验证时，它会传递从客户端的 InitializeSecurityContext 调用收到的一个数据 blob。 身份验证协议负责验证提供的 Blob 是否源自所指示的用户。 AcceptSecurityContext 无法断言它未看到的应用程序消息其余部分的真实性。
应用程序中一个常见安全错误是在成功对内部身份验证协议 Blob 进行身份验证后，将应用程序流量视为通过身份验证。 这通常见于使用 TLS 作为其线路协议的应用程序。 TLS 通常不使用客户端证书；它为服务器提供完整性和保密性保障，但不提供身份验证。 内部身份验证提供客户端身份验证，但仅适用于其 Blob。 它不会对 TLS 通道或其中包含的应用程序协议其余部分进行身份验证。
攻击者通过在编制的请求中插入来自一个源的身份验证 Blob 来实施转移攻击。 例如，攻击者可以观察网络上的身份验证流量，并将其插入其自己对服务器的请求中。 这使攻击者能够通过捕获的身份验证流量以客户端的身份访问服务器。
此处的重点是，SSPI 身份验证消息需要在网络上公开，而不应保密。 这不同于许多基于 Web 的身份验证方案，这些方案使用始终在 TLS 通道中保密的持有者令牌。
什么是解决方案？
首选解决方案是使用身份验证协议的会话密钥对其他流量进行签名或加密（MakeSignature、EncryptMessage）。 由于会话密钥在身份验证协议交互期间以加密方式派生，因此可保证经过其身份验证的数据以及受该密钥保护的任何流量都来自经过身份验证的客户端。
并不总是有这个选项。 在某些情况下，会按照为持有者令牌设计的标准来修复应用程序协议消息的格式。 在这种情况下，针对验证的扩展保护 (EPA) - 也称为通道绑定，可防止通过 TLS/SSL 通道执行的转发。
什么是 EPA？
EPA 以加密方式将 TLS 会话密钥绑定到身份验证协议的会话密钥，使 TLS 能够提供与身份验证协议密钥相同的客户端身份验证。 有关详细信息，请参阅针对验证的扩展保护概述。
服务绑定
EPA 的第二部分称为服务绑定。 与通道绑定不同，它不为服务提供加密保证，并在无法进行通道绑定时充当最后一道防线。 此机制使服务器能够调用 QueryContextAttributes 来检索属性 SECPKG_ATTR_CLIENT_SPECIFIED_TARGET，该属性包含传递给 InitializeSecurityContext 的经过身份验证的客户端的名称。
例如，设想某个驻留在某个终止 TLS 的负载均衡器后面的服务。 它无权访问 TLS 会话密钥，只能通过通道绑定确定客户端的身份验证是针对某个受 TLS 保护的服务。 客户端提供的名称应与用于验证 TLS 服务器证书的名称相同。 通过验证客户端正在对某个与负载均衡器中服务器 TLS 证书匹配的名称进行身份验证，服务可大概率确认身份验证来自与 TLS 通道相同的客户端。
本文不讨论如何支持服务绑定。 有关详细信息，请参阅如何：在配置中指定服务绑定。
如何支持 EPA？
实施 EPA 时，服务可能会注意到客户端由于兼容性问题而无法进行身份验证。 我们因此创建了一个 EPA 审核模式，其中服务可以启用审核，这让管理员能够在实施 EPA 之前观察客户端的响应方式。
支持审核模式的 Microsoft 服务包括：
注意
下面提供了启用 EPA 审核功能的可选步骤。 请注意，在不强制执行 EPA 的情况下启用 EPA 审核功能无法防范中继攻击。 建议有相关需要的服务先是仅在审核模式下启用 EPA，稍后采取措施修正不兼容的客户端，并在最后严格执行 EPA 以避免任何潜在的中继攻击。
注意
传入 AcceptSecurityContext 的通道绑定无需为“仅审核”绑定也能获取审核结果。 服务可以在强制实施 EPA 的同时运行审核模式。
客户端
- 使用 QueryContextAttributes (TLS) 获取通道绑定（填写唯一与终结点）
- 调用 InitializeSecurityContext，并在 SECBUFFER_CHANNEL_BINDINGS 中传递通道绑定
服务器
- 使用 QueryContextAttributes (TLS)，像在客户端上那样
- （可选）通过调用 SspiSetChannelBindingFlags 转换为“仅审核”
- （可选）将通道绑定结果缓冲区添加到 ASC 的输出缓冲区。
- 通过使用 SECBUFFER_CHANNEL_BINDINGS 调用 AcceptSecurityContext 来指定 EPA 级别和其他配置
- （可选）使用标志来控制边缘情况中的行为：
- ASC_REQ_ALLOW_MISSING_BINDINGS - 不会导致无任何信息的客户端失败，比如旧的第三方设备。 未获得 SECBUFFER_CHANNEL_BINDINGS 的启发式客户端会发送空绑定，而不是不发送任何内容。
- ASC_REQ_PROXY_BINDINGS - 对于终止 TLS 的负载均衡器而言是罕见情况。 我们没有要传递的 SECBUFFER_CHANNEL_BINDINGS，但仍希望强制客户端将请求放入 TLS 通道。 这在使用服务绑定时最有效，可确保客户端也放入服务器证书与我们名称匹配的 TLS 通道中。
如何强制实施 EPA？
一旦服务已支持 EPA，管理员可以一直控制从审核到充分实施整个过程中的 EPA 状态。 这为服务提供了所需工具来评估其生态系统的 EPA 就绪情况、修正不兼容的设备，并逐步强制实施 EPA 来保护其环境。
可使用以下属性和值在环境中强制实施各种级别的 EPA：
| 名称 | 描述 |
|---|---|
| 无 | 不执行任何通道绑定验证。 这是所有尚未更新的服务器的行为。 |
| 允许 | 所有已更新的客户端必须向服务器提供通道绑定信息。 尚未更新的客户端无需执行此操作。 这是一个中间选项，可以实现应用程序兼容。 |
| 需要 | 所有客户端都必须提供通道绑定信息。 服务器拒绝来自不提供通道绑定信息的客户端的身份验证请求。 |
这些属性可以结合审核功能来收集不同级别的 EPA 强制实施的设备兼容性信息。 需要将所需配置传递到 SspiSetChannelBindingFlags。
- 审核 - 审核模式可与上述任何 EPA 强制实施级别结合应用。
如何解释 EPA 审核结果？
审核结果是一组位标志：
| 标记 | 说明 |
|---|---|
| SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT | 客户端指示它能够进行通道绑定。 |
| SEC_CHANNEL_BINDINGS_RESULT_ABSENT | 客户端未提供与外部通道的绑定。 |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH | 客户端绑定指示使用了与服务器不同的通道。 |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING | 由于 SEC_CHANNEL_BINDINGS_RESULT_ABSENT，通道绑定失败。 |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED | 通道已成功绑定。 |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY | 客户端指示绑定到外部通道，该通道由于 ASC_REQ_PROXY_BINDINGS 而被传递。 |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING | 通道绑定由于 ASC_REQ_ALLOW_MISSING_BINDINGS 而被传递。 |
还存在多组位的定义：
| 标记 | 说明 |
|---|---|
| SEC_CHANNEL_BINDINGS_RESULT_VALID | 用于在所有 SEC_CHANNEL_BINDINGS_VALID_* 情况下进行测试。 |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID | 用于在所有 SEC_CHANNEL_BINDINGS_NOTVALID_* 情况下进行测试。 |
审核流
由于 SEC_CHANNEL_BINDINGS_RESULT_VALID 和 SEC_CHANNEL_BINDINGS_RESULT_NOTVALID，支持相应结果的任何 OS 会始终设置至少一位。
通道绑定失败：测试来自 SEC_CHANNEL_BINDINGS_RESULT_NOTVALID 的任何位。 对于非“仅审核”的绑定，这对应于 ASC 失败并收到 STATUS_BAD_BINDINGS 或 SEC_E_BAD_BINDINGS。
- SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH：客户端和服务器都了解通道绑定，但不同意使用该通道。 这是一种很难与后述攻击情况相区分的攻击情况或不当安全配置：因配置泄露用于检查流量的 HTTPS 而引发的攻击（例如 Fiddler）。 这也可能是因客户端和服务器就“唯一”绑定与“终结点”绑定发生分歧所致。
- SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING 分为两种情况：
- 使用 SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT 意味着客户端表明它知道通道绑定但却说没有绑定。 这可能是来自非 TLS 服务的转移攻击，但它很可能是客户端上运行的未启发应用程序，它在执行 TLS，但未告知内部身份验证。
- 如果没有 SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT，则是无法进行通道绑定的客户端。 所有受支持的 Windows 版本都能进行通道绑定，所以这是设置了 SuppressExtendedProtection 注册表值的第三方或系统。 如果传递 ASC_REQ_ALLOW_MISSING_BINDINGS，就会是这种情况，并会转变为 SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING。
通道绑定成功：这是故障检查或 SEC_CHANNEL_BINDINGS_RESULT_VALID 测试的相反情况。
- SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED 是成功的情况。 正在启用安全保护（或如果按“仅审核”来启用 EPA，则会启用安全保护）。
- SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING 意味着传递了 ASC_REQ_ALLOW_MISSING_BINDINGS，也即允许了一个未声明通道绑定支持的客户端。 遇到此情况的客户端不受保护，应对其进行调查以确认发生了什么问题。 需要更新它们以支持通道绑定，或在更新了出错的应用程序后清除 SuppressExtendedProtection 注册表值。
- SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY 是一种特殊情况，与 TLS 在负载均衡器处终止而非到达服务器时使用的标志 ASC_REQ_PROXY_BINDINGS 关联。 服务器无法验证客户端所使用的 TLS 连接与在负载均衡器上终止的相同。 出于审核目的，此情况与 SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED 的处理方式相同。