Видалення вразливого шифру в 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), я спробував застосувати шаблон "Кращі практики", а також шаблон PCI 3.1, однак обидва вони включають незахищений шифр (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

Якщо я відключу цей шифр, RDP з цього комп’ютера на багатьох станціях Windows припиняє роботу (він все ще працює на деяких серверах R2 2008 та 2012 R2 2008). Клієнт 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, підтримується протокол 8.1 RDP).

Я порівнював протоколи та шифри TLS, використовуючи криптовалюту IIS, щоб зробити "Зберегти шаблон" за їх поточними налаштуваннями, щоб я міг порівняти файли шаблонів. Вони були однакові! Отже, що б не було питання, схоже, це не є відсутнім набором чіперів для хоста. Ось знімок екрана з програми "Більше порівняння" у файлах:

Що може відрізнятися між двома хостами 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, але НЕ порушує R2 2008 року. Можливо, підтримувані параметри відрізняються між ядрами.

Поділюся відповідь від 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

Потім у вас відбудуться події в журналі СИСТЕМИ;

Рукостискання з клієнтом 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 Валідація

Набір криптографічних алгоритмів, якими буде користуватися сервер протоколу віддаленого робочого столу (RDP), охоплюється таким чином: Алгоритм хешування SHA - CALG_SHA_256 - 256-бітний алгоритм хешування SHA - CALG_SHA_384 - алгоритм хешування SHA 384 біт - CALG_SHA_512 - алгоритм хешування 512 бітного SHA

Зрештою, не ясно, чи може RDP підтримувати протоколи не 3DES, коли включений режим FIPS, але дані свідчать, що це не так.

Я не бачу доказів того, що Server 2012 R2 функціонував би інакше, ніж Server 2008 R2, однак, схоже, що сервер 2008 R2 базувався на відповідності FIPS 140-1, а сервер 2012 R2 дотримувався FIPS 140-2, тому цілком можливо, що сервер 2012 р2 підтримує додаткові протоколи. Додаткові протоколи ви помітите у посиланні 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 також добре працюють. Потрібно зламати декомпозицію тих старих DC :)