Share via

Schannel SSP 技术概述

  • 项目

 

发布日期： 2016年8月

适用于： Windows Vista,Windows Server 2008,Windows 7,Windows 8.1,Windows Server 2008 R2,Windows Server 2012 R2,Windows Server 2012,Windows 8

面向 IT 专业人员的本参考主题介绍什么是安全通道 (Schannel) 安全支持提供程序 (SSP) 以及它使用传输层安全性 (TLS) 和安全套接字层 (SSL) 协议提供的身份验证服务。

本主题包含下列部分：

备注

传输层安全协议主题中介绍了 TLS。

数据报传输层安全协议主题中介绍了 DTLS（包含在 Schannel SSP 中）。

什么是 TLS、SSL 和 Schannel？

管理网络时要解决的一个问题是保护跨不受信任的网络在应用程序之间发送的数据。 你可以使用 TLS/SSL 对服务器和客户端计算机进行身份验证，然后使用它加密经身份验证的参与方的消息。

TLS 协议、SSL 协议、DTLS 协议和专用通信传输 (PCT) 协议基于公钥加密。 Schannel 身份验证协议套件提供这些协议。 所有 Schannel 协议使用客户端和服务器模型。 有关支持的协议的列表，请参阅 Schannel SSP 中支持的密码套件和协议。

在身份验证过程中，TLS/SSL 客户端计算机会向 TLS/SSL 服务器发送消息，服务器使用相应信息进行响应以便对自己进行身份验证。 客户端和服务器执行会话密钥的附加交换，身份验证对话结束。 身份验证完成时，SSL 通信可以使用在身份验证过程中建立的对称加密密钥在服务器与客户端之间开始进行。

对于向客户端进行身份验证的服务器，TLS/SSL 不需要将服务器密钥存储在域控制器上或数据库中（如 Active Directory 域服务）。 客户端会确认具有受信任根证书颁发机构 (CA) 证书（在安装 Windows Server 操作系统时加载）服务器凭据的有效性。 因此，除非服务器要求进行用户身份验证，否则用户不需要在创建与服务器之间的安全连接之前建立帐户。

TLS 和 SSL 的历史和标准

SSL 是 1994 年由 Netscape Communications Corporation 开发的，用于保护万维网上的事务。 不久之后，Internet 工程任务组 (IETF) 开始开发提供相同功能的标准协议。 他们使用 SSL 3.0 作为该工作的基础，这发展为 TLS 协议。 从 Windows Server 2003 开始，TLS 协议的实现紧密遵循 IETF RFC 数据库中列出的以下规范中定义的规范：

作为为 Web 浏览器与 Web 服务器之间的网上事务提供安全 HTTP (HTTPS) 的协议，TLS 和 SSL 得到了最广泛的认同。 TLS/SSL 还可以用于其他应用程序级别协议，如文件传输协议 (FTP)、轻型目录访问协议 (LDAP) 和简单邮件传输协议 (SMTP)。 TLS/SSL 在网络（如万维网）上实现了服务器身份验证、客户端身份验证、数据加密和数据完整性。

TLS 与 SSL 之间的差异

虽然 SSL 3.0 与 TLS 版本之间存在一些细微差异，不过本参考指南将协议称为 TLS/SSL。

备注

TLS 和 SSL 3.0 虽然不可互换，但是它们之间的差异十分微小。 如果客户端和服务器不支持相同的协议，则它们必须协商一种通用协议以成功进行通信。

由于 SSL 容易遭受不断增加的安全攻击，因此 IETF 开发了 Internet 标准以实现更安全的协议（即 TLS）。 以下列表介绍除超出 SSL 对不受信任网络上的通信进行保护的能力范围的 TLS 改进。

  • 键控哈希消息身份验证代码 (HMAC) 算法替代了 SSL 消息身份验证代码 (MAC) 算法。

  • TLS 进行了标准化，是一种 Internet 标准，而 SSL 具有许多变体。

  • TLS 包含其他警报消息。

  • SSL 需要由根 CA 颁发（或链接回）的证书。 使用 TLS 时，并不总是需要包含链接回根 CA 的证书。 可以使用中间颁发机构。

  • TLS RFC 中不包括 Fortezza 算法，因为它们未开放进行公开查看。

TLS 和 SSL 的益处

与将其他身份验证方法用于客户端和服务器相比，TLS/SSL 提供了许多益处。 下表介绍了其中一些益处：

益处

说明

强身份验证、消息隐私和完整性。

TLS/SSL 可以使用加密来帮助保护传输的数据。 TLS/SSL 对服务器进行身份验证，并且可以选择对客户端进行身份验证以证明参与安全通信的系统的标识。

它还通过完整性检查值提供数据完整性。

除了防范数据泄漏，TLS/SSL 安全协议还可以用于帮助防范伪装攻击 (masquerade attack)、中间人或桶队列 (bucket-brigade) 攻击、回滚攻击和重播攻击。

互操作性

TLS/SSL 在大多数操作系统和 Web 服务器上适用于大多数 Web 浏览器。 它通常集成在新闻阅读器、LDAP 服务器以及可在市场上购买的其他各种应用程序中。

算法灵活性

TLS/SSL 为在安全会话过程中使用的身份验证机制、加密算法和哈希算法提供了各种选项。

易于部署

许多应用程序在 Windows Server 操作系统中以透明方式使用 TLS/SSL。 在使用 Internet Explorer 和 Internet Information Services (IIS) 时，可以使用 TLS 实现更安全的浏览。 如果服务器已安装了服务器证书，则只需在 Internet Explorer 中选中相应复选框。

易于使用

因为你是在应用程序层下实现 TLS/SSL，所以其大多数操作对于客户端计算机都是完全不可见的。 这使客户端可以几乎或完全不了解通信安全，仍可防范攻击者。

TLS 和 SSL 的限制

使用 TLS/SSL 时有几个限制，如下表中所述。

限制

说明

增加了处理器负载

这是实现 TLS/SSL 的最重要限制。 加密（尤其是公钥操作）会大量占用 CPU。 因此使用 SSL 时，性能会发生变化。 遗憾的是，无法知道你将丢失多少性能。 性能因连接的建立频率及其持续时间长度而异。 设置连接时，TLS 会使用最多资源。

管理开销

TLS/SSL 环境十分复杂，需要维护。 系统管理员必须配置系统并管理证书。

常见 TLS 和 SSL 方案

许多人将 TLS 和 SSL 视为与 Web 浏览器一起使用以便更安全地浏览 Internet 的协议。 但是，它们也是可以在需要身份验证和数据保护时使用的通用协议。 事实上，能够通过安全服务提供程序接口 (SSPI) 访问这些协议意味着你可以将它们用于几乎任何应用程序。 许多应用程序正在进行修改以利用 TLS/SSL 功能。 下表提供有关如何使用 TLS/SSL 的示例。

方案

说明

使用电子商务网站的 SSL 事务

这种情况表示浏览器与 Web 服务器之间的 SSL 的典型用法。 一个示例是电子商务购物网站，顾客在其中需要提供其信用卡号码。 协议首先确认网站的证书是否有效，然后以密码文本形式发送信用卡信息。 对于此类型的事务，当服务器的证书来自受信任的源时，仅对服务器进行身份验证。 必须为发生数据事务的网页（如订单）启用 TLS/SSL。

对使用 SSL 进行保护的网站进行经身份验证的客户端访问

客户端和服务器需要来自相互信任的证书颁发机构 (CA) 的证书。 借助 Schannel SSP，客户端证书可以按一对一或多对一映射到 Windows Server 操作系统上的用户或计算机帐户。 它们随后可以通过“Active Directory 用户和计算机”进行管理，用户可以向网站进行身份验证而不提供密码。

多对一映射具有几种用法。 例如，如果你要使多个用户可以访问机密材料，则可以创建一个组，将这些用户的证书映射到该组，并向该组提供针对相应材料的所需权限。

在一对一映射中，服务器具有客户端证书的副本，当用户从客户端计算机登录时，服务器会验证它们是否相同。 此一对一映射通常用于私有材料（例如只有一个人有权查看个人帐户的银行网站）。

远程访问

远程办公是 Schannel SSP 的一个常见用法。 可以使用此技术在用户远程登录到基于 Windows 的系统或网络时提供身份验证和数据保护。 用户可以从家中或在旅行时更安全地访问其电子邮件或企业应用程序，从而降低向 Internet 上的任何人公开信息的风险。

SQL Server 访问

你可以在客户端计算机连接到运行 SQL Server 的服务器时要求它进行身份验证。 客户端或服务器可以配置为要求对在它们之间传输的数据进行加密。 非常敏感的信息（例如财务或医疗数据库）可以进行保护以防止未经授权的访问和有关网络的信息泄露。

电子邮件

使用 Exchange Server 时，可以使用 Schannel SSP 帮助保护 Intranet 或 Internet 上在服务器之间移动的数据。 完整的端到端安全可能需要使用安全/多用途 Internet 邮件扩展 (S/MIME)。 但是，通过帮助保护在服务器之间交换的数据，公司可以使用 Internet 在相同公司内的部门、子公司和合作伙伴间安全地传输电子邮件。 无论是否使用 S/MIME，都可以实现这一点。

Schannel SSP 体系结构

在 Windows Server 操作系统中，Schannel 身份验证协议套件包含 TLS。 下图显示 Schannel SSP 在这些技术和其他技术间的适当位置。 客户端应用程序或服务器应用程序通过 SSPI 调用使用 Secur32.dll 与本地安全机构子系统服务 (LSASS) 进行通信。

Schannel SSP 体系结构

Schannel Architecture

下表列出了参与 TLS/SSL 的元素的说明。

TLS 和 SSL 身份验证中使用的安全子系统元素

元素

说明

Schannel.dll

TLS/SSL 身份验证协议。 此协议通过加密通道而不是安全性较低的无干扰通道提供身份验证。

Lsasrv.dll

LSASS 强制实施安全策略并充当本地安全机构的安全包管理器。

Netlogon.dll

对于 TLS 服务，Netlogon 服务通过 SSL 通道将用户的证书信息传递给域控制器以将用户证书映射到用户帐户。

Secur32.dll

实现 SSPI 的多个身份验证提供程序。

身份验证协议套件由 Schannel SSP 启用，后者由为 Windows Server 操作系统提供安全服务的 SSPI 应用程序编程接口 (API) 进行支持。

Microsoft 安全支持提供程序接口 (SSPI) 是 Windows 操作系统中身份验证的基础。 也就是说，要求进行身份验证的应用程序和基础结构服务会使用 SSPI 提供它。 当客户端和服务器需要进行身份验证以便它们可以更安全地通信时，进行身份验证的请求会路由到 SSPI，后者会完成身份验证过程（不考虑当前正在使用的网络协议）。 SSPI 是通用安全服务 API (GSSAPI)。 有关 GSSAPI 的详细信息，请参阅 IETF RFC 数据库中的以下 RFC。

有关所有 SSP 的 SSPI 体系结构以及 Kerberos 提供程序如何适合此体系结构的信息，请参阅Security Support Provider Interface Architecture。

可以使用 Schannel SSP 访问启用 Web 的服务（如在网页上提供服务的电子邮件或个人信息）。 Schannel SSP 使用公钥证书验证参与方。 它在套件中包含四个身份验证协议。 对参与方进行身份验证时，会按以下优先顺序来选择四个协议之一：

  1. TLS 版本 1.2

  2. TLS 版本 1.1

  3. TLS 版本 1.0

  4. TLS 版本 3.0

Schannel SSP 随后选择客户端和服务器可以支持的最优先的身份验证协议。 例如，如果服务器支持所有四个 Schannel 协议，而客户端计算机仅支持 SSL 3.0，则 Schannel 提供程序使用 SSL 3.0 进行身份验证。

客户端身份验证的受信任颁发者的管理

在 Windows Server 2012 和 Windows 8 之前，使用 Schannel SSP（包括 HTTP.sys 和 IIS）的应用程序或进程可以提供它们支持用于客户端身份验证的受信任颁发者的列表。 此信息通过证书信任列表 (CTL) 来提供。

需要使用 SSL 或 TLS 进行客户端计算机的身份验证时，服务器可以配置为发送受信任证书颁发者的列表。 此列表包含服务器将信任的证书颁发者集合，会提示客户端计算机要选择哪个客户端证书（如果存在多个证书）。 此外，必须根据配置的受信任颁发者列表来验证客户端计算机发送到服务器的证书链。

在 Windows Server 2012 和 Windows 8 中，对基础身份验证过程进行了更改，以便：

  1. 不再支持基于 CTL 的受信任颁发者列表管理。

  2. 发送受信任颁发者列表的行为在默认情况下是关闭的。 SendTrustedIssuerList 注册表项的默认值现在是 0（默认情况下关闭）而不是 1。

  3. 保留与以前版本的 Windows 操作系统的兼容性。

这样可以通过 Windows PowerShell 提供程序中的现有证书管理 cmdlet 以及命令行工具（如 certutil.exe）实现更熟悉的可管理性。 虽然 Schannel SSP 支持的受信任证书颁发机构列表的最大大小 (16 KB) 仍与 Windows Server 2008 R2 中相同，但是在 Windows Server 2012 中，有一个新的专用证书存储用于客户端身份验证颁发者，以便不相关的证书不包含在客户端/服务器消息中。

工作原理

受信任颁发者列表使用证书存储进行配置；一个默认的全局计算机证书存储，以及对于每个站点可选的一个证书存储。 按如下方式确定列表的源：

  • 如果为站点配置了特定凭据存储，则它会用作源。

  • 如果应用程序定义的存储中不存在任何证书，则 Schannel 会检查本地计算机上的“客户端身份验证颁发者”存储。 如果证书存在，则 Schannel 使用该存储作为源。

  • 如果全局和本地存储都不包含证书，则 Schannel SSP 会使用“受信任根证书颁发机构”存储作为受信任颁发者列表的源。 （这也是 Windows Server 2008 R2 中的行为。）

你可以构造可能的证书颁发者名称列表，以便为最终用户提供有关要选择哪个名称的提示。 此列表可使用组策略配置。

如果“受信任根证书颁发机构”存储包含根（自签名）和证书颁发机构 (CA) 颁发者证书的混合，则默认情况下仅将 CA 颁发者证书发送到服务器。

如何配置 Schannel 以将证书存储用于受信任颁发者

Schannel SSP 在默认情况下会按如上所述，使用存储管理受信任颁发者列表。 你仍可以使用 Windows PowerShell 提供程序中的现有证书管理 cmdlet 以及命令行工具（如 certutil.exe）来管理证书。

有关使用 Windows PowerShell 提供程序管理证书的信息，请参阅 Windows 中的 AD CS 管理 Cmdlet。

有关使用证书实用工具管理证书的信息，请参阅 certutil.exe。

有关为 Schannel 凭据定义的数据（包括应用程序定义的存储）的信息，请参阅 SCHANNEL_CRED 结构 (Windows)。

配置应用程序或功能以使用客户端身份验证颁发者存储

某些技术在默认情况下不使用客户端身份验证颁发者存储。 在这些情况下，你必须配置该技术以使用存储。

例如，对于 Web 服务器，HTTP.sys（实现 Windows HTTP 服务器堆栈）在默认情况下未配置为使用客户端身份验证颁发者存储。

若要配置 HTTP.SYS 以使用客户端身份验证颁发者存储，可以使用以下命令：

netsh http add sslcert ipport=0.0.0.0:443 certhash=GUID hash value appid={GUID application identifier}  sslctlstorename=ClientAuthIssuer

若要在服务器上查找 certhash 和 appid 的值，可以使用以下命令：

netsh http show sslcert

用于信任模式的默认值

Schannel SSP 支持三种客户端身份验证信任模式。 信任模式控制如何执行客户端证书链的验证。 这是系统范围设置，由 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel 下的 REG_DWORD“ClientAuthTrustMode”进行控制。

值

信任模式

说明

0

计算机信任（默认值）

需要由受信任颁发者列表中的证书颁发客户端证书。

1

独占根信任

需要客户端证书链接到调用方指定的受信任颁发者存储中包含的根证书。 也必须从受信任颁发者列表颁发证书。

2

独占 CA 信任

需要客户端证书链接到中间 CA 证书或调用方指定的受信任颁发者存储中的根证书。

有关由于受信任颁发者列表中的配置问题而导致的身份验证失败的信息，请参阅 Microsoft 知识库文章 280256。

TLS 和 SSL 依赖关系

TLS 和 SSL 依赖于几个相关技术和资源才能正常运行。 下表介绍了这些技术和资源并总结了它们如何与 TLS/SSL 身份验证相关。

依赖关系

说明

操作系统

TLS 和 SSL 身份验证依赖于内置到 Windows Server 操作系统和 Windows 客户端操作系统中的客户端功能。 如果客户端或服务器运行的操作系统不支持 TLS/SSL，则无法使用 TLS/SSL 身份验证。

TCP/IP 网络连接

若要进行 TLS 或 SSL 身份验证，必须在客户端与目标服务器之间存在 TCP/IP 网络连接。 有关详细信息，请参阅 TCP/IP。

Active Directory 域

当服务器应用程序需要客户端身份验证时，Schannel SSP 会自动尝试将客户端提供的证书映射到用户帐户。 通过手动创建将证书信息与 Windows 用户帐户关联的映射，你可以对使用客户端证书登录的用户进行身份验证。 创建并启用证书映射后，客户端每次出示证书时，服务器应用程序都会自动将该用户与 Windows 操作系统中的相应用户帐户关联。 如果你要使用证书映射，则必须在 Active Directory 域服务中使用用户帐户。 有关详细信息，请参阅 Active Directory 域服务概述。

受信任的证书颁发机构

因为身份验证依赖于数字证书，所以证书颁发机构（CA，如 Verisign 或 Active Directory 证书服务）是 TLS/SSL 的重要组成部分。 CA 是相互信任的、非 Microsoft 证书，它可确认证书请求者（通常是用户或计算机）的身份，随后向请求者颁发证书。 证书将请求者的身份绑定到公钥。 CA 还根据需要续订和吊销证书。 例如，如果向客户端提供服务器的证书，则客户端计算机可能会尝试按照客户端的受信任 CA 列表来匹配服务器的 CA。 如果颁发 CA 受信任，则客户端会验证证书是否可信以及它是否未篡改。 有关 CA 的详细信息，请参阅 Active Directory 证书服务概述。

另请参阅

Schannel 安全支持提供程序技术参考