Supported Cipher Suites and Protocols in the Schannel SSP

 

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 professional lists the cipher suites and protocols that are supported by the Schannel Security Support Provider (SSP), and it describes the different types of algorithms that are used by the suites.

The following table lists the protocols implemented by the Schannel SSP. For more information about how changes to the following protocols are implemented in the Schannel SSP, see Differences in the Schannel SSP by Operating System Version.

Protocol	Description	Resource
TLS 1.2	IETF RFC 5246 is defined TLS 1.2, and it made the following RFCs obsolete: 3268, 4346, and 4366. The significant improvements over TLS 1.1 included handshake and renegotiation improvements.	IETF RFC 5246
TLS 1.1	The IETF RFC 4346 made the original RFC 2246 obsolete because it defined TLS 1.1. The significant improvements over TLS 1.0 included: The implicit initialization vector was replaced with an explicit initialization vector to protect against cipher-block chaining attacks. Handling of padding errors was changed to use the “bad record message authentication code” alert rather than the “decryption failed” alert to protect against cipher-block chaining attacks. Internet Assigned Numbers Authority (IANA) registries were defined for protocol parameters. The IANA was administered under the U.S Department of Commerce, and it is responsible for the allocation of globally unique names and numbers, which are used in Internet protocols that are published as RFC documents. Premature closures no longer cause a condition where the session cannot be resumed.	IETF RFC 4346
TLS 1.0	SSL 3.0 was standardized through the IETF as RFC 2246, which resulted in the public protocol TLS 1.0. The protocol is composed of two layers: the TLS record protocol and the TLS handshake protocol. The TLS record protocol provides connection security that has two basic properties: The connection is private. Symmetric cryptography is used for data encryption, and the keys for this encryption are generated uniquely for each connection. In addition, the keys are based on a secret negotiated by another protocol (such as the TLS handshake protocol). The record protocol can also be used without encryption. The connection is reliable. Message transport includes a message integrity check that uses a keyed message authentication code (MAC). Secure hash functions are used for MAC computations. The record protocol can operate without a MAC, but it is generally only used in this mode while another protocol is using the record protocol as a transport for negotiating security parameters.	IETF RFC 2246
SSL 3.0	SSL 3.0 was a Netscape Corporation private protocol that has not been upgraded with modern cipher suites. It is dependent on the MD5 hash function for half of the master key. The Schannel SSP will use SSL 3.0, which is useful for backwards compatibility, if all other protocol versions of TLS fail to negotiate.
SSL 2.0	SSL 2.0 was a Netscape Corporation proprietary protocol. It is disabled by default on Windows client computers designated in the Applies To list at the beginning of this topic.
DTLS 1.0	The Datagram Transport Layer Security (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, reducing the need to use IPsec or designing a custom application layer security protocol.	IETF RFC 4347
PCT 1.0	The Private Communications Technology protocol is a technology developed by Microsoft, which was replaced by more robust protocols(SSL 3.0 and TLS). The Schannel SSP will not use PCT 1.0.

A cipher suite is a set of cryptographic algorithms. Schannel protocols use algorithms from a cipher suite to create keys and encrypt information. A cipher suite specifies one algorithm for each of the following tasks:

• Key exchange

• Bulk encryption

• Message authentication

Key exchange algorithms protect the information that is required to create shared keys. These algorithms are asymmetric (public key algorithms), and they perform well for relatively small amounts of data.

Bulk encryption algorithms encrypt messages that are exchanged between client computers and servers. These algorithms are symmetric, and they perform well for large amounts of data.

Message authentication algorithms generate message hashes and signatures that ensure the integrity of a message.

For information about each supported cipher suite in Windows Server 2012 R2 and Windows 8.1, FIPS-compliance enablement, key exchange algorithms, encryption algorithms, and message hashes that are used in SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2, see article 2929781 in the Microsoft Knowledge Base.

For information about each supported cipher suite, FIPS-compliance enablement, key exchange algorithms, encryption algorithms, and message hashes that are used in SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2, see Cipher Suites in Schannel.

For information about each supported cipher suite, FIPS-compliance enablement, key exchange algorithms, encryption algorithms, and message hashes that are used in SSL 2.0, SSL 3.0, and TLS 1.0 in Windows Server 2008 and Windows Vista, see Schannel Cipher Suites in Windows Vista.

Cipher suite and protocol support

The following table shows information about protocol and ciper suite support in the Windows operating systems.

Note

For information about restricting algorithms and protocols in Schannel, see How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll.

Operating system version	Protocol support	Cipher suite support	Notes
Windows Server 2012 R2 and Windows 8.1	TLS 1.2 TLS 1.1 TLS 1.0 SSL 3.0 SSL 2.0 DTLS 1.0	AES 128 AES 256 RC4 128/128 RC4 56/128 RC4 40/128 Triple DES 168 DES 56	For more information, see Differences in the Schannel SSP by Operating System Version.
Windows Server 2012 and Windows 8	TLS 1.2 TLS 1.1 TLS 1.0 SSL 3.0 SSL 2.0 DTLS 1.0	AES 128 AES 256 RC4 128/128 RC4 56/128 RC4 40/128 Triple DES 168 DES 56	As defined in RFC 5246, Server Name Indication (SNI) is a feature that extends the SSL and TLS protocol. It permits the client to request the domain name before the certificate is committed to the server. This is essential for using TLS in virtual hosting mode. SNI addresses this issue by sending the name of the virtual domain as part of the TLS negotiation. This enables the server to switch to the correct virtual domain early and present the browser with the certificate that contains the correct common name. RFC 4366 describes this and other TLS extensions. For more information, see Differences in the Schannel SSP by Operating System Version.
Windows Server 2008 R2 and Windows 7	TLS 1.1 TLS 1.0 SSL 3.0 SSL 2.0	AES 128 AES 256 RC4 128/128 RC4 56/128 RC4 40/128 Triple DES 168 DES 56	PCT disabled For more information, see Differences in the Schannel SSP by Operating System Version.
Windows Server 2008 and Windows Vista	TLS 1.0 SSL 3.0 SSL 2.0 PCT 1.0	AES 128 AES 256 RC4 128/128 RC4 56/128 RC4 40/128 Triple DES 168 DES 56

See also

Schannel Security Support Provider Technical Reference