Quelle est la sécurité de la connexion Bureau à distance?


8

Lors de l'utilisation de la connexion Bureau à distance, les informations sont-elles envoyées dans les deux sens en toute sécurité, comme dans SSL? Les noms d'utilisateur et les mots de passe sont-ils sécurisés? Lors de la connexion à un serveur distant via Connexion Bureau à distance, le serveur doit-il utiliser, au minimum, un certificat SSL auto-signé afin de sécuriser les données envoyées dans les deux sens? Je veux simplement savoir si mes informations passant par la connexion Bureau à distance sont sécurisées ou non. Je me connecte d'un PC Win7 à un serveur Web Windows 2008 R2. Merci de votre aide!

Réponses:


3

par défaut, la connexion est cryptée SSL avec un certificat auto-signé. vous devriez et un avertissement sur la première connexion ou éventuellement sur chaque connexion à ce sujet. Vous pouvez utiliser un certificat signé si vous êtes paranoïaque.


Cette fonctionnalité spécifique est uniquement disponible sur Server 2003 x64, Vista et versions ultérieures. En outre, je crois que le client XP RDC n'a pas la possibilité de vérifier même s'il se connecte à des ordinateurs plus récents, de sorte que chaque connexion peut être à risque.
penguin359

1
Et dans la question d'origine, l'affiche a mentionné qu'il se connectait de Win7 à Server 2008 R2, ce qui devrait être bien.
Ryan Bolger

Oui Chris, alors que beaucoup de ces informations historiques sont intéressantes, elles ne sont pas pertinentes pour votre scénario. Si vous êtes simplement intéressé par Win7 parlant à 2008R2, alors TLS 1.0 SSL est la valeur par défaut et très sécurisée, et la réponse d'Ollybee est correcte.
Bret Fisher

2

RDP peut utiliser le cryptage RC4 128 bits. D'après ce que je comprends, RC4 n'est pas considéré comme aussi fort que AES pour la même longueur de clé, mais je ne suis pas un cryptographe. Cette fonctionnalité est présente depuis XP, mais elle n'est pas requise. La stratégie de groupe par défaut permet un chiffrement minimal ou nul pour la compatibilité. Malheureusement, jusqu'à Server 2003 SP1, alors qu'il était crypté, il n'y avait pas d'authentification de la connexion car il utilisait une clé privée codée en dur. (Je ne fais pas référence à l'invite de connexion une fois la connexion établie, mais pendant la tentative de connexion.) Cela signifie que vous ne pouvez pas être sûr de parler réellement au vrai serveur RDP. Vous pourriez être soumis à une attaque d'homme au milieu où vous venez de négocier une connexion chiffrée avec un tiers malveillant qui déchiffre tout, puis le rechiffre pour l'envoyer au vrai serveur. Cela ne peut se produire qu'au premier contact. Si vous vous êtes effectivement connecté et avez négocié le chiffrement avec le vrai serveur, vous êtes en sécurité, au moins jusqu'à ce que vous essayiez de vous reconnecter. À partir de Server 2003 SP1 et Vista, TLS a été ajouté et un certificat est généré automatiquement utilisé pour signer la négociation de connexion. Vous devez toujours savoir ce qu'est le certificat, mais il peut être stocké pour vérifier les connexions futures. Idéalement, le certificat sera signé par l'autorité de certification interne pour votre domaine, mais sans PKI, vous pouvez toujours être soumis à l'homme du milieu lors de la toute première connexion, sauf si vous vérifiez l'empreinte digitale.


Pour ajouter à cela; RC4 n'est pas «sûr» de nos jours. En raison de son utilisation dans le cryptage WEP Wifi, beaucoup de temps et d'énergie ont été consacrés au développement de meilleures attaques contre les failles mathématiques de RC4. Pour les mêmes raisons que le WEP est une très mauvaise idée de nos jours, il en va de même pour RC4.
Shane Madden

2
@Shane WEP était également une mauvaise implémentation de RC4, ce n'était pas entièrement la faute de RC4 quand on n'utilisait qu'une clé 40 bits et une graine 24 bits. Mais, RC4 vieillit un peu maintenant.
penguin359

Oh, je devrais ajouter cet article: mobydisk.com/techres/securing_remote_desktop.html
penguin359
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.