Параметры безопасности протокола tls windows 10 как исправить
Перейти к содержимому

Параметры безопасности протокола tls windows 10 как исправить

  • автор:

При использовании протокола RDP с шифрованием SSL отображается неправильный протокол TLS

В этой статье описано решение проблемы, из-за которой протокол SSL (TLS 1.0) отображается как протокол уровня безопасности, а не фактический протокол TLS 1.2.

Область действия: Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Исходный номер базы знаний: 3097192

Симптомы

Рассмотрим следующий сценарий.

  • У вас есть компьютер под управлением операционной системы Windows Server.
  • На этом компьютере настроена роль посредника подключений к удаленному рабочему столу (RDCB).
  • Вы пытаетесь защитить подключения по протоколу RDP к целевым компьютерам с помощью шифрования SSL (TLS).

В этом сценарии можно заметить, что в списке уровней безопасности отображается протокол SSL (TLS 1.0), даже если он фактически использует TLS 1.2:

Уровень безопасности отображает SSL (TLS 1.0) на странице

Вы также можете заметить аналогичное поведение при попытке настроить параметры уровня безопасности, применив следующий групповая политика:

Требовать использование определенного уровня безопасности для удаленных подключений (RDP)

Параметры уровня безопасности в диалоговом окне

Этот параметр можно найти в следующем расположении:

Конфигурация компьютера\Политики\Административные шаблоны\Компоненты Windows\Службы удаленных рабочих столов\Хост сеансов удаленных рабочих столов\Безопасность

Решение

Эта проблема вызвана ошибкой в guis Windows Server. Вы можете спокойно игнорировать версию TLS, отображаемую в графическом пользовательском интерфейсе, так как это не отражает версию TLS, используемую для клиентских подключений.

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

В следующем обязательном исправлении реализована поддержка TLS 1.2 на сервере узла сеансов Windows Server 2008 R2. Это исправление соответствует последним стандартам безопасности PCI DSS.

3080079 обновления для добавления поддержки RDS для TLS 1.1 и TLS 1.2 в Windows 7 или Windows Server 2008 R2

Если клиентский компьютер работает под управлением Windows 7, для использования TLS 1.2 на нем должно быть установлено обновление RDC 8.0. Без обновления RDC 8.0 клиент Windows 7 может использовать только TLS 1.0.

Обратная связь

Были ли сведения на этой странице полезными?

Как включить TLS 1.2 на клиентах

При включении TLS 1.2 для среды Configuration Manager сначала убедитесь, что клиенты поддерживают и правильно настроены для использования TLS 1.2 перед включением TLS 1.2 и отключением старых протоколов на серверах сайта и удаленных системах сайта. Существует три задачи для включения TLS 1.2 на клиентах:

  • Обновление Windows и WinHTTP
  • Убедитесь, что протокол TLS 1.2 включен в качестве протокола для SChannel на уровне операционной системы.
  • Обновление и настройка платформа .NET Framework для поддержки TLS 1.2

Дополнительные сведения о зависимостях для конкретных функций и сценариев Configuration Manager см. в статье О включении TLS 1.2.

Обновление Windows и WinHTTP

Windows 8.1, Windows Server 2012 R2, Windows 10, Windows Server 2016 и более поздних версий Windows изначально поддерживают протокол TLS 1.2 для обмена данными между клиентом и сервером через WinHTTP.

В более ранних версиях Windows, таких как Windows 7 или Windows Server 2012, протокол TLS 1.1 или TLS 1.2 по умолчанию не включается для безопасного взаимодействия с помощью WinHTTP. Для этих более ранних версий Windows установите update 3140245 , чтобы включить приведенное ниже значение реестра, которое можно задать для добавления TLS 1.1 и TLS 1.2 в список защищенных протоколов по умолчанию для WinHTTP. Установив исправление, создайте следующие значения реестра:

Включите эти параметры на всех клиентах под управлением более ранних версий Windows перед включением TLS 1.2 и отключением старых протоколов на серверах Configuration Manager. В противном случае их можно непреднамеренно захотеть.

Проверьте значение DefaultSecureProtocols параметра реестра, например:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\ DefaultSecureProtocols = (DWORD): 0xAA0 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\ DefaultSecureProtocols = (DWORD): 0xAA0 

Если изменить это значение, перезагрузите компьютер.

В приведенном выше примере показано значение 0xAA0 параметра WinHTTP DefaultSecureProtocols . Обновите, чтобы включить протоколы TLS 1.1 и TLS 1.2 в качестве протоколов безопасности по умолчанию в WinHTTP в Windows, в списке шестнадцатеричных значений для каждого протокола. По умолчанию в Windows это значение предназначено 0x0A0 для включения SSL 3.0 и TLS 1.0 для WinHTTP. В приведенном выше примере эти значения по умолчанию сохраняются, а также протоколы TLS 1.1 и TLS 1.2 для WinHTTP. Эта конфигурация гарантирует, что изменение не нарушает работу любого другого приложения, которое по-прежнему может полагаться на SSL 3.0 или TLS 1.0. Значение 0xA00 можно использовать, чтобы включить только TLS 1.1 и TLS 1.2. Configuration Manager поддерживает наиболее безопасный протокол, который Windows согласовывает между обоими устройствами.

Если вы хотите полностью отключить SSL 3.0 и TLS 1.0, используйте параметр SChannel disabled protocols (Отключенные протоколы SChannel) в Windows. Дополнительные сведения см. в разделе Ограничение использования определенных криптографических алгоритмов и протоколов в Schannel.dll.

Убедитесь, что протокол TLS 1.2 включен в качестве протокола для SChannel на уровне операционной системы.

В большинстве случаев использование протокола контролируется на трех уровнях: на уровне операционной системы, на уровне платформы или платформы, а также на уровне приложения. Протокол TLS 1.2 включен по умолчанию на уровне операционной системы. Убедившись, что значения реестра .NET настроены для включения TLS 1.2 и убедитесь, что среда правильно использует TLS 1.2 в сети, может потребоваться изменить SChannel\Protocols раздел реестра, чтобы отключить старые, менее безопасные протоколы. Дополнительные сведения об отключении TLS 1.0 и 1.1 см. в разделе Настройка протоколов Schannel в реестре Windows.

Обновление и настройка платформа .NET Framework для поддержки TLS 1.2

Определение версии .NET

Установите обновления .NET

Установите обновления .NET, чтобы включить надежное шифрование. Для некоторых версий платформа .NET Framework могут потребоваться обновления для включения надежного шифрования. Воспользуйтесь следующими инструкциями:

    NET Framework 4.6.2 и более поздних версий поддерживает TLS 1.1 и TLS 1.2. Подтвердите параметры реестра, но никаких дополнительных изменений не требуется.

Примечание. Начиная с версии 2107 для Configuration Manager требуется Майкрософт платформа .NET Framework версии 4.6.2 для серверов сайта, определенных систем сайта, клиентов и консоли. Если это возможно в вашей среде, установите последнюю версию .NET версии 4.8.

  • Для Windows 8.1 и Server 2012 R2: накопительный пакет исправлений 3099842
  • Для Windows Server 2012: накопительный пакет исправлений 3099844

Настройка для надежного шифрования

Настройте платформа .NET Framework для поддержки надежного шифрования. Задайте для SchUseStrongCrypto параметра реестра значение DWORD:00000001 . Это значение отключает шифр потока RC4 и требует перезагрузки. Дополнительные сведения об этом параметре см. в 296038 рекомендаций по безопасности Майкрософт.

Обязательно задайте следующие разделы реестра на любом компьютере, который обменивается данными по сети с системой с поддержкой TLS 1.2. Например, Configuration Manager клиентов, удаленные роли системы сайта, не установленные на сервере сайта, и сам сервер сайта.

Для 32-разрядных приложений, работающих на 32-разрядных ос, и для 64-разрядных приложений, работающих на 64-разрядных ОС, обновите следующие значения подраздела:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001 

Для 32-разрядных приложений на 64-разрядных системах измените следующие значения подразделов:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001 

Этот SchUseStrongCrypto параметр позволяет .NET использовать TLS 1.1 и TLS 1.2. Этот SystemDefaultTlsVersions параметр позволяет .NET использовать конфигурацию ОС. Дополнительные сведения см. в статье Рекомендации по TLS с платформа .NET Framework.

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

  • Включение TLS 1.2 на серверах сайта и удаленных системах сайта
  • Распространенные проблемы при включении протокола TLS 1.2

Параметры реестра протокола TLS

В этой статье описываются поддерживаемые сведения о параметрах реестра для реализации протокола TLS и протокола SSL через поставщик поддержки безопасности SChannel (SSP). Подразделы реестра и записи, описанные в этой статье, помогают администрировать и устранять неполадки SChannel SSP, в частности протоколы TLS и SSL.

Эти сведения предоставляются в виде справочника для использования при устранении неполадок или проверки правильности применения нужных параметров. Рекомендуется не изменять реестр напрямую, если есть другие возможности. Изменения в реестре не проверяются редактором реестра или операционной системой Windows перед их применением. В результате могут сохраниться неверные значения, что приведет к неустранимым ошибкам в системе. Если это возможно, вместо прямого редактирования реестра используйте групповую политику или другие средства Windows, такие как консоль управления Майкрософт (MMC). Если отредактировать реестр все же необходимо, соблюдайте крайнюю осторожность.

Ведение журнала SChannel

Существует восемь уровней ведения журнала для событий SChannel, сохраненных в системном журнале событий и доступных для просмотра с помощью Просмотр событий. Этот путь реестра хранится в HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL в разделе EventLogging с значением DWORD, равным 1.

Десятичная или шестнадцатеричная События ведения журнала SChannel
0 Нет событий
1 События ошибок
2 События предупреждения
3 События ошибки и предупреждения
4 Информационные и успешные события
5 События ошибки, информационные и успешные события
6 События предупреждения, информационные и успешные события
7 События ошибки, предупреждения, информационные и успешные события

После изменения уровня ведения журнала SChannel необходимо перезагрузить устройство.

CertificateMappingMethods

Если приложению сервера требуется проверка подлинности клиента, SChannel автоматически пытается сопоставить сертификат, предоставленный клиентским компьютером, с учетной записью пользователя. Вы можете проверять подлинность пользователей, выполняющих вход с сертификатом клиента, создавая сопоставления, связывающие данные сведения с учетной записью пользователя Windows.

После создания и включения сопоставления сертификатов каждый раз, когда клиент предоставляет сертификат клиента, серверное приложение автоматически сопоставляет этого пользователя с соответствующей учетной записью Windows.

В большинстве случаев сертификат сопоставляется с учетной записью пользователя одним из двух следующих способов.

  • Один сертификат сопоставляется с одной учетной записью пользователя (сопоставление «один к одному»).
  • Несколько сертификатов сопоставляются с одной учетной записью пользователя (сопоставление «многие к одному»).

Поставщик SChannel использует четыре метода сопоставления сертификатов:

  1. Сопоставление Kerberos service-for-user (S4U) (включено по умолчанию)
  2. Сопоставление имени участника-пользователя.
  3. Сопоставление «один к одному» (также называемое сопоставлением «субъект/поставщик»).
  4. Сопоставление «многие к одному».

Путь к реестру: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Имя записи DWORD Включено по умолчанию
Тема или издатель 0x000000001 No
Издатель 0x000000002 No
UPN 0x000000004 No
S4U2Self 0x000000008 Да
S4U2Self Явный 0x000000010 Да

Применимые версии: как указано в списке «Область применения» в начале этой статьи.

Ciphers

Шифры TLS/SSL должны контролироваться путем настройки порядка набора шифров. Дополнительные сведения см. в разделе «Настройка порядка набора шифров TLS».

Сведения о заказах набора шифров по умолчанию, используемых SSP SChannel, см. в статьях «Наборы шифров» в tls/SSL (SChannel SSP).

CipherSuites

Настройка наборов шифров TLS/SSL должна выполняться с помощью групповой политики, MDM или PowerShell, см. дополнительные сведения о настройке порядка шифров TLS.

Сведения о заказах набора шифров по умолчанию, используемых SSP SChannel, см. в статьях «Наборы шифров» в tls/SSL (SChannel SSP).

ClientCacheTime

Эта запись указывает время существования элемента кэша сеансов TLS клиента в миллисекундах. Начиная с Windows Server 2008 и Windows Vista значение по умолчанию составляет 10 часов. Значение 0 отключает кэширование сеанса TLS на клиенте.

При первом подключении клиента к серверу через SChannel SSP выполняется полное подтверждение TLS/SSL. После завершения главная копия секрета, комплект шифров и сертификаты хранятся в кэше сеанса на соответствующем клиенте и сервере.

Путь к реестру: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

EnableOcspStaplingForSni

Подключение протокола OCSP позволяет веб-серверу, например службы IIS (IIS), предоставить текущее состояние отзыва сертификата сервера при отправке сертификата сервера клиенту во время подтверждения TLS. Эта функция снижает нагрузку на серверы OCSP, так как веб-сервер может кэшировать текущее состояние сертификата сервера OCSP и отправлять его нескольким веб-клиентам. Без этой функции каждый веб-клиент попытается получить текущее состояние OCSP сертификата сервера с сервера OCSP. Это приведет к высокой нагрузке на этот сервер OCSP.

Помимо IIS веб-службы по протоколу http.sys также могут воспользоваться этим параметром, включая службы федерации Active Directory (AD FS) (AD FS) и прокси веб-приложения (WAP).

По умолчанию поддержка OCSP включена для веб-сайтов IIS, имеющих простую безопасную привязку (SSL/TLS). Однако эта поддержка не включена по умолчанию, если веб-сайт IIS использует один или оба из следующих типов привязок SSL/TLS:

  • Требовать указание имени сервера
  • Использовать централизованное хранилище сертификатов

В этом случае ответ приветствия сервера во время подтверждения TLS по умолчанию не будет включать состояние OCSP с срезанный по умолчанию. Это повышает производительность: реализация windows OCSP масштабируется до сотен сертификатов сервера. Однако указание имени сервера (SNI) и центральное хранилище сертификатов (CCS) позволяют службам IIS масштабироваться до тысяч веб-сайтов, которые потенциально имеют тысячи сертификатов сервера, поэтому включение привязки OCSP для привязок CCS может привести к проблемам с производительностью.

Применимые версии: все версии, начиная с Windows Server 2012 и Windows 8.

Путь к реестру: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Добавьте следующий ключ:

Чтобы отключить, задайте для значения DWORD значение 0:

Включение этого раздела реестра может повлиять на производительность.

Hashes

Алгоритмы хэша TLS/SSL должны контролироваться путем настройки порядка набора шифров. Дополнительные сведения см. в разделе «Настройка заказа набора шифров TLS».

IssuerCacheSize

Эта запись управляет размером кэша издателя и используется с сопоставлением издателя. SChannel SSP пытается сопоставить все издатели в цепочке сертификатов клиента, а не только прямой издатель сертификата клиента. Если издатели не сопоставляются с учетной записью, что является типичным случаем, сервер может попытаться сопоставить одно и то же имя издателя несколько раз в секунду.

Чтобы предотвратить это, сервер имеет отрицательный кэш, поэтому если имя издателя не сопоставляется с учетной записью, она добавляется в кэш, и SChannel SSP не попытается сопоставить имя издателя еще раз до истечения срока действия записи кэша. Эта запись реестра указывает размер кэша. Эта запись не существует в реестре по умолчанию. Значение по умолчанию — 100.

Применимые версии: все версии, начиная с Windows Server 2008 и Windows Vista.

Путь к реестру: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

IssuerCacheTime

Эта запись определяет продолжительность интервала времени ожидания кэша в миллисекундах. SChannel SSP пытается сопоставить все издатели в цепочке сертификатов клиента, а не только прямой издатель сертификата клиента. В случае, если издатели не сопоставляются с учетной записью, что является типичным случаем, сервер может попытаться сопоставить одно и то же имя издателя несколько раз в секунду.

Чтобы предотвратить это, сервер имеет отрицательный кэш, поэтому если имя издателя не сопоставляется с учетной записью, она добавляется в кэш, и SChannel SSP не попытается сопоставить имя издателя еще раз до истечения срока действия записи кэша. Этот кэш хранится по соображениям производительности, чтобы система не продолжала пытаться сопоставить одни и те же издатели. Эта запись не существует в реестре по умолчанию. Значение по умолчанию равно 10 минутам.

Применимые версии: все версии, начиная с Windows Server 2008 и Windows Vista.

Путь к реестру: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Размеры ключей KeyExchangeAlgorithm

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

Добавлено в Windows 10 версии 1507 и Windows Server 2016.

Путь к реестру: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman

Чтобы указать минимальный поддерживаемый диапазон бита ключа Diffie-Hellman для клиента TLS, создайте запись ClientMinKeyBitLength . После создания записи измените значение DWORD на нужную битовую длину. Если не настроено, 1024 бита будет минимальной.

Чтобы указать максимальный поддерживаемый диапазон битового ключа Diffie-Hellman для клиента TLS, создайте запись ClientMaxKeyBitLength . После создания записи измените значение DWORD на нужную битовую длину.

Чтобы указать длину бита ключа Diffie-Hellman для сервера TLS по умолчанию, создайте запись ServerMinKeyBitLength . После создания записи измените значение DWORD на нужную битовую длину. Если не настроено, по умолчанию используется 2048 бит.

Добавлено в Windows 10 версии 1507 и Windows Server 2016.

Путь к реестру: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS

Чтобы указать минимальный поддерживаемый диапазон длины бита ключа RSA для клиента TLS, создайте запись ClientMinKeyBitLength . После создания записи измените значение DWORD на нужную битовую длину. Если не настроено, 1024 бита является минимальным.

Чтобы указать максимальный поддерживаемый диапазон длины бита ключа RSA для клиента TLS, создайте запись ClientMaxKeyBitLength . После создания записи измените значение DWORD на нужную битовую длину. На стороне сервера сила обмена ключами RSA управляется указанным сертификатом сервера.

Настроенные эллиптические кривые определяют криптографическую силу обмена ключами ECDHE. Дополнительные сведения см. в разделе «Управление безопасностью транспортного уровня ( TLS)».

Дополнительные сведения о криптографических алгоритмах набора шифров TLS/SSL см. в следующем разделе:

  • Наборы шифров в TLS/SSL (SChannel SSP)
  • Demystifying SChannel (блог)

MaximumCacheSize

Эта запись управляет максимальным количеством сеансов TLS для кэширования. Если параметр MaximumCacheSize задано значение 0 , кэш сеансов на стороне сервера отключается, чтобы предотвратить возобновление сеанса. Если для MaximumCacheSize задать значение больше установленного по умолчанию, Lsass.exe будет потреблять дополнительный объем памяти. Каждый элемент кэша сеансов обычно требует от 2 КБ до 4 КБ памяти. Эта запись не существует в реестре по умолчанию. Значение по умолчанию — 20000.

Применимые версии: все версии, начиная с Windows Server 2008 и Windows Vista.

Путь к реестру: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Обмен сообщениями — синтаксический анализ фрагментов

Эта запись управляет максимальным допустимым размером сообщения подтверждения TLS, которое будет принято. Сообщения, превышающие допустимый размер, не будут приняты, и подтверждение TLS завершится ошибкой. Эти записи не существуют в реестре по умолчанию.

Если задать значение 0x0, фрагментированные сообщения не обрабатываются и приведут к сбою подтверждения TLS. Это делает клиенты ИЛИ серверы TLS на текущем компьютере несоответствующим с ПРОТОКОЛАМИ RFCS.

Максимальный допустимый размер может быть увеличен до 2^16 байт. Разрешение клиенту или серверу считывать и хранить большие объемы непроверенных данных из сети не рекомендуется и будет использовать дополнительную память для каждого контекста безопасности.

Добавлено в Windows 7 и Windows Server 2008 R2: обновление, которое позволяет Обозреватель в Windows XP, в Windows Vista или в Windows Server 2008 для анализа фрагментированных сообщений tls/SSL.

Путь к реестру: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging

Чтобы указать максимальный допустимый размер фрагментированных сообщений подтверждения TLS, которые будет принимать клиент TLS, создайте запись MessageLimitClient . После создания записи измените значение DWORD на нужную битовую длину. Если значение по умолчанию не настроено, 0x8000 байтами.

Чтобы указать максимальный допустимый размер фрагментированных сообщений подтверждения TLS, которые сервер TLS принимает при отсутствии проверки подлинности клиента, создайте запись MessageLimitServer . После создания записи измените значение DWORD на нужную битовую длину. Если значение по умолчанию не настроено, 0x4000 байт.

Чтобы указать максимальный допустимый размер фрагментированных сообщений подтверждения TLS, которые сервер TLS принимает при проверке подлинности клиента, создайте запись MessageLimitServerClientAuth . После создания записи измените значение DWORD на нужную битовую длину. Если значение по умолчанию не настроено, 0x8000 байтами.

SendTrustedIssuerList

Серверы TLS могут отправлять список различаемых имен допустимых центров сертификации при запросе проверки подлинности клиента. Это может помочь клиентам TLS выбрать соответствующий сертификат клиента TLS. Серверы TLS на основе SChannel по умолчанию не отправляют этот список доверенных издателей, так как он предоставляет центрам сертификации доверенные сервером пассивные наблюдатели, а также увеличивает объем данных, обмениваемых в ходе подтверждения TLS. Если задать значение 1 , серверы на основе SChannel отправляют свои списки доверенных издателей.

Не отправляя список доверенных издателей, может повлиять на то, что клиент отправляет, когда он запрашивает сертификат клиента. Например, получив запрос на проверку подлинности клиента, Internet Explorer отображает только сертификаты клиента, по цепочке связанные с одним из центров сертификации, отправленных сервером. Если сервер не отправил список, интернет-Обозреватель отображает все сертификаты клиента, установленные на клиенте.

Это поведение может быть нежелательно. Например, если среды PKI включают кросс-сертификаты, сертификаты клиента и сервера не будут иметь один корневой ЦС; Таким образом, интернет-Обозреватель не может выбрать сертификат, который объединяется с одним из ЦС сервера. Клиенты TLS могут предлагать любой доступный сертификат клиента, если сервер не отправляет список доверенных издателей. Эта запись не существует в реестре по умолчанию.

Поведение списка доверенных издателей по умолчанию

Версия Windows Поведение по умолчанию
Windows Server 2012, Windows 8 и более поздних версий FALSE
Windows Server 2008 R2, Windows 7 и более ранних версий TRUE

Применимые версии: все версии, начиная с Windows Server 2008 и Windows Vista.

Путь к реестру: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

ServerCacheTime

Эта запись указывает время существования элемента кэша сеансов TLS сервера в миллисекундах. Значение по умолчанию — 10 часов. Значение 0 отключает кэширование сеанса TLS на сервере и предотвращает возобновление сеанса. Если для ServerCacheTime задать значение больше установленного по умолчанию, Lsass.exe будет потреблять дополнительный объем памяти. Каждый элемент кэша сеансов обычно требует от 2 КБ до 4 КБ памяти. Эта запись не существует в реестре по умолчанию.

Применимые версии: все версии, начиная с Windows Server 2008 и Windows Vista.

Путь к реестру: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Время кэша сервера по умолчанию: 10 часов

Параметры версии протокола TLS, DTLS и SSL

SChannel SSP реализует версии протоколов TLS, DTLS и SSL. Разные выпуски Windows поддерживают разные версии протокола. Набор доступных версий TLS и SSL может быть ограничен (но не расширен) вызывающими средствами SSPI, указывающими структуру SCH_CREDENTIALS в вызове AcquireCredentialsHandle . Рекомендуется использовать системные значения по умолчанию, а не вводить ограничения версий протокола.

Поддерживаемая версия протокола TLS или SSL может существовать в одном из следующих состояний:

  • Включено: если вызывающий объект SSPI явно не отключает эту версию протокола с помощью структуры SCH_CREDENTIALS , SChannel SSP может согласовывать эту версию протокола со вспомогательным пирингом.
  • Отключен: SChannel SSP не будет согласовывать эту версию протокола независимо от параметров, которые может указывать вызывающий объект SSPI.

Эти значения реестра настраиваются отдельно для ролей клиента и сервера протокола в подразделах реестра с именем следующего формата:

Эти подразделы для конкретной версии можно создать в следующем пути реестра:

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Например, ниже приведены допустимые пути реестра с вложенными ключами для конкретной версии:

  • HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client
  • HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
  • HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\DTLS 1.2\Client

Чтобы переопределить системное значение по умолчанию и задать поддерживаемую версию протокола TLS или SSL в состоянии «Включено», создайте значение реестра DWORD с именем «Включено» со значением записи «1» в соответствующем подразделе для конкретной версии.

В следующем примере показан клиент TLS 1.0 с включенным состоянием :

Screenshot of Set TLS 1.0 client-side to enabled in Windows Server registry setting.

Чтобы переопределить системное значение по умолчанию и задать поддерживаемую версию протокола TLS или SSL в отключенном состоянии, измените значение реестра DWORD «Включено» на «0» в соответствующем подразделе для конкретной версии.

В следующем примере показан параметр DTLS 1.2, отключенный в реестре:

Screenshot of Windows Server registry setting for DTLS 1.2 set to disabled by default.

Переключение версии протокола TLS или SSL на отключенное состояние может привести к сбою вызовов AcquireCredentialsHandle из-за отсутствия версий протокола, включенных системой, и в то же время, разрешенных определенными вызывающими пользователями SSPI. Кроме того, сокращение набора включенных (D)TLS и SSL-версий может нарушить взаимодействие с удаленными одноранговыми узлами.

После изменения параметров версии протокола TLS или SSL они вступают в силу для подключений, установленных с помощью дескрипторов учетных данных, открытых последующими вызовами AcquireCredentialsHandle . (D) Клиент TLS и серверные приложения и службы TLS, как правило, повторно используют дескриптор учетных данных для нескольких подключений по соображениям производительности. Чтобы получить эти приложения для повторного получения маркеров учетных данных, может потребоваться перезапуск приложения или службы.

Эти параметры реестра применяются только к SChannel SSP и не влияют на сторонние реализации TLS и SSL, которые могут быть установлены в системе.

Решение проблемы с TLS 1.0, выпуск 2

В этом документе представлено последнее руководство по быстрому определению и удалению зависимостей протокола TLS версии 1.0 в программном обеспечении, созданном на базе лучших операционных систем Майкрософт. Ниже приведены подробные сведения об изменениях в продуктах и новых возможностях, предоставленных корпорацией Майкрософт для защиты собственных клиентов и веб-служб. Он предназначен для использования в качестве отправной точки для создания плана миграции в сетевую среду TLS 1.2+. Несмотря на то, что обсуждаемые здесь решения могут способствовать удалению использования TLS 1.0 в операционных системах сторонних производителей или библиотеках шифрования, они не будут в центре внимания данного документа.

TLS 1.0 — это процедуры обеспечения безопасности, впервые определенные в 1999 г. для установки каналов шифрования по компьютерным сетям. Корпорация Майкрософт поддерживала этот протокол с момента выпуска Windows XP/Server 2003. Несмотря на то, что в современных ОС не используется протокол безопасности по умолчанию, TLS 1.0 по-прежнему поддерживается для обеспечения обратной совместимости. Развитие нормативных требований, а также новые уязвимые места системы безопасности в TLS 1.0 предоставляют организациям возможность полностью отключить TLS 1.0.

Компания Майкрософт рекомендует клиентам обойти эту проблему, удалив зависимости TLS 1.0 в своих средах и отключив TLS 1.0 на уровне операционной системы, где это возможно. Учитывая время, в течение которого TLS 1.0 поддерживается отраслью программного обеспечения, настоятельно рекомендуется, чтобы любой план по отключению TLS 1.0 включал следующее.

  • Анализ кода для поиска и исправления жестко закодированных экземпляров TLS 1.0 или более старых протоколов безопасности.
  • Проверка конечных точек сети и анализ трафика для обнаружения операционных систем, использующих TLS 1.0 или более старые протоколы.
  • Полное тестирование регрессии через весь стек приложений с отключенным TLS 1.0.
  • Миграция устаревших операционных систем и библиотек или платформ разработки в версии, способные по умолчанию согласовывать TLS 1.2.
  • Тестирование совместимости между операционными системами, используемыми в вашей организации, для обнаружения любых проблем, связанных с поддержкой TLS 1.2.
  • Согласуйте со своими бизнес-партнерами и клиентами решение о переходе на нерекомендуемый протокол TLS 1.0.
  • Узнайте, какие клиенты больше не смогут подключаться к вашим серверам после того, как TLS 1.0 будет отключен.

Целью данного документа является предоставление рекомендаций, которые могут помочь устранить технические препятствия при отключении TLS 1.0 и в то же время увеличить видимость воздействия этого изменения на ваших собственных клиентов. Выполнение такого исследования поможет снизить влияние следующей уязвимости системы безопасности в TLS 1.0 на организацию. В рамках этого документа ссылки на отключение TLS 1.0 также включают TLS 1.1.

У разработчиков корпоративного программного обеспечения есть стратегическая потребность в принятии более безопасных и гибких решений (также известных как Crypto Agility), которые могут повлиять на будущие протоколы безопасности. В то время как данный документ предлагает гибкие решения для устранения жесткого задания TLS, более масштабные решения Crypto Agility находятся за рамками данного документа.

Текущее состояние реализации Microsoft TLS 1.0

В реализации TLS 1.0 от Майкрософт нет известных уязвимостей безопасности. В связи с возможностью будущих атак при переходе на использование более ранней версии и других уязвимостей TLS 1.0, не относящихся к реализации Майкрософт, рекомендуется при возможности удалить зависимости по всем протоколам безопасности, выпущенным раньше TLS 1.2 (TLS 1.1/1.0/SSLv3/SSLv2).

Планируя миграцию на TLS 1.2+, разработчики и системные администраторы должны знать о возможностях версии протокола в приложениях, разработанных их сотрудниками и партнерами. Жесткое кодирование здесь означает, что версия TLS исправлена до устаревшей версии и менее безопасна по сравнению с более новыми версиями. Версии TLS более поздней версии, чем жестко закодированная, нельзя использовать без изменения рассматриваемой программы. Этот класс проблемы нельзя устранить без изменения исходного кода и развертывания обновлений программного обеспечения. В прошлом версия протокола жесткого кодирования была распространена для тестирования и поддержки, поскольку многие обозреватели и операционные системы имели различные уровни поддержки TLS.

Обеспечение поддержки TLS 1.2 в развернутых операционных системах

Многие операционные системы имеют устаревшую версию TLS по умолчанию или поддерживают лимиты, которые необходимо учитывать. Использование Windows 8/Server 2012 или более поздней версии означает, что TLS 1.2 будет иметь версию протокола безопасности по умолчанию:

Рис. 1. Поддержка протокола безопасности по версии ОС
ОС Windows SSLv2 SSLv3 TLS 1.0 TLS 1.1 TLS 1.2
Windows Vista Включен Активировано По умолчанию Не поддерживается Не поддерживается
Windows Server 2008 Включен Активировано По умолчанию Отключено* Отключено*
Windows 7 (WS2008 R2) Включен Активировано По умолчанию Отключено* Отключено*
Windows 8 (WS2012) Выключено Включен Включен Активировано По умолчанию
Windows 8.1 (WS2012 R2) Выключено Включен Включен Активировано По умолчанию
Windows 10 Выключено Включен Включен Активировано По умолчанию
Windows Server 2016 Не поддерживается Выключено Включен Активировано По умолчанию

*TLS 1.1/1.2 можно включить в Windows Server 2008 с помощью этого дополнительного пакета Центра обновления Windows.

Чтобы быстро определить, какая версия TLS будет запрошена различными клиентами при подключении к веб-службам, обратитесь к имитации подтверждений в Qualys SSL Labs. Эта модель охватывает сочетания клиентских операционных систем или браузеров разных производителей. Подробный пример, в котором показаны версии протокола TLS, согласованные различными сочетаниями клиентских операционных систем и браузеров при подключении к www.microsoft.com, см. в разделе Приложение A в конце документа.

Если это еще не сделано, мы настоятельно рекомендуем провести инвентаризацию операционных систем, используемых предприятием, клиентами и партнерами (двух последних с помощью распространения или коммуникации, или по крайней мере через сбор строк агента обработки HTTP). Эту инвентаризацию можно дополнить анализом трафика на границе вашей корпоративной сети. В такой ситуации при анализе трафика будут выдаваться версии TLS, успешно согласованные клиентами или партнерами, подключающимся к вашим службам, но сам трафик останется зашифрованным.

Улучшения в инженерии корпорации Майкрософт для устранения зависимостей TLS 1.0

С момента выпуска версии 1 этого документа Корпорация Майкрософт выпустила ряд обновлений программного обеспечения и новых функций для поддержки отключения TLS 1.0. Например:

  • Настраиваемое ведение журнала IIS для сопоставления строки агента пользователя или IP-адреса клиента, URI службы, версии протокола TLS и набора шифров.
    • С помощью этого журнала администраторы могут количественно оценить подверженность своих клиентов слабому TLS.
    • Этот портал предоставляет администраторам клиентов Office 365 ценные сведения, необходимые им для обращения к своим клиентам, которые могут не знать о своих зависимостях TLS 1.0.
    • Дополнительные сведения см. https://securescore.microsoft.com/
    • FYI. Все приложения, предназначенные для .NET 4.5 или более ранней версии, скорее всего, должны быть изменены для поддержки TLS 1.2.

    Поиск и исправление зависимостей TLS 1.0 в коде

    Для продуктов, использующих библиотеки шифрования и протоколы безопасности, предоставляемые ОС Windows, следующие шаги должны помочь определить любое жестко закодированное использование TLS 1.0 в приложениях.

    1. Найдите все экземпляры AcquireCredentialsHandle(). Это помогает рецензентам приблизиться к блокам кода, в которых TLS может быть жестко закодирован.
    2. Просмотрите все экземпляры структур SecPkgContext_SupportedProtocols и SecPkgContext_Подключение ionInfo для жестко закодированных TLS.
    3. В машинном коде задайте для любого ненулевого назначения grbitEnabledProtocols значение ноль. Это позволяет операционной системе применить используемую по умолчанию версию TLS.
    4. Отключите режим FIPS, если он включен из-за возможности конфликта с параметрами, необходимыми для явного отключения TLS 1.0/1.1 в этом документе. Дополнительные сведения см. в Приложении Б.
    5. Обновите и перекомпилируйте все приложения с помощью WinHTTP, размещенной на Server 2012 или более ранней версии.
      1. Управляемые приложения — перестроение и перенацеливание на последнюю версию .NET Framework
      2. Приложения должны добавить код для поддержки TLS 1.2 через WinHttpSetOption
      1. SecurityProtocolType
      2. SSLv2, SSLv23, SSLv3, TLS1, TLS 10, TLS11
      3. WINHTTP_FLAG_SECURE_PROTOCOL_
      4. SP_PROT_
      5. NSStreamSocketSecurityLevel
      6. PROTOCOL_SSL или PROTOCOL_TLS

      Рекомендуемое решение во всех приведенных выше случаях — удалить жестко заданный выбор версий протокола и отложить его до операционной системы по умолчанию. Если вы используете DevSkim, щелкните здесь, чтобы просмотреть правила, описывающие приведенные выше проверки, которые можно использовать с собственным кодом.

      Обновление сценариев Windows PowerShell или связанных параметров реестра

      Windows PowerShell использует .NET Framework 4.5, который не включает TLS 1.2 в качестве доступного протокола. Для решения этой проблемы доступны два решения.

        Измените скрипт, который имеется в вопросе, чтобы включить следующее:

      [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12; 

      Решения (1) и (2) являются взаимоисключающими, то есть их не нужно реализовывать вместе.

      Перестроение и изменение целевой платформы управляемых приложений с использованием последней версии .NET Framework

      В приложениях, использующих версии .NET Framework до версии 4.7, могут наблюдаться ограничения по эффективной поддержке ограничения TLS 1.0 независимо от базовой операционной системы по умолчанию. Дополнительные сведения см. в приведенной ниже схеме и платформа .NET Framework рекомендациях по протоколу TLS.

      Rebuild managed applications

      SystemDefaultTLSVersion имеет приоритет над нацеливанием версий TLS на уровне приложений. Рекомендуется всегда отдавать предпочтение стандартной версии TLS для ОС. Это также единственное решение для гибкого шифрования, позволяющее вашим приложениям пользоваться преимуществами будущей поддержки TLS 1.3.

      Если как целевые заданы более старые версии .NET Framework, например 4.5.2 или 3.5, то по умолчанию приложение будет использовать более старые нерекомендуемые протоколы, такие как SSL 3.0 или TLS 1.0. Настоятельно рекомендуется обновить .NET Framework до более новой версии, например .NET Framework 4.6, или задать соответствующие разделы реестра для UseStrongCrypto.

      Тестирование с помощью TLS 1.2+

      Следуя исправлениям, рекомендуемым в разделе выше, продукты следует проверить на наличие ошибок согласования протокола и совместимость с другими операционными системами предприятия, используя регрессионное тестирование.

      • Наиболее распространенной проблемой в этом регрессионном тестировании является сбой согласования TLS из-за попытки подключения клиента к операционной системе или браузеру, не поддерживающему TLS 1.2.
        • Например, клиент Vista не сможет согласовать протокол TLS с сервером, настроенным для TLS 1.2+, так как максимальная поддерживаемая версия TLS в Vista — 1.0. Этот клиент должен быть либо обновлен, либо списан в среде TLS 1.2+.
        • Если продукт согласовывает MTLS с сертификатом из нестандартного расположения (за пределами стандартного именованного хранилища сертификатов в Windows), то для правильного получения сертификата может потребоваться обновление кода.
        • Любые службы, взаимодействующие со сторонними службами, должны выполнять дополнительное тестирование взаимодействия с этими сторонними службами.
        • Для всех приложений, не использующих Windows, или серверных операционных систем требуется исследование или подтверждение того, что они могут поддерживать TLS 1.2. Чтобы определить это, проще всего выполнить сканирование.

        Простая схема для тестирования этих изменений в веб-службе состоит из следующих компонентов.

        1. Выполните проверку систем рабочей среды, чтобы найти операционные системы, не поддерживающие TLS 1.2.
        2. Проверьте исходный код и файлы конфигурации веб-службы для жестко заданного TLS, как описано в разделе «Поиск и исправление зависимостей TLS 1.0 в коде».
        3. Обновление и повторная компиляция приложений по мере необходимости:
          1. Управляемые приложения
            1. Выполните повторную сборку до последней версии .NET Framework.
            2. Убедитесь, что для любого использования перечисления SSLProtocols установлено значение SSLProtocols.None, чтобы использовать настройки ОС по умолчанию.

            Уведомление партнеров о планах отключения TLS 1.0

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

            • Для успешного отключения протокола TLS 1.0 очень важно установить ранний контакт с партнерами и клиентами. Как минимум, это должны быть записи в блогах, технические документы или другое веб-содержимое.
            • Каждому партнеру необходимо оценить собственный протокол TLS 1.2 с помощью описанных выше инициатив по тестированию операционной системы, сканированию кода и тестированию регрессии.

            Заключение

            Удаление зависимостей TLS 1.0 является сложной проблемой, которую нужно устранить от начала до конца. Корпорация Майкрософт и отраслевые партнеры на сегодняшний день работают над этим, чтобы обеспечить большую безопасность всего стека продуктов, от наших компонентов ОС и платформ разработки до приложений и служб, созданных на их основе. Следование рекомендациям, представленным в этом документе, поможет вашему предприятию наметить правильный курс и узнать, какие проблемы следует ожидать. Это также поможет вашим клиентам лучше подготовится к переходу.

            Приложение A. Имитация подтверждения для различных клиентов, подключающихся к www.microsoft.com, любезно SSLLabs.com

            Results of Handshake Simulation

            Приложение B. Отключение TLS 1.0/1.1 с сохранением режима FIPS

            Выполните следующие действия, если вашей сети требуется режим FIPS, но вы хотите отключить TLS 1.0/1.1:

            1. Настройте версии TLS с помощью реестра, задав для параметра «Включено» для нежелательных версий TLS значение 0.
            2. Отключите кривую 25519 (только Server 2016) с помощью групповой политики.
            3. Отключите все комплекты шифров с помощью алгоритмов, которые не разрешены соответствующей публикацией FIPS. Для Server 2016 (предполагая, что действуют настройки по умолчанию) это означает отключение шифров RC4, PSK и NULL.
            Спонсоры/Благодарность

            Марк Картрайт (Mark Cartwright)
            Брайан Салливан (Bryan Sullivan)
            Патрик Джанглс (Patrick Jungles)
            Майкл Сковетта (Michael Scovetta)
            Тони Райс (Tony Rice)
            Дэвид ЛеБлан (David LeBlanc)
            Мортимер Кук (Mortimer Cook)
            Даниэль Зоммерфельд (Daniel Sommerfeld)
            Андрей Попов (Andrei Popov)
            Мичико Шорт (Michiko Short)
            Джастин Берк (Justin Burke)
            Гов Махарадж (Gov Maharaj)
            Брэд Тернер (Brad Turner)
            Шон Стивенсон (Sean Stevenson)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *