Настраиваем DNS over HTTPS (DoH) в Windows 10

Поддержка протокола DNS over HTTPS (DoH) появилась в последнем билде Windows 10 2004 (May 2020 Update). Начиная с этой версии, Windows 10 может выполнять разрешение имен через HTTPS с помощью встроенного клиента DoH. В этой статье мы расскажем для чего нужен протокол DNS over HTTPS, как его включить и использовать в Windows 10.

Когда ваш компьютер обращается к серверу DNS для разрешения имен, этот обмен данными происходит в открытом виде. Злоумышленник может подслушать ваш трафик, определить какие ресурсы вы посещали, или манипулировать DNS трафиком по типу main-in-the-middle. Протокол DNS over HTTPS предполагает усиление защиты приватности данных пользователей за счет шифрования всех DNS запросов. Протокол DoH инкапсулирует запросы DNS в HTTPS трафик и отправляет из DNS серверу (нужен специальный DNS сервер с поддержкой DoH).

В Windows 10 2004 пока нет параметра групповой политики или опции в графическом интерфейсе для включения DNS-over-HTTPS. Пока можно включить DoH только через реестр:

1. Запустите regedit.exe ;
2. Перейдите в ветку реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameter;
3. Создайте DWORD параметр с именем EnableAutoDoh и значением 2;

Затем нужно изменить настройки DNS вашего сетевого подключения. Нужно указать DNS сервера с поддержкой DNS over HTTPS. Пока далеко не все DNS сервера поддерживают DoH. В таблице ниже перечислен список общедоступных DNS с поддержкой DNS over HTTPS.

Провайдер	IP адреса DNS серверов с поддержкой DNS over HTTPS
Cloudflare	1.1.1.1, 1.0.0.1
Google	8.8.8.8, 8.8.4.4
Quad9	9.9.9.9, 149.112.112.112

Откройте панель настройки сети — Control Panel -> Network and Internet -> Network and Sharing Center (или ncpa.cpl ). Затем в свойствах сетевого адаптера измените текущие адреса DNS серверов на адреса DNS серверов с поддержкой DoH.

$PhysAdapter = Get-NetAdapter -Physical
$PhysAdapter | Get-DnsClientServerAddress -AddressFamily IPv4 | Set-DnsClientServerAddress -ServerAddresses ‘8.8.8.8’, ‘1.1.1.1’

Теперь клиент DNS начинает использовать для разрешения имен протокол HTTPS по порту 443 вместо обычного 53 порта.

С помощью утилиты захвата сетевого трафика PktMon.exe (о которой мы говорили ранее) вы можете проверить, что с компьютера теперь не отправляются DNS запросы по порту 53.

Удалите все текущие фильтры Packet Monitor:

pktmon filter remove

Создайте новый фильтр для классического DNS порт 53:

pktmon filter add -p 53

Запустите мониторинг трафика в реальном времени (трафик выводится в консоль):

pktmon start —etw -p 0 -l real-time

Если вы правильно настроили DNS over HTTPS, то трафик по порту 53 должен отсутствовать (на скриншоте ниже показан вывод в консоль при отключённом DoH и при включенном).

DNS over HTTPS за последний год реализован во всех популярных браузерах (Google Chrome, Mozilla Firefox, Microsoft Edge, Opera). В каждом из этих браузеров вы можете включить поддержку DoH. Таком образом все DNS запросы от браузера будут шифроваться (DNS трафик других приложений по прежнему будет идти в открытом текстовом виде).

Больше все проблем технологии DNS over HTTPS и DNS over TLS создадут администраторам корпоративных сетей, которым станет сложнее блокировать доступн к внешним ресурсам из внутренних сетей. Также не понятно, что парирует делать Роскомнадзор, чья методика глубокой проверки и управления сетевым трафиком Deep Packet Inspection (DPI) перестанет работать при переходе протокола DNS на рельсы шифрованного https.

Настройка протоколов TLS на Windows Server

Написать эту статью подоткнул тот факт, что Windows Server 2016, установленный из коробки, почему-то не имеел TLS протокол, включенный как основный по умолчанию, в то время как SSL3.0 был включен. Приводит это к разным последствиям, как для безопасности, так и для функционирования различных сервисов и приложений.

Проблемы версий протоколов SSL и TLS и совместимости приложений

Для начала рассмотрим проблемы связанные с версиями SSL протоколов:

• SSL v2 небезопасен, устарел и не рекомендуется для использования. См. атаку DROWN по этому протоколу.
• SSL v3 небезопасен и устаревший инструмент. См. атаку POODLE.
• TLS v1.0 также является устаревшим протоколом, но на практике он все же оказывается необходим. Его основная слабость (BEAST) была смягчена в современных браузерах.
• TLS v1.1 и TLS v1.2 оба не имеют известных проблем с безопасностью, но только v1.2 предоставляет современные криптографические алгоритмы.

SSL 2.0, SSL 3.0 и TLS 1.0 настоятельно рекомендуется отключить, так как большинство стандартов безопасности их уже давно не поддерживают (например, PCI DSS 3.1). Рекомендуемые протоколы TLS v1.1 и TLS v1.2 с актуальными алгоритмами шифрование и снятия хэшей.

Но и это оказывается не полной правдой. Дело в том, что использование протоколов зависит не только от системных настроек, но и от того, как написаны приложения. Например, я выяснил, что .NET приложения используют свои собственные настройки безопасности. Также известно, что если включить поддержку TLS 1.2 на SQL Server (например, применив патч https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server), установленный на Windows Server 2012, то приложения .NET и JAVA потеряют возможность подключаться к SQL.

Также давно известна проблема с вэб приложениями, написанными на базе интерфейса WinHTTP API. После включения TLS 1.1/1.2 они также перестают подключаться.

Службы IIS и ADFS при этом прекрасно используют новые протоколы, следуя системным настройкам. Более того, к сервисам Azure вы не сможете подключиться через TLS 1.2, но при этом, как выяснилось, Powershell даже в Windows Server 2016 использует SSL3.0 и TLS 1.0, несмотря на то, что согласно системной настройке они отключены.

Как правильно настроить TLS для разного типа приложений?

Начнем с того, что для всего есть свои реестровые ключи, однако нужно точно понимать, какой тип приложения вы хотите настроить, чтобы избежать проблем. Начну с того, что полный список доступных системных ключей в Windows 10/Windows Server 2016/2019 доступен по ссылке https://docs.microsoft.com/ru-ru/windows-server/security/tls/tls-registry-settings. Изменяя их, вы можете настроить IIS, ADFS и прочие службы. Однако, эти ключи не влияют на работу приложений .NET (и в частности, Powershell) и WinHTTP!

В чем же дело? Дело в библиотеках. IIS и ADFS используют Schannel — поставщик поддержки безопасности (SSP), реализующий стандартные протоколы проверки подлинности SSL, TLS и DTLS Internet. Интерфейс поставщика поддержки безопасности (SSPI) является интерфейсом API, используемым системами Windows для выполнения функций, связанных с безопасностью, включая проверку подлинности. В Windows все функции SSPI выполняет библиотека Schannel.dll, в которой реализованы все протоколы и наборы шифрования.

Итак, ветки реестра, которые нас интересуют:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols — включение и отключение протоколов для Schannel.dll, как клиентских, так и серверных. Для каждого протокола — своя ветка;
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers — здесь можно изменить список и порядок просмотра (это важно!) наборов шифрования;
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp — в параметре DefaultSecureProtocols настраиваются протоколы для приложений на WinHttp API;
• HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Cryptography\ECCParameters — настройка эллиптических кривых для криптографии;
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5 — отключение MD5 шифрования для маркеров безопасности.

Теперь пройдем по конкретным примерам и настройкам.

Отключение SSL и TLS 1.0 протоколов на системном в Schannel подробно описано в документации Microsoft. Отключить небезопасные можно как через реестр, так и с помощью Powershell.

В этой же статье ниже описано, как отключить небезопасные алгоритмы шифрования, такие как RC4.

Отключить небезопасные наборы шифрования (cipher suites) можно через параметр Functions в ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002 .

Этот параметр является многострочным текстовым значением, который просто содержит построчный список наборов (один на строку). Удалите ненужные строки.

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

Ну и наконец, для управления доступными наборами появились командлеты Powershell. Например, с помощью Disable-TlsCipherSuite вы можете отключить неугодный набор.

Отключение SSL для Powershell и других .NET приложений

Как я уже писал, системные настройки выше не влияют на Powershell сессии. Проверить, какие протоколы сейчас активны в вашей Powershell сессии, можно выполнив команду

Если в выводе команды увидите ssl30, tls, то их надо отключить.

Для этого в Windows Srver 2012 / Windows 2016 используйте ключ реестра

С помощью самого Powershell это можно изменить одной командой:

New-ItemProperty -path ‘HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319’ -name ‘SchUseStrongCrypto’ -value ‘1’ -PropertyType ‘DWord’ -Force | Out-Null

Включение TLS 1.2 для WinHTTP

Если коротко, то в ключе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp нужно добавить параметр DefaultSecureProtocols, который в 16-ричном виде будет содержать сумму значений всех протоколов, которые необходимо включить. Например, для включения TLS 1.1 и 1.2 надо добавить значение 0x00000A00, которое будет суммой значений TLS 1.1 (0×00000200) и TLS 1.2 (0×00000800).

Готовый патч от Microsoft для исправления этого также можно скачать по ссылке KB3140245

Настройка с помощью IISCrypto

IISCrypto — это бесплатная утилита, не требующая установки, которая позволяет включить/выключить многие настройки Schannel через графический интерфейс, .NET и WinHTTP она не настраивает.

Скачать её можно с сайта разработчика без регистрации.

TLS/SSL Settings

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 contains registry setting, Group Policy, and network port information for the Windows implementation of the Transport Layer Security (TLS) protocol and the Secure Sockets Layer (SSL) protocol through the Schannel Security Support Provider (SSP).

This topic is divided into the following sections:

Schannel SSP registry entries

The following registry subkeys and entries can help you administer and troubleshoot the Schannel SSP, specifically the TLS and SSL protocols.

This information is provided as a reference to use when you are troubleshooting or verifying that the required settings are applied. We recommend that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the Registry Editor or by the Windows operating system before they are applied. As a result, incorrect values can be stored, and this can result in unrecoverable errors in the system. When possible, instead of editing the registry directly, use Group Policy or other Windows tools such as the Microsoft Management Console (MMC) to accomplish tasks. If you must edit the registry, use extreme caution.

CertificateMappingMethods

This entry does not exist in the registry by default. The default value is that all four certificate mapping methods, listed below, are supported.

When a server application requires client authentication, Schannel automatically attempts to map the certificate that is supplied by the client computer to a user account. You can authenticate users who sign in with a client certificate by 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 client certificate, your server application automatically associates that user with the appropriate Windows user account.

In most cases, a certificate is mapped to a user account in one of two ways:

A single certificate is mapped to a single user account (one-to-one mapping).

Multiple certificates are mapped to one user account (many-to-one mapping).

By default, the Schannel provider will use the following four certificate mapping methods, listed in order of preference:

Kerberos service-for-user (S4U) certificate mapping

User principal name mapping

One-to-one mapping (also known as subject/issuer mapping)

Applicable versions: As designated in the Applies To list that is at the beginning of this topic

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Ciphers

This entry does not exist in the registry by default. For information about ciphers that are used by the Schannel SSP, see Supported Cipher Suites and Protocols in the Schannel SSP.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

To disable a cipher, create an Enabled entry in the appropriate subkey. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. When you disable any algorithm, you disallow all cipher suites that use that algorithm. To enable the cipher, change the DWORD value to 1.

CipherSuites

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\CipherSuites

To disable a cipher suite, create an Enabled entry in the appropriate subkey. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. When you disable any algorithm, you disallow all cipher suites that use that algorithm. To enable the cipher suite, change the DWORD value to 1.

For information about cipher suites that are used by the Schannel SSP, see Supported Cipher Suites and Protocols in the Schannel SSP.

ClientCacheTime

This entry controls the amount of time that the operating system takes in milliseconds to expire client-side cache entries. A value of 0 turns off secure-connection caching. This entry does not exist in the registry by default.

The first time a client connects to a server through the Schannel SSP, a full TLS/SSL handshake is performed. When this is complete, the master secret, cipher suite, and certificates are stored in the session cache on the respective client and server.

Applicable versions: See the following default client cache time table.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Default client cache time

Windows Version	Time
Windows Server 2012 R2 and Windows 8.1	10 hours
Windows Server 2012 and Windows 8	10 hours
Windows Server 2008 R2 and Windows 7	10 hours
Windows Server 2008 and Windows Vista	10 hours

FIPSAlgorithmPolicy

This entry controls Federal Information Processing (FIPS) compliance. The default is 0.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\LSA

Hashes

This subkey controls use of hash algorithms.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

To disable a hash algorithm, create an Enabled entry in the appropriate subkey. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. When you disable any algorithm, you disallow all cipher suites that use that algorithm. To enable the hash algorithm, change the DWORD value to 1.

Hashes subkey table

Subkey	Description	Default
MD5	Controls the use of MD5 as the hashing algorithm.	Enabled
SHA	Controls the use of SHA1, SHA256, and SHA384 as the hashing algorithm.	Enabled

SHA256 and SHA384 were introduced in Windows Server 2008 R2.

For a list of supported cipher suites and hash algorithms, see Supported Cipher Suites and Protocols in the Schannel SSP.

IssuerCacheSize

This entry controls the size of the issuer cache, and it is used with issuer mapping. The Schannel SSP attempts to map all of the issuers in the client’s certificate chain—not only the direct issuer of the client certificate. When the issuers do not map to an account, which is the typical case, the server might attempt to map the same issuer name repeatedly, hundreds of times per second.

To prevent this, the server has a negative cache, so if an issuer name does not map to an account, it is added to the cache and the Schannel SSP will not attempt to map the issuer name again until the cache entry expires. This registry entry specifies the cache size. This entry does not exist in the registry by default. The default value is 100.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

IssuerCacheTime

This entry controls the length of the cache timeout interval in milliseconds. The Schannel SSP attempts to map all of the issuers in the client’s certificate chain—not only the direct issuer of the client certificate. In the case where the issuers do not map to an account, which is the typical case, the server might attempt to map the same issuer name repeatedly, hundreds of times per second.

To prevent this, the server has a negative cache, so if an issuer name does not map to an account, it is added to the cache and the Schannel SSP will not attempt to map the issuer name again until the cache entry expires. This cache is kept for performance reasons, so that the system does not continue trying to map the same issuers. This entry does not exist in the registry by default. The default value is 10 minutes.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

KeyExchangeAlgorithm

This subkey controls the use of key exchange algorithms.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

To disable a key exchange algorithm, create an Enabled entry in the appropriate subkey. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. When you disable any algorithm, you disallow all cipher suites that use that algorithm. To enable the key exchange algorithm, change the DWORD value to 1.

Exchange algorithm subkey table

Subkey	Description	Default
Diffie-Hellman\Enabled	Controls the use of Diffie-Hellman (DH) for key exchange.	Enabled
PKCS	Controls the use of RSA for key exchange.	Enabled

MaximumCacheSize

This entry controls the maximum number of cache elements. Setting MaximumCacheSize to 0 disables the server-side session cache and prevents reconnection. Increasing MaximumCacheSize above the default values causes Lsass.exe to consume additional memory. Each session-cache element typically requires 2 to 4 KB of memory. This entry does not exist in the registry by default. The default value is 20,000 elements.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

PCT 1.0

This subkey controls the use of the Private Communications Transport (PCT) protocol.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

To disable the PCT protocol, create an Enabled entry in the appropriate subkey. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. To enable the protocol, change the DWORD value to 1.

PCT subkey table

Subkey	Description	Default
Client	Controls the use of the PCT protocol on the client	Enabled
Server	Controls the use of the PCT protocol on the server	Enabled
DisabledByDefault	Controls disabling the PCT protocol by default. This entry does not exist in the registry by default.	Enabled

SendTrustedIssuerList

This entry controls the flag that is used when the list of trusted issuers is sent. In the case of servers that trust hundreds of certification authorities for client authentication, there are too many issuers for the server to be able to send them all to the client computer when requesting client authentication. In this situation, this registry key can be set, and instead of sending a partial list, the Schannel SSP will not send any list to the client.

Not sending a list of trusted issuers might impact what the client sends when it is asked for a client certificate. For example, when Internet Explorer receives a request for client authentication, it only displays the client certificates that chain up to one of the certification authorities that is sent by the server. If the server did not send a list, Internet Explorer displays all of the client certificates that are installed on the client.

This behavior might be desirable. For example, when PKI environments include cross certificates, the client and server certificates will not have the same root CA; therefore, Internet Explorer cannot chose a certificate that chains up to one of the server’s CAs. By configuring the server to not send a trusted issuer list, Internet Explorer will send all its certificates.

This entry does not exist in the registry by default. This value is True by default.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

ServerCacheTime

This entry controls the amount of time in milliseconds that the operating system takes to expire server-side cache entries. A value of 0 disables the server-side session cache and prevents reconnection. Increasing ServerCacheTime above the default values causes Lsass.exe to consume additional memory. Each session cache element typically requires 2 to 4 KB of memory. This entry does not exist in the registry by default.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Default server cache time: 10 hours

SSL 2.0

This subkey controls the use of SSL 2.0.

SSL 2.0 is disabled by default on Windows client computers.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic excluding Windows client versions.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

To disable the SSL 2.0 protocol, create an Enabled entry in the appropriate subkey. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. To enable the protocol, change the DWORD value to 1.

SSL 2.0 subkey table

Subkey	Description	Default
Client	Controls the use of SSL 2.0 on the client.	Disabled
Server	Controls the use of SSL 2.0 on the server.	Enabled
DisabledByDefault	Flag to disable SSL 2.0 by default.	Enabled

SSL 3.0

This subkey controls the use of SSL 3.0.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

To disable the SSL 3.0 protocol, create an Enabled entry in the appropriate subkey. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. To enable the protocol, change the DWORD value to 1.

SSL 3.0 subkey table

Subkey	Description	Default
Client	Controls the use of SSL 3.0 on the client.	Enabled
Server	Controls the use of SSL 3.0 on the server.	Enabled
DisabledByDefault	Flag to disable SSL 3.0 by default.	Enabled

TLS 1.0

This subkey controls the use of TLS 1.0.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

To disable the TLS 1.0 protocol, create an Enabled entry in the appropriate subkey. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. To enable the protocol, change the DWORD value to 1.

TLS 1.0 subkey table

Subkey	Description	Default
Client	Controls the use of TLS 1.0 on the client.	Enabled
Server	Controls the use of TLS 1.0 on the server.	Enabled
DisabledByDefault	Flag to disable TLS 1.0 by default.	Enabled

TLS 1.1

This subkey controls the use of TLS 1.1.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic excluding those versions prior to Windows Server 2008 R2 and Windows 7.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

To disable the TLS 1.1 protocol, create an Enabled entry in the appropriate subkey. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. To enable the protocol, change the DWORD value to 1.

TLS 1.1 subkey table

Subkey	Description	Default
Client	Controls the use of TLS 1.1 on the client.	Enabled
Server	Controls the use of TLS 1.1 on the server.	Enabled
DisabledByDefault	Flag to disable TLS 1.1 by default.	Enabled

TLS 1.2

This subkey controls the use of TLS 1.2.

Note: For TLS 1.2 to be enabled and negotiated on servers that run Windows Server 2008 R2, you MUST create the «DisabledByDefault» entry in the appropriate subkey (Client, Server) and set it to «0». The entry will not be seen in the registry and it is set to «1» by default.

Applicable versions: As designated in the Applies To list that is at the beginning of this topic excluding those versions prior to Windows Server 2008 R2 and Windows 7.

Registry path: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

To disable the TLS 1.2 protocol, create an Enabled entry in the appropriate subkey. This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. To enable the protocol, change the DWORD value to 1.

TLS 1.2 subkey table

Subkey	Description	Default
Client	Controls the use of TLS 1.2 on the client.	Enabled
Server	Controls the use of TLS 1.2 on the server.	Enabled
DisabledByDefault	Flag to disable TLS 1.2 by default.	Enabled

OCSP stapling

Online Certificate Status Protocol (OCSP) stapling enables a web server, such as Internet Information Services (IIS), to provide the current revocation status of a server certificate when it sends the server certificate to a client during the TLS handshake. This feature reduces the load on OCSP servers because the web server can cache the current OCSP status of the server certificate and send it to multiple web clients. Without this feature, each web client would try to retrieve the current OCSP status of the server certificate from the OCSP server. This would generate a high load on that OCSP server.

By default, OCSP support is enabled for IIS websites that have a simple secure (SSL/TLS) binding. However, this support is not enabled by default if the IIS website is using either or both of the following types of secure (SSL/TLS) bindings:

Require Server Name Indication

Use Centralized Certificate Store

In this case, the server hello response during the TLS handshake won’t include an OCSP stapled status by default. This behavior improves performance: The Windows OCSP stapling implementation scales to hundreds of server certificates. Because SNI and CCS enable IIS to scale to thousands of websites that potentially have thousands of server certificates, setting this behavior to be enabled by default may cause performance issues.

To enable OCSP stapling for SNI and CCS bindings, locate the following registry subkey:

Registry path: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]

To this subkey, add the following key:

Note Enabling this registry key has a potential performance impact.

Group Policy settings

The following table lists and describes the Group Policy setting that is associated with the Schannel SSP.

Group Policy setting associated with Schannel SSP

Group Policy Setting

Description

System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing. (This is a Security options Group Policy setting.)

Changes to this setting determine whether the Schannel SSP will support the TLS protocol as a client(or as a server, if applicable), and if it will use only the following algorithms: — Triple Data Encryption Algorithm (Triple DES) for the TLS traffic encryption — Rivest-Shamir-Adleman (RSA) public key algorithm for the TLS key exchange and authentication — Secure Hash Algorithm version 1 (SHA-1) for TLS hashing Читайте также:  Windows синий экран stop 0x00000116 Оцените статью Вам также может понравиться Windows или Linux: Что лучше выбрать? Есть много причин выбирать между Windows и Linux, но Файл владелец изменить linux Команда Chown в Linux Chown Command in Linux (File Установка шлюза по умолчанию linux Настройка сети вручную Содержание Краткое описание Чем разбить диск для linux ИТ База знаний Курс по Asterisk Полезно — Узнать IP — Правообладателям Политика конфиденциальности Контакты