Ondrej Sevecek's English Pages

I was writing about certificates, cryptography and SHA2 in a previous article, and TLS tightly relates with its own specific SHA2 support. So go ahead.

TLS and SSL versions support in operating system

In Windows, TLS protocol functionality is provided by SCHANNEL security package (just a DLL). This component supports (if enabled) SSL 2.0, SSL 3.0, TLS 1.0 and since Windows 7 and Windows 2008 R2 also TLS 1.1 and TLS 1.2.

Any Windows component and all Microsoft applications use the SCHANNEL library to implement their TLS. These include RDP, IIS and IE HTTPS, Outlook S/MIME, LDAPS, SMTPS, SSTP, IPHTTPS (DirectAccess), EAP-TLS including PEAP etc.

Other software, such as third party browsers may or do not use Schannel. For example, Chrome can be reconfigured to use the built-in Windows cryptography, while Java cannot (according to my limited knowledge).

Support for each TLS/SSL version in Schannel can be exlicitly disabled or enabled in registry. If you want to disable SSL 2.0 and SSL 3.0 explicitly and also enable TLS 1.1 and TLS 1.2, you can apply the following registry keys (refer to its precise documentation for details):

HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Client
	Enabled = DWORD = 0
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server
	Enabled = DWORD = 0
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client
	Enabled = DWORD = 0
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server
	Enabled = DWORD = 0
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client
	Enabled = DWORD = 0
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server
	Enabled = DWORD = 0
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
	Enabled = DWORD = 1
	DisabledByDefault = DWORD = 0
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server
	Enabled = DWORD = 1
	DisabledByDefault = DWORD = 0
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
	Enabled = DWORD = 1
	DisabledByDefault = DWORD = 0
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
	Enabled = DWORD = 1
	DisabledByDefault = DWORD = 0

So the Schannel support is crutial. Yet, applications must support the protocol version as well on their part - they just need to be able to tell Schannel to use it if the protocol version is enabled in Schannel at all.

For example, Internet Explorer has its own separate setting for this while TLS 1.1 is enabled by default only since IE 10 (I think).

As another example Internet Explore 8 and IE 9 enabled only SSL 3.0 and TLS 1.0 by default while it was already able to enable TLS 1.1 and TLS 1.2 on Windows 7 and Windows 2008 R2 in the Internet Options dialog box. On older systems, such as Internet Explorer 8 running on Windows XP, the options for TLS 1.1 and TLS 1.2 were not available at all, because the Schannel library didn't have a support for that.

Some technologies, such as SSTP or AD LDAPS and SMTPS do not need to be configured. They support the newer TLS protocol versions as soon as their are available in the operating system's Schannel. The same applies to IIS web server (actually its HTTP.SYS driver component). Here, the Schannel's own settings apply automatically.

Note that there is a speciality as an accepted bug in Microsoft Exchagne 2010 which does not support TLS 1.1 and TLS 1.2 at all for its SMTP connections on Windows 2008 R2, regardless of Schannel capabilities.

Some applications also do not support it, until later.

Later and customized support for TLS 1.1 and TLS 1.2 in some applications

For example, both RDP server and RDP client support TLS 1.1 and TLS 1.1 only since Windows 8 and Windows 2012. Although you can enable TLS 1.1 and TLS 1.2 in Schannel system wide in Windows 7, the RDP client will not use until Windows 8.

The same applies to a RDP server side. Even if you connect to Windows 2008 R2 from a client running Windows 8.1 with TLS 1.1 and TLS 1.2 enabled on both the client and server sides, the connection falls back to TLS 1.0, because the Windows 2008 R2 RDP server does not support anything newer.

Worse with EAP and PEAP client which authenticates remote VPN and wired and wireless 802.1x connections with RADIUS server (NPS or IAS server). While the NPS server supports TLS 1.1 and TLS 1.2 according to its Schannel settings, the EAP client does not.

EAP client support for TLS 1.1 and TLS 1.2 was added only recently - see an official support article. You also have to enable the protocols in separate registry key of the EAP client itself in addition to what is enabled on the Schannel part.

HKLM\SYSTEM\CurrentControlSet\services\RasMan\PPP\EAP\13
    TlsVersion = DWORD = 0xFC0

Not that it would be too a serious security problem to have only TLS 1.0 EAP support by default because you usually pass this inside a (hopefully not using PPTP) secure VPN connection. But yes, for wired and even more for wireless 802.1x connections it may have some more importance.

Ralation of the EAP TLS update to CNG and CSP certificate operations

TLS is implemented in Schannel and I do not know about any supportability relations to CNG or CSP cryptography providers. Although any update may enable any TLS or TLS algorithm suite support for any system, it does not affect application support for CNG or CSP certificates.

So although the EAP client on Windows 7 might have been updated to TLS 1.1 and TLS 1.2, it still does not support authentication by client TLS certificates whose private keys are stored in CNG.

TLS support is one thing. TLS is performed by Schannel. Certificate validation and authentication is completelly separate one which is performed by CSP or CNG and depends on application support for these crypto providers.

Support for SHA2 hash algorithms in TLS and cryptography suites

Not only TLS versions matter. TLS protocol always negotiates the best cryptographich protocol suite between client and server. First of all, client proposes list of its own supported algorithm suites to the server. This goes over wire in TLS Client Hello packet.

From this offer the server selects what it supports and what is best (most secure) from its own perspective. Server then returns only a single selected crypto suite to the client as part of its reply TLS Server Hello packet.

Again, this is property of Schannel which can affect the various suites that a computer supports.

TLS protocol suites supported by default Windows XP and Windows 2003 are in the following table:

Although AES cryptography providers are available with Windows XP, yet as you see from the previous table, Microsoft only later added AES support to Schannel and only to Windows 2003. The update requires to be manually download and is not offered automatically over Windows Update or Microsoft Update. You can add it to WSUS manually though.

You can also note, that Windows XP nor Windows 2003 offer SHA2 (any of the SHA-256, SHA-384 or SHA-512) suites at all, even if you updated the systems with the SHA2 updates.

Windows Vista and Windows 2008 do not support TLS 1.1 nor TLS 1.2. For TLS 1.0 in such systems, they offer the following algorithm suites by default. Even all newer systems, such as Windows 2012 R2 or Windows 8.1 use the same suites:

From the previous table, it should be clear, that not even newer systems, such as Windows 2012 and Windows 8.1 support SHA-256, SHA-384 or SHA-512 (SHA2 family) with TLS 1.0 at all, while thay at least upgraded to AES finally.

Although there are no SHA2 suites, mind the ECDH suites. You can have PFS (perfect forward secrecy) with ECDH even since Windows 2008 with TLS 1.0. Although they are not preferred, you can always change it through registry or the SSL Configuration Settings node in Administrative Templates of a Group Policy Object (GPO).

Recently, in November 2014 critical security issue and its associated update KB299611 which applied to Schannel remote code execution vulnerability, Microsoft tried to add some new SHA2 suites to TLS 1.0 in Windows 2008 R2 and Windows 7 and newer. Because it resulted in various reported incompatibilities, it is not enabled by default. You could enable these manually if really required though:

The previous might have brought SHA2 support in TLS 1.0 even for Windows 7 and Windows 2008 R2, but it is not really recommanded to enable the support, as many people have had issues with that.

Side note about TLS certificates

We talk here about the TLS suites. It says nothing about the serer or client certificates used to authenticated the TLS connection. Support for the certificate validation has been discussed in my previous article. Even Windows XP and Windows 2003 can validate SHA2 certificates if all necessary updates have been applied to them.

Back to the TLS 1.1 and TLS 1.2 and their cryptography cipher suites

These protocols are available since Windows 7 and Windows 2008 R2 only. They offer the following algorithm cipher suites by default:

TLS 1.2 on Windows 2012 and Windows 8.1 if updated with KB2929781

With the most current systems and the most current TLS 1.2, Microsoft is probably looking more sensitively at them. In April 2014 update cycle, they updated Windows 8.1 and Windows 2012 R2 to the following TLS 1.2 cipher suites and their order:

You can see that with TLS 1.2 you may be safe as heaven :-)

Wrapping the parcel up

If you want SHA2 suites, you do not only need to have Windows 7 and Windows 2008 R2, you also need to enable TLS 1.1 and/or TLS 1.2 and you may also have to enable the TLS 1.1 and TLS 1.2 support in registry, in a particular application or update your systems.

Definitelly, if you want to be sure, you must verify everything with Network Monitor or Message Analyzer after implementation.