Edit (2018-09-26): J'ai découvert que la désactivation de 3DES sur 2012R2 ne casse pas RDP mais cela casse sur 2008 R2. Les options prises en charge semblent être différentes entre les noyaux.
Je vais partager ma réponse à partir d'un fil TechNet mais d'abord BLUF:
Conclusion de la défaillance du serveur: vous avez très probablement une autre différence entre les systèmes. Vous vous connectez entre différentes versions de système d'exploitation, un système a activé FIPS et l'autre pas, ou vous avez différentes restrictions de chiffrement en place sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers
. Je certainement activer la journalisation SCHANNEL sur le système qui fait le travail pour déterminer quel chiffre est utilisé. Je serais ravi de vous répondre si vous avez réussi à faire fonctionner RDP avec un autre chiffrement.
Copie du message:
Nous l'avons fait fonctionner!
Apparemment, 2008 et 2012 ont des problèmes de syntaxe et le 2008/7 nécessite un / 168 de fin. 2012 / 8.1 / 10 ne fonctionne pas.
la clé de 2008 ressemble à ceci: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168
Et la clé de 2012 ressemble à ceci: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168
Je peux confirmer que l'utilisation de "Triple DES 168/168" NE désactive PAS 3DES sur le système. Vous pouvez le prouver vous-même avec un scanner de protocole (comme Nessus) ou en activant la journalisation SCHANNEL:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007
Vous aurez alors des événements dans le journal SYSTEM par exemple;
Une négociation client SSL s'est terminée avec succès. Les paramètres cryptographiques négociés sont les suivants.
Protocole: TLS 1.0 CipherSuite: 0x2f Force d'échange: 1024
Pour moi, le résultat est 0xa que Google révèle comme TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Lorsque j'utilise "Triple DES 168" (sans le / 168), l'ID d'événement système 36880 n'apparaît pas et la session RDP est bloquée.
Par l'article: Cryptographie du système: utilisez des algorithmes compatibles FIPS pour le chiffrement, le hachage et la signature
Services Bureau à distance (RDS) Pour crypter la communication réseau des Services Bureau à distance, ce paramètre de stratégie prend en charge uniquement l'algorithme de cryptage Triple DES.
Par l'article: «Cryptographie système: utilisez des algorithmes conformes FIPS pour le chiffrement, le hachage et la signature» des effets de paramètre de sécurité dans Windows XP et dans les versions ultérieures de Windows
Ce paramètre affecte également les services Terminal Server dans Windows Server 2003 et dans les versions ultérieures de Windows. L'effet dépend de si TLS est utilisé pour l'authentification du serveur.
Si TLS est utilisé pour l'authentification du serveur, ce paramètre entraîne uniquement l'utilisation de TLS 1.0.
Par défaut, si TLS n'est pas utilisé et que ce paramètre n'est pas activé sur le client ou sur le serveur, le canal RDP (Remote Desktop Protocol) entre le serveur et le client est chiffré à l'aide de l'algorithme RC4 avec 128 bits. longueur de clé. Une fois que vous avez activé ce paramètre sur un ordinateur Windows Server 2003, les conditions suivantes sont remplies: Le canal RDP est chiffré à l'aide de l'algorithme 3DES en mode CBC (Cipher Block Chaining) avec une longueur de clé de 168 bits. L'algorithme SHA-1 est utilisé pour créer des résumés de messages. Les clients doivent utiliser le programme client RDP 5.2 ou une version ultérieure pour se connecter.
Donc, les deux soutiennent l'idée que RDP ne peut utiliser que 3DES. Cependant, cet article suggère qu'une plus grande gamme de chiffres est disponible: Validation FIPS 140
L'ensemble d'algorithmes cryptographiques qu'un serveur RDP (Remote Desktop Protocol) utilisera est limité à: - CALG_RSA_KEYX - Algorithme d'échange de clés publiques RSA - CALG_3DES - Algorithme de chiffrement Triple DES - CALG_AES_128 - AES 128 bits - CALG_AES_256 - AES 256 bits - CALG_SHA1 - Algorithme de hachage SHA - CALG_SHA_256 - Algorithme de hachage SHA 256 bits - CALG_SHA_384 - Algorithme de hachage SHA 384 bits - CALG_SHA_512 - Algorithme de hachage SHA 512 bits
En fin de compte, il n'est pas clair si RDP peut prendre en charge les protocoles non 3DES lorsque le mode FIPS est activé, mais les preuves suggèrent que non.
Je ne vois aucune preuve que Server 2012 R2 fonctionnerait différemment de Server 2008 R2, mais il semble que Server 2008 R2 était basé sur la conformité FIPS 140-1 et Server 2012 R2 suit FIPS 140-2, il est donc tout à fait possible que Server 2012 R2 prenne en charge protocoles supplémentaires. Vous noterez les protocoles supplémentaires dans le lien de validation FIPS 140 .
En conclusion: je ne pense pas que Server 2008 R2 puisse prendre en charge RDP en mode FIPS avec 3DES désactivé. Ma recommandation est de vérifier si votre système remplit les conditions pour une attaque SWEET32 (plus de 768 Go envoyés en une seule session) et si la désactivation de 3DES vaut la peine de supprimer la capacité RDP. Il existe d'autres utilitaires pour gérer les serveurs au-delà de RDP, en particulier dans un monde où la virtualisation est très courante.