Як відключити TLS 1.0, не порушуючи RDP?


48

Нещодавно наш процесор кредитних карток повідомив, що станом на 30 червня 2016 року нам потрібно буде відключити TLS 1.0, щоб залишатися сумісними з PCI . Я намагався бути активним, відключивши TLS 1.0 на нашій машині Windows Server 2008 R2, лише щоб виявити, що одразу після перезавантаження я повністю не зміг підключитися до нього через протокол віддаленого робочого столу (RDP). Після деяких досліджень виявляється, що RDP підтримує лише TLS 1.0 (див. Тут або тут ), або, принаймні, не зрозуміло, як включити RDP через TLS 1.1 або TLS 1.2. Хтось знає спосіб відключити TLS 1.0 на Windows Server 2008 R2, не порушуючи RDP? Чи планує Microsoft підтримку RDP для TLS 1.1 або TLS 1.2?

Примітка. Схоже, існує спосіб зробити це шляхом налаштування сервера на рівень безпеки RDP, але це відключає автентифікацію мережевого рівня , що здається торгуючи одним злом для іншого.

ОНОВЛЕННЯ 1 : Microsoft вирішила цю проблему. Дивіться відповідь нижче щодо відповідного оновлення сервера.

ОНОВЛЕННЯ 2 : Microsoft випустила підручник щодо підтримки SQL Server для PCI DSS 3.1 .


Вибачте всім - інструкції, які я опублікував, дійсні лише для Win8 / Server2012 / 2012R2 ... вони не працюють у 2008R2 / Win7. Я тестував 2008R2, і це не те саме. Мені шкода.
Райан Райс

І зауважте, що у 2012 році, як згадується, видалення TLS 1.0 змушує RDP переходити на рівень безпеки RDP.
Джим Б

Я зробив те саме, і не можу потрапити на свій сервер (AWS), чи змогли ви зрозуміти спосіб потрапити без фізичного доступу?
Томас Пайн

1
Відповідно до цієї статті підтримки Microsoft нещодавно виправляла SQL 2012 та 2014 для роботи з TLS 1.1 та 1.2 support.microsoft.com/en-us/kb/3052404
CarlR

1
@CarlR ця стаття, схоже, не конкретно згадує RDP'ing на сервері. Насправді це, мабуть, є специфічним для самого підключення до бази даних, як згадується: "Це оновлення додає підтримку протоколу протоколу безпеки транспортного рівня (TLS) версії 1.2 до SQL Server 2014 та драйвера Microsoft ODBC для SQL Server."
k1DBLITZ

Відповіді:


19

Microsoft випустила патч для цієї проблеми 15 вересня 2015 року

Дивіться https://support.microsoft.com/en-us/kb/3080079


Дякую дуже корисно. Після встановлення цього оновлення на екрані tsconfig.msc не відображаються ознаки TLS 1.1 або TLS 1.2. Хтось зміг підтвердити, що ви підключаєтесь до сервера за допомогою RDP через TLS 1.2? Я знаю, що ми можемо перевірити, відключивши ранній протокол TLS на сервері. Але якщо це не працює, ви взагалі не можете віддалено використовувати RDP до сервера.
Нірлеп

Цілком можливо, що коли ви виберете варіант "Переговори", він передасть найвищий рівень, який може бути TLS 1.2
Nirlep

1
Ви можете ввімкнути реєстрацію schannel, щоб побачити, яка версія використовується. Посилання про те, як це зробити, показано у моїй відповіді.
CarlR

Я знаю, що це стара нитка, але ... У мене старший Windows Server 2008 R2, який я піднімаю до нюху. Я встановив KB3080079 і тепер відключить TLS 1.0. Але я не впевнений, чи слід встановити параметр сервера RDP на "Переговори" або на "TLS".
Кріс Харрінгтон

15

Я розглядаю це вже пару днів, оскільки нам потрібно дотримуватися PCI-DSS 3.1, який вимагає відключення TLS 1.0.

Ми також не хочемо повертатися до рівня безпеки RDP, що є головним питанням безпеки.

Нарешті мені вдалося знайти документацію, яка підтверджує, що TLS 1.1 та TLS 1.2 ARE підтримуються RDP. Ця документація прихована в протоколі SChannel та дуже детальній специфікації для RDP .

Існує повна відсутність документації на основний потік на Technet або інших сайтах Майкрософт, мабуть, настільки, сподіваємось, документування цього тут може допомогти деяким людям.

Відповідні витяги із наданих посилань:

За посиланням MSDN:

"RDP supports four External Security Protocols: TLS 1.0 ([RFC2246]) TLS 1.1 ([RFC4346])<39>, TLS 1.2 ([RFC5246])<40>"

З специфікації PDF RDP:

"When Enhanced RDP Security is used, RDP traffic is no longer protected by using the techniques
described in section 5.3. Instead, all security operations (such as encryption and decryption, data
integrity checks, and Server Authentication) are implemented by one of the following External
Security Protocols:
TLS 1.0 (see [RFC2246])
TLS 1.1 (see [RFC4346])
TLS 1.2 (see [RFC5246])
CredSSP (see [MS-CSSP])"

"<39> Section 5.4.5: TLS 1.1 is not supported by Windows NT, Windows 2000 Server, Windows XP,
Windows Server 2003, Windows Vista and Windows Server 2008.
<40> Section 5.4.5:  TLS 1.2 is not supported by Windows NT, Windows 2000 Server, Windows XP,
Windows Server 2003, Windows Vista, and Windows Server 2008"

Тому можна зробити висновок, що ви можете використовувати TLS 1.1 або 1.2 на Windows Server 2008 R2 відповідно до цієї документації.

Однак наше тестування довело, що це не працює з клієнтом RDP для Windows 7 (версія 6.3.9600), коли TLS 1.0 вимкнено, а для параметра захисту RDP встановлено необхідність використання TLS 1.0.

Це, звичайно, також дозволяє включити TLS 1.1 і 1.2, які за замовчуванням вимкнено на 2008R2 - ми, до речі, це робимо за допомогою дуже корисного інструмента криптоінформації IIS від Nartac Software .

При перегляді цього питання корисно ввімкнути ведення журналу SChannel, щоб побачити докладніші відомості про те, що відбувається під час відкриття сеансу.

Ви можете встановити журнал SChannel , змінивши клавішу HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ EventLogging на 5 та перезавантажившись.

Після цього ви зможете спостерігати події SChannel, які показують, що версія TLS використовується під час з'єднання RDP. Після ввімкнення журналу ви можете помітити помилку SChannel, коли клієнт RDP намагається встановити з'єднання в Windows 2008 R2 з відключеним TLS 1.0:

A fatal error occurred while creating an SSL server credential. The internal error state is 10013.

Я також перевірив відключення TLS 1.0 на Windows Server 2012 та 2012 R2, і я можу підтвердити, що він ідеально працює за допомогою клієнта RDP Windows 7. Запис журналу SChannel показує, що TLS 1.2 використовується:

An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows.

   Protocol: TLS 1.2
   CipherSuite: 0xC028
   Exchange strength: 256

Я сподіваюся, що це допоможе тому, хто шукає роз'яснення з цього приводу.

Я продовжуватиму шукати, як ми можемо змусити RDP працювати над TLS 1.1 та TLS 1.2 у Windows Server 2008 R2.

ОНОВЛЕННЯ: 2015-серпня-05

Ми порушили питання про те, що RDP не працює з Server 2008 R2 з підтримкою Microsoft, включаючи кроки для відтворення.

Через кілька тижнів назад і вперед ми сьогодні нарешті отримали телефонний дзвінок від служби підтримки, щоб визнати, що вони дійсно могли його відтворити, і тепер це віднесено до помилок. Патч оновлень буде випущений, на даний момент це очікується в жовтні 2015 року. Як тільки у мене з’явиться стаття KB або інші деталі, я додам їх до цієї публікації.

Сподіваємося, що ті, хто застряг у Windows Server 2008 R2, зможуть принаймні вирішити це питання до закінчення червня 2016 року після виходу патча.

ОНОВЛЕННЯ: 19 вересня 2015 року

Microsoft нарешті -то випустила підтримку кб статтю про це тут , і я можу підтвердити , що він працює нормально.


Ваше останнє оновлення говорить: "Я спробував Windows 7 та Windows 2012 r2, і він не працює; він все ще підключається за допомогою TLS1." Ви коли-небудь змогли змусити це працювати?
Doug S

Хтось ще вклав цей коментар, я щойно видалив його, оскільки він працює добре для нас зараз через TLS1.2.
CarlR

Хммм. Мені ніколи не вдалося змусити його працювати, навіть із цими змінами / оновленнями та всім іншим, що я міг знайти.
Doug S

Журнал SChannel можна знайти в системному журналі.
Іван Чау

8

Замість цього використовуйте IPsec, як рекомендується в документі: "Налаштування спочатку сильно зашифрованого сеансу (наприклад, тунель IPsec), потім передача даних через SSL у захищеному тунелі"

Основна причина цього робити при налаштуванні TLS для RDP полягає в тому, що політика брандмауера легко перевіряється на відповідність (проти доведення помилок змін у реєстрі), а IPsec досить легко налаштувати у Windows.

Якщо вам потрібен повний пакет B, відповідність IPSEC з tls 1.0 - це єдиний доступний спосіб застосувати відповідні тривалості сертифікатів


Тунелювання через SSH - це також варіант, про який я згадаю. (Звичайно, потрібне серверне програмне забезпечення SSH для Windows.)
Chris W. Rea

IPsec не SSH
Jim B

3
Правильно, і я не мав на увазі, що вони однакові. Швидше, SSH - це альтернативний метод встановлення захищеного тунелю до сервера.
Кріс В. Реа

@JimB Вибачте, ви мали рацію.
Райан Райс

1
@RyanRies Np, я все ще чухаю голову, як 12 інших проголосували б за нього, не знаючи, що це працює.
Джим Б

8

Це не відповідь на питання, а на підпитання "Як відновити віддалений доступ до віртуальної машини, де я відключив TLS 1.0 і не мав фізичного доступу?".

Я відключив TLS 1.0 за допомогою IISCrypto, який дав корисне попередження про побічний ефект, що RDP перестане працювати, якщо він встановлений на TLS. Тому я зареєструвався:

Admin Tools\Remote Desktop Services\Remote Desktop Session Host Configuration, RDP-Tcp, General Tab, Security Layer

і для мого рівня безпеки було встановлено "Переговори". Я припускав, що це означає, що якщо TLS недоступний, він виграшно перейде на безпеку RDP.

Але ні, переговори не так працюють. Перш ніж вимкнути TLS 1.0, ви повинні встановити рівень безпеки на RDP Security, а не на переговори.

Так я втратив здатність віддаленого підключення до мого екземпляра AWS!

Для відновлення зв’язку я використав інший екземпляр AWS.

  1. Я оновив SecurityGroup, щоб дозволити підключення брандмауера з цієї машини до моєї "втраченої" машини.
  2. Я відкрив загальну частку адміністративної мережі в DOS з користувачем адміністратором та паролем:

net use \\lost_machine_ip\c$

  1. Потім я відкрив Regedit і в меню Файл виберіть "Підключити мережевий реєстр" і введіть IP-адресу "загубленого" сервера. Ви повинні побачити реєстр віддаленого сервера. Йти до :

\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\

і встановіть значення для SecurityLayer0 (0 - RDP Security).

Після цього ви зможете віддалено підключитися та при необхідності повторно ввімкнути TLS 1.0 у IISCrypto.


Дякую, це врятувало мені багато роботи з відтворення сервера. Не впевнений, як ви змінили групу безпеки, щоб дозволити з'єднання між машинами --- я відкрив весь доступ "загубленого" машини до IP-адреси другої машини, і це спрацювало. Чи є кращий спосіб?
Гулбірд

@Gullbyrd або це, або встановити ВСІ TCP групі безпеки, до якої належать обидва машини. Робить те саме.
Dave Beer

3

Вам потрібно буде встановити RDP 8.0 на своїх комп'ютерах Windows 7 та серверах Windows Server 2008 R2, а потім увімкнути RDP 8.0 в локальній комп'ютерній політиці або груповій політиці.

Ось Microsoft KB для RDP 8.0. https://support.microsoft.com/en-us/kb/2592687

Після цього ви зможете вимкнути TLS 1.0 на комп’ютерах та серверах, відредагувавши реєстр відповідно до інструкцій у цій статті про техніку. https://technet.microsoft.com/en-us/library/dn786418.aspx

Після установки RDP 8.0 ви також можете встановити RDP 8.1, але RDP 8.0 повинен бути встановлений до встановлення RDP 8.1. RDP 8.0 містить як клієнтські, так і компоненти серверного протоколу, але RDP 8.1 включає лише клієнта. Microsoft KB для RDP 8.1 - KB2830477.

Я вніс ці зміни на одній з моїх робочих станцій Windows 7 і протестував RDP-з'єднання з "Потрібно використовувати специфічний рівень безпеки для віддалених (RDP) з'єднань" Налаштування групової політики увімкнено та встановлено на "SSL (TLS 1.0)", щоб переконатися, що це не повернеться до шифрування RDP.

ОНОВЛЕННЯ 19.06.2015:

Нарешті я отримав шанс протестувати це на одному з наших серверів Windows Server 2008 R2, і він безумовно розриває з'єднання RDP з сервером. Схоже, компоненти сервера RDP 8.0 встановлені лише на комп’ютерах Windows 7 і не встановлюються на сервери Windows Server 2008 R2.


Стаття бази знань про підтримку, на яку посилається, наразі не працює (цикл переадресації), проте ви можете використовувати кеш-версію Google, щоб переглянути вміст. Цікаво, що у цій статті досі абсолютно не згадується про підтримку TLS 1.1 або 1.2, але все ж я здогадуюсь, що це головна причина, коли хтось буде дивитись на це питання! Існує також велика кількість застережень, включаючи місцевих адміністраторів, які більше не можуть входити в систему, якщо спеціально не додано до групи користувачів віддаленого зупинки. Слідкуйте, чи намагаєтесь ви це.
CarlR

Ви відкрили порт 3389 UDP на сервері під час спроби підключення до сервера 2008?
Ельвар

Я пішов так далеко, щоб тимчасово повністю відключити Брандмауер Windows на сервері сервера 2008 R2, але я все одно не зміг підключитися до нього за допомогою RDP з відключеним TLS 1.0 на сервері.
Kenny R

3

Як розміщено в розділі Як відключити TLS 1.0, не порушуючи RemoteApps на сервері 2012 R2, але репостуючи тут, на користь тих, хто може не контролювати це посилання:

Через майже рік я нарешті придумав робоче рішення щодо відключення TLS 1.0 / 1.1 без порушення RDP та віддалених служб на робочому столі та запуску RemoteApps:

Запустіть IISCrypto та відключіть TLS 1.0, TLS 1.1 та всі погані шифри.

На сервері віддалених служб робочого столу, який виконує роль шлюзу, відкрийте локальну політику безпеки та перейдіть до Параметри безпеки - Системна криптографія: Використовуйте алгоритми, сумісні з FIPS, для шифрування, хешування та підпису. Змініть налаштування безпеки на Увімкнено. Перезавантажте, щоб зміни вступили в силу.

Зауважте, що в деяких випадках (особливо, якщо на сервері 2012 R2 використовуються сертифікати, що підписуються самостійно), можливо, потрібно встановити параметр Політики безпеки Мережева безпека: рівень автентифікації локального менеджера LAN повинен бути встановлений лише для надсилання відповідей NTLMv2.


2

Просто оновлення цього питання, якщо хтось інший шукає інформацію про нього. Для моїх 64-розрядних вікон Windows 7 мені довелося встановити KB2574819 (перший) та KB2592687 (другий). У Windows 7 повинен бути встановлений SP1, перш ніж встановити ці 2 pkgs. Якщо у вас виникли проблеми з установкою SP1, як у мене, мені спочатку довелося видалити KB958830, а потім встановити SP1.

Для своїх ящиків для Windows Server 2008 R2 мені довелося встановити KB3080079. Після того, як ви зробите це і буде встановлено всі відповідні настройки для безпечного зв’язку, тоді він використовуватиме TLS 1.2. Ви можете підтвердити, використовуючи Wireshark, щоб здійснити захоплення зв'язку між вашими двома полями.



0

Один випадок, не охоплений існуючими відповідями: клієнти Windows 7, що підключаються через шлюз RDP, все одно використовуватимуть TLS 1.0 під час підключення до шлюзу і не спрацьовують, якщо шлюз не підтримує TLS 1.0, навіть після застосування KB3080079 , як це спостерігається в цьому потоці форуму TechNet .

Щоб використовувати TLS 1.2 для підключення через шлюз RDP, переконайтесь, що KB3140245 встановлений та додайте наступні ключі реєстру (збережіть у файлі з .regрозширенням для імпорту):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800

Як задокументовано в KB3140245 , це буде замінити WINHTTP_OPTION_SECURE_PROTOCOLSвикористання TLS 1.2 (і лише TLS 1.2) за замовчуванням. Тож майте на увазі, що це вплине не тільки на клієнта RDP.

(Примітка. Якщо потрібна зворотна сумісність, dword:00000800її можна змінити на dword:00000A00або dword:00000A80включити TLS 1.1 та 1.0 відповідно)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.