Sunting (2018-09-26): Saya telah menemukan bahwa menonaktifkan 3DES pada 2012R2 TIDAK merusak RDP tetapi TIDAK rusak pada 2008 R2. Opsi yang didukung tampaknya berbeda di antara kernel.
Saya akan membagikan jawaban saya dari utas TechNet tetapi pertama-tama BLUF:
Kesimpulan Serverfault: Kemungkinan besar Anda memiliki beberapa perbedaan lain di antara sistem. Anda menghubungkan antara versi OS yang berbeda, satu sistem memiliki FIPS diaktifkan dan yang lainnya tidak, atau Anda memiliki batasan cipher yang berbeda di tempatnya HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers
. Saya pasti akan memungkinkan SCHANNEL logging pada sistem yang tidak bekerja untuk menentukan cipher digunakan. Senang mendengar kembali jika Anda entah bagaimana membuat RDP bekerja dengan cipher alternatif.
Salinan pos:
Kami berhasil!
Rupanya 2008 dan 2012 memiliki masalah sintaksis dan 2008/7 membutuhkan trailing / 168. 2012 / 8.1 / 10 tidak.
kunci pada 2008 terlihat seperti ini: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168
Dan kuncinya pada 2012 terlihat seperti ini: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168
Saya dapat mengkonfirmasi bahwa penggunaan "Triple DES 168/168" JANGAN menonaktifkan 3DES pada sistem. Anda dapat membuktikan ini sendiri dengan pemindai protokol (seperti Nessus) atau dengan mengaktifkan pendataan SCHANNEL:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007
Anda kemudian akan memiliki acara di log SISTEM misalnya;
Jabat tangan klien SSL berhasil diselesaikan. Parameter kriptografi yang dinegosiasikan adalah sebagai berikut.
Protokol: TLS 1.0 CipherSuite: 0x2f Kekuatan pertukaran: 1024
Bagi saya hasilnya adalah 0xa yang diungkapkan oleh Google sebagai TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Ketika saya menggunakan "Triple DES 168" (tanpa / 168), System event ID 36880 tidak muncul dan sesi RDP diblokir.
Per artikel: Sistem kriptografi: Gunakan algoritma yang sesuai FIPS untuk enkripsi, hashing, dan penandatanganan
Remote Desktop Services (RDS) Untuk mengenkripsi komunikasi jaringan Remote Desktop Services, pengaturan kebijakan ini hanya mendukung algoritma enkripsi Triple DES.
Per artikel: "Kriptografi sistem: Gunakan algoritma yang sesuai FIPS untuk enkripsi, hashing, dan penandatanganan" efek pengaturan keamanan di Windows XP dan di versi Windows yang lebih baru
Pengaturan ini juga memengaruhi Layanan Terminal di Windows Server 2003 dan di versi Windows yang lebih baru. Efeknya tergantung pada apakah TLS digunakan untuk otentikasi server.
Jika TLS digunakan untuk otentikasi server, pengaturan ini hanya menyebabkan TLS 1.0 digunakan.
Secara default, jika TLS tidak sedang digunakan, dan pengaturan ini tidak diaktifkan pada klien atau di server, saluran Remote Desktop Protocol (RDP) antara server dan klien dienkripsi dengan menggunakan algoritma RC4 dengan 128-bit panjang kunci. Setelah Anda mengaktifkan pengaturan ini pada komputer berbasis Windows Server 2003, berikut ini benar: Saluran RDP dienkripsi dengan menggunakan algoritma 3DES dalam mode Cipher Block Chaining (CBC) dengan panjang kunci 168-bit. Algoritma SHA-1 digunakan untuk membuat intisari pesan. Klien harus menggunakan program klien RDP 5.2 atau versi yang lebih baru untuk terhubung.
Jadi keduanya mendukung gagasan bahwa RDP hanya dapat memanfaatkan 3DES. Namun, artikel ini menyarankan berbagai jenis cipher tersedia: Validasi FIPS 140
Himpunan algoritma kriptografi yang akan digunakan server Remote Desktop Protocol (RDP) untuk: - CALG_RSA_KEYX - Algoritma pertukaran kunci publik RSA - CALG_3DES - Algoritme enkripsi Triple DES - CALG_AES_128 - 128 bit AES - CALG_AES_256 - 256 bit AES - CALG_SHA Algoritma hashing SHA - CALG_SHA_256 - 256 bit Algoritma hashing SHA - CALG_SHA_384 - 384 bit Algoritma hashing SHA - CALG_SHA_512 - 512 bit Algoritma hashing SHA
Pada akhirnya tidak jelas apakah RDP dapat mendukung protokol non-3DES ketika mode FIPS diaktifkan tetapi bukti menunjukkan itu tidak.
Saya tidak melihat bukti bahwa Server 2012 R2 akan berfungsi secara berbeda dari Server 2008 R2, namun tampaknya Server 2008 R2 didasarkan pada kepatuhan FIPS 140-1 dan Server 2012 R2 mengikuti FIPS 140-2 sehingga sangat mungkin bahwa Server 2012 R2 mendukung protokol tambahan. Anda akan mencatat protokol tambahan di tautan Validasi FIPS 140 .
Sebagai kesimpulan: Saya tidak berpikir Server 2008 R2 dapat mendukung RDP dalam mode FIPS dengan 3DES dinonaktifkan. Rekomendasi saya adalah memastikan apakah sistem Anda memenuhi persyaratan untuk serangan SWEET32 (lebih dari 768GB yang dikirim dalam satu sesi) dan apakah menonaktifkan 3DES layak untuk menghapus kemampuan RDP. Utilitas lain ada untuk mengelola server di luar RDP terutama di dunia di mana virtualisasi sangat umum.