La suppression du chiffrement vulnérable sur Windows 10 rompt le RDP sortant

Le scanner de vulnérabilité de TrustWave échoue à une analyse en raison d'une machine Windows 10 exécutant RDP:

Algorithmes de chiffrement par blocs d'une taille de bloc de 64 bits (comme DES et 3DES), attaque d'anniversaire connue sous le nom de Sweet32 (CVE-2016-2183)

REMARQUE: Sur les systèmes Windows 7/10 exécutant RDP (Remote Desktop Protocol), le chiffrement vulnérable qui doit être désactivé est étiqueté «TLS_RSA_WITH_3DES_EDE_CBC_SHA».

En utilisant IIS Crypto (par Nartac), j'ai essayé d'appliquer le modèle "Best Practices" ainsi que le modèle PCI 3.1, mais les deux incluent le chiffrement non sécurisé (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

Si je désactive ce chiffre, RDP de cet ordinateur vers de nombreuses stations Windows cesse de fonctionner (il fonctionne toujours avec certains serveurs 2008 R2 et 2012 R2). Le client RDP donne simplement «Une erreur interne s'est produite» et le journal des événements:

Une erreur fatale s'est produite lors de la création des informations d'identification du client TLS. L'état d'erreur interne est 10013.

J'ai vérifié le journal des événements du serveur de l'un des serveurs et voir ces deux messages

Une demande de connexion TLS 1.2 a été reçue d'une application cliente distante, mais aucune des suites de chiffrement prises en charge par l'application cliente n'est prise en charge par le serveur. La demande de connexion SSL a échoué.

L'alerte fatale suivante a été générée: 40. L'état d'erreur interne est 1205.

Comment puis-je corriger la vulnérabilité de sécurité sans rompre le RDP sortant?

Ou, si ce qui précède n'est pas possible, y a-t-il quelque chose que je peux faire sur chaque hôte RDP auquel je ne peux plus me connecter et qui le gère à cette fin?

--- Mise à jour # 1 ---

Après avoir désactivé TLS_RSA_WITH_3DES_EDE_CBC_SHA sur la machine Windows 10, j'ai essayé de me connecter à plusieurs hôtes RDP (la moitié d'entre eux a échoué avec "Une erreur interne ..."). J'ai donc comparé un de ces hôtes auquel je peux me connecter à un autre auquel je ne peux pas me connecter. Les deux sont 2008 R2. Les deux ont la même version RDP (6.3.9600, protocole RDP 8.1 pris en charge).

J'ai comparé les protocoles TLS et les chiffrements en utilisant IIS Crypto pour faire "Enregistrer le modèle" sur leurs paramètres actuels afin de pouvoir comparer les fichiers de modèle. Ils étaient identiques! Quel que soit le problème, il ne semble pas s'agir d'une suite de chiffrement manquante sur l'hôte. Voici une capture d'écran de Beyond Compare sur les fichiers:

Qu'est-ce qui pourrait être différent entre les deux hôtes RDP à l'origine de ce problème et comment le résoudre?

IIS Crypto a la possibilité de définir les options côté serveur (entrant) et côté client (sortant). Il y a une poignée de chiffrements que vous devez laisser activés côté client pour des raisons de compatibilité.

Pour faire ce que vous voulez, j'irais personnellement avec ce qui suit:

• Appliquer le modèle 3.1
• Laissez toutes les suites de chiffrement activées
• Appliquer au client et au serveur (case cochée).
• Cliquez sur «appliquer» pour enregistrer les modifications

Redémarrez ici si vous le souhaitez (et vous avez un accès physique à la machine).

• Appliquer le modèle 3.1
• Laissez toutes les suites de chiffrement activées
• Appliquer au serveur (case décochée).
• Décochez l'option 3DES

Le redémarrage ici devrait entraîner un état final correct.

En effet, vous ne souhaitez désactiver que 3DES entrant, mais autorisez toujours l'utilisation sortante de ladite suite de chiffrement.

J'ai eu le même problème, l'installation du correctif KB3080079 sur le serveur permet la prise en charge de tls 1.1 et 1.2.

Notez que pour les clients Windows 7, vous devrez installer la mise à jour du client rdp (KB2830477), sinon seuls Windows 8+ pourront se connecter.

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.

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

** Super trouvaille j'ai eu exactement le même problème sur certains contrôleurs de domaine Windows 2008 R2, curieusement mes serveurs membres 2008R2 semblent ok ... et mes serveurs 2012R2 fonctionnent bien aussi. Besoin de casser le déclassement de ces anciens DC :)