Comment désactiver TLS 1.0 sans rompre le protocole RDP?

Notre processeur de carte de crédit nous a récemment informés que, à compter du 30 juin 2016, nous devrons désactiver TLS 1.0 pour rester conforme à la norme PCI . J'ai essayé d'être proactif en désactivant TLS 1.0 sur notre ordinateur Windows Server 2008 R2, mais je me suis aperçu que, immédiatement après le redémarrage, je ne pouvais plus me connecter via le protocole RDP (Remote Desktop Protocol). Après quelques recherches, il semble que RDP ne supporte que TLS 1.0 (voir ici ou ici ), ou du moins on ne sait pas comment activer RDP sur TLS 1.1 ou TLS 1.2. Est-ce que quelqu'un connaît un moyen de désactiver TLS 1.0 sur Windows Server 2008 R2 sans rompre le protocole RDP? Microsoft prévoit-il de prendre en charge RDP par rapport à TLS 1.1 ou 1.2?

Remarque: il semble y avoir un moyen de le faire en configurant le serveur pour utiliser la couche de sécurité RDP, mais cela désactive l'authentification au niveau du réseau , ce qui semble être un échange entre deux fléaux.

MISE À JOUR 1 : Microsoft a maintenant résolu ce problème. Voir la réponse ci-dessous pour la mise à jour du serveur concerné.

MISE À JOUR 2 : Microsoft a publié un tutoriel sur la prise en charge de SQL Server par PCI DSS 3.1 .

Microsoft a publié le correctif pour ce problème 15 septembre 2015

Voir https://support.microsoft.com/en-us/kb/3080079.

Je me penche sur la question depuis quelques jours maintenant, car nous devons nous conformer à la norme PCI-DSS 3.1, selon laquelle TLS 1.0 doit être désactivé.

Nous ne voulons pas non plus nous rabattre sur la couche de sécurité RDP, qui constitue un problème de sécurité majeur.

J'ai finalement réussi à trouver de la documentation qui confirme que TLS 1.1 et TLS 1.2 SONT pris en charge par RDP. Cette documentation est cachée dans une journalisation SChannel et une spécification très détaillée pour RDP .

Il semble y avoir un manque total de documentation sur les flux principaux sur Technet ou d’autres sites Microsoft. Il est donc souhaitable que le documenter ici puisse aider certaines personnes.

Extraits pertinents des liens fournis:

À partir du lien MSDN:

"RDP supports four External Security Protocols: TLS 1.0 ([RFC2246]) TLS 1.1 ([RFC4346])<39>, TLS 1.2 ([RFC5246])<40>"

A partir de la spécification RDP PDF:

"When Enhanced RDP Security is used, RDP traffic is no longer protected by using the techniques
described in section 5.3. Instead, all security operations (such as encryption and decryption, data
integrity checks, and Server Authentication) are implemented by one of the following External
Security Protocols:
TLS 1.0 (see [RFC2246])
TLS 1.1 (see [RFC4346])
TLS 1.2 (see [RFC5246])
CredSSP (see [MS-CSSP])"

"<39> Section 5.4.5: TLS 1.1 is not supported by Windows NT, Windows 2000 Server, Windows XP,
Windows Server 2003, Windows Vista and Windows Server 2008.
<40> Section 5.4.5:  TLS 1.2 is not supported by Windows NT, Windows 2000 Server, Windows XP,
Windows Server 2003, Windows Vista, and Windows Server 2008"

Par conséquent, on peut en conclure que vous pouvez utiliser TLS 1.1 ou 1.2 sur Windows Server 2008 R2 conformément à cette documentation.

Cependant, nos tests ont prouvé que cela ne fonctionnait PAS avec le client RDP Windows 7 (version 6.3.9600) lorsque TLS 1.0 était désactivé et que l'option de sécurité RDP était définie pour nécessiter TLS 1.0.

Ceci est bien sûr ainsi que l'activation de TLS 1.1 et 1.2 qui sont désactivés par défaut sur 2008R2 - nous le faisons d'ailleurs à l'aide du très utile outil de cryptographie IIS de Nartac Software .

Lorsque vous examinez ce problème, il est utile d'activer la journalisation SChannel pour afficher plus de détails sur ce qui se passe à l'ouverture de votre session.

Vous pouvez définir la journalisation SChannel en modifiant la clé HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ EventLogging sur 5 et en redémarrant.

Une fois que cela est fait, vous pouvez observer les événements SChannel qui indiquent la version de TLS utilisée lors de l'établissement d'une connexion RDP. Une fois la journalisation activée, vous pouvez observer l'erreur SChannel lorsque le client RDP tente d'établir une connexion sur Windows 2008 R2 avec TLS 1.0 désactivé:

A fatal error occurred while creating an SSL server credential. The internal error state is 10013.

J'ai également testé la désactivation de TLS 1.0 sur Windows Server 2012 et 2012 R2 qui, je le confirme, fonctionne parfaitement à l'aide du client RDP Windows 7. L'entrée du journal SChannel indique que TLS 1.2 est utilisé:

An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows.

   Protocol: TLS 1.2
   CipherSuite: 0xC028
   Exchange strength: 256

J'espère que cela aidera quelqu'un qui cherche des éclaircissements à ce sujet.

Je continuerai à rechercher des solutions pour que RDP fonctionne avec TLS 1.1 et TLS 1.2 dans Windows Server 2008 R2.

MISE À JOUR: 2015-AUG-05

Nous avons soulevé le problème suivant: RDP ne fonctionne pas avec Server 2008 R2 avec le support technique de Microsoft, y compris les étapes à suivre pour reproduire.

Après plusieurs semaines d'avant en arrière, nous avons finalement reçu un appel de l'équipe de support aujourd'hui pour lui confirmer qu'il était en mesure de le reproduire. Il s'agit désormais d'un bug. Un correctif de mise à jour sera publié. Pour le moment, ceci est attendu pour octobre 2015. Dès que j'ai un article de la Base de connaissances ou d'autres détails, je les ajouterai à cet article.

Espérons que les personnes bloquées sous Windows Server 2008 R2 pourront au moins résoudre ce problème avant la date limite de juin 2016, une fois le correctif publié.

MISE À JOUR: 19 septembre 2015

Microsoft a finalement publié un article de support technique en kb à ce sujet ici et je peux confirmer que cela fonctionne correctement.

Utilisez plutôt IPsec, comme le recommande le document: "Configurer d'abord une session fortement cryptée (par exemple un tunnel IPsec), puis envoyer des données via SSL dans un tunnel sécurisé"

La principale raison de faire cela sur la configuration de TLS pour RDP est que la conformité de la stratégie de pare-feu est facilement vérifiée (par opposition à la preuve que de nombreuses modifications du registre sont conformes) et qu’IPsec est assez facile à configurer dans Windows.

Si vous avez besoin de la conformité à la suite complète B, IPSEC avec tls 1.0 est le seul moyen disponible pour appliquer des longueurs de certificat appropriées.

Ce n'est pas une réponse à la question mais à la sous-question "Comment restaurer l'accès à distance à une machine virtuelle sur laquelle j'ai désactivé TLS 1.0 sans accès physique?".

J'ai désactivé TLS 1.0 à l'aide d'IISCrypto, ce qui constitue un avertissement utile sur l'effet secondaire suivant: RDP cessera de fonctionner s'il est configuré sur TLS. Alors j'ai vérifié:

Admin Tools\Remote Desktop Services\Remote Desktop Session Host Configuration, RDP-Tcp, General Tab, Security Layer

et mon niveau de sécurité a été réglé sur "Négocier". J'ai supposé que cela signifiait que si TLS n'était pas disponible, il se dégraderait gracieusement en sécurité RDP.

Mais non, négocier ne fonctionne pas de cette façon. Avant de désactiver TLS 1.0, vous devez définir le niveau de sécurité sur Sécurité RDP, et non sur Négocier.

J'ai donc perdu ma capacité à me connecter à distance à mon instance AWS!

Pour vous reconnecter, j'ai utilisé une autre instance AWS.

1. J'ai mis à jour le SecurityGroup pour permettre la connexion de pare-feu de cette machine à ma machine "perdue".
2. J'ai ouvert un partage réseau administratif sous DOS, avec un utilisateur et un mot de passe administrateur:

net use \\lost_machine_ip\c$

3. Ensuite, j'ai ouvert Regedit, et dans le menu Fichier, choisissez "Connect Network Registry" et entrez l'adresse IP du serveur "perdu". Vous devriez voir le registre du serveur distant. Aller à :

\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\

et définissez la valeur SecurityLayersur 0 (0 correspond à la sécurité RDP).

Vous pourrez alors vous connecter à distance et réactiver TLS 1.0 dans IISCrypto si nécessaire.

Vous devez installer RDP 8.0 sur vos ordinateurs Windows 7 et vos serveurs Windows Server 2008 R2, puis activer RDP 8.0 sur la stratégie de l'ordinateur local ou la stratégie de groupe.

Voici la base de connaissances Microsoft pour le RDP 8.0. https://support.microsoft.com/en-us/kb/2592687

Ceci fait, vous devriez pouvoir désactiver TLS 1.0 sur les ordinateurs et les serveurs en modifiant le registre, comme indiqué dans cet article technique. https://technet.microsoft.com/en-us/library/dn786418.aspx

Après avoir installé RDP 8.0, vous pouvez également installer RDP 8.1, mais ce dernier doit être installé avant de procéder à l'installation de RDP 8.1. RDP 8.0 contient les composants de protocole côté client et côté serveur, mais RDP 8.1 n'inclut que le client. La base de connaissances Microsoft pour RDP 8.1 est KB2830477.

J'ai effectué ces modifications sur l'un de mes postes de travail Windows 7 et testé les connexions RDP avec le paramètre de stratégie de groupe "Requérir l'utilisation d'une couche de sécurité spécifique pour les connexions distantes (RDP)" activé et défini sur "SSL (TLS 1.0)" pour garantir son respect. ne retomberait pas sur le cryptage RDP.

MISE À JOUR DU 19/06/2015:

J'ai finalement eu la chance de tester cela sur l'un de nos serveurs Windows Server 2008 R2, et cela rompt définitivement les connexions RDP au serveur. Il semble que les composants côté serveur RDP 8.0 ne soient installés que sur des ordinateurs Windows 7 et non sur des serveurs Windows Server 2008 R2.

Comme indiqué sur Comment désactiver TLS 1.0 sans interrompre les RemoteApps sur le serveur 2012 R2, mais le republier ici au profit de ceux qui ne surveillent peut-être pas ce lien:

Après presque un an, j'ai finalement trouvé une solution efficace pour désactiver TLS 1.0 / 1.1 sans rompre la connectivité RDP et les services de bureau à distance et lancer les applications à distance:

Exécutez IISCrypto et désactivez TLS 1.0, TLS 1.1 et tous les chiffrements incorrects.

Sur le serveur de services de bureau à distance qui exécute le rôle de passerelle, ouvrez la stratégie de sécurité locale et accédez à Options de sécurité - Cryptographie système: utilisez des algorithmes compatibles FIPS pour le cryptage, le hachage et la signature. Définissez le paramètre de sécurité sur Activé. Redémarrez pour que les modifications prennent effet.

Notez que dans certains cas (notamment si vous utilisez des certificats auto-signés sur Server 2012 R2), l'option de stratégie de sécurité Sécurité réseau: le niveau d'authentification LAN Manager peut devoir être défini sur Envoyer uniquement les réponses NTLMv2.

Juste une mise à jour à ce sujet si quelqu'un d'autre cherche des informations à ce sujet. Pour mes boîtes Windows 7 64 bits, je devais installer KB2574819 (première) et KB2592687 (seconde). Windows 7 devait disposer du SP1 avant de pouvoir installer ces deux ordinateurs. Si vous rencontrez des problèmes pour installer SP1 comme je l’ai fait, j’ai du désinstaller KB958830, puis installer SP1.

Pour mes boîtes Windows Server 2008 R2, je devais installer KB3080079. Une fois que vous avez fait cela et que tous les paramètres appropriés ont été définis pour la communication sécurisée, il utilisera TLS 1.2. Vous pouvez confirmer en utilisant Wireshark pour capturer la communication entre vos deux boîtiers.

J'ai utilisé avec succès rdesktop ( http://www.rdesktop.org ) pour Linux pour résoudre ce problème.

Cas possibles non couverts par les réponses existantes: les clients Windows 7 qui se connectent via une passerelle RDP continueront à utiliser TLS 1.0 lors de la connexion à la passerelle et échoueront si la passerelle ne prend pas en charge TLS 1.0, même après l’application de KB3080079 , comme indiqué dans ce fil de discussion TechNet. .

Pour utiliser TLS 1.2 pour la connexion via une passerelle RDP, assurez- vous que KB3140245 est installé et ajoutez les clés de registre suivantes (enregistrez-les dans un fichier avec l' .regextension à importer):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800

Comme indiqué dans le document KB3140245 , cela remplacera WINHTTP_OPTION_SECURE_PROTOCOLSpar défaut l'utilisation de TLS 1.2 (et uniquement de TLS 1.2). Sachez donc que cela ne concerne pas uniquement le client RDP.

(Note: Si la rétrocompatibilité est souhaitée, dword:00000800peut être changé dword:00000A00ou dword:00000A80pour inclure TLS 1.1 et 1.0 , respectivement)