grdpwasm - Client RDP basé sur le web

 (github.com/nakagami)
8 points par GN⁺ 4 일 전 | 2 commentaires | Partager sur WhatsApp
  • Un client RDP basé sur le web permettant de se connecter à un Bureau à distance Windows depuis un simple navigateur, sans plugin
  • Sépare le Go WebAssembly côté navigateur et un proxy WebSocket-vers-TCP côté serveur, qui prend en charge à la place du navigateur les connexions TCP RDP qu’il ne peut pas ouvrir directement
  • La connexion suit le flux Browser -> WebSocket -> proxy -> TCP -> RDP Server ; une fois connecté, l’écran distant s’affiche dans un canvas et les entrées clavier/souris sont transmises
  • Les périphériques d’entrée prennent en charge un clavier basé sur les RDP scan codes ainsi qu’une souris avec déplacement, clic et molette ; l’audio distant est reçu via RDPSND puis lu avec la Web Audio API
  • Comme l’architecture du proxy autorise toutes les origins, il faut l’exécuter uniquement sur un réseau de confiance ou ajouter HTTPS/WSS et une couche d’authentification avant toute exposition externe

Vue d’ensemble du projet

  • Fonctionne comme un client RDP basé sur le web permettant d’accéder à un Bureau à distance Windows depuis le navigateur, sans plugin
  • L’implémentation repose sur la combinaison de Go WebAssembly et de grdp, avec une architecture séparant la partie exécutée dans le navigateur et le composant proxy intermédiaire
  • Comme le navigateur ne peut pas ouvrir directement de socket TCP brute, un proxy Go léger est nécessaire pour relier la connexion WebSocket au port TCP du serveur RDP

Architecture et mode de fonctionnement

  • Le chemin complet suit l’ordre Browser (WASM) -> WebSocket -> proxy (Go) -> TCP -> RDP Server
  • Dans le navigateur, c’est le binaire WASM qui s’exécute, tandis que le proxy joue à la fois le rôle de pont WebSocket-vers-TCP et de serveur de fichiers statiques
  • Le résultat de make all est réparti entre static/main.wasm, exécuté dans le navigateur, static/wasm_exec.js, fichier d’assistance au runtime Go, et proxy/proxy, le serveur proxy
  • Grâce à cette structure, la partie navigateur gère la connexion avec des technologies web standard, tandis que le proxy prend en charge la communication TCP réelle avec le serveur RDP

Flux d’utilisation et interface utilisateur

  • Ouvrez http://localhost:8080 dans le navigateur, saisissez les valeurs Host, Port, Domain, User, Password, Width, Height dans le formulaire de connexion, puis cliquez sur Connect pour démarrer la session
  • La valeur par défaut de Port est 3389, et Domain peut être laissé vide en cas d’utilisation d’un compte local
  • Une fois la connexion établie, le Bureau à distance s’affiche dans le canvas ; pour recevoir les entrées clavier, il faut cliquer sur le canvas
  • Cliquez sur Disconnect pour terminer la session

Périphériques d’entrée et prise en charge audio

  • Toutes les entrées clavier standard sont transmises au Bureau à distance via les RDP scan codes
  • La souris prend en charge le déplacement, les clics de bouton et la molette de défilement
  • L’onglet du navigateur doit avoir le focus pour que les événements clavier soient transmis ; si la saisie s’interrompt, il faut recliquer dans la zone du canvas
  • L’audio distant est diffusé via RDPSND et lu dans le navigateur avec la Web Audio API
    • Le format audio est indiqué comme PCM 44100 Hz, stereo, 16-bit signed little-endian

Conditions d’exploitation et points de vigilance en matière de sécurité

  • Les prérequis sont Go 1.24 ou supérieur et un serveur RDP accessible ; le serveur cible peut être Windows ou tout hôte compatible RDP
  • Le proxy autorise les connexions depuis toutes les origins ; il doit donc être exécuté uniquement sur un réseau de confiance ou complété par une couche d’authentification avant exposition à Internet
  • Les identifiants étant transmis du navigateur au proxy via WebSocket, l’utilisation de HTTPS/WSS est nécessaire sur les réseaux non fiables
    • Le README mentionne aussi la possibilité d’utiliser un reverse proxy avec terminaison TLS comme nginx ou Caddy

Exécution et informations complémentaires

  • L’exécution est possible via make serve ou ./proxy/proxy -listen :8080 -static static
  • Les options du proxy permettent de définir l’adresse et le port d’écoute avec -listen, ainsi que le répertoire de fichiers statiques avec -static
  • Les cibles de développement sont réparties entre make wasm pour reconstruire uniquement le WASM, make proxy pour reconstruire uniquement le proxy, make wasm_exec pour mettre à jour wasm_exec.js, et make clean pour supprimer les artefacts
  • La licence est GPLv3, avec une référence supplémentaire à la licence de grdp

À lire aussi

2 commentaires

 
yeobi222 2 일 전

Mais honnêtement, je ne vois pas le véritable avantage.
Au final, ce n’est qu’un client, donc il ne peut pas non plus imposer des exigences côté serveur.
Et ce n’est même pas accessible uniquement avec un navigateur pur.
 
GN⁺ 4 일 전
Commentaires sur Hacker News

  • Ça a l’air plutôt sympa. Avec la prise en charge de l’enregistrement de session et de l’authentification SSO, ça pourrait être utilisé directement comme hôte de rebond RDP.
    J’ai déjà utilisé quelque chose de similaire avec Azure Bastion : on se connecte au portail Azure avec la méthode d’authentification configurée pour le tenant, puis on ouvre une session RDP vers la VM dans le navigateur, avant de se connecter avec un compte local côté VM. La gestion des fichiers et du presse-papiers fonctionne plutôt bien, et les sessions console sont aussi prises en charge dans le navigateur.
    Je ne sais pas si c’est possible côté Windows/RDP car je ne l’ai pas testé, mais le SSH dans le navigateur de GCP était de loin l’une des meilleures implémentations que j’aie vues jusqu’à présent.
    Même sur Linux, j’ai parfois trouvé que xrdp était meilleur que d’autres alternatives.
    L’une des grandes valeurs que cela apporte, c’est la séparation de l’interface d’administration des VM/serveurs. Rien que le fait que le service d’administration d’un serveur web ne soit pas exposé sur la même IP, le même domaine ou la même interface que le service HTTP améliore considérablement la sécurité.

    • Pour cet usage, nous utilisons Apache Guacamole avec notre proxy OIDC.

  • Le presse-papiers dans un RDP de navigateur est un cauchemar discret. La négociation du protocole réseau elle-même fonctionne bien, mais l’API Clipboard côté navigateur est contrainte par les permissions et les exigences de geste utilisateur.
    Pour la lecture, la plupart des navigateurs demandent pratiquement une confirmation à l’utilisateur à chaque fois. Du coup, il faut soit créer un tampon de presse-papiers séparé dans la page, soit accepter que le collage vers l’intérieur du RDP soit fluide mais que la copie depuis le RDP vers l’extérieur exige un clic à chaque fois.
    Aucune de ces solutions ne correspond vraiment au comportement que les gens attendent d’un client RDP web. Avant de considérer cela comme équivalent au mstsc natif, il faut absolument vérifier comment le comportement diffère entre Chrome et Firefox.

    • Ce n’est pas forcément le cas. Google Docs, Office 365 et Notion fonctionnent sans redemander l’autorisation en permanence.

  • Depuis que HP a abandonné Anyware / Teradici / PCoIP, beaucoup de gens cherchent une alternative. Il y a notamment un vrai besoin pour les configurations avec multi-écrans haute résolution, 60fps, lecture à grande profondeur de bits, prise en charge des tablettes Wacom et compatibilité avec les trois OS.
    Côté solutions payantes, il y a Parsec et DCV, et c’est encourageant de voir des initiatives open source. Avec des projets comme rustdesk, kyber et teraguchi, la communauté a clairement besoin d’options open source performantes.
    https://github.com/rustdesk/rustdesk
    https://github.com/thedepartmentofexternalservices/teraguchi
    https://kyber.tech/

    • À noter que DCV est gratuit sur EC2 et que, dans d’autres environnements aussi, l’avertissement en l’absence de licence reste très discret.

  • Ça a l’air intéressant, mais je suis surpris que la fonction la plus importante ne soit pas mentionnée. Je me demande à quel point le partage du presse-papiers fonctionne bien en pratique.

    • Je n’aime pas particulièrement Windows, mais le fait de pouvoir copier-coller des fichiers en naviguant à travers des sessions RDP imbriquées sur 3 niveaux me semble toujours magique.
    • Nous développons aussi un client RDP sur mesure, donc nous avons un peu d’expérience sur ce type d’implémentation. Nous avons procédé d’une manière similaire.
      Le partage du presse-papiers ainsi que l’upload/download via des lecteurs partagés sont des fonctionnalités de FreeRDP, donc relativement faciles à exploiter telles quelles.
      Et l’enregistrement de session est non négociable dans un environnement PAM.
      [1] https://adaptive.live

  • La mise à l’échelle du bureau, la prise en charge du multi-écran, le transfert de fichiers, la redirection de lecteurs et la redirection de périphériques sont tous importants.

  • Je me demande aussi si cela fonctionne pour ouvrir les fichiers RDP reçus depuis CyberArk PAM.

  • Je me demande également si le client RDP peut intercepter Alt-Tab à l’intérieur d’un onglet du navigateur.
    C’était autrefois le principal problème du RDP navigateur de Guacamole.

  • C’est intéressant techniquement, mais comme il existe déjà des clients RDP natifs sur presque toutes les plateformes, je ne vois pas très bien pourquoi ce serait nécessaire.

    • Si ça fonctionne dans le navigateur, il n’y a rien à installer sur la machine locale. À l’époque où j’étais coincé dans un box au bureau, j’utilisais souvent Apache Guacamole pour accéder à mon ordinateur à la maison.
      https://guacamole.apache.org/
    • Un seul contributeur, un seul commit, projet tout neuf : ça donne un peu une impression de vibe-coding.
    • Le navigateur est une sandbox, alors que les clients natifs ne le sont généralement pas, donc l’avantage est réel. Il y a aussi la portabilité, la facilité d’intégration embarquée, et il est plus simple d’inspecter le trafic ou de faire du MITM.
    • Il n’y a pas beaucoup de bonnes options de MFA pour les RDP/RDG natifs. En passant par le navigateur, on peut encapsuler l’ensemble avec OAuth ou des passkeys.
    • Ça pourrait aussi servir de client web pour des bureaux distants connectés à des puces BMC.