Differences in the Schannel SSP by Operating System Version
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 the IT professional describes the significant differences in the architecture and processes for the Schannel Security Support Provider (SSP) in the following versions of the Windows operating system:
Windows Server 2012 R2 and Windows 8.1
The following sections describe what changes in functionality were made to TLS in the Schannel SSP.
TLS session resumption
Devices that connect TLS to servers frequently need to reconnect. TLS session resumption reduces the cost of establishing TLS connections, because resumption involves an abbreviated TLS handshake,. which This facilitates more resumption attempts by allowing a group of TLS servers to resume each other’s TLS sessions.
For more information about TLS session resumption as implemented in the Schannel SSP, see TLS session resumption.
For information about stateless TLS session resumption, see the IETF document RFC 5077..
Application protocol negotiation
Windows Server 2012 R2 and Windows 8.1 support client-side TLS application protocol negotiation so applications can leverage protocols as part of the HTTP 2.0 standard development, and users can access online services (such as Google and Twitter) by using apps that run the SPDY protocol.
For more information about application protocol negotiation, see Application protocol negotiation.
For information about how application protocol negotiation works, see Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension.
Windows Server 2012 and Windows 8
The following sections describe what changes in functionality were made to TLS in the Schannel SSP.
Management of trusted issuers for client authentication
When authentication of the client computer is required by using SSL or TLS, you can configure the server 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.
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). 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.
Introduced in Windows Server 2012, the use of the CTL has been replaced with a certificate store-based implementation. This allows for more familiar manageability by using the existing certificate management cmdlets in the Windows PowerShell provider, and command-line tools, such as certutil.exe.
For more information about this feature, see Management of trusted issuers for client authentication.
For information about authentication failures due to trusted issuer's configuration issues, see article 280256 in the Microsoft Knowledge Base.
TLS support for Server Name Indication Extensions
The Server Name Indication (SNI) feature extends the SSL and TLS protocols to allow proper identification of the server when numerous virtual images are running on a single server. In a virtual hosting scenario, several domains, each with its own potentially distinct certificate, are hosted on one server. In this case, the server has no way of knowing beforehand which certificate to send to the client computer. SNI allows the client computer to provide this information to the target domain earlier in the protocol, and this allows the server to correctly select the proper certificate.
Datagram Transport Layer Security
The Datagram Transport Layer Security (DTLS) version 1.0 protocol has been added to the Schannel SSP. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client and server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol, and it provides equivalent security guarantees. This reduces the need to use IPsec or design a custom application layer security protocol.
For more information, see Datagram Transport Layer Security protocol.
Windows Server 2008 R2 and Windows 7
Schannel SSP supports TLS version 1.2 so that it can support:
Hash negotiation. The client and server can negotiate any hash algorithm to be used as a built-in feature. In addition, the default cipher pair, MD5/SHA-1, has been replaced with SHA-256.
Certificate hash or signature control. You can configure the certificate requester to accept only specified hash or signature algorithm pairs in the certification path.
Suite B–compliant cipher suites. The following two cipher suites have been added so that the use of TLS can be Suite B compliant:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
For more information about Suite B compliance as introduced in Windows Server 2008 R2 and Windows 7, see Introducing Compliance to Suite B Cryptography.
Windows Server 2008 and Windows Vista
Microsoft has added new TLS extensions that enable the support of the Advance Encryption Standard (AES) and the elliptic curve cryptography (ECC) cipher suites. In addition, custom cryptographic mechanisms can be implemented and used with the Schannel SSP as custom cipher suites.
AES cipher suites
The support for AES (which is not available in Windows 2000 Server or Windows Server 2003) is important because AES has become a National Institute of Standards and Technology (NIST) standard. To ease the process of bulk encryption, cipher suites that support AES have been added.
The following list is the subset of TLS AES cipher suites that are available in Windows Vista as defined in Request for Comments (RFC) 3268, Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS):
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
To negotiate these cipher suites, clients and servers must be running Windows Vista or Windows Server 2008.
For information about the registry entries used to configure TLS/SSL ciphers in previous versions of Windows, see TLS/SSL Tools and Settings. These settings are only available for cipher suites included with Windows operating systems earlier than Windows Vista, and they are not supported for AES.
Cipher preferences are configured in Windows Vista by enabling the SSL Cipher Suite Order Group Policy setting in Administrative Templates\Network\SSL Configuration Settings.
Note
Computers running Windows Vista must be restarted for any setting changes to take effect.
ECC cipher suites
ECC is a key-generation technique that is based on the elliptic curve theory and is used to create more efficient and smaller cryptographic keys. ECC key generation differs from the traditional method that uses the product of very large prime numbers to create keys.
Instead, ECC uses an elliptic curve equation to create keys. ECC keys are approximately six times smaller than the equivalent strength traditional keys, which significantly reduces the computations that are needed during the TLS handshake to establish a secure connection.
In Windows Vista, the Schannel SSP includes cipher suites that support ECC cryptography. ECC cipher suites can be negotiated as part of the standard TLS handshake. The subset of ECC cipher suites that are available in Windows Vista are defined in RFC 4492, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS). For more information about these cypher suites in Windows Server 2008 and Windows Vista, see Cipher Suites in Schannel (Windows).
The ECC cipher suites use three NIST curves: P-256 (secp256r1), P-384 (secp384r1), and P-521 (secp521r1).
To use the ECDHE_ECDSA cipher suites, ECC certificates must be used. Rivest-Shamir-Adleman (RSA) certificates can be used to negotiate the ECDHE_RSA cipher suites. Additionally, the clients and servers must be running Windows Vista or Windows Server 2008.
Cipher preferences are configured in Windows Vista by using the SSL Cipher Suite Order Group Policy setting in Administrative Templates\Network\SSL Configuration Settings.
Note
Computers running Windows Vista must be restarted for these settings to take effect.
Note
For current information about supported cipher suites, see Supported Cipher Suites and Protocols in the Schannel SSP.
See also
Changes in functionality by operating system version