Transport Layer Security (TLS) connections might fail or timeout when connecting or attempting a resumption

Symptoms

When attempting to connect, Transport Layer Security (TLS) might fail or timeout. You might also receive one or more of the with the following errors:

«The request was aborted: Could not create SSL/TLS secure Channel»

An error logged in the System Event Log for SCHANNEL event 36887 with alert code 20 and the description, «A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 20.​»

Cause

Due to security related enforcement for CVE-2019-1318, all updates for supported versions of Windows released on October 8, 2019 or later enforce Extended Master Secret (EMS) for resumption as defined by RFC 7627. Connections to third-party devices and OSes that are non-compliant might have issues or fail.

Next Steps

Connections between two devices running any supported version of Windows should not have this issue when fully updated. There is no update for Windows needed for this issue. These changes are required to address a security issue and security compliance.

Any third-party operating system, device or service that does not support EMS resumption might exhibit issues related to TLS connections. You should contact your administrator, manufacturer or service provider for updates that fully support EMS resumption as defined by RFC 7627.

Note Microsoft does not recommend disabling EMS. If EMS was previously explicitly disabled, it can be re-enabled by setting following registry key values:

On TLS Server: DisableServerExtendedMasterSecret: 0
On TLS Client: DisableClientExtendedMasterSecret: 0

Advanced information for administrators

1. A Windows device attempting a Transport Layer Security (TLS) connection to a device that does not support Extended Master Secret (EMS) when TLS_DHE_* cipher suites are negotiated might intermittently fail approximately 1 out of 256 attempts. To mitigate this issue, implement one of the following solutions listed in order of preference:

Enable support for Extend Master Secret (EMS) extensions when performing TLS connections on both the client and the server operating system.

For operating systems that do not support EMS, remove the TLS_DHE_* cipher suites from the cipher suite list in the OS of the TLS client device. For instructions on how to do this on Windows, see Prioritizing Schannel Cipher Suites.

2. Operating systems that only send certificate request messages in a full handshake following resumption are not RFC 2246 (TLS 1.0) or RFC 5246 (TLS 1.2) compliant and will cause each connection to fail. Resumption is not guaranteed by the RFCs but may be used at the discretion of the TLS client and server. If you encounter this issue, you will need to contact the manufacturer or service provider for updates that comply with RFC standards.

3. FTP servers or clients that are not compliant with RFC 2246 (TLS 1.0) and RFC 5246 (TLS 1.2) might fail to transfer files on resumption or abbreviated handshake and will cause each connection to fail. If you encounter this issue, you will need to contact the manufacturer or service provider for updates that comply with RFC standards.

Affected Updates

Any latest cumulative update (LCU) or Monthly Rollups released on October 8, 2019 or later for the affected platforms may experience this issue:

KB4517389 LCU for Windows 10, version 1903.

KB4519338 LCU for Windows 10, version 1809 and Windows Server 2019.

KB4520008 LCU for Windows 10, version 1803.

KB4520004 LCU for Windows 10, version 1709.

KB4520010 LCU for Windows 10, version 1703.

KB4519998 LCU for Windows 10, version 1607 and Windows Server 2016.

KB4520011 LCU for Windows 10, version 1507.

KB4520005 Monthly Rollup for Windows 8.1 and Windows Server 2012 R2.

KB4520007 Monthly Rollup for Windows Server 2012.

KB4519976 Monthly Rollup for Windows 7 SP1 and Windows Server 2008 R2 SP1.

KB4520002 Monthly Rollup for Windows Server 2008 SP2

The following Security Only released on October 8, 2019 for the affected platforms may experience this issue:

KB4519990 Security-only update for Windows 8.1 and Windows Server 2012 R2.

KB4519985 Security-only update for Windows Server 2012 and Windows Embedded 8 Standard.

KB4520003 Security-only update for Windows 7 SP1 and Windows Server 2008 R2 SP1

KB4520009 Security-only update for Windows Server 2008 SP2

TLS (Schannel SSP) changes in Windows 10 and Windows Server 2016

Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016 and Windows 10

Cipher Suite Changes

Windows 10, version 1511 and Windows Server 2016 add support for configuration of cipher suite order using Mobile Device Management (MDM).

For cipher suite priority order changes, see Cipher Suites in Schannel.

Added support for the following cipher suites:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (RFC 5289) in Windows 10, version 1507 and Windows Server 2016
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) in Windows 10, version 1507 and Windows Server 2016

DisabledByDefault change for the following cipher suites:

• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (RFC 5246) in Windows 10, version 1703
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (RFC 5246) in Windows 10, version 1703
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA (RFC 5246) in Windows 10, version 1703
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA (RFC 5246) in Windows 10, version 1703
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (RFC 5246) in Windows 10, version 1703
• TLS_RSA_WITH_RC4_128_SHA in Windows 10, version 1709
• TLS_RSA_WITH_RC4_128_MD5 in Windows 10, version 1709

Starting with Windows 10, version 1507 and Windows Server 2016, SHA 512 certificates are supported by default.

RSA key changes

Windows 10, version 1507 and Windows Server 2016 add registry configuration options for client RSA key sizes.

Diffie-Hellman key changes

Windows 10, version 1507 and Windows Server 2016 add registry configuration options for Diffie-Hellman key sizes.

SCH_USE_STRONG_CRYPTO option changes

With Windows 10, version 1507 and Windows Server 2016, SCH_USE_STRONG_CRYPTO option now disables NULL, MD5, DES, and export ciphers.

Elliptical Curve changes

Windows 10, version 1507 and Windows Server 2016 add Group Policy configuration for elliptical curves under Computer Configuration > Administrative Templates > Network > SSL Configuration Settings. The ECC Curve Order list specifies the order in which elliptical curves are preferred as well as enables supported curves which are not enabled.

Added support for the following elliptical curves:

• BrainpoolP256r1 (RFC 7027) in Windows 10, version 1507 and Windows Server 2016
• BrainpoolP384r1 (RFC 7027) in Windows 10, version 1507 and Windows Server 2016
• BrainpoolP512r1 (RFC 7027) in Windows 10, version 1507 and Windows Server 2016
• Curve25519 (RFC draft-ietf-tls-curve25519) in Windows 10, version 1607 and Windows Server 2016

Dispatch level support for SealMessage & UnsealMessage

Windows 10, version 1507 and Windows Server 2016 add support for SealMessage/UnsealMessage at dispatch level.

DTLS 1.2

Windows 10, version 1607 and Windows Server 2016 add support for DTLS 1.2 (RFC 6347).

HTTP.SYS thread pool

Windows 10, version 1607 and Windows Server 2016 add registry configuration of the size of the thread pool used to handle TLS handshakes for HTTP.SYS.

To specify a maximum thread pool size per CPU core, create a MaxAsyncWorkerThreadsPerCpu entry. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to the desired size. If not configured, then the maximum is 2 threads per CPU core.

Next Protocol Negotiation (NPN) support

Beginning with Windows 10 version 1703, Next Protocol Negotiation (NPN) has been removed and is no longer supported.

Pre-Shared Key (PSK)

Windows 10, version 1607 and Windows Server 2016 add support for PSK key exchange algorithm (RFC 4279).

Added support for the following PSK cipher suites:

• TLS_PSK_WITH_AES_128_CBC_SHA256 (RFC 5487) in Windows 10, version 1607 and Windows Server 2016
• TLS_PSK_WITH_AES_256_CBC_SHA384(RFC 5487) in Windows 10, version 1607 and Windows Server 2016
• TLS_PSK_WITH_NULL_SHA256 (RFC 5487) in Windows 10, version 1607 and Windows Server 2016
• TLS_PSK_WITH_NULL_SHA384 (RFC 5487) in Windows 10, version 1607 and Windows Server 2016
• TLS_PSK_WITH_AES_128_GCM_SHA256 (RFC 5487) in Windows 10, version 1607 and Windows Server 2016
• TLS_PSK_WITH_AES_256_GCM_SHA384 (RFC 5487) in Windows 10, version 1607 and Windows Server 2016

Session Resumption without Server-Side State server-side performance improvements

Windows 10, version 1507 and Windows Server 2016 provide 30% more session resumptions per second with session tickets compared to Windows Server 2012.

Session Hash and Extended Master Secret Extension

Windows 10, version 1507 and Windows Server 2016 add support for RFC 7627: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension.

Due to this change, Windows 10 and Windows Server 2016 requires 3rd party CNG SSL provider updates to support NCRYPT_SSL_INTERFACE_VERSION_3, and to describe this new interface.

SSL support

Beginning with Windows 10, version 1607 and Windows Server 2016, the TLS client and server SSL 3.0 is disabled by default. This means that unless the application or service specifically requests SSL 3.0 via the SSPI, the client will never offer or accept SSL 3.0 and the server will never select SSL 3.0.

Beginning with Windows 10 version 1607 and Windows Server 2016, SSL 2.0 has been removed and is no longer supported.

Changes to Windows TLS adherence to TLS 1.2 requirements for connections with non-compliant TLS clients

In TLS 1.2, the client uses the «signature_algorithms» extension to indicate to the server which signature/hash algorithm pairs may be used in digital signatures (i.e., server certificates and server key exchange). The TLS 1.2 RFC also requires that the server Certificate message honor «signature_algorithms» extension:

«If the client provided a «signature_algorithms» extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension.»

In practice, some third-party TLS clients do not comply with the TLS 1.2 RFC and fail to include all the signature and hash algorithm pairs they are willing to accept in the «signature_algorithms» extension, or omit the extension altogether (the latter indicates to the server that the client only supports SHA1 with RSA, DSA or ECDSA).

A TLS server often only has one certificate configured per endpoint, which means the server can’t always supply a certificate that meets the client’s requirements.

Prior to Windows 10 and Windows Server 2016, the Windows TLS stack strictly adhered to the TLS 1.2 RFC requirements, resulting in connection failures with RFC non-compliant TLS clients and interoperability issues. In Windows 10 and Windows Server 2016, the constraints are relaxed and the server can send a certificate that does not comply with TLS 1.2 RFC, if that’s the server’s only option. The client may then continue or terminate the handshake.

When validating server and client certificates, the Windows TLS stack strictly complies with the TLS 1.2 RFC and only allows the negotiated signature and hash algorithms in the server and client certificates.

Подключения TLS могут завершаться сбоем или тайм-аутом при соединении или попытке возобновления

Проблемы

При попытке соединения может происходить сбой или тайм-аут TLS. Вы также можете получить одну или несколько из указанных ниже ошибок.

«Запрос прерван: не удалось создать безопасный канал SSL/TLS»

Ошибка, зарегистрированная в журнале системных событий для события SCHANNEL 36887 с кодом предупреждения 20 и описанием, «С удаленной конечной точки получено оповещение о неустранимой ошибке. Определенный в протоколе TLS код оповещения о неустранимой ошибке: 20».​

Причина

В связи с принудительным применением CVE-2019-1318 из соображений безопасности все обновления для поддерживаемых версий Windows, выпущенные 8 октября 2019 г. или позже, применяют Extended Master Secret (EMS) для возобновления, как определено в RFC 7627. При подключении к сторонним устройствам и ОС, которые не соответствуют требованиям, могут возникать проблемы и сбои.

Дальнейшие действия

После полного обновления соединения между двумя устройствами под управлением любой поддерживаемой версии Windows не должны иметь этой ошибки. Для этой ошибки обновление Windows не требуется. Эти изменения необходимы для устранения неполадок безопасности и соответствия требованиям безопасности.

Все сторонние операционные системы, устройства и службы, которые не поддерживают возобновление EMS, могут проявлять проблемы, связанные с подключениями TLS. Обратитесь к администратору, изготовителю или поставщику услуг за обновлениями, которые полностью поддерживают возобновление EMS, как определено в RFC 7627.

Примечание. Корпорация Майкрософт не рекомендует отключать EMS. Если служба EMS была явным образом отключена ранее, ее можно снова включить, задав следующие значения в разделе реестра:

На сервере TLS — DisableServerExtendedMasterSecret: 0
На клиенте TLS — DisableClientExtendedMasterSecret: 0

Дополнительные сведения для администраторов

1. На устройстве с Windows, которое пытается установить TLS-подключение к устройству, которое не поддерживает Extended Master Secret (EMS), при согласовании комплектов шифров TLS_DHE_* может иногда возникать сбой, приблизительно в 1 попытке из 256. Чтобы устранить эту ошибку, реализуйте одно из следующих решений, указанных в порядке предпочтения.

Включите поддержку расширений Extend Master Secret (EMS) при выполнении TLS-подключений как в клиентской, так и в серверной операционной системе.

Для операционных систем, которые не поддерживают EMS, удалите комплекты шифров TLS_DHE_* из списка комплектов шифров в ОС клиентского устройства TLS. Инструкции о том, как это сделать в Windows, см в разделе Определение приоритета для комплектов шифров Schannel.

2. Операционные системы, которые отправляют сообщения запроса сертификата только в режиме полного подтверждения после возобновления, не соответствуют стандарту RFC 2246 (TLS 1.0) или RFC 5246 (TLS 1.2) и приводят к сбою каждого подключения. Возобновление не гарантируется в соответствии со спецификацией RFC, но оно может быть использовано по усмотрению клиента и сервера TLS. При возникновении этой проблемы необходимо обратиться к производителю или поставщику услуг за обновлениями, которые соответствуют стандартам RFC.

3. FTP-серверы или клиенты, не совместимые с RFC 2246 (TLS 1.0) и RFC 5246 (TLS 1.2), могут не передавать файлы при возобновлении или сокращенном подтверждении, и это приведет к сбою каждого подключения. При возникновении этой проблемы необходимо обратиться к производителю или поставщику услуг за обновлениями, которые соответствуют стандартам RFC.

Затронутые обновления

Эта проблема может возникать для любого последнего накопительного обновления (LCU) или ежемесячных накопительных пакетов, выпущенных 8 октября 2019 года или позже, для затронутых платформ:

KB4517389 LCU для Windows 10, версия 1903.

KB4519338 LCU для Windows 10 версии 1809 и Windows Server 2019.

KB4520008 LCU для Windows 10, версия 1803.

KB4520004 LCU для Windows 10, версия 1709.

KB4520010 LCU для Windows 10, версия 1703.

KB4519998 LCU для Windows 10 версии 1607 и Windows Server 2016.

KB4520011 LCU для Windows 10, версия 1507.

KB4520005 Ежемесячный накопительный пакет для Windows 8.1 и Windows Server 2012 R2.

KB4520007 Ежемесячный накопительный пакет обновления для Windows Server 2012.

KB4519976 Ежемесячный накопительный пакет для Windows 7 SP1 и Windows Server 2008 R2 SP1.

KB4520002 Ежемесячный накопительный пакет обновления для Windows Server 2008 SP2

Эта проблема может возникать для следующих обновлений системы безопасности, выпущенных 8 октября 2019 года, для затронутых платформ:

KB4519990 Обновление для системы безопасности для Windows 8.1 и Windows Server 2012 R2.

KB4519985 Обновление для системы безопасности для Windows Server 2012 и Windows Embedded 8 Standard.

KB4520003 Обновление для системы безопасности для Windows 7 SP1 и Windows Server 2008 R2 SP1

KB4520009 Обновление для системы безопасности Windows Server 2008 SP2