Comment désactiver TLS 1.0 sans interrompre RDP ?

Je me penche sur cette question depuis quelques jours car nous devons nous conformer à la norme PCI-DSS 3.1 qui exige que TLS 1.0 soit désactivé.

Nous ne voulons pas non plus nous rabattre sur la couche de sécurité RDP, qui pose 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 supportés par RDP. Cette documentation est cachée dans un Journalisation du canal SC et un spécification très détaillée pour RDP .

Il semble qu'il y ait un manque total de documentation sur Technet ou sur d'autres sites Microsoft, alors j'espère que le fait de documenter ceci ici pourra aider certaines personnes.

Extraits pertinents des liens fournis :

A partir du lien MSDN :

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

Extrait 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"

On peut donc 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 montré que cela ne fonctionne PAS avec le client RDP de Windows 7 (version 6.3.9600) lorsque TLS 1.0 est désactivé et que l'option de sécurité RDP est configurée pour exiger TLS 1.0.

Il s'agit bien sûr d'activer TLS 1.1 et 1.2, qui sont désactivés par défaut sur 2008R2 - nous le faisons d'ailleurs à l'aide de la très utile fonction IIS Crypto Tool de Nartac Software .

Lorsque vous examinez ce problème, il est utile d'activer la journalisation SChannel pour voir plus en détail ce qui se passe lorsque votre session est ouverte.

Vous pouvez définir Journalisation du canal SC en modifiant le fichier HKEY_LOCAL_MACHINE \System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging sur 5 et redémarrer.

Une fois que cela a été fait, vous pouvez observer les événements SChannel qui montrent la version TLS utilisée lorsqu'une connexion RDP est établie. 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, ce qui fonctionne parfaitement avec le client RDP de 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 aidera quelqu'un qui cherche des éclaircissements à ce sujet.

Je vais continuer à chercher comment faire fonctionner RDP avec TLS 1.1 et TLS 1.2 dans Windows Server 2008 R2.

MISE À JOUR : 2015-AUG-05

Nous avons soulevé le problème du non fonctionnement de RDP avec le serveur 2008 R2 auprès de l'assistance Microsoft, y compris les étapes à suivre pour le reproduire.

Après plusieurs semaines de va-et-vient, nous avons finalement reçu aujourd'hui un appel téléphonique de l'équipe d'assistance qui nous a confirmé qu'elle pouvait effectivement reproduire le problème et que celui-ci était désormais considéré comme un bogue. Un patch de mise à jour sera publié, à l'heure actuelle, il est attendu pour octobre 2015. Dès que j'aurai un article KB ou d'autres détails, je les ajouterai à ce post.

Espérons que ceux qui sont coincés avec Windows Server 2008 R2 pourront au moins résoudre ce problème avant la date limite de juin 2016, une fois que le correctif aura été publié.

MISE À JOUR : 19 septembre 2015

Microsoft a enfin publié un article d'assistance sur ce sujet. aquí et je peux confirmer qu'il fonctionne correctement.

Utilisez plutôt IPsec, comme le recommande le document : "Établir d'abord une session fortement cryptée (par exemple, un tunnel IPsec), puis envoyer des données via SSL à l'intérieur du tunnel sécurisé".

La principale raison de procéder ainsi plutôt que de configurer TLS pour RDP est que la conformité de la politique de pare-feu est facilement vérifiée (au lieu de prouver qu'un grand nombre de modifications du registre sont conformes) et qu'IPsec est assez facile à configurer dans Windows.

Si vous avez besoin d'une conformité totale à la suite B, IPSEC avec tls 1.0 est la seule façon d'appliquer les longueurs de certificats appropriées.

Il ne s'agit pas d'une réponse à la question, mais à la sous-question "Comment restaurer l'accès à distance à une machine virtuelle pour laquelle j'ai désactivé TLS 1.0 et qui n'a pas d'accès physique ?

J'ai désactivé TLS 1.0 en utilisant IISCrypto, qui a donné un avertissement utile sur l'effet secondaire que RDP cessera de fonctionner s'il est configuré sur TLS. J'ai donc vérifié :

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

et mon niveau de sécurité était réglé sur "Négocier". J'ai supposé que cela signifiait que si TLS n'était pas disponible, la sécurité RDP serait dégradée de manière élégante.

Mais non, Négocier ne fonctionne pas de cette manière. Vous devez définir le niveau de sécurité sur RDP Security, et non sur Negociate, avant de désactiver TLS 1.0.

J'ai donc perdu la possibilité de me connecter à distance à mon instance AWS !

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

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

net use \\lost_machine_ip\c$

3. J'ai ensuite ouvert Regedit et, dans le menu Fichier, j'ai choisi "Connecter le registre réseau" et j'ai entré l'adresse IP du serveur "perdu". Vous devriez voir le registre du serveur distant. Allez à :

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

et fixer la valeur de SecurityLayer à 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 devrez installer RDP 8.0 sur vos ordinateurs Windows 7 et vos serveurs Windows Server 2008 R2, puis activer RDP 8.0 dans la stratégie de l'ordinateur local ou la stratégie de groupe.

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

Une fois cette opération effectuée, vous devriez pouvoir désactiver TLS 1.0 sur les ordinateurs et les serveurs en modifiant le registre comme indiqué dans cet article de 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 RDP 8.1. RDP 8.0 contient à la fois les composants du protocole côté client et côté serveur, alors que RDP 8.1 ne comprend que le client. La 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 j'ai testé les connexions RDP avec le paramètre de stratégie de groupe "Require use of specific security layer for remote (RDP) connections" activé et défini sur "SSL (TLS 1.0)" pour m'assurer qu'il ne se rabattrait pas sur RDP Encryption.

MISE À JOUR 6/19/2015 :

J'ai enfin eu l'occasion de le tester sur l'un de nos serveurs Windows Server 2008 R2, et il interrompt définitivement les connexions RDP au serveur. Il semble que les composants RDP 8.0 côté serveur ne soient installés que sur les ordinateurs Windows 7 et qu'ils ne le soient pas sur les serveurs Windows Server 2008 R2.