FR 2988952 A1 20131004 FR 1252884 A 20120330 Changement de port TCP d'une connexion client/serveur La présente invention concerne la communication d'un équipement avec un serveur via un réseau, et plus particulièrement sa connexion au serveur par un port de connexion selon un protocole de contrôle de transmission, tel que par exemple le protocole TCP (pour « Transmission Control Protocol »). Dans le protocole TCP (situé au niveau de la couche de transport, entre la couche de réseau et une couche application), des applications transmettent des flux de données sur une connexion réseau, et le protocole TCP permet de découper un flux d'octets en segments. Le protocole TCP utilise la notion de numéro de port pour identifier les applications. À chaque extrémité de la connexion TCP, entre l'équipement client d'une part et le serveur d'autre part, est associé un numéro de port, généralement sur 16 bits (de 1 à 65535) assigné à l'application émettrice et/ou réceptrice. On connaît par exemple des ports assignés dans la plage 1-1024, pour des applications classiques fonctionnant en tant que serveur et en attente de connexions (par exemple FTP (pour File Transfer Protocol), SMTP (pour Simple Mail Transfer Protocol), ou encore HTTP (HyperText Transfer Protocol)). Bien entendu, le protocole TCP est appliqué dans de nombreuses autres applications. A titre purement illustratif et aucunement limitatif, le protocole Remote Framebuffer 3.8 (recommandation RFC6143, mars 2011), plus connu sous le nom de VNC (pour Virtual Network Computing) est largement répandu dans les applications de prise de contrôle à distance et de déport d'écran. Il apparait dans toutes sortes de produits d'administration et s'impose par exemple au coeur du protocole MirrorLink (anciennement Terminal Mode) destiné à faciliter la connexion de terminaux mobiles dans un véhicule automobile, pour en exploiter les applications et services de manière confortable sur un écran intégré de la planche de bord du véhicule. Le protocole VNC se compose de deux éléments : le serveur VNC, correspondant à un module logiciel installé et exécuté sur l'équipement dont on veut répliquer l'écran et auquel on souhaite envoyer des commandes : l'application serveur installée sur cet équipement se met en écoute sur le port 5900/tcp par défaut pour recevoir les requêtes des clients ; il convient de noter qu'un système peut héberger simultanément plusieurs serveurs VNC, auquel cas le serveur N écoute les connexions sur le port 5900+N/tcp ; le client VNC, correspondant à un module logiciel installé et exécuté sur l'équipement comportant l'écran d'accueil, pilote cet équipement pour se connecter au port 5900/tcp afin d'entrer en contact avec le serveur VNC et, de là, récupérer les données d'écran distant et de commandes tels les clics de souris, les appuis sur les touches d'un clavier, etc. Le serveur est toujours passif dans cette application notamment, en toutes circonstances. Seul le client peut prendre l'initiative de contacter un serveur VNC pour lui remonter des événements clavier/souris et/ou pour lire les éventuelles modifications intervenues sur l'écran de la machine distante. En d'autres termes, le client doit solliciter régulièrement le serveur pour être certain de posséder une copie à jour de l'écran. L'écoute du serveur VNC est limitée à un seul port par défaut (5900/tcp), sauf dans certaines situations, par exemple dans le cas d'une même machine hébergeant plusieurs serveurs VNC (le serveur N écoutant 5900+N/tcp). D'autres situations toutefois peuvent justifier un changement de numéro de port : par sécurité, on peut décider que le serveur VNC puisse répondre sur un port différent à intervalles réguliers, par exemple, afin d'éviter certaines attaques par déni de service, ou tout simplement pour rester aussi discret que possible. Or, le client ne peut pas deviner a priori sur quel port tel ou tel serveur VNC est configuré. Il en résulte une administration fastidieuse en termes de gestion d'un parc de serveurs VNC, consistant à dresser la liste des serveurs VNC et de leurs ports d'écoute respectifs, et à en informer le ou les clients. Cette solution, si elle peut être envisagée dans un cadre industriel, ne peut être mise en oeuvre dans un cadre domestique, où un minimum de connaissances techniques est requis par des utilisateurs. La présente invention vient améliorer la situation. Elle propose à cet effet un procédé de connexion entre au moins un premier et un deuxième équipement, pour une communication selon un mode client et serveur utilisant un protocole de contrôle de transmission, le procédé comportant une première connexion entre les équipements sur un premier port de connexion prédéterminé Le procédé au sens de l'invention comporte les étapes de : transmission du premier équipement au deuxième équipement d'un message de changement de port de connexion, comportant une valeur définissant un deuxième port de connexion, test du message auprès du deuxième équipement, et le message étant validé auprès du deuxième équipement, transmission d'un message de validation du deuxième équipement au premier équipement, deuxième connexion des premier et deuxième équipements sur le deuxième port de connexion. Ainsi, l'invention permet au client et au serveur de se repérer et de se connecter dans un réseau sans requérir d'intervention humaine, et ce indépendamment du numéro de port en écoute sur le serveur. Avantageusement, communiquer ensuite sur un port dédié permet d'améliorer la sécurité de la communication et de la rendre plus robuste aux intrusions. Par exemple, le protocole de contrôle de transmission précité peut être le protocole TCP et ainsi, le premier port de connexion précité peut être par exemple le port 5900/tcp. Dans une réalisation, le premier équipement qui prend l'initiative de transmettre la requête de changement de port correspond au serveur et comporte à cet effet un module serveur, tandis que le deuxième équipement comporte un module client, pour une mise en oeuvre de la communication précité selon un mode client/serveur. Néanmoins, comme on le verra en détails plus loin, les rôles du client et du serveur pour prendre l'initiative d'émettre la requête de changement de port peuvent être inversés. Dans une réalisation, l'équipement serveur parmi les premier et deuxième équipements garde une connexion ouverte sur le premier port, en tant que port par défaut, pour une communication éventuelle avec au moins un autre équipement client. Cette réalisation permet un fonctionnement autonome, sans faire appel à une infrastructure logicielle de publication et de configuration de service comme dans de nombreux protocoles. Dans une réalisation, l'étape de deuxième connexion sur le deuxième port comporte les opérations : sur réception du message de validation, le premier équipement ferme la première connexion avec le premier équipement sur le premier port, et le deuxième équipement envoie un message de demande de connexion sur le deuxième port. Cette réalisation assure une sécurité supplémentaire en cas de connexions supplémentaires intruses. Dans une réalisation, les étapes de première et deuxième connexions respectivement sur les premier ou deuxième ports comportent les opérations : envoi par le deuxième équipement au premier équipement d'un message de demande de connexion sur le premier ou le deuxième port, vérification auprès du premier équipement de données du message de demande de connexion, pour autoriser ou refuser une connexion avec le deuxième équipement, et la vérification étant positive, établissement de la connexion entre les premier et deuxième équipements. Par exemple, l'opération de vérification peut comporter une négociation/authentification pour s'assurer que le deuxième équipement (typiquement l'équipement client) est bien un équipement autorisé. Dans une réalisation, la communication entre les premier et deuxième équipements utilise un protocole de contrôle à distance d'au moins une fonctionnalité de l'un des premier et deuxième équipements par l'autre des premier et deuxième équipements. En particulier, le premier équipement comportant un module serveur et le deuxième équipement comportant un module client, l' autre des premier et deuxième équipements est le deuxième équipement (équipement client). Le protocole de contrôle à distance peut être par exemple le protocole VNC. Une telle application au protocole VNC permet avantageusement de limiter toute prise de contrôle, par exemple de commande et/ou d'affichage sur écran, par un équipement pirate. Dans une réalisation, la valeur définissant le deuxième port de connexion précité, comporte une première valeur identifiant un type de message correspondant à un message de demande de changement de port (une simple valeur codée sur un octet par exemple) et une deuxième valeur correspondant à un numéro du deuxième port. Par exemple, la deuxième valeur peut être simplement un entier codé sur 16 bits, compris entre 0 et 65535, préférentiellement entre 1025 et 65535. La présente invention vise aussi un programme informatique comportant des instructions (distribuées entre les premier et deuxième équipements par exemple) pour la mise en oeuvre du procédé ci-avant, lorsque ce programme est exécuté par un processeur. A ce titre, la figure 3 commentée ci-après correspond à un organigramme de l'algorithme général d'un tel programme La présente invention vise aussi un système comportant au moins un premier et un deuxième équipement, communiquant selon un mode client et serveur et utilisant un protocole de contrôle de transmission, les premier et deuxième équipements comportant en particulier des moyens pour, conjointement, suite à une première connexion entre les équipements sur un premier port de connexion prédéterminé - - transmettre, du premier équipement au deuxième équipement, un message de changement de port, comportant une valeur définissant un deuxième port de connexion, - tester le message auprès du deuxième équipement, et le message étant validé auprès du deuxième équipement, transmettre un message de validation du deuxième équipement au premier équipement, - établir une deuxième connexion des premier et deuxième équipements sur le deuxième port précité. La présente invention vise aussi un équipement requérant un changement de port dans un système selon l'invention, et comportant à cet effet des moyens pour : - transmettre, du premier équipement au deuxième équipement, un message de changement de port, comportant une valeur définissant un deuxième port de connexion, et - sur réception d'un message de validation du deuxième équipement, établir une deuxième connexion sur le deuxième port. La présente invention vise aussi un équipement traitant une requête de changement de port dans un système selon l'invention, et comportant à cet effet des moyens pour : - recevoir du premier équipement un message de changement de port, comportant une valeur définissant un deuxième port de connexion, - tester le message et, le message étant validé, transmettre un message de validation au premier équipement, - traiter une demande d'établissement d'une deuxième connexion sur le deuxième port, reçue du premier équipement. Bien entendu, chacun de ces équipements comporte des moyens logiciels tels que des instructions du programme informatique précité, ces instructions étant exécutées par des moyens physiques tels qu'au moins un processeur (PROC ; PROC', en référence à la figure 1) et une mémoire de travail (MEM ; MEM'). D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels : - la figure 1 illustre un système au sens de l'invention pour mettre en oeuvre une application dans le cadre du protocole VNC, - la figure 2 illustre les messages échangés entre les deux équipements du système de la figure 1, pour un changement de port de connexion, et - la figure 3 illustre les principales étapes mises en oeuvre pour ce changement de port. On présente ci-après à titre d'exemple illustratif une application de l'invention dans le cadre de la norme VNC (« Virtual Network Computing »). Comme indiqué ci-avant, cette norme spécifie un protocole permettant de déporter les fonctionnalités COM d'un ensemble d'écran ECR1 et de moyens de commande de type clavier/souris Cl d'une machine Ml, comme illustré sur la figure 1, sur une autre machine M2 (par exemple un écran tactile ECR2) de manière à ce que la machine M2 prenne le contrôle à distance de la machine M1. Cette norme VNC définit un serveur SER (application installée dans la machine à contrôler Ml) et un client CLI (application installée dans la machine M2 qui prend le contrôle de la machine M1). En fonctionnement, le serveur SER se met en écoute du port 5900/tcp pour recevoir les requêtes de contrôle du client CLI adressées sur ce port spécifique. Régulièrement, le client CLI interroge le serveur SER à travers le port 5900/tcp (portant la référence Pl sur la figure 1) de la machine M1 afin de rafraîchir l'écran et le clavier. L'invention propose de changer de port d'écoute, par négociation entre le client CLI et le serveur SER. A cet effet, le serveur SER envoie au client CLI un nouveau message indiquant un nouveau numéro de port d'écoute. Le changement de port peut être réalisé en phase initiale de configuration et/ou ultérieurement pendant la période de contrôle à distance, éventuellement à intervalles réguliers. Cette réalisation permet notamment de limiter les risques de piratage par prise de contrôle. Il est ainsi proposé d'augmenter le protocole VNC avec la capacité de négocier un nouveau numéro de port TCP sur lequel interroger le serveur SER. On définit à cet effet un cinquième message, identifié par un entier entre 7 et 255, et appelé ci-après ServerPortChange (la valeur 7 est la première immédiatement disponible dans la liste des messages que peut envoyer un client vers le serveur VNC). Il est composé comme suit : Nombre d'octets Type Description [Valeur] 1 U8 [7] Type du message, par exemple ici ServerPortChange = 7 2 U16 Numéro du port TCP sur lequel le serveur VNC écoute désormais les demandes de connexion. Il s'agit d'un entier codé sur 16 bits et pouvant donc aller de 0 jusqu'à 65535, ou préférentiellement de 1025 à 65535 pour réserver les premières valeurs 0 à 1024 à des applications habituelles comme indiqué précédemment. Ce message peut être envoyé à tout moment par le serveur au client, après ou pendant la phase d'initialisation décrite ci-après en référence aux figures 2 et 3. Lors de cette phase d'initialisation, à l'étape S 1 , le client CLI contacte d'abord le serveur SER sur le port habituel 5900/tcp. Il s'ensuit, une phase classique d'authentification et de négociation à l'étape S2 qui permet au serveur SER de s'assurer que le client CLI est bien un client autorisé. Une fois cette phase S2 réalisée, le serveur peut souhaiter changer de numéro de port, pour la communication avec le client CLI. A cet effet, il envoie au client à l'étape S3 le message ServerPortChange avec un nouveau numéro de port, par exemple 6427. La valeur du message ServerPortChange peut être par exemple le chiffre 7, suivi de la valeur codée sur 16 bits de 6427, les deux derniers octets du message codant le nouveau numéro de port sur 16 bits. Si le client CLI ne reconnaît pas ce nouveau message (par exemple en raison de versions de protocole différentes), il ne répond rien ou retourne un message d'erreur, ce que le serveur interprète comme un refus (flèche en traits pointillés sur la figure 3). Dans ce cas, le port de connexion reste le port 5900/tcp et la session se poursuit sur ce port. En revanche, si le client CLI reconnaît le message ServerPortChange, il répond à l'étape S4 par un accusé de réception validant la demande du serveur. Le serveur peut alors mettre fin à la connexion initiale sur l'ancien port 5900/tcp, et attendre que le client le recontacte sur le nouveau port 6427/tcp (dans l'exemple ici). La session se poursuit alors normalement sur ce nouveau port 6427/tcp. Le serveur peut, selon la politique de fonctionnement ou de sécurité mise en oeuvre, fermer ensuite le port 5900/tcp à l'étape S5 pour se mettre notamment à l'abri de connexions supplémentaires ou, au contraire, attendre de nouvelles connexions sur le port 5900/tcp pour les router ensuite sur un autre numéro de port. Ainsi, sur réception d'un message, le client CLI peut se comporter de deux manières différentes : s'il ne connaît pas le message ServerPortChange (échec au test T34 de la figure 3), il l'ignore : le serveur, ne recevant pas de réponse, comprend que le client ne sait pas traiter le message et continue la communication sur le port 5900/tcp ; s'il connaît le message ServerPortChange (réussite au test T34 de la figure 3), il répond par une validation (étape S4) : le client prend note du changement de port, coupe le lien actuel avec le serveur sur le port 5900/tcp, et recontacte le serveur sur le nouveau numéro de port 6427/tcp. Dans un exemple de réalisation, un nouveau cycle d'initialisation peut avoir lieu aux étapes S6 et S7 (message de connexion sur le nouveau port 6427/tcp du client au serveur et vérification auprès du serveur de l'autorisation du client). Les échanges se poursuivent ensuite normalement.35 Il convient de noter qu'il est possible d'inverser les échanges et d'autoriser le client à émettre une telle demande de changement de port auprès du serveur. Les rôles sont alors simplement inversés, mais le résultat (changement du numéro de port TCP sur le serveur) reste le même. Dans la réalisation ci-avant, il convient de noter qu'il est recommandé de n'échanger un message de changement de port ServerPortChange qu'après la phase d'initialisation, et donc après authentification et ouverture d'un lien permanent TCP. Une telle réalisation permet de mettre le serveur à l'abri de changements de port hostiles (par exemple destinés à le rendre inaccessible). Le serveur doit continuer à écouter le port par défaut 5900/tcp, en plus du nouveau port qu'il a choisi, ce qui permet à d'éventuels nouveaux clients de se connecter normalement avant d'être redirigés vers un nouveau numéro de port. Cette technique permet un fonctionnement autonome, sans faire appel à une infrastructure logicielle de publication et de configuration de service comme dans les protocoles UPnP ou DLNA. La possibilité de changer de numéro de port d'écoute sur le serveur ouvre la voie à des techniques de protection de communication. Même si le port 5900/tcp reste ouvert initialement dans la présente réalisation, il peut être mis en oeuvre une réalisation dans laquelle le client et le serveur négocient un nouveau numéro de port à la première connexion, puis n'en changent plus ultérieurement. Le serveur se met ainsi à l'abri de tentatives de connexion hostiles et libère le port 5900/tcp. L'implémentation du nouveau message de changement de port « ServerPortChange » notamment dans la norme RFB 3.8 est très simple à réaliser, puisque la modification n'affecte qu'un seul paramètre. Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemple ; elle s'étend à d'autres variantes. Ainsi, on comprendra que l'invention s'applique à tout équipement communicant, comportant une interface graphique et connectable à un réseau selon le protocole IP (pour Internet Protocol), par exemple un terminal mobile par exemple de type Smartphone, une tablette, un ordinateur PC, un écran de télévision, ou autre. Un tel équipement peut mettre en oeuvre des applications selon le protocole particulier VNC (notamment RFB 3.8). Ainsi, le protocole VNC peut être enrichi par la mise en oeuvre de l'invention par exemple sous la forme d'extension de ce protocole. Néanmoins, l'invention ne se limite pas à une application dans ce protocole VNC. D'autres applications sont possibles. Par exemple, dans le cadre de la communication de courriers électroniques, le protocole de transfert de courrier, dit « simple » (pour « Simple Mail Transfer Protocol » ou « SMTP »), est un protocole de communication utilisé pour transférer le courrier électronique (courriel) vers des serveurs de messagerie électronique, et dans lequel on commence par spécifier l'expéditeur du message puis, le ou les destinataires d'un message, puis le corps du message est transféré. On peut commencer par tester un serveur SMTP en utilisant une commande telnet par exemple, sur le port 25 du serveur distant, puis changer le numéro de port TCP pour la communication du courriel et assurer ainsi une sécurité supplémentaire de cette communication, avec une mise en oeuvre de changement de port au sens de l'invention. REVENDICATIONS1. Procédé de connexion entre au moins un premier et un deuxième équipement, pour une communication selon un mode client et serveur utilisant un protocole de contrôle de transmission, le procédé comportant une première connexion (S1, S2) entre les équipements sur un premier port de connexion prédéterminé, caractérisé en ce que le procédé comporte les étapes : transmission du premier équipement au deuxième équipement d'un message de changement de port de connexion (S3), comportant une valeur définissant un deuxième port de connexion, test du message auprès du deuxième équipement (T34), et le message étant validé auprès du deuxième équipement, transmission d'un message de validation du deuxième équipement au premier équipement (S4), deuxième connexion des premier et deuxième équipements sur le deuxième port de connexion (S6, S7). 2. Procédé selon la revendication 1, caractérisé en ce que le premier équipement comporte un module serveur (SER) et le deuxième équipement comporte un module client (CLI), pour une mise en oeuvre de ladite communication selon un mode client/serveur. 3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que l'équipement serveur parmi les premier et deuxième équipements garde une connexion ouverte sur le premier port, en tant que port par défaut, pour une communication éventuelle avec au moins un autre équipement client. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que l'étape de deuxième connexion sur le deuxième port comporte les opérations : sur réception du message de validation, le premier équipement ferme la première connexion avec le premier équipement sur le premier port (S5), et le deuxième équipement envoie un message de demande de connexion sur le deuxième port (S6). 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que les étapes de première et deuxième connexions respectivement sur les premier ou deuxième ports comportent les opérations : envoi par le deuxième équipement au premier équipement d'un message de demande de connexion sur le premier ou le deuxième port (51 ; S6), vérification auprès du premier équipement de données du message de demande de connexion, pour autoriser ou refuser une connexion avec le deuxième équipement, etla vérification étant positive, établissement de la connexion entre les premier et deuxième équipements. 6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que la communication entre les premier et deuxième équipements utilise un protocole de contrôle à distance d' au moins une fonctionnalité de l'un des premier et deuxième équipements par l'autre des premier et deuxième équipements. 7. Procédé selon la revendication 6, caractérisé en ce que le premier équipement comporte un module serveur (SER) et le deuxième équipement comporte un module client (CLI), et en ce que ledit autre des premier et deuxième équipements est le deuxième équipement (CLI). 8. Procédé selon l'une des revendications 6 et 7, caractérisé en ce que le protocole de contrôle à distance est le protocole VNC. 9. Procédé selon l'une des revendications précédentes, caractérisé en ce que le protocole de contrôle de transmission est le protocole TCP. 10. Procédé selon l'une des revendications précédentes, caractérisé en ce que la valeur définissant le deuxième port de connexion, comporte une première valeur identifiant un type de message correspondant à un message de demande de changement de port (ServerPortChange) et une deuxième valeur correspondant à un numéro du deuxième port. 11. Procédé selon la revendication 10, caractérisé en ce que la deuxième valeur est un entier codé sur 16 bits, compris entre 0 et 65535, et préférentiellement entre 1025 et 65535. 12. Programme informatique comportant des instructions pour la mise en oeuvre du procédé selon l'une des revendications précédentes, lorsque ce programme est exécuté par un processeur. 13. Système comportant au moins un premier et un deuxième équipement, communiquant selon un mode client et serveur et utilisant un protocole de contrôle de transmission, caractérisé en ce que les premier et deuxième équipements comportent des moyens pour, suite à une première connexion entre les équipements sur un premier port de connexion prédéterminé - transmettre, du premier équipement au deuxième équipement, un message de changement de port (S3), comportant une valeur définissant un deuxième port de connexion,tester le message auprès du deuxième équipement (T34), et le message étant validé auprès du deuxième équipement, transmettre un message de validation du deuxième équipement au premier équipement (S4), établir une deuxième connexion des premier et deuxième équipements sur le deuxième port de connexion (S6, S7). 14. Equipement requérant un changement de port dans un système selon la revendication 13, caractérisé en ce qu'il comporte des moyens pour : transmettre, du premier équipement au deuxième équipement, un message de changement de port (S3), comportant une valeur définissant un deuxième port de connexion, et sur réception d'un message de validation du deuxième équipement, établir une deuxième connexion sur le deuxième port (S6, S7). 15. Equipement traitant une requête de changement de port dans un système selon la revendication 13, caractérisé en ce qu'il comporte des moyens pour : recevoir du premier équipement un message de changement de port (S3), comportant une valeur définissant un deuxième port de connexion, tester le message (T34) et, le message étant validé, transmettre un message de validation au premier équipement (S4), traiter une demande d'établissement d'une deuxième connexion sur le deuxième port (S6, S7), reçue du premier équipement.