Edycja (26.09.2018): Odkryłem, że wyłączenie 3DES na 2012R2 NIE psuje RDP, ale JEST psuje się na 2008 R2. Obsługiwane opcje wydają się różnić w zależności od jądra.
Podzielę się odpowiedzią z wątku TechNet, ale najpierw BLUF:
Wniosek dotyczący błędu serwera: najprawdopodobniej masz inną różnicę między systemami. Łączysz różne wersje systemu operacyjnego, jeden system ma włączoną obsługę FIPS, a drugi nie, lub obowiązują inne ograniczenia szyfrowania HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. Z pewnością pozwoliłbym na logowanie SCHANNEL w systemie, który działa, aby ustalić, który szyfr jest w użyciu. Chciałbym usłyszeć odpowiedź, jeśli w jakiś sposób RDP będzie działać z alternatywnym szyfrem.
Kopia postu:
Mamy to do pracy!
Najwyraźniej w 2008 i 2012 roku występują problemy ze składnią, a 2008/7 wymaga końcowego / 168. 2012 / 8.1 / 10 nie.
klucz z 2008 roku wygląda następująco: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168
A klucz w 2012 roku wygląda następująco: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168
Mogę potwierdzić, że użycie „Triple DES 168/168” NIE WYŁĄCZA 3DES w systemie. Możesz to sobie udowodnić za pomocą skanera protokołów (takiego jak Nessus) lub włączając rejestrowanie SCHANNEL:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007
Będziesz wtedy miał zdarzenia na przykład w dzienniku SYSTEM;
Uzgadnianie klienta SSL zakończyło się pomyślnie. Negocjowane parametry kryptograficzne są następujące.
Protokół: TLS 1.0 CipherSuite: 0x2f Siła wymiany: 1024
Dla mnie wynikiem jest 0xa, który Google ujawnia jako TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Gdy używam „Triple DES 168” (bez / 168), identyfikator zdarzenia systemowego 36880 nie pojawia się, a sesja RDP jest blokowana.
Zgodnie z artykułem: Kryptografia systemu: Użyj zgodnych algorytmów FIPS do szyfrowania, mieszania i podpisywania
Usługi pulpitu zdalnego (RDS) Do szyfrowania komunikacji sieciowej usług pulpitu zdalnego to ustawienie zasad obsługuje tylko algorytm szyfrowania Triple DES.
Zgodnie z artykułem: „Kryptografia systemu: używaj zgodnych algorytmów FIPS do szyfrowania, mieszania i podpisywania” efekty ustawień zabezpieczeń w systemie Windows XP i nowszych wersjach systemu Windows
To ustawienie wpływa również na usługi terminalowe w systemie Windows Server 2003 i nowszych wersjach systemu Windows. Efekt zależy od tego, czy TLS jest używany do uwierzytelniania serwera.
Jeśli TLS jest używany do uwierzytelniania serwera, to ustawienie powoduje, że używany jest tylko TLS 1.0.
Domyślnie, jeśli TLS nie jest używany, a to ustawienie nie jest włączone na kliencie lub serwerze, kanał protokołu RDP (Remote Desktop Protocol) między serwerem a klientem jest szyfrowany przy użyciu algorytmu RC4 z 128-bitowym długość klucza. Po włączeniu tego ustawienia na komputerze z systemem Windows Server 2003 spełnione są następujące warunki: Kanał RDP jest szyfrowany przy użyciu algorytmu 3DES w trybie Łańcuch bloków szyfrów (CBC) z kluczem o długości 168 bitów. Algorytm SHA-1 służy do tworzenia skrótów wiadomości. Klienci muszą korzystać z programu klienta RDP 5.2 lub nowszej wersji, aby się połączyć.
Oba te argumenty wspierają ideę, że RDP może wykorzystywać tylko 3DES. Jednak ten artykuł sugeruje, że dostępna jest większa liczba szyfrów: walidacja FIPS 140
Zestaw algorytmów kryptograficznych, których będzie używał serwer RDP, obejmuje: - CALG_RSA_KEYX - algorytm wymiany klucza publicznego RSA - CALG_3DES - algorytm szyfrowania potrójnego DES - CALG_AES_128 - 128-bitowy AES - CALG_AES_256 - 256-bitowy AES - CALG_SHA1 - Algorytm mieszania SHA - CALG_SHA_256 - 256-bitowy algorytm mieszania SHA - CALG_SHA_384 - 384-bitowy algorytm mieszania SHA - CALG_SHA_512 - 512-bitowy algorytm mieszania SHA
Ostatecznie nie jest jasne, czy RDP może obsługiwać protokoły inne niż 3DES, gdy włączony jest tryb FIPS, ale dowody sugerują, że tak nie jest.
Nie widzę dowodów na to, że Server 2012 R2 działałby inaczej niż Server 2008 R2, jednak wydaje się, że Server 2008 R2 był oparty na zgodności z FIPS 140-1, a Server 2012 R2 jest zgodny z FIPS 140-2, więc jest całkowicie możliwe, że Server 2012 R2 obsługuje dodatkowe protokoły. Zanotujesz dodatkowe protokoły w linku Walidacja FIPS 140 .
Podsumowując: nie sądzę, aby Server 2008 R2 mógł obsługiwać RDP w trybie FIPS z wyłączonym 3DES. Moim zaleceniem jest sprawdzenie, czy Twój system spełnia warunki ataku SWEET32 (ponad 768 GB wysłane w jednej sesji) i czy wyłączenie 3DES jest warte usunięcia możliwości RDP. Istnieją inne narzędzia do zarządzania serwerami poza protokołem RDP, szczególnie w świecie, w którym wirtualizacja jest bardzo powszechna.
