Schannel SSP Technical Overview

發行項
09/06/2016

Applies To: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8

This reference topic for IT professionals explains what the Secure Channel (Schannel) Security Support Provider (SSP) is and what authentication services it provides by using the Transport Layer Security (TLS), and the Secure Sockets Layer (SSL) protocols.

This topic includes the following sections:

Note

TLS is described in the Transport Layer Security protocol topic. DTLS, which is included in the Schannel SSP, is described in the Datagram Transport Layer Security protocol topic.

What are TLS, SSL, and Schannel?

One issue to address when you administer a network is securing data that is being sent between applications across an untrusted network. You can use TLS/SSL to authenticate servers and client computers, and then use it to encrypt messages between the authenticated parties.

The TLS protocols, SSL protocols, DTLS protocol, and the Private Communications Transport (PCT) protocol are based on public key cryptography. The Schannel authentication protocol suite provides these protocols. All Schannel protocols use a client and server model. For a list of supported protocols, see Supported Cipher Suites and Protocols in the Schannel SSP.

In the authentication process, a TLS/SSL client computer sends a message to a TLS/SSL server, and the server responds with the appropriate information to authenticate itself. The client and server perform an additional exchange of session keys, and the authentication dialog ends. When authentication is complete, SSL communication can begin between the server and the client by using the symmetric encryption keys that are established during the authentication process.

For servers to authenticate to clients, TLS/SSL does not require server keys to be stored on domain controllers or in a database, such as Active Directory Domain Services. Clients confirm the validity of a server’s credentials with trusted root certification authority (CA) certificates, which are loaded when you install a Windows Server operating system. Therefore, unless user authentication is required by the server, users do not need to establish accounts before they create a secure connection with a server.

History and standards for TLS and SSL

SSL was developed by Netscape Communications Corporation in 1994 to secure transactions over the World Wide Web. Soon after, the Internet Engineering Task Force (IETF) began to develop a standard protocol that provided the same functionality. They used SSL 3.0 as the basis for that work, which evolved into the TLS protocol. The implementation of the TLS protocol, beginning with Windows Server 2003, closely follows the specification defined in the following specifications listed in the IETF RFC database:

TLS and SSL are most widely recognized as the protocols that provide secure HTTP (HTTPS) for Internet transactions between web browsers and web servers. TLS/SSL can also be used for other application level protocols, such as File Transfer Protocol (FTP), Lightweight Directory Access Protocol (LDAP), and Simple Mail Transfer Protocol (SMTP). TLS/SSL enables server authentication, client authentication, data encryption, and data integrity over networks such as the World Wide Web.

Differences between TLS and SSL

Although there are some slight differences between SSL 3.0 and the versions of TLS, this reference guide refers to the protocol as TLS/SSL.

Note

TLS and SSL 3.0 are not interchangeable, although their differences are minor. If the same protocol is not supported by the client and the server, they must negotiate a common protocol to communicate successfully.

Because SSL was vulnerable to increasing security attacks, the IETF developed Internet standards for a more secure protocol, which is TLS. The following list describes TLS improvements beyond the ability of SSL to secure communication over untrusted networks.

The keyed-hash message authentication code (HMAC) algorithm replaces the SSL message authentication code (MAC) algorithm.
TLS is standardized, and it is an Internet standard, whereas SSL has numerous variants.
TLS contains additional alert messages.
SSL requires certificates that are issued by (or chained back to) the root CA. When you se TLS, it is not always necessary to include certificates chained back to the root CA. You can use an intermediary authority.
Fortezza algorithms are not included in the TLS RFC because they are not open for public review.

Benefits of TLS and SSL

TLS/SSL provides numerous benefits over using other methods of authentication for clients and servers. The following table describes some of these benefits:

Benefit	Description
Strong authentication, message privacy, and integrity	TLS/SSL can help secure transmitted data by using encryption. TLS/SSL authenticates servers, and optionally, it authenticates clients to prove the identities of the systems that are engaged in secure communication. It also provides data integrity through an integrity check value. In addition to protecting against data disclosure, the TLS/SSL security protocol can be used to help protect against masquerade attacks, man-in-the-middle or bucket-brigade attacks, rollback attacks, and replay attacks.
Interoperability	TLS/SSL works with most web browsers and on most operating systems and web servers. It is often integrated in news readers, LDAP servers, and a variety of other commercially available applications.
Algorithm flexibility	TLS/SSL provides options for the authentication mechanisms, encryption algorithms, and hash algorithms that are used during the secure session.
Ease of deployment	Many applications use TLS/SSL transparently in Windows Server operating systems. You can use TLS for more secure browsing when you are using Internet Explorer and Internet Information Services (IIS). If the server already has a server certificate installed, you only have to select the check box in Internet Explorer.
Ease of use	Because you implement TLS/SSL under the application layer, most of its operations are completely invisible to the client computer. This allows the client to have little or no knowledge of security of communications and still be protected from attackers.

Limitations of TLS and SSL

There are a couple limitations to using TLS/SSL, as discussed in the following table.

Limitation	Description
Increased processor load	This is the most significant limitation to implementing TLS/SSL. Cryptography, specifically public key operations, is CPU-intensive. As a result, performance varies when you are using SSL. Unfortunately, there is no way to know how much performance you will lose. The performance varies depending on how often connections are established and how long they last. TLS uses the greatest resources when it is setting up connections.
Administrative overhead	A TLS/SSL environment is complex and requires maintenance. The system administrator must configure the system and manage certificates.

Increased processor load

This is the most significant limitation to implementing TLS/SSL. Cryptography, specifically public key operations, is CPU-intensive. As a result, performance varies when you are using SSL. Unfortunately, there is no way to know how much performance you will lose. The performance varies depending on how often connections are established and how long they last. TLS uses the greatest resources when it is setting up connections.

Administrative overhead

A TLS/SSL environment is complex and requires maintenance. The system administrator must configure the system and manage certificates.

Common TLS and SSL scenarios

Many people think of TLS and SSL as protocols that are used with web browsers to browse the Internet more securely. However, they are also general purpose protocols that can be used whenever authentication and data protection are necessary. In fact, the ability to access these protocols through the Security Service Provider Interface (SSPI) means that you can use them for almost any application. Many applications are being modified to take advantage of the features of TLS/SSL. The following table provides examples for how you can use TLS/SSL.

Scenario	Description
SSL transactions with an e-commerce website	This situation represents a typical use of SSL between a browser and a web server. An example is an e-commerce shopping site where patrons need to provide their credit card numbers. The protocol first confirms that the certificate of the website is valid, and then it sends the credit card information as cipher text. For this type of transaction, when the server’s certificate comes from a trusted source, authentication only occurs for the server. TLS/SSL must be enabled for the webpage, such as an order form, where the data transactions occur.
Authenticated client access to a website secured with SSL	The client and the server need certificates from a mutually trusted certification authority (CA). With the Schannel SSP, client certificates can be mapped on a one-to-one or many-to-one basis to user or computer accounts on a Windows Server operating system. They can then be managed through Active Directory Users and Computers, and users can be authenticated to a website without providing a password. Many-to-one mapping has several uses. For example, if you want to give several users access to confidential material, you can create a group, map the users’ certificates to the group, and give the group the necessary permissions to the material. In one-to-one mapping, the server has a copy of the client’s certificate, and when a user signs in from the client computer, the server verifies that they are identical. This one-to-one mapping is typically used for private material, such as a banking website where only one individual has the right to view a personal account.
Remote access	Telecommuting is a common use for the Schannel SSP. You can use this technology to provide authentication and data protection when users remotely sign in to Windows-based systems or networks. Users can more securely access their email or enterprise applications from home or when traveling, reducing the risk of exposure of the information to anyone on the Internet.
SQL Server access	You can require authentication of a client computer when it connects to a server running SQL Server. The client or the server can be configured to require encryption of the data that is transferred between them. Very sensitive information, such as financial or medical databases, can be protected to prevent unauthorized access and disclosure of information about the network.
Email	When you use Exchange Server, you can use the Schannel SSP to help protect data as it moves from server to server on the intranet or Internet. Full end-to-end security might require the use of Secure/Multipurpose Internet Mail Extensions (S/MIME). However, helping to protect data in a server-to-server exchange allows companies to use the Internet to securely transfer email among divisions within the same company, subsidiaries, and partners. This can be done regardless of whether S/MIME is used.

Schannel SSP architecture

In the Windows Server operating systems, the Schannel authentication protocol suite contains TLS. The following diagram shows where the Schannel SSP fits among these and other technologies. Client applications or server applications use Secur32.dll by way of SSPI calls to communicate with the Local Security Authority Subsystem Service (LSASS).

Schannel SSP architecture

The following table lists descriptions of the elements that participate in TLS/SSL.

Security subsystem elements used in TLS and SSL authentication

Element	Description
Schannel.dll	TLS/SSL authentication protocol. This protocol provides authentication over an encrypted channel instead of a less-secure clear channel.
Lsasrv.dll	The LSASS enforces security policies and acts as the security package manager for the Local Security Authority.
Netlogon.dll	In regards to TLS services, the Netlogon service passes the user’s certificate information through an SSL channel to the domain controller to map the user certificate to a user account.
Secur32.dll	The multiple authentication provider that implements SSPI.

The authentication protocol suite is enabled by the Schannel SSP, which is supported by the SSPI application programming interface (API) that provides the security services for Windows Server operating systems.

The Microsoft Security Support Provider Interface (SSPI) is the foundation for authentication in the Windows operating system. That is, applications and infrastructure services that require authentication use SSPI to provide it. When a client and a server need to be authenticated so they can communicate more securely, the requests for authentication are routed to the SSPI, which completes the authentication process, regardless of the network protocol currently in use. The SSPI is the implementation of the Generic Security Service API (GSSAPI). For more information about GSSAPI, see the following RFCs in the IETF RFC database.

For information about the SSPI architecture for all SSPs and how the Kerberos provider fits into this architecture, see Security Support Provider Interface Architecture.

You can use the Schannel SSP for access to web-enabled services, such as email or personal information that is served on webpages. The Schannel SSP uses public key certificates to authenticate parties. It includes four authentication protocols in the suite. When authenticating parties, it will select one of the four protocols in the following order of preference:

TLS version 1.2
TLS version 1.1
TLS version 1.0
SSL version 3.0

The Schannel SSP then selects the most preferred authentication protocol that the client and server can support. For example, if a server supports all four Schannel protocols and the client computer supports only SSL 3.0, the Schannel provider uses SSL 3.0 for authentication.

Management of trusted issuers for client authentication

Prior to Windows Server 2012 and Windows 8, applications or processes that used the Schannel SSP (including HTTP.sys and IIS) could provide a list of the trusted issuers that they supported for client authentication. This information was provided through a Certificate Trust List (CTL).

When authentication of the client computer is required by using SSL or TLS, the server can be configured to send a list of trusted certificate issuers. This list contains the set of certificate issuers that the server will trust, and it provides a hint to the client computer as to which client certificate to select if there are multiple certificates present. In addition, the certificate chain the client computer sends to the server must be validated against the configured trusted issuers list.

In Windows Server 2012 and Windows 8, changes were made to the underlying authentication process so that:

CTL-based trusted issuer list management is no longer supported.
The behavior to send the trusted issuer list by default is off. The default value of the SendTrustedIssuerList registry key is now 0 (off by default), instead of 1.
Compatibility with previous versions of Windows operating systems is preserved.

This allows for more familiar manageability through the existing certificate management cmdlets in the Windows PowerShell provider, and command-line tools, such as certutil.exe. Although the maximum size of the trusted certification authorities list that the Schannel SSP supports (16 KB) remains the same as in Windows Server 2008 R2, in Windows Server 2012, there is a new dedicated certificate store for client authentication issuers so that unrelated certificates are not included in the client/server message.

How it works

The trusted issuers list is configured by using certificate stores: one default global computer certificate store and one that is optional per site. The source of the list is determined as follows:

If there is a specific credential store configured for the site, it will be used as the source.
If no certificates exist in the application-defined store, Schannel checks the Client Authentication Issuers store on the local computer. If certificates are present, Schannel uses that store as the source.
If neither the global or local stores contain certificates, the Schannel SSP will use the Trusted Root Certification Authorities store as the source of trusted issuers list. (This is also the behavior in Windows Server 2008 R2.)

You can construct a list of probable certificate issuer names that provide the end user with hints about which one to choose. This list is configurable using Group Policy.

If the Trusted Root Certification Authorities store contains a mix of root (self-signed) and certification authority (CA) issuer certificates, only the CA issuer certificates will be sent to the server by default.

How to configure Schannel to use the certificate store for trusted issuers

The Schannel SSP will, by default, use the stores as described previously to manage the trusted issuers list. You can still use the existing certificate management cmdlets in the Windows PowerShell provider, and command-line tools, such as certutil.exe to manage certificates.

For information about managing certificates by using the Windows PowerShell provider, see AD CS Administration Cmdlets in Windows.

For information about managing certificates by using the certificate utility, see certutil.exe.

For information about what data (including the application-defined store) is defined for a Schannel credential, see SCHANNEL_CRED structure (Windows).

Configuring an application or feature to use the Client Authentication Issuers store

Some technologies do not use the Client Authentication Issuers store by default. In these cases, you must configure the technology to use the store.

For example, with the web server, HTTP.sys, which implements the Windows HTTP-server stack, is not configured by default to use the Client Authentication Issuers store.

To configure HTTP.SYS to use the Client Authentication Issuers store, you can use the following command:

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

To find the values for certhash and appid on your server, you can use the following command:

netsh http show sslcert

Defaults for trust modes

There are three client authentication trust modes supported by the Schannel SSP. The trust mode controls how validation of the client’s certificate chain is performed. It is a system-wide setting that is controlled by REG_DWORD “ClientAuthTrustMode” under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.

Value	Trust Mode	Description
0	Machine Trust (default)	Requires that the client certificate is issued by a certificate in the trusted issuers list.
1	Exclusive Root Trust	Requires that a client certificate is chained to a root certificate that is contained in the caller-specified trusted issuer store. The certificate must also be issued from the trusted issuers list.
2	Exclusive CA Trust	Requires that a client certificate is chained to an intermediate CA certificate or to a root certificate in the caller-specified trusted issuer store.

For information about authentication failures due to configuration issues in the trusted issuers list, article 280256 in the Microsoft Knowledge Base.

TLS and SSL dependencies

TLS and SSL depend on several related technologies and resources to function properly. The following table describes these technologies and resources and summarizes how they relate to TLS/SSL authentication.

Dependency	Description
Operating system	TLS and SSL authentication rely on client functionality that is built-in to the Windows Server operating systems and the Windows client operating systems. If a client or server is running an operating system that does not support TLS/SSL, it cannot use TLS/SSL authentication.
TCP/IP network connectivity	For TLS or SSL authentication to occur, there must be TCP/IP network connectivity between the client and the target server. For more information, see TCP-IP.
Active Directory domain	When a server application requires client authentication, the Schannel SSP automatically attempts to map the certificate that is supplied by the client to a user account. You can authenticate users who sign in with a client certificate by manually creating mappings, which relate the certificate information to a Windows user account. After you create and enable a certificate mapping, each time a client presents a certificate, your server application automatically associates that user with the appropriate user account in the Windows operating system. You must use user accounts in Active Directory Domain Services if you want to use certificate mapping. For more information, see Active Directory Domain Services Overview.
Trusted certification authorities	Because authentication relies on digital certificates, certification authorities (CAs) (such as Verisign or Active Directory Certificate Services) are an important part of TLS/SSL. A CA is a mutually trusted, non-Microsoft certificate that confirms the identity of a certificate requestor (usually a user or computer), and then issues the requestor a certificate. The certificate binds the requestor’s identity to a public key. CAs also renew and revoke certificates as necessary. For example, if a client is presented with a server’s certificate, the client computer might try to match the server’s CA against the client’s list of trusted CAs. If the issuing CA is trusted, the client will verify that the certificate is authentic and that it has not been tampered with. For more information about CAs, see Active Directory Certificate Services Overview.

共用方式為