Figure 1: Architecture générale du réseau MSN Messenger
Depuis la fin des années 90, l’utilisation des logiciels de dialogue en direct s’est répandu au sein des université puis des entreprises. Des logiciels tels que ICQ, AOL Instant Messenger ou MSN Messenger – pour ne citer qu’eux – permettent à leurs utilisateurs de dialoguer par message texte interposé, de s’échanger des fichiers voire même désormais de faire de la visioconférence. Ces outils peuvent réduire de manière significative les factures de télécommunication des entreprises surtout lorsque celle-ci souhaite faire travailler ensemble des équipes transnationales. Cependant, ils risquent de faire chuter considérablement la productivité des équipes et peuvent faciliter la divulgation d’information ou de fichiers confidentiels. Par ailleurs, nous verrons plus loin que le fonctionnement de ces logiciels ne garantie aucune confidentialité en dehors de l’entreprise.
Ces logiciels sont également utilisés par le grand public dont de jeunes enfants. Ils peuvent leurs permettre de travailler à plusieurs sur un exercice ou un exposé en étant chacun chez soi et également leur permettre de discuter et faire des rencontres, ce qui peut éventuellement poser un problème aux parents.
En somme, bien utilisé ces logiciels sont très utiles et accroissent la productivité ; mal utilisé ils représentent une perte de temps et un danger. Il serait donc intéressant pour un administrateur, ou un parent très informé, de limiter l’utilisation du logiciel et filtrer les données pouvant sortir plutôt que de totalement en interdire l’utilisation.
L’objectif de ce projet est donc de fournir un système permettant de contrôler l’utilisation d’un logiciel de messagerie instantanée par la surveillance des heures de connexion, des durées passées à dialoguer, de la liste des interlocuteurs et éventuellement la possibilité de censurer certains mots-clés particuliers tels qu’un numéro de carte bancaire. Par ailleurs, il serait intéressant que ce système puisse améliorer la confidentialité des conversations entre les employés d’une même entreprise.
Le choix a été fait de créer un serveur permettant d’encadrer l’utilisation de MSN Messenger, le logiciel de Microsoft, en effet celui-ci est leader en France. ICQ qui était le pionner du dialogue en direct a depuis été racheté par la société AOL et n’a plus été maintenu. Le logiciel d’AOL est relativement peu utilisé en France comparé à MSN Messenger même s’il reste leader sur le continent américain. Il faut d’ailleurs noter que ce dernier offre la possibilité de crypter les informations transmises sur le réseau.
Différentes versions de MSN Messenger sont actuellement utilisées, elles peuvent utiliser différentes version du protocole MSNP (MSN Protocol).C’est pourquoi durant la phase de connexion, chaque client s’accorde avec le serveur pour savoir quelle version il utilisera. La dernière version dont on dispose d’informations suffisante est la version 15. Les versions 8, 9 et 11 sont utilisés par les clients Windows Messenger, MSN Messenger et la plupart des clients compatibles. Les versions 13 et 15 ne sont pour l’instant utilisés que par Windows Live Messenger. On remarquera qu’il n’a pas été fait référence aux versions 10, 12 et 14, cela est dû à l’absence de documentation sur ces versions qui ont soit eu une très courte durée de vie ou n’ont tout simplement pas été utilisés dans une version finale d’un client Microsoft.
Pour comprendre l’infrastructure choisie, il faut garder à l’esprit que ce protocole a été conçu pour pouvoir supporter plusieurs millions d’utilisateurs connectés en même temps dans le monde et pouvant souhaiter discuter avec un nombre important d’utilisateurs vivant dans des régions pouvant être très éloignées.
Pour mettre en œuvre son système de messagerie instantanée, Microsoft utilise donc 3 types de serveurs (cf. Figure 1), un « Dispatch Server », de nombreux « Notification Server » ainsi que de nombreux « Switchboard ». Le « Dispatch Server » est le premier serveur contacté par les clients MSN, il est chargé de rediriger ceux-ci vers un « Notification Server » qui ne soit pas trop encombré et si possible proche géographiquement de l’utilisateur. Les « Notification Server » dialoguent tout le temps de la connexion de l’utilisateur avec celui-ci, l’informant de demandes de conversation, de la connexion ou non des contacts de sa liste d’amis et recevant ses demandes d’ouverture de conversation. Ils peuvent également envoyer des messages au client pour l’informer de messages e-mail reçus. Un client est donc connecté tout au long de sa session avec un et un seul « Notification Server », généralement celui indiqué par le « Dispatch Server ».
Il est à noter que la distinction entre « Dispatch Server » et « Notification Server » se remarque que dans le sens ou le premier possède une adresse constante : « messenger.hotmail.com » et redirige systématiquement les utilisateurs vers un autre serveur. Par conséquent lors de sa connexion un client supportera très bien d’arriver directement sur un Notification Server. Par ailleurs, ces derniers ne vérifient pas que l’utilisateurs est passé par le « Dispatch Server » avant de se connecter à eux. Ceci sera exploité par notre proxy.
Figure 1: Architecture générale du réseau MSN Messenger
Les « Switchboard Server » ont pour rôle d’héberger les conversations ayant lieu entre différents membres de la communauté MSN. En effet, deux clients A et B désirant discuter entre eux ne sont pas nécessairement connectés au même serveur, donc plutôt que de transférer l’un des deux vers le serveur de l’autre, le choix a été fait de les relier via un serveur tiers. Cette solution a également l’avantage de permettre à un client de discuter avec plusieurs autres clients chacun connectés à un serveur différent.
On notera que les transfert de fichiers pouvant avoir lieu entre l’utilisateur A et l’utilisateur B se font par une connexion directe entre les deux ordinateurs, sans passer par un serveur intermédiaire.
On notera également pour la suite que tous les transfert de données se font en mode texte.
Figure 2 : Exemples de situation où 3 utilisateurs dialoguent
La Figure 2 présente une situation où deux conversations ont lieu au même moment : une regroupant les trois utilisateurs A, B et C sur le Switchboard A et une autre où les utilisateurs A et C discutent entre eux (l’utilisateur B ne sait pas ce qu’il s’y passe). Cet exemple illustre l’indépendance entre les Notification Server et les Switchboard. Comme on peut le voir, le système fonctionne car les Notification Server discutent entre eux via des connexions auxquelles nous n’avons pas accès. On peut également préciser l’existence du serveur «.NET Passport » de Microsoft chargé de vérifier les mots de passe des clients. Ce dernier est contacté directement par le client.
D’autres situations peuvent arriver, par exemple, un Notification Server peut demander n’importe quand à un client d’aller se connecter sur un autre, en général parce qu’il part en maintenance ou qu’il est surchargé.
Une fois complet, notre système de surveillance devra :
Il a été décidé de présenter au client notre système sous la forme d’un serveur MSN de type « Notification Server » (cf. Figure 3). Les clients officiels fournis par Microsoft ne permettant pas de spécifier un serveur autre que l’officiel, les utilisateurs devront utilisé un client tiers tel que Gaim, Kopete, Trillian ou Miranda IM. La majorité des clients libres compatible MSN offrant cette fonctionnalité.
La figure ci-dessous présente une situation où trois utilisateurs participent à la même discussion, ce qui explique qu’ils soient tous connectés au même Switchboard. Deux de ces utilisateurs (clients A et B) sont connectés via notre système, le troisième est extérieur. Le fait qu’ils partagent tous le même Notification Server est du pur hasard, il pourraient très bien être connectés à 3 serveurs différents.
Figure 3 : Architecture réseau du système complet
Le système complet se présentera sous la forme de deux serveurs, le Notification Server enregistrant et filtrant les connexions, le Switchboard enregistrant les dates, heures et listes des participant des conversations. Par ailleurs ces serveurs seront toujours connectés aux serveurs de Microsoft afin de permettre aux utilisateurs de communiquer avec d’autres utilisateurs qui seraient connectés normalement.
Ce serveur est prévu pour fonctionner sur un système POSIX, les limites de portabilités sont dues à l’utilisation du multithreading et des sockets. Ce programme a été écrit en C++.
Lors du démarrage, le thread principal ouvre le port 1863 correspondant au port habituellement utilisé par Microsoft puis prépare une connexion sans l’ouvrir vers le Dispatch Server officiel. Lors de la connexion de chaque utilisateur, un nouveau thread est créé pour lancer un objet qui prendra l’utilisateur en charge. Le premier utilisateur sera forcément redirigé vers un Notification Server, c’est là que notre programme interviens et intercepte la redirection : il informe le programme principal du changement de serveur et demande à l’utilisateur de se reconnecter. A partir de ce moment, tous les nouveau utilisateurs seront connectés aux Notification Server indiqué par Microsoft. S’il venait à être surchargé, il renverrait une redirection à certains utilisateurs qui serait pris en charge de la même manière.
Afin d’enregistrer et de filtrer les connexions, chaque commande reçue est transmise à une objet chargé de contrôler celle-ci et pouvant la modifier ou ordonner la déconnexion. Toute commande incomprise étant directement retransmise afin de limiter la quantité de commandes à décoder.
Par ailleurs, le Notification Server filtre les informations de version du client et du serveur afin d’empêcher ceux-ci d’utiliser les protocoles de Windows Live Messenger.
A l’heure actuelle, ce serveur n’a pas encore été écris. Cependant il est prévu de l’écrire de la même manière, à la différence près que celui-ci ne devrait pas avoir à subir de redirection intempestive. Ce programme devra communiquer avec le Notification Server précédemment décrit afin de savoir à quel Switchboard il doit se connecter. Il devra donc avoir un port réservé afin de pouvoir recevoir des informations de la par du Notification Server.