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 avec 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 intitulé "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 chiffrement, RDP de cet ordinateur à de nombreuses stations Windows cesse de fonctionner (il fonctionne toujours sur 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 casser 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 que je puisse comparer les fichiers de modèle. Ils étaient identiques! Donc, quel que soit le problème, ce n'est pas semble être une question de 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.
Edit (2018-09-26): J'ai découvert que la désactivation de 3DES sur 2012R2 ne rompt pas RDP, mais elle rompt sur 2008 R2. Les options prises en charge semblent être différentes entre les noyaux.
Je vais partager ma réponse à partir d'un TechNet thread mais d'abord BLUF:
Conclusion de la défaillance du serveur: Très probablement, vous avez une autre différence entre les systèmes. Vous vous connectez entre différentes versions de système d'exploitation, un système a FIPS activé et l'autre pas, ou vous avez différentes restrictions de chiffrement en place sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. J'activerais certainement la connexion SCHANNEL sur le système qui le fait fonctionne 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/168Et 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 par un scanner de protocole (comme Nessus) ou en activant la journalisation SCHANNEL:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007Vous 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 système: utilisez FIPS algorithmes conformes pour le cryptage, 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.
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 14
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 - Triple DES algorithme de chiffrement - CALG_AES_128 - AES 128 bits - CALG_AES_256 - AES 256 bits - CALG_SHA1 - SHA algorithme de hachage - CALG_SHA_256 - 256 bits SHA algorithme de hachage - CALG_SHA_384 - 384 bits SHA algorithme de hachage - CALG_SHA_512 - 512 bits SHA algorithme de hachage
En fin de compte, il n'est pas clair si RDP peut prendre en charge les protocoles non 3DES lorsque FIPS est activé, mais les preuves suggèrent que ce n'est pas le cas.
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 FIPS 140-1 conformité et Server 2012 R2 suit FIPS 140-2, il est donc tout à fait possible que Server 2012 R2 prenne en charge des protocoles supplémentaires. Vous noterez les protocoles supplémentaires dans le lien Validation FIPS 14 .
En conclusion: Je ne pense pas que Server 2008 R2 puisse prendre en charge RDP en FIPS avec 3DES désactivé. Ma recommandation consiste à vérifier si votre système remplit les conditions d'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. D'autres utilitaires existent pour gérer les serveurs au-delà de RDP, en particulier dans un monde où la virtualisation est très courante .
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.
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
** Excellente 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 également. Besoin de casser le déclassement de ces anciens DC :)