Удаление уязвимого шифра в Windows 10 нарушает исходящий RDP

Сканер уязвимостей 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?

Или, если описанное выше невозможно, могу ли я что-то сделать на каждом узле 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 по файлам:

Что может отличаться между двумя узлами RDP, что вызывает эту проблему и как ее исправить?

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

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

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

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

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

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

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

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

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

Редактирование (2018-09-26): я обнаружил, что отключение 3DES на 2012R2 НЕ нарушает RDP, но на 2008 R2. Поддерживаемые параметры в ядрах разные.

Поделюсь ответ от 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 блокируется.

По статье: Системная криптография: используйте FIPS-совместимые алгоритмы для шифрования, хеширования и подписи.

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

В статье: «Системная криптография: использовать FIPS-совместимые алгоритмы для шифрования, хэширования и подписывания» эффекты настройки безопасности в Windows XP и в более поздних версиях Windows

Этот параметр также влияет на службы терминалов в Windows Server 2003 и более поздних версиях Windows. Эффект зависит от того, используется ли TLS для аутентификации сервера.

Если TLS используется для проверки подлинности сервера, этот параметр вызывает использование только TLS 1.0.

По умолчанию, если TLS не используется, и этот параметр не включен на клиенте или на сервере, канал протокола удаленного рабочего стола (RDP) между сервером и клиентом шифруется с использованием алгоритма RC4 с 128-разрядным длина ключа. После включения этого параметра на компьютере под управлением Windows Server 2003 выполняется следующее: Канал RDP шифруется с использованием алгоритма 3DES в режиме Cipher Block Chaining (CBC) с длиной ключа 168 бит. Алгоритм SHA-1 используется для создания дайджестов сообщений. Клиенты должны использовать клиентскую программу RDP 5.2 или более позднюю версию для подключения.

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

Набор криптографических алгоритмов, которые будет использовать сервер протокола удаленного рабочего стола (RDP), предназначен для: - CALG_RSA_KEYX - алгоритма обмена открытым ключом RSA - CALG_3DES - алгоритма шифрования Triple DES - CALG_AES_128 - 128-битного AES - CALG_AES_256 - 256-битного AES - CALG_S Алгоритм хеширования SHA - CALG_SHA_256 - Алгоритм хеширования 256 битов - CALG_SHA_384 - Алгоритм хеширования 384 битов - CALG_SHA_512 - Алгоритм хеширования SHA 512

В конечном счете, неясно, может ли 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, особенно в мире, где виртуализация широко распространена.

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

ключ 2008 года выглядит следующим образом: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ Triple DES 168/168

** Замечательно, что у меня была точно такая же проблема на некоторых контроллерах домена Windows 2008 R2, как ни странно, мои рядовые серверы 2008R2 кажутся нормальными ... и мои серверы 2012R2 также работают нормально. Нужно взломать на разложении тех старых ДК :)