Comment désactiver TLS 1.0 sans casser RDP?
Notre processeur de carte de crédit nous a récemment informé que le 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 machine Windows Server 2008 R2, seulement pour constater qu'immédiatement après le redémarrage, j'étais complètement incapable de me connecter via Remote Desktop Protocol (RDP). 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. Quelqu'un connaît-il un moyen de désactiver TLS 1.0 sur Windows Server 2008 R2 sans casser RDP? Microsoft prévoit-il la prise en charge de RDP sur TLS 1.1 ou TLS 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ésea , ce qui semble être l'échange d'un mal contre un autre .
MISE À JOUR 1 : Microsoft a maintenant résolu ce problème. Voir réponse ci-dessous pour la mise à jour du serveur appropriée.
MISE À JOUR 2 : Microsoft a publié un tutoriel concernant Prise en charge SQL Server pour PCI DSS 3.1 .
Microsoft a publié le correctif de ce problème le 15 septembre 2015
J'étudie cela depuis quelques jours maintenant car nous devons nous conformer à PCI-DSS 3.1 qui nécessite la désactivation de TLS 1.0.
Nous ne voulons pas non plus revenir à la couche de sécurité RDP, qui est un problème de sécurité majeur.
J'ai finalement réussi à trouver une documentation qui confirme que TLS 1.1 et TLS 1.2 SONT pris en charge par RDP. Cette documentation est cachée dans un journalisation SChannel et un spécification très détaillée pour RDP .
Il y a un manque total de documentation du flux principal sur Technet ou d'autres sites Microsoft, il semble donc que j'espère que documenter cela 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>"
Du PDF de spécification RDP:
"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 pourrait conclure que vous pouvez utiliser TLS 1.1 ou 1.2 sur Windows Server 2008 R2 selon cette documentation.
Cependant, nos tests ont prouvé que cela NE FONCTIONNE PAS à partir du client Windows 7 RDP (version 6.3.9600) lorsque TLS 1.0 est désactivé et que l'option de sécurité RDP est définie pour nécessiter TLS 1.0.
Ceci est bien sûr aussi bien que l'activation de TLS 1.1 et 1.2 qui sont désactivés par défaut sur 2008R2 - d'ailleurs nous le faisons en utilisant le très utile IIS Crypto Tool de Nartac Software .
Lorsque vous examinez ce problème, il est utile d'activer la journalisation SChannel pour voir plus de détails sur ce qui se passe lorsque votre session est ouverte.
Vous pouvez définir journalisation SChannel en modifiant la clé HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging sur 5 et en redémarrant.
Une fois cela fait, vous pouvez observer les événements SChannel qui montrent la version 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 dont je peux confirmer le fonctionnement parfait en utilisant le client RDP Windows 7. L'entrée du journal SChannel montre 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 aide quelqu'un qui cherche des éclaircissements à ce sujet.
Je continuerai à chercher comment nous pourrions faire fonctionner RDP sur TLS 1.1 et TLS 1.2 dans Windows Server 2008 R2.
MISE À JOUR: 2015-AOÛT-05
Nous avons soulevé le problème de RDP ne fonctionnant pas avec Server 2008 R2 avec prise en charge de Microsoft, y compris les étapes de reproduction.
Après plusieurs semaines de va-et-vient, nous avons finalement reçu un appel téléphonique aujourd'hui de la part de l'équipe de support pour reconnaître qu'ils pouvaient en effet le reproduire et cela est maintenant classé comme un bug. Un correctif de mise à jour sera publié, pour le moment, cela est prévu pour octobre 2015. Dès que j'aurai un article de la base de connaissances ou d'autres détails, je les ajouterai à cet article.
J'espère que ceux qui sont bloqués avec 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 sur ce sujet ici et je peux confirmer que cela fonctionne bien.
Utilisez plutôt IPsec, comme le recommande le document: "Configurer d'abord une session fortement cryptée (par exemple, tunnel IPsec), puis envoyer des données via SSL dans un tunnel sécurisé"
La principale raison de faire cela au-dessus de la configuration de TLS pour RDP est que la politique de pare-feu est facilement auditée pour la conformité (par rapport à la preuve qu'une multitude de modifications du registre sont conformes) et IPsec est assez facile à configurer dans Windows.
Si vous avez besoin d'une conformité complète à la suite 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 où j'ai désactivé TLS 1.0 et sans accès physique?".
J'ai désactivé TLS 1.0 en utilisant IISCrypto, ce qui a donné un avertissement utile sur l'effet secondaire que RDP cessera de fonctionner s'il est défini sur TLS. Je me suis donc enregistré:
Admin Tools\Remote Desktop Services\Remote Desktop Session Host Configuration, RDP-Tcp, General Tab, Security Layer
et mon niveau de sécurité a été défini sur "Négocier". J'ai supposé que cela signifie que si TLS n'est pas disponible, il se dégraderait gracieusement en sécurité RDP.
Mais non, Negotiate ne fonctionne pas de cette façon. Vous devez définir le niveau de sécurité sur Sécurité RDP, et non sur Négocier, avant de désactiver TLS 1.0.
J'ai donc perdu ma capacité à me connecter à distance à mon instance AWS!
Pour me reconnecter, j'ai utilisé une autre instance AWS.
- J'ai mis à jour le SecurityGroup pour permettre la connexion du pare-feu de cette machine à ma machine "perdue".
- J'ai ouvert un partage réseau administratif sous DOS, avec un utilisateur administrateur et un mot de passe:
Net Use \\lost_machine_ip\c$
- Ensuite, j'ai ouvert Regedit, et dans le menu Fichier, choisissez "Connecter le registre réseau" et saisissez l'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 de SecurityLayer sur 0 (0 est la sécurité RDP).
Vous pourrez ensuite vous connecter à distance et réactiver TLS 1.0 dans IISCrypto si nécessaire.
Vous devrez installer RDP 8.0 sur vos ordinateurs Windows 7 et 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
Une fois cela fait, vous devriez pouvoir désactiver TLS 1.0 sur les ordinateurs et les serveurs en modifiant le registre comme indiqué dans cet article technet. https://technet.Microsoft.com/en-us/library/dn786418.aspx
Après avoir installé RDP 8.0, vous pouvez également installer RDP 8.1, mais RDP 8.0 doit être installé avant d'installer RDP 8.1. RDP 8.0 contient à la fois les composants de protocole côté client et côté serveur, mais RDP 8.1 inclut uniquement le client. Le KB de 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 "Exiger 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 m'assurer qu'il ne retomberait pas sur le cryptage RDP.
MISE À JOUR 19/06/2015:
J'ai finalement eu la chance de tester cela sur l'un de nos serveurs Windows Server 2008 R2, et cela brise définitivement les connexions RDP au serveur. Il semble que les composants côté serveur RDP 8.0 ne soient installés que sur les ordinateurs Windows 7 et ne soient pas installés sur les serveurs Windows Server 2008 R2.
Tel que publié le Comment désactiver TLS 1.0 sans casser les RemoteApps sur le serveur 2012 R2 mais republier ici pour le bénéfice de ceux qui ne surveillent pas ce lien:
Après presque un an, j'ai finalement trouvé une solution de travail pour désactiver TLS 1.0/1.1 sans interrompre la connectivité RDP et Remote Desktop Services et lancer RemoteApps:
Exécutez IISCrypto et désactivez TLS 1.0, TLS 1.1 et tous les mauvais chiffrements.
Sur le serveur des services Bureau à distance exécutant 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 conformes FIPS pour le chiffrement, le hachage et la signature. Modifiez le paramètre de sécurité Redémarrez pour que les modifications prennent effet.
Notez que dans certains cas (en particulier 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îtiers Windows 7 64 bits, j'ai dû installer KB2574819 (premier) et KB2592687 (second) Windows 7 doit avoir installé SP1 avant que ces 2 paquets ne soient installés. Si vous rencontrez des problèmes pour installer SP1 comme je l'ai fait, j'ai dû d'abord désinstaller KB958830, puis installer SP1.
Pour mes boîtiers Windows Server 2008 R2, j'ai dû installer KB3080079. Une fois que vous avez fait cela et que tous les paramètres appropriés pour une communication sécurisée sont mis en place, il utilisera TLS 1.2. Vous pouvez confirmer en utilisant Wireshark pour effectuer une capture de la communication entre vos deux boîtiers.
Un cas non couvert par les réponses existantes: les clients Windows 7 se connectant via une passerelle RDP utiliseront toujours 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 application KB3080079 , comme observé 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 .reg extension à 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 KB3140245 , cela remplacera WINHTTP_OPTION_SECURE_PROTOCOLS pour utiliser TLS 1.2 (et uniquement TLS 1.2) par défaut. Soyez donc conscient que cela affectera plus que le client RDP.
(Remarque: si la rétrocompatibilité est souhaitée, dword:00000800 peut être changé en dword:00000A00 ou dword:00000A80 pour inclure TLS 1.1 et 1.0 respectivement)
J'ai utilisé avec succès rdesktop ( http://www.rdesktop.org ) pour Linux pour contourner ce problème.