Отключить поддержку шифров 3des windows server 2008 r2

Обновлено: 23.01.2025

В этой статье описывается ограничение использования определенных криптографических алгоритмов и протоколов в Schannel.dll файле. Эта информация также применяется к приложениям независимых поставщиков программного обеспечения (ISV), которые написаны для API шифрования Microsoft (CAPI).

Применяется к: Windows Server 2003
Исходный номер КБ: 245030

Эта статья применима к Windows Server 2003 и более ранним версиям Windows. Ключи реестра, применимые к Windows Server 2008 и более поздним версиям Windows, см. в Параметры .

Сводка

Следующие поставщики криптографических служб (CSPs), включенные в Windows NT 4.0 Пакет обновления 6, получили сертификаты для проверки криптографии FIPS-140-1.

Поставщик шифрования Microsoft Base (Rsabase.dll)
Microsoft Enhanced Cryptographic Provider (Rsaenh.dll) (неэкспортная версия)

Поставщик безопасности Microsoft TLS/SSL , Schannel.dll, использует указанные здесь CSP для ведения безопасной связи по SSL или TLS в своей поддержке internet Explorer и службы IIS (IIS).

Вы можете изменить файл Schannel.dll для поддержки Шифра Suite 1 и 2. Однако программа также должна поддерживать Пакет шифров 1 и 2. Наборы шифров 1 и 2 не поддерживаются в IIS 4.0 и 5.0.

В этой статье содержатся необходимые сведения для настройки поставщика безопасности TLS/SSL для Windows NT 4.0 Пакет обновления 6 и более поздних версий. Вы можете использовать реестр Windows для управления использованием определенных наборов шифров SSL 3.0 или TLS 1.0 в отношении криптографических алгоритмов, поддерживаемых базовым криптографическим поставщиком или расширенным криптографическим поставщиком.

В Windows NT 4.0 Пакет обновления 6 файл Schannel.dll не использует поставщика шифрования Microsoft Base DSS (Dssbase.dll) или расширенного поставщика шифрования Microsoft DS/Diffie-Hellman (Dssenh.dll).

Наборы шифров

SSL 3.0 и TLS 1.0 (RFC2246) с 56-битными пакетами экспортного шифра INTERNET-DRAFT для TLS draft-ietf-tls-56-bit-ciphersuites-00.txtпредоставляют варианты использования различных наборов шифров. Каждый набор шифров определяет алгоритмы обмена ключами, проверки подлинности, шифрования и MAC, которые используются в сеансе SSL/TLS. При использовании RSA в качестве алгоритмов обмена ключами и проверки подлинности термин RSA отображается только один раз в соответствующих определениях набора шифров.

Поставщик Windows NT 4.0 Пакет обновления 6 Microsoft TLS/SSL security Provider поддерживает следующий SSL 3.0-определенный cipherSuite при использовании базового поставщика шифрования или расширенного поставщика шифрования:

SSL 3.0	Набор шифров
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
SSL_RSA_EXPORT1024_WITH_RC4_56_SHA

Ни SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA, ни SSL_RSA_EXPORT1024_WITH_RC4_56_SHA не определены в тексте SSL 3.0. Однако несколько поставщиков SSL 3.0 поддерживают их. Это относится к Корпорации Майкрософт.

Windows NT 4.0 Пакет обновления 6 Microsoft TLS/SSL Security Provider также поддерживает следующий TLS 1.0-определенный cipherSuite при использовании базового поставщика шифрования или расширенного поставщика шифрования:

TLS 1.0	Набор шифров
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

Набор шифров, определяемый с помощью первого 0x00, не является частным и используется для открытых интероперабельных коммуникаций. Поэтому поставщик Windows NT 4.0 Пакет обновления 6 Microsoft TLS/SSL Security Provider следует процедурам использования этих наборов шифров, как указано в SSL 3.0 и TLS 1.0, чтобы убедиться в возможности обеспечения связи.

Ключи реестра, определенные для Schannel

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

Любые изменения содержимого ключа CIPHERS или ключа HASHES вступает в силу немедленно, без перезапуска системы.

Ключ SCHANNEL

Начните редактор реестра (Regedt32.exe), а затем найдите следующий ключ реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Подкайка SCHANNEL\Protocols

Чтобы система мог использовать протоколы, которые не будут согласованы по умолчанию (например, TLS 1.1 и TLS 1.2), измените данные значения DWORD значения DisabledByDefault на 0x0 в следующих ключах реестра в ключе Протоколы:

SCHANNEL\Protocols\TLS 1.1\Client
SCHANNEL\Protocols\TLS 1.1\Server
SCHANNEL\Protocols\TLS 1.2\Client
SCHANNEL\Protocols\TLS 1.2\Server

Значение DisabledByDefault в ключе реестра в ключе Протоколы не имеет приоритета над значением grbitEnabledProtocols, которое определяется в структуре, содержаной данные учетных данных SCHANNEL_CRED Schannel.

Подкайка SCHANNEL\Ciphers

Ключ реестра шифров под ключом SCHANNEL используется для управления использованием симметричных алгоритмов, таких как DES и RC4. Ниже приводится допустимый ключ реестра под ключом Ciphers.

Создание подкайки шифров SCHANNEL в формате: SCHANNEL\(VALUE)\(VALUE/VALUE)

RC4 128/128

Подмышка шифров: SCHANNEL\Ciphers\RC4 128/128

Чтобы разрешить этот алгоритм шифра, измените данные значения DWORD значения включенного значения на 0xffffffff . Или измените данные значения DWORD на 0x0. Если не настроить значение Включено, включено значение по умолчанию. Этот ключ реестра не применяется к экспортируемом серверу, у него нет сертификата SGC.

Отключение этого алгоритма фактически отключит следующие значения:

SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA

Triple DES 168

Подмышка шифров: SCHANNEL\Ciphers\Triple DES 168

Чтобы разрешить этот алгоритм шифра, измените данные значения DWORD значения включенного значения на 0xffffffff . Или измените данные DWORD на 0x0. Если не настроить значение Включено, включено значение по умолчанию.

Отключение этого алгоритма фактически отключит следующие значения:

Для версий Windows, выпускаемой до Windows Vista, ключ должен быть Triple DES 168/168.

RC2 128/128

Подмышка шифров: SCHANNEL\Ciphers\RC2 128/128

Чтобы разрешить этот алгоритм шифра, измените данные значения DWORD значения включенного значения на 0xffffffff . В противном случае измените данные значения DWORD на 0x0. Если не настроить значение Включено, включено значение по умолчанию.

RC4 64/128

Подмышка шифров: SCHANNEL\Ciphers\RC4 64/128

Этот ключ реестра относится к 64-битной RC4. Он не применяется к экспортной версии (но используется в Microsoft Money).

RC4 56/128

Подмышка шифров: SCHANNEL\Ciphers\RC4 56/128

Этот ключ реестра относится к 56-битной RC4.

Чтобы разрешить этот алгоритм шифра, измените данные значения DWORD значения включенного значения на 0xffffffff. В противном случае измените данные значения DWORD на 0x0. Если не настроить значение Включено, включено значение по умолчанию.

Отключение этого алгоритма фактически отключит следующее значение:

RC2 56/128

Подмышка шифров: SCHANNEL\Ciphers\RC2 56/128

Этот ключ реестра относится к 56-битной RC2.

DES 56

Подмышка шифров: SCHANNEL\Ciphers\DES 56/56

Этот ключ реестра относится к 56-битной des, как указано в FIPS 46-2. Его реализация в Rsabase.dll и Rsaenh.dll проверяется в рамках программы проверки криптографического модуля FIPS 140-1.

Отключение этого алгоритма фактически отключит следующие значения:

SSL_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA

RC4 40/128

Подмышка шифров: SCHANNEL\Ciphers\RC4 40/128

Этот ключ реестра относится к 40-битной RC4.

Отключение этого алгоритма фактически отключит следующие значения:

SSL_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC4_40_MD5

RC2 40/128

Подмышка шифров: SCHANNEL\Ciphers\RC2 40/128

Этот ключ реестра относится к 40-битной RC2.

Отключение этого алгоритма фактически отключит следующие значения:

SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

NULL

Подмышка шифров: SCHANNEL\Ciphers\NULL

Этот ключ реестра не означает шифрования. По умолчанию он отключен.

Чтобы отключить шифрование (отключите все алгоритмы шифров), измените значение DWORD значения включенного значения на 0xffffffff . В противном случае измените данные значения DWORD на 0x0.

Hashes

Подмышка шифров: SCHANNEL/Hashes

Ключ реестра hashes под ключом SCHANNEL используется для управления использованием алгоритмов хеширования, таких как SHA-1 и MD5. Ниже приводится допустимый ключ реестра под ключом Hashes.

MD5

Подмышка шифров: SCHANNEL\Hashes\MD5

Чтобы разрешить этот алгоритм хаширования, измените данные значения DWORD значения Включено на значение по умолчанию 0xffffffff. В противном случае измените данные значения DWORD на 0x0.

Отключение этого алгоритма фактически отключит следующие значения:

SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

SHA

Подмышка шифров: SCHANNEL\Hashes\SHA

Этот ключ реестра относится к безопасному алгоритму хаша (SHA-1), как указано в FIPS 180-1. Его реализация в Rsabase.dll и Rsaenh.dll проверяется в рамках программы проверки криптографического модуля FIPS 140-1.

Отключение этого алгоритма фактически отключит следующие значения:

SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
SSL_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

KeyExchangeAlgorithms

Подмышка шифров: SCHANNEL/KeyExchangeAlgorithms

Ключ реестра KeyExchangeAlgorithms под ключом SCHANNEL используется для управления использованием ключевых алгоритмов обмена, таких как RSA. Ниже приводится допустимый ключ реестра в ключе KeyExchangeAlgorithms.

PKCS

Подмышка шифров: SCHANNEL\KeyExchangeAlgorithms\PKCS

Этот ключ реестра относится к RSA как к алгоритмам обмена ключами и проверки подлинности.

Чтобы разрешить RSA, измените данные значения DWORD значения Включено на значение по умолчанию 0xffffffff. В противном случае измените данные DWORD на 0x0.

Отключение RSA фактически отключит все шифры SSL и TLS на основе RSA, поддерживаемые Windows NT4 SP6 Microsoft TLS/SSL Security Provider.

Наборы шифров FIPS 140-1

Возможно, вам нужно использовать только те наборы шифров SSL 3.0 или TLS 1.0, которые соответствуют алгоритмам FIPS 46-3 или FIPS 46-2 и FIPS 180-1, предоставленным поставщиком шифрования Microsoft Base или Enhanced Cryptographic.

В этой статье мы называем их шифрами FIPS 140-1. В частности, они являются следующими:

SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA

Чтобы использовать только наборы шифров FIPS 140-1, как определено здесь, и поддерживаемые Windows NT 4.0 Пакет обновления 6 Поставщик безопасности Microsoft TLS/SSL с базовым криптографическим поставщиком или расширенным криптографическим поставщиком, настройте данные значения DWORD значения Включено в следующих ключах реестра для 0x0:

SCHANNEL\Ciphers\RC4 128/128
SCHANNEL\Ciphers\RC2 128/128
SCHANNEL\Ciphers\RC4 64/128
SCHANNEL\Ciphers\RC4 56/128
SCHANNEL\Ciphers\RC2 56/128
SCHANNEL\Ciphers\RC4 40/128
SCHANNEL\Ciphers\RC2 40/128
SCHANNEL\Ciphers\NULL
SCHANNEL\Hashes\MD5

И настройте данные значения DWORD значения Включено в следующих ключах реестра для 0xffffffff:

SCHANNEL\Ciphers\DES 56/56
SCHANNEL\Ciphers\Triple DES 168/168 (не применяется в экспортной версии)
SCHANNEL\Hashes\SHA
SCHANNEL\KeyExchangeAlgorithms\PKCS

Master secret computation by using FIPS 140-1 cipher suites

Процедуры использования шифров FIPS 140-1 в SSL 3.0 отличаются от процедур использования шифров FIPS 140-1 в TLS 1.0.

В SSL 3.0 ниже приводится определение master_secret вычислений:

В TLS 1.0 ниже приводится определение master_secret вычислений:

Выбор варианта использования только шифров fiPS 140-1 в TLS 1.0:

Из-за этой разницы клиентам может потребоваться запретить использование SSL 3.0, даже если разрешенный набор наборов шифров ограничен только подмножество шифров fips 140-1 suites. В этом случае измените значение DWORD значения включенного значения на 0x0 в следующих ключах реестра в ключе Протоколы:

SCHANNEL\Protocols\SSL 3.0\Client
SCHANNEL\Protocols\SSL 3.0\Server

Данные включенного значения в этих ключах реестра в ключе Протоколы имеют приоритет над значением grbitEnabledProtocols, которое определяется в структуре, содержаной данные для учетных данных SCHANNEL_CRED Schannel. По умолчанию включено значение 0xffffffff.

В этой статье приводится информация о завершении поддержки Windows Server 2008 и Windows Server 2008 R2.

Применяется к: Windows Server 2012 R2
Исходный номер КБ: 4456235

Summary

Windows Server 2008 and Windows Server 2008 R2 are approaching the end of their support lifecycle. This means that as of the dates in the table below there will be no additional:

Free security updates on-premises
Non-security updates
Free support options
Online technical content update

Customers who use Windows Server 2008 or Windows Server 2008 R2 products and services should migrate to Microsoft Azure to take advantage of three additional years of Critical and Important security updates at no additional charge and modernize when ready. For environments other than Azure, we recommend customers upgrade to the latest version before the deadline. For customers who cannot meet the end-of-support deadline may purchase Extended Security Updates to keep server workloads protected until they upgrade (some restrictions apply).

More information

The following Windows Server 2008 and 2008 R2 products are approaching End of Support:

Product	End of Extended Support
Windows Server 2008 Datacenter	1/14/2020
Windows Server 2008 Datacenter without Hyper-V	1/14/2020
Windows Server 2008 Enterprise	1/14/2020
Windows Server 2008 Enterprise without Hyper-V	1/14/2020
Windows Server 2008 for Itanium-Based Systems	1/14/2020
Windows Server 2008 Foundation	1/14/2020
Windows Server 2008 R2 Datacenter	1/14/2020
Windows Server 2008 R2 Enterprise	1/14/2020
Windows Server 2008 R2 for Itanium-Based Systems	1/14/2020
Windows Server 2008 R2 Standard	1/14/2020
Windows Server 2008 Standard	1/14/2020
Windows Server 2008 Standard without Hyper-V	1/14/2020

We recommend that you migrate to Azure or upgrade to the current product versions before the support end dates. This lets you take advantage of the latest product innovations and make sure you have uninterrupted support from Microsoft.

The following Server products are NOT eligible for Extended Security Updates.

Product	End of Extended Support
Microsoft Hyper-V Server 2008	1/14/2020
Microsoft Hyper-V Server 2008 R2	1/14/2020
Windows HPC Server 2008	4/14/2020
Windows HPC Server 2008 R2	4/14/2020
Windows HPC Server 2008 without Hyper-V	4/14/2020
Windows Server Update Services 3.0	7/14/2009
Windows Server Update Services 3.0 SP1	10/12/2010
Windows Server Update Services 3.0 SP2	1/14/2020
Windows Storage Server 2008 Basic	1/14/2020
Windows Storage Server 2008 Basic 32-bit	1/14/2020
Windows Storage Server 2008 Basic Embedded	1/14/2020
Windows Storage Server 2008 Basic Embedded 32-bit	1/14/2020
Windows Storage Server 2008 Enterprise	1/14/2020
Windows Storage Server 2008 Enterprise Embedded	1/14/2020
Windows Storage Server 2008 R2	1/14/2020
Windows Storage Server 2008 R2 Essentials	1/14/2020
Windows Storage Server 2008 Standard	1/14/2020
Windows Storage Server 2008 Standard Embedded	1/14/2020
Windows Storage Server 2008 Workgroup	1/14/2020
Windows Storage Server 2008 Workgroup Embedded	1/14/2020

Resources

Migration assistance with the Azure Migration and Modernization Center

The Azure Migration and Modernization Center has a full range of tools available to help you assess your current on-premises environment, migrate your workloads onto Azure, and optimize your Azure usage to best suit your needs. Microsoft also works with many Partners, who are available to help you at every step of the journey.

В прошлой публикации про POODLE-уязвимость я упустил из виду сервера, работающие на ОС Windows, сконцентрировавшись на юниксовом программном обеспечении.
Но судя по статистике популярности веб-серверов Microsoft-IIS занимает 13,5%, и третью строчку в тройке лидеров, оставляя далеко позади все остальные веб-серверы.

И в комментариях никто не обратил внимание на досадное упущение и я исправляюсь этой статьей.
Информация актуальна для Windows Server 2008 и IIS 7.5.

UPD: Хабраюзер Ivan_83 ранее рассмотрел более широко в своей статье аспекты повышения безопасности на Windows 7, что так же применимо к другим версиям Windows.

Все изменения будут проводиться в реестре, поэтому первым делом следует сделать его резервную копию:
запустить редактор реестра regedit -> Файл -> Экспорт

После того, как резервная копия сделана, приступим непосредственно к внесению изменений в реестр для отключения SSLv2 и включения TLS.

Отключение SSLv2/SSLv3
В редакторе реестра следует перейти в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server
В случае, если раздел Server отсутствует, его необходимо создать.
После чего создайте параметр DWORD (32 бита) с названием «Enabled» и значением 0

То же самое повторите для раздела Client
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client

Для отключения SSLv3 повторите процедуру для раздела SSL 3.0.

Включение TLS
Включение алгоритма шифрования TLS происходит по схожему сценарию.
С помощью редактора реестра regedit перейдите в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
И создайте раздел TLS 1.1 и внутри него подразделы Client и Server
Так же, как и при отключении SSLv2, создайте два параметра DWORD (32 бита): с названием «Enabled» и значением 1; и с названием DisabledByDefault и значением 0.

Сканер уязвимостей TrustWave не выполняет сканирование из-за компьютера с Windows 10, на котором запущен RDP:

Алгоритмы блочного шифрования с размером блока 64 бита (например, DES и 3DES), день рождения, известный как Sweet32 (CVE-2016-2183)

ПРИМЕЧАНИЕ. В системах Windows 7/10 с RDP (протокол удаленного рабочего стола) уязвимый шифр, который следует отключить, помечен как «TLS_RSA_WITH_3DES_EDE_CBC_SHA».

Используя IIS Crypto (от Nartac), я попытался применить шаблон «Best Practices», а также шаблон PCI 3.1, однако оба они включают небезопасный шифр (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

Если я отключу этот шифр, RDP с этого компьютера на многие станции Windows перестанет работать (он все еще работает на некоторых серверах 2008 R2 и 2012 R2). RDP-клиент просто выдает «Произошла внутренняя ошибка» и журнал событий:

При создании учетных данных клиента TLS произошла неустранимая ошибка. Состояние внутренней ошибки 10013.

Запрос на подключение TLS 1.2 был получен от удаленного клиентского приложения, но ни один из наборов шифров, поддерживаемых клиентским приложением, не поддерживается сервером. Запрос на соединение SSL не выполнен.

Было сгенерировано следующее фатальное предупреждение: 40. Состояние внутренней ошибки - 1205.

Или, если описанное выше невозможно, могу ли я что-то сделать на каждом узле RDP, к которому я больше не могу подключиться, и обработать его на этом конце?

--- Обновление № 1 ---

После отключения TLS_RSA_WITH_3DES_EDE_CBC_SHA на компьютере с Windows 10 я попытался подключиться к нескольким узлам RDP (половина из них завершилась с ошибкой «Внутренняя ошибка . »). Поэтому я сравнил один из этих хостов, к которому я могу подключиться, с тем, к которому я не могу подключиться. Оба 2008 R2. Оба имеют одинаковую версию RDP (6.3.9600, поддерживается протокол RDP 8.1).

Я сравнил протоколы и шифры TLS с помощью IIS Crypto, чтобы выполнить «Сохранить шаблон» в их текущих настройках, чтобы я мог сравнить файлы шаблонов. Они были идентичны! Так что, какая бы проблема ни была, похоже, это не проблема отсутствующего набора микросхем на хосте. Вот скриншот из Beyond Compare по файлам:

Можете ли вы использовать NetMon или Wireshark для захвата приветствия клиента / сервера, чтобы увидеть, о каком наборе шифров на самом деле идет речь при сбое соединения, а не об успешном? @RyanRies: Уже сделал, но это никогда не добирается до фактического рукопожатия TLS. Клиент отправляет пакет «TPKT, продолжение», а сервер отвечает «RST, ACK».

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

Чтобы сделать то, что вы хотите, я бы лично пошел со следующим:

Применить шаблон 3.1
Оставьте все наборы шифров включенными
Применить как к клиенту, так и к серверу (флажок установлен).
Нажмите «Применить», чтобы сохранить изменения

Перезагрузите здесь, если хотите (и у вас есть физический доступ к машине).

Применить шаблон 3.1
Оставьте все наборы шифров включенными
Применить к серверу (флажок снят).
Снимите флажок с опции 3DES

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

По сути, вы хотите только отключить входящий 3DES, но разрешить исходящее использование указанного набора шифров.

Это звучит многообещающе! Однако отключение 3DES 168, похоже, было ошибкой - я больше не могу подключиться к нему. После того, как я справлюсь с этим, я попытаюсь просто отключить шифр только на стороне сервера и доложить / принять ответ. Я попробовал ваше предложение: 1) Примените «Рекомендации» и примените к серверу и клиенту, затем 2) Снимите флажок с шифра TLS_RSA_WITH_3DES_EDE_CBC_SHA и «Установите протоколы на стороне клиента» и примените снова, затем, конечно, перезагрузите компьютер. Проблема RDPing от этой машины все еще сохраняется. Дополнительные предложения приветствуются. @ Зек странный . Я использовал ту же самую технику, и она работает. @Zek Я только что понял, что сделал большую ошибку в том, как написал это. Я обновлю соответственно. Я попробовал это. 1) Выберите шаблон 3.1 + оставьте все комплекты шифров без изменений + «Установить протоколы на стороне клиента» + проверьте TLS 1.0 (SQL и т. Д. Обрывы без TLS 1.0) + Применить и перезагрузить. 2) Выберите шаблон 3.1 + оставьте все комплекты шифров без изменений + "Установить протоколы на стороне клиента", не снимайте флажок + снимите флажок 3DES + отметьте TLS 1.0 + Применить и перезагрузить. Я больше не могу подключиться, «произошла внутренняя ошибка» (я думаю, что сервер должен поддерживать 3DES). Я подключаюсь с компьютера с Windows 10.

У меня была такая же проблема, установка патча KB3080079 на сервере позволяет поддерживать tls 1.1 и 1.2.

Обратите внимание, что для клиентов Windows 7 вам нужно будет установить обновление клиента rdp (KB2830477), иначе только Windows 8+ сможет подключиться.

Я просто дважды проверил, и эти обновления уже установлены (я думаю, что они уже включены в стандартное обновление Windows уже некоторое время), так что это не проблема.

Поделюсь ответ от TechNet нити , но первого BLUF:

Вывод о сбое сервера: Скорее всего, у вас есть другое различие между системами. Вы подключаетесь между разными версиями ОС, в одной системе включена поддержка FIPS, а в другой нет, или в вашей системе действуют другие ограничения шифрования HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers . Я бы определенно включил протоколирование SCHANNEL в системе, которая работает, чтобы определить, какой шифр используется. Хотелось бы получить ответ, если бы вы каким-то образом заставили RDP работать с альтернативным шифром.

Мы получили это на работу!

Очевидно, что в 2008 и 2012 годах есть синтаксические проблемы, а в 2008/7 требуется трейлинг / 168. 2012 / 8.1 / 10 нет.

ключ на 2008 выглядит так: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

И ключ на 2012 год выглядит так: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

Я могу подтвердить, что использование «Triple DES 168/168» НЕ отключает 3DES в системе. Вы можете доказать это себе с помощью сканера протокола (например, Nessus) или включив ведение журнала SCHANNEL:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007

Тогда у вас будут события в журнале SYSTEM, например;

Рукопожатие клиента SSL успешно завершено. Согласованные криптографические параметры заключаются в следующем.

Протокол: TLS 1.0 CipherSuite: 0x2f Сила обмена: 1024

Для меня результат 0xa, который Google показывает как TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Когда я использую «Triple DES 168» (без / 168), системный идентификатор события 36880 не появляется и сеанс RDP блокируется.

Службы удаленных рабочих столов (RDS) Для шифрования сетевого взаимодействия Служб удаленных рабочих столов этот параметр политики поддерживает только алгоритм шифрования Triple DES.

Таким образом, оба из них поддерживают идею, что RDP может использовать только 3DES. Тем не менее, эта статья предлагает более широкий спектр шифров: FIPS 140 Validation

В конечном счете, неясно, может ли RDP поддерживать протоколы не 3DES, когда включен режим FIPS, но свидетельства предполагают, что это не так.

Я не вижу доказательств того, что Server 2012 R2 будет функционировать иначе, чем Server 2008 R2, однако, похоже, что Server 2008 R2 основан на соответствии FIPS 140-1, а Server 2012 R2 следует FIPS 140-2, поэтому вполне возможно, что Server 2012 R2 поддерживает дополнительные протоколы. Вы заметите дополнительные протоколы в ссылке FIPS 140 Validation .

В заключение: я не думаю, что Server 2008 R2 может поддерживать RDP в режиме FIPS с отключенным 3DES. Я рекомендую выяснить, соответствует ли ваша система условиям для атаки SWEET32 (более 768 ГБ отправлено за один сеанс) и стоит ли отключать 3DES, чтобы исключить возможность RDP. Существуют и другие утилиты для управления серверами за пределами RDP, особенно в мире, где виртуализация широко распространена.

Читайте также: