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.