Rapport Du Projet Portail Captif [PDF]

Zitiervorschau

Mathieu Dubois Olivier Gatimel Thomas Molle

Rapport du projet Portail Captif

Tuteur: Rachid Elazouzi Groupe de projet n°10

Table des matières I. Présentation........................................................................................................................4 1. Introduction....................................................................................................................4 2. Limites d'un portail captif...............................................................................................4 3. Solution..........................................................................................................................5 4. Objectifs.........................................................................................................................5 5. Résumé du travail effectué............................................................................................5 II. Organisation.......................................................................................................................6 1. Répartition......................................................................................................................6 2. Avantages de cette organisation...................................................................................6 3. Inconvénient de cette organisation................................................................................7 4. Conclusion sur l'organisation.........................................................................................7 III. Les failles de sécurité de NoCat.......................................................................................8 1. Présentation...................................................................................................................8 2. Connexions wifi ou réseau en clair................................................................................8 3. Vol des droits d’accès d’un utilisateur..........................................................................11 4. Usurper l’identité du hot spot.......................................................................................15 5. La pop-up.....................................................................................................................16 6. Bilan personnel............................................................................................................17 IV. Mise en place du VPN....................................................................................................19 1. Pourquoi OpenVPN ?..................................................................................................19 2. Tests d'OpenVPN.........................................................................................................19 3. Amélioration de la gestion des certificats au niveau utilisateur...................................20 4. Programme de gestion des certificats côté clients Windows......................................21 5. Configuration et déploiement.......................................................................................22 6. Bilan personnel............................................................................................................22

V. Cryptographie...................................................................................................................24 1. Technique de chiffrement.............................................................................................24 2. Comparaison des deux méthodes, du point de vu de la sécurité, appliqué au contexte de la faculté......................................................................................................................27 1. Chiffrement symétrique...........................................................................................27 2. Chiffrement asymétrique.........................................................................................27 3. Bilan personnel............................................................................................................28 VI. Conclusion......................................................................................................................29

I Présentation 1 Introduction De plus en plus de personnes disposent aujourd'hui d'un organe mobile (portable, PDA, ...) et souhaitent pouvoir accéder à l'Internet avec cet organe dans la majorité des lieux qu'ils fréquentent. Dans cet optique, l'expansion très rapide des points d'accès sans-fil permet la connexion des appareils nomades. Néanmoins chaque réseau possède sa politique d'accès et ne souhaite pas laisser n'importe qui accéder aux ressources réseaux. Ainsi il est nécessaire de mettre en place des systèmes d'authentification sur ces réseaux qui doivent cumuler de multiples avantages comme une compatibilité avec la majorité des appareils mobiles du marché, sécuriser les échanges entre les client et le réseau, offrir à l'utilisateur la plus grande transparence aussi bien lors de la phase d'authentification que lors de l'utilisation du réseau, réduire l'impact au niveau des ressources matériels et de la bande passante. Devant ces enjeux, le portail captif s'est imposé comme une solution fréquemment utilisée dans les points d'accès payants, mais elle peut se généraliser à tous types de réseau (sans-fil ou filaire) nécessitant un contrôle d'accès. La technique du portail captif consiste à forcer un client souhaitant accéder à un service en HTTP ou HTTPS sur un réseau à passer par une page web servant à l'authentifier sur ce réseau. Après authentification, la passerelle peut le laisser passer; le client a accès au réseau de façon classique. Ainsi le système utilisé dans notre université permet d'authentifier les utilisateurs désirant se connecter depuis n'importe quelle machine apportées à l'intérieur des bâtiments; la seule nécessité est de disposer d'un compte utilisateur valide, d'un navigateur web gérant le HTTPS et dans le cas du portail captif NoCat, utilisé actuellement, du Javascript.

2 Limites d'un portail captif De part leur fonctionnement, les communications entre le client et le point d'accès ne sont pas chiffrés. De plus le réseau WiFi agissant comme un hub, il est possible d'accéder à l'ensemble des données échangées par les clients connectés en WiFi. En utilisant la technique du Man in the Middle par flood arp ciblé, on peut arriver à se faire passer pour la passerelle auprès des clients connectés au WiFi. Par conséquent on peut proposer sa propre fenêtre de capture et ainsi récupérer le login/pass de l'utilisateur. La conséquence est immédiate pour ce dernier. Une première tentative serait de crypter le réseau WiFi. Cependant si tout le monde utilise la même clé (cryptage wep ou wpa) ou authentification PSK (pre-shared key), les trames réseaux seront déchiffrables par tout le monde, on se retrouve donc dans la situation hub précédente avec l'accès aux données échangées par tous. Une solution avec authentification 802.1x (certificat ou login/pass) permet de garantir ce point là. En effet 802.1x permet de générer une clé de chiffrement pour chaque utilisateur connecté au point d'accès. Ainsi un utilisateur ne peut déchiffrer la communication d'un autre utilisateur. Il serait intéressant d'apporter cette solution dans notre portail captif, mais ce chiffrement ne peut être géré que par le point d'accès sans-fil ce qui se retrouve hors du cadre de notre projet.

3 Solution La solution que nous avons choisie d'implémenter dans ce projet est l'utilisation d'un VPN. Un VPN (Virtual Private Network ) est vu comme une extension des réseaux locaux et préserve la sécurité logique que l'on peut avoir à l'intérieur d'un réseau local. En d'autres termes, cet outil va nous permettre de connecter les utilisateurs au réseau local en passant par un canal chiffré. Ainsi le fait que la connexion sans-fil ne soit pas sécurisée n'est plus un problème. De plus un VPN cherche à apporter certains éléments essentiels dans la transmission de données : l'authentification (et donc l'identification) des interlocuteurs et du serveur VPN, l'intégrité des données (le chiffrement vise à les rendre inutilisables par quelqu'un d'autre que le destinataire).

4 Objectifs Dans ce but, voici les objectifs que nous nous sommes fixés pour ce projet. Mettre en évidence les failles et les faiblesses du portail captif existant. Ce travail permet de justifier l'intérêt d'utiliser un VPN. – Mettre en place de la solution VPN. Il faut choisir le logiciel le plus adapté et le configurer selon nos besoin. – Avoir au niveau du client une installation et une configuration simple. – Avoir une solution VPN compatible avec la majorité des clients. –

5 Résumé du travail effectué Une première partie a consisté en l’analyse des failles du système existant avec démonstrations et exploitations à l’appui. Son travail résume principalement les failles de sécurité et les faiblesses de l’interface du côté utilisateur (convivialité, agrément). Ainsi, en montrant les points faibles du système existant, notre projet fait preuve d’une utilité et d’un intérêt encore plus grand. Nous avons fait le choix d’utiliser le logiciel OpenVPN pour notre projet. Une deuxième partie de notre projet a ainsi été de prendre en main ce logiciel, de comprendre son fonctionnement afin de l’adapter du mieux possible à nos besoins. Sa polyvalence a nécessité un travail de documentation et d’expérimentation important, néanmoins cette polyvalence nous a permit de créer la solution convenant le mieux à notre cahier des charges. OpenVPN utilise des certificats SSL pour identifier les utilisateurs lors de la connexion et pour chiffrer la connexion. Nous avons donc du trouver un moyen efficace, simple pour l’administrateur et l’utilisateur et fiable. Notre solution se base sur deux composants. Le premier est un script php connecté à la base de données gérant les utilisateurs qui a pour but de générer les certificats SSL à la demande. Ce script propose une interface web et une interface de type Web Service utilisant le protocole SOAP. Le deuxième composant est un logiciel client interrogeant la Web Service précédente; il permet d’automatiser la récupération du certificat SSL et son installation.

II Organisation Nous avons mis l'accent sur la répartition du travail entre les participants de ce projet. Ce rapport en garde l'esprit en mettant en évidence le travail effectué par chacun.

1 Répartition Thomas s’est occupé de la gestion du site internet présentant notre projet. De plus il a installé , configuré et adapté NoCat sur les machines de test pour les besoins de sa partie et pour le développement des parties suivantes. Ce travail a été effectué dès le début afin de permettre la suite du projet. Enfin il s’est chargé de l’analyse et de la rédaction de la première partie. Ce travail n’avait pas de contraintes temporelles particulières et n’impactait pas les autres parties. Olivier s’est chargé de la configuration d’OpenVPN et de l’écriture de scripts de connexion, déconnexion et logs. Il s’est aussi occupé de la configuration du client VPN, de l’écriture du programme client permettant la récupération des certificats et de la création du programme d’installation côté client. Et il s’est chargé de la cohérence de l’ensemble du projet et des prises de décision dans les choix technologiques. Mathieu a écrit le programme php permettant de générer les certificats SSL à la demande. Ceci inclut l’interface web, la mise à disposition de méthodes pour accéder à la Web Service et la connexion à la base de données gérant les utilisateurs.

2 Avantages de cette organisation Globalement cette organisation s’est révélée de bonne qualité. En effet, les parties empiètent peu sur chacune et mettent l’accent sur l’autonomie des participants. Prenons l’exemple de la partie de Thomas, il a d’abord du installer une plate-forme pour permettre le développement et les tests. C’est le seul moment de notre projet où tant que cette plate-forme n’était pas en place, les autres ne pouvaient pas travailler avec efficacité. Ensuite son travail était d’analyser la sécurité de l’existant en faisant des exploits et des démonstrations; ce travail n’impacte pas les autres parties et n’attend pas quelque chose des autres parties. Les points à vérifier ou à confirmer ont déjà été ciblés lors de l’analyse du premier semestre. Et cette partie laisse une très grande autonomie dans la gestion du travail. Ensuite regardons la partie d’Olivier. Dès la mise à disposition de la plate-forme de développement, il a pu installer et découvrir OpenVPN aussi bien du côté serveur que du côté client. Même si OpenVPN nécessite des certificats SSL pour fonctionner, il a pu en générer des « faux » pour pouvoir faire fonctionner son VPN. Les tests de configuration, la fiabilité et la solidité du lien VPN, l’installation du logiciel client, tout ceci se fait dans cette partie et ne nécessite rien d’autre que la plate forme de développement et de la documentation sur les logiciels utilisés. Seul le dernier logiciel, celui permettant de récupérer et d’installer automatiquement les certificats SSL, a besoin du Web Service de la partie des certificats SSL pour pouvoir être implémenté. Enfin la partie de Mathieu suit la même logique. Il existe des outils pour vérifier la validité des certificats SSL sans avoir besoin du VPN, la génération de certificats SSL peut

se faire sans pré-requis, le tout était de se mettre d’accord sur le Common Name et le format de sortie pour qu’il soit compatible avec le OpenVPN. Grâce à cette organisation très sectorisée, nous avons pu travaillé chacun de notre côté en étant le moins dépendant des autres; on trouve ici la grande force du découpage de notre projet et d’avoir le choix de solutions technologiques permettant cette répartition. Ceci était essentiel car nous avions fait des choix d’options différents, nous n’étions pas dans les mêmes groupes de TD et par conséquent nos emplois du temps divergeaient fréquemment; travailler ensemble la majorité du temps aurait été une tache vouée à l’échec. De plus ceci permet d’identifier clairement le travail de chacun et chaque participant peut se spécialiser dans son domaine. La connaissance de l’ensemble du projet, et donc de la finalité de sa partie, est essentiel pour rester motivé et intéressé par ce projet mais ne constitue pas une étape essentiel pour la réussite de sa partie. Malgré cette sectorisation du travail, nous avons discuté des choix techniques ensemble en analysant le choix de chacun et de trouver la meilleure façon d’y parvenir

3 Inconvénient de cette organisation Comme dit précédemment, notre organisation nous permet de travailler chacun de notre côté. Cette manière de travailler a des avantages mais aussi des limites. En premier, nous avons plutôt l’habitude de travailler en binôme; or ici nous étions plus dans un travail individuel; même si cela reste un travail d’équipe pour la création du produit final. C’est une étape pas toujours évidente. Ensuite, découlant de problèmes d’emploi du temps, nous nous sommes peu vus sur ce projet. Il était rare que nous soyons tout les trois présents le même jour et la même heure. Ce problème s’est aussi posé pour rencontrer notre responsable de projet. En se voyant peu, il est difficile de savoir exactement où chacun en est. Ce point n’est pas trop grave dans notre organisation, mais il est important de savoir ce que font les autres pour continuer à avancer, pour savoir si on n’est pas trop en retard ou en avance sur les autres. Peut-être que la présence d’étapes supplémentaires dans chaque partie aurait rendu ce point moins présent, mais cela aurait alourdi la gestion de projet en la rendant moins proche des contraintes du terrain et cela aurait augmenté le risque de faire une planification où les dates changent tous les jours.

4 Conclusion sur l'organisation A cause contraintes sur notre emploi du temps, nous avons fait le choix d'avoir une répartition assez stricte du travail entre nous. Cela nous a permis de travailler sans devoir perdre notre temps à trouver des périodes de travail communes. Néanmoins, le fait que le projet s'étale sur une longue durée rend difficile son suivi. Et en se voyant peu, nous avons parfois pris du retard car nous ne savions pas exactement où chacun en était. La communication a souvent fait défaut durant notre projet.

III Les failles de sécurité de NoCat 1 Présentation Lors du premier semestre, plusieurs failles de sécurité ont été évoquées : NoCat ne sécurise pas les connexions wifi ou réseau (pas de chiffrement). Les données entre le client et le hot spot circulent en clair. ● Possibilité de voler les droits d’accès d’un utilisateur (attaque). En spoofant le couple @MAC/IP de l’utilisateur, déconnecter l’utilisateur et utiliser ses droits jusqu’à expiration, ou attendre une déconnexion non-explicite. ● Usurper l’identité du hot spot pour récupérer les login/mot de passe des utilisateurs. ● NoCat utilise une pop up pour savoir si l’utilisateur est toujours connecté ou pas. Or l’utilisation des pop up pose un problème. Tous les équipements n’autorisent pas forcement les pop up. Les PDA ne supportent pas les pop up. ●

2 Connexions wifi ou réseau en clair Les données entre le client et le hot spot circulent en clair. Pour voir cela, nous allons sniffer le réseau lorsqu’un utilisateur y est connecté. (A l’aide de Wireshark)

Plan de la situation :

Nous pouvons bien voir sur la capture suivante que l’utilisateur surfe sur www.free.fr. En sniffant le réseau, nous avons la possibilité de suivre tout ce que fait l’utilisateur.

3 Vol des droits d’accès d’un utilisateur

NoCat identifie une machine par son adresse MAC et son adresse IP. Le hot spot créé donc des règles pour autoriser ou non un couple MAC/IP à passer sur internet. Pour pouvoir utiliser les droits d’accès d’un utilisateur, nous allons donc lui voler son adresse MAC et son adresse IP. Nous allons écouter le réseau pour savoir s’il y a une machine de connecté au hotspot. Nous utiliserons l’utilitaire « Airodump » sous une distribution Linux.

Nous pouvons voir sur la capture, une machine (00:13:46:97:F1:7B) associé à notre point d’accès de test (NoDog > 00:40:F4:E3:1B:36). Nous avons donc déjà récupéré sont adresse MAC. Il ne reste plus qu’à trouver son adresse IP en fonction de l’adresse MAC déjà récupéré. Pour cela, nous allons sniffer le réseau à l’aide de « Wireshark »

La capture montre que l’adresse MAC 00:13:46:97:F1:7B a comme adresse IP 192.168.2.1 Nous avons maintenant tous les éléments pour pouvoir utiliser les droits d’accès de l’utilisateur. Notre adresse MAC et adresse IP devrons être remplacé par celles de l’utilisateur. La capture ci-dessous est un exemple de configuration IP/MAC.

A partir de là, nous devrions pouvoir utiliser le couple IP/MAC de l’utilisateur pour surfer

à notre guise sur le web. Lors de nos tests, il c’est avéré que ce n’était pas possible. (Pour deux machines associé sur la même borne wifi) Petit rappel sur la norme 802.11 : Dans un réseau local Ethernet classique, la méthode d'accès utilisée par les machines est le CSMA/CD (Carrier Sense Multiple Access with Collision Detect), pour lequel chaque machine est libre de communiquer à n'importe quel moment. Chaque machine envoyant un message vérifie qu'aucun autre message n'a été envoyé en même temps par une autre machine. Si c'est le cas, les deux machines patientent pendant un temps aléatoire avant de recommencer à émettre. Dans un environnement sans fil ce procédé n'est pas possible dans la mesure où deux stations communiquant avec un récepteur ne s'entendent pas forcément mutuellement en raison de leur rayon de portée. Ainsi la norme 802.11 propose un protocole similaire appelé CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance). Le protocole CSMA/CA utilise un mécanisme d'esquive de collision basé sur un principe d'accusé de réceptions réciproques entre l'émetteur et le récepteur :

La station voulant émettre écoute le réseau. Si le réseau est encombré, la transmission est différée. Dans le cas contraire, si le média est libre pendant un temps donné (appelé DIFS pour Distributed Inter Frame Space), alors la station peut émettre. La station transmet un message appelé Ready To Send (noté RTS signifiant prêt à émettre) contenant des informations sur le volume des données qu'elle souhaite émettre et sa vitesse de transmission. Le récepteur (généralement un point d'accès) répond un Clear To Send (CTS, signifiant Le champ est libre pour émettre), puis la station commence

l'émission des données. A réception de toutes les données émises par la station, le récepteur envoie un accusé de réception (ACK). Toutes les stations avoisinantes patientent alors pendant un temps qu'elle considère être celui nécessaire à la transmission du volume d'information à émettre à la vitesse annoncée. C’est ce système qui fait que le faite d’avoir deux machines ayant le même couple MAC/IP associé sur la même borne, pose un problème. Le réseau entre les deux machines et la borne wifi s’écroule alors. Il faudra donc attendre que l’utilisateur ce déconnecte. Et nous serions de toute façon limités à la durée de vie de la pop up.

4 Usurper l’identité du hot spot Le but étant ici de récupérer les login et mot de passe des utilisateurs. Nous avons donc installé une passerelle d’authentification à l’aide de NoCat (logiciel utilisé sur le site de la fac d’Avignon) Les paramètres du hot spot que ce soit son nom (wl-uapv) ou la page d’accueil (ou de redirection) ont été configuré de tel sorte qu’ils soient les même que ceux de la fac. Ainsi, n’importe quel utilisateur essayant de se connecter au réseau « wl-uapv » pourra tomber sur notre page d’authentification. (Cela en fonction de la puissance du signal entre notre point d’accès et celui de la fac) La capture ci-dessous montre un réseau « wl-uapv » qui pourrai très bien être celui de la fac, mais qui n’est autre que celui créé pour récupérer les login et mot de passe des

utilisateurs.

Maintenant il va falloir récupérer les identifiants des utilisateurs qui se connectent à notre point d’accès.

Nous allons modifier le fichier « login » : /usr/local/nocat/authserv/cgi-bin/login, y récupérer les variables « user » et « pass » et les réécrire dans un fichier de notre choix. On rajoute juste au fichier « login » : ### Recuperation du login / passwd des utilisateurs # On ouvre le fichier 'users' en ecriture (ajout) open ( USERS,">>/home/roxx/perl/loginpass") || die ("Erreur d'ouverture de users"); my $login = $params->{user}; my $passwd = $params->{pass}; my $mac = $params->{mac}; print ( USERS "youpi\n"); print ( USERS "$login $passwd $mac\n"); # Fermeture du fichier users close (USERS);

Il nous restera plus qu’a récupérer les identifiants dans notre fichier users ! Exemple de fichier users après 5 minutes : youpi toto toto1234 00:13:46:97:F1:7B youpi toto toto1234 00:13:46:97:F1:7B

L’utilisateur toto c’est connecté deux fois avec comme login toto1234 et comme adresse MAC : 00:13:46:97:F1:7B

5 La pop-up NoCat utilise une pop up pour savoir si l'utilisateur est toujours connecté au réseau. Au bout d'un délai d'absence sur le réseau, le portail captif va couper l'accès à cet utilisateur. Or une pop up est inutilisable sur un PDA ! Dans notre solution, on aurai pu utiliser le principe du ping pour savoir si l’utilisateur est toujours connecté ou pas. Mais si une personne mal attentionné récupère notre couple MAC/IP il lui sera beaucoup plus facile de répondre à un ping que de refaire une pop up sécurisé pour rester connecter au réseau. Après un étude des fichiers de configuration de Nocat, nous avons pu voir qu'on pouvait implémenter aussi le ping (en plus de la pop up). Nocat utilise donc une double vérification de l'état de l'utilisateur.

6 Bilan personnel La première chose qui a été faite lors du premier semestre à été une prise de connaissance de l'existant. C'est à dire, une recherche approfondie de tout les systèmes de Hot spot (ou portail captif) et de leurs principes de fonctionnement. Ce travail c'est résumé à collecter des informations sur le web. Un peu comme si on devait changer de voiture et qu'on allait se renseigner dans tout les concessionnaires automobile. Toute cette approche n'est pas négligeable car elle permet de bien avancer dans la suite du projet et à répondre au mieux au cahier des charges. Suite à cette recherche, deux solutions ont été retenues : Nocat et Wifi Dog qui possède quelques différences intéressante avec Nocat (voir Comparaison des Portails Captif). Après en avoir parlé avec notre tuteur, il à été décidé de n'utiliser que Nocat pour ce projets. Si certaines fonctionnalités de Wifi Dog nous intéressaient, il faudrai alors les implémenter à notre Hot spot. Il faut savoir aussi que actuellement le système utilisé sur le site de la fac d'Avignon est Nocat. Ce qui nous a fortement aidé dans le choix d'une solution. Si un système devait être mis en place suite à notre projet, il serai d'autant plus facile à réaliser avec le moins de changement possible. Toute la partie installation et configuration de Nocat a été très intéressante pour moi. J'ai pu mettre en pratique certaines connaissances acquises en TP comme le serveur dhcp par exemple et de me familiariser encore un peu plus avec Linux. Cela ma permit aussi de bien comprendre le fonctionnement réseau du hot spot. Un grand point du projet étant la sécurité dans le hot spot, il a fallu étudier les failles de sécurité avec Nocat, les points noir, ce qu'il fallait améliorer. Une série de tests à donc été réalisé sur le site de la fac qui reprend les principales failles de sécurité comme par exemple le faite que les données entre l'utilisateur et la borne wifi ne soient pas chiffré ou encore le vol de login / mot de passe en trois ligne de code. Un rapport à été réalisé, (au départ pour le CRI) que vous pouvez retrouver dans ce rapport ou bien sur le site web du projet à l'adresse suivante : http://projets-gmi.iup.univ-avignon.fr/projets/proj0708/M1/p10 A l'aide de cette étude sur les failles de sécurité dans un réseau sans fil comme celui ci, nous avons pu repérer les points à améliorer. Pour tenir tout le monde informé de l'état d'avancement de notre projet, un site web à dût être créé. Il reprend la présentation du projet, le cahier des charges, toute les fiches compte rendu postées sur le site tout les mois ainsi que les contacts des personnes concernées par le projet et quelque liens. Lors de la réunion projet de Mars 2008, Corinne Fredouille et Sophie Nabitz ont fait remarquer que notre site web était plutôt simple. Il est vrai qu'il n'était vraiment pas attrayant et assez vide. Je me suis donc pris une après midi pour le refaire, avec des images, des CSS ... On n'y pense pas tout le temps mais autour d'un projet, il y a plein d'éléments qui viennent s'y greffer comme par exemple le site web! Le faite d'avoir bien réparti les taches à réaliser à nous trois, m'a obligé à travailler ma partie pour que les autres puissent avancer la leur. Nocat étant la base du projet, il a fallu le mettre en place rapidement pour bien pouvoir cerner les problèmes, les points à revoir et surtout pour que Mathieu et Olivier puissent s'appuyer dessus au besoin. Le travail de chacun était en rapport avec le travail de l'autre, même s'il était souvent bien différent ( du développement php à des fichiers de configuration sous linux en passant par des

iptables...) Lors du deuxième semestre, nous n'étions plus dans le même groupe de TP. Nous avons donc dû communiquer un maximum entre nous et s'échanger toute les informations possible afin d'avancer le projet le mieux possible sans mal entendu. Ce fut un très bon exercice de réalisation de projet, de coordinations de taches et de communications au seins d'un groupe d'informaticien. Je pense qu'on s'en ait pas trop mal sorti puisque à la fin nos trois parties se sont imbriquées quasiment comme il fallait.

IV Mise en place du VPN 1 Pourquoi OpenVPN ? Mes recherches bibliographiques m'ont amené vers deux solution de VPN: IPSec et OpenVPN. J'ai donc cherché à établir des critères pourquoi l'un et pas l'autre. Le premier critère que j'ai retenu est la robustesse et la notoriété de la solution. IPSec est souvent implémenté sur des équipements réseaux, cependant il demande des modifications de la couche 3 pour pouvoir fonctionner. OpenVPN n'a pas ce problème car il s'intercale entre les couches réseaux et application. De plus OpenVPN est souvent considéré comme plus sûr car il s'exécute en espace utilisateur. Ainsi une corruption de ce programme n'entraîne pas un accès au noyau. Ensuite j'ai examiné l'interopérabilité de ces logiciels. IPSec requière des changements dans le noyaux et donc une adaptation à chaque OS. OpenVPN n'a pas ce problème et permet ainsi de toujours avoir le même logiciel à configurer. On le retrouve ainsi sur Linux, MacOS, Windows,... Enfin OpenVPN se base sur OpenSSL. Il est ainsi possible de baser notre VPN sur l'utilisation de certificats SSL qui sont éprouvés et dont les outils pour les manipuler sont courants. Pour conclure, le choix d'OpenVPN, pour notre projet, s'impose de lui-même. Il garantit une compatibilité avec le réseau, permet d'avoir des clients sur plusieurs OS et permet de gérer les utilisateurs grâce à des certificats SSL. Et il remplit les objectifs essentiels à notre solution: –

Un lien chiffré entre le client et le serveur OpenVPN

Une vérification qu'on se connecte sur le bon serveur VPN grâce au certificat SSL du serveur

–

–

Une authentification des client grâce à un certificat SSL spécifique à chaque client.

2 Tests d'OpenVPN Les premiers tests avec OpenVPN se sont fait sous Linux (avec la distribution Ubuntu). Les premières tentatives ont été laborieuses notamment à cause de problèmes sur les tables de routage au niveau du client. Le serveur VPN ne donnait pas les bonnes informations au client. Après divers changements dans la configuration du serveur, ce problème était réglé. Fort de ce succès et vu que j'avais un ordinateur sous Vista, j'ai fait le choix de passer à cet OS pour continuer mes tests. Les premières tentatives se sont faites avec la version stable du client Windows. La connexion avec le serveur VPN se faisait sans problèmes, cependant les tables de routage étaient incohérentes et empêchaient tout accès au réseau. J'ai donc choisi d'installer la version bêta du client Windows. Mal m'en a pris, car cette installation du driver permettant la mise en place du tunnel chiffré a complètement fait planter l'OS; même le démarrage en mode sans échec était devenu impossible.

Après concertations avec mon responsable de projet, nous avons fait le choix de laisser tomber la plateforme Vista et de concentrer nos efforts sur la version XP de Windows. J'ai donc testé OpenVPN sur Windows XP. La suite s'en déroulé sans encombres aussi bien au niveau de l'installation, de la configuration et de l'utilisation.

3 Amélioration de la gestion des certificats au niveau utilisateur OpenVPN ne fournit pas d'outils de configuration et de gestion des certificats. Cette charge est généralement laissée l'administrateur du parc informatique qui se charge de configurer les postes clients. Cependant, dans notre cas, il fallait que l'utilisateur puisse faire cette configuration et ceci sans nécessiter de connaissances particulières. Nous avons donc choisi d'utiliser le portail captif pour fournir les certificats et le logiciel OpenVPN aux utilisateurs. Cette partie a été traitée par Mathieu, je n'y reviens donc pas. Notre responsable de projet nous a demandé d'aller encore plus loin en mettant en place un logiciel très simple pour récupérer les certificats et les copier dans le bon répertoire pour que OpenVPN puisse les exploiter. A ce niveau, nous devons distinguer les environnements de bureau Linux (KDE,Gnome) et l'environnement de bureau Windows. En effet, les bureaux Linux utilisent le programme NetworkManager qui gère les connexions réseaux du PC et qui permet aussi de configurer des VPN. Et notamment il est compatible avec OpenVPN. Proposer un programme tout en un avec le logiciel OpenVPN, un programme pour récupérer les certificats et toutes les librairies aurait été intéressant. Mais cela irait à l'inverse de la majorité des distributions basées sur des gestionnaires de paquets et l'intégration que vise à proposer ces environnements de bureau. J'ai donc fait le choix de laisser les utilisateurs de ces plateformes utiliser NetworkManager, même s'ils doivent passer par une récupération manuelle des certificats et une configuration en passant par le greffon OpenVPN de NetworManager. La mise en place est peut-être plus longue, mais ceci permet de garder la cohérence de la gestion de la configuration réseau du PC.

Par conséquent, j'ai concentré mon travail sur la création d'un programme tournant sous Windows pour gérer les certificats.

4 Programme de gestion des certificats côté clients Windows Tout d'abord il a fallu choisir l'architecture logicielle de ce programme en minimisant au maximum les modifications à faire sur les autres logiciels. Mon choix s'est porté sur une architecture distribuée en utilisant le protocole SOAP. Il a ainsi suffit de rajouter une interface SOAP, grâce à la librairie Php NuSoap, au logiciel créé par Mathieu. Deux intérêts s'en dégagent: on ne réécrit pas le programme s'occupant de la gestion et de la distribution des certificats; et grâce au fichier de description de la Web Service, n'importe qui peut créer un client compatible avec notre interface.

Gestion et distribution des certificats SSL sur le serveur d'authentification

Interface Web accessible avec un navigateur Web

Interface SOAP avec description des services Récupération des certificats Client Windows

Utilisateur Saisie login et mot de passe

Copie des certificats

Répertoire de travail d'OpenVPN

Architecture logicielle du client Windows Ayant, en parallèle, suivi le cours de « Systèmes embarqués et applications mobiles », j'ai pu utiliser C# afin d'exploiter des Web Services. J'ai été admiratif devant la facilité et la rapidité de développement. J'ai donc programmé ce client léger sous C# avec l'environnement de développement Visual Studio Express.

L'intérêt de programmer en utilisant des Web Services est la possibilité de pouvoir commencer à développer le client dès que l'interface WSDL (Web Service Description Language) est rédigée. On n'est pas obligé d'attendre que la Web Service soit à 100% opérationnelle.

L'interface graphique se réduit au strict minimum. Deux champs permettent la saisie du couple login et mot de passe, un bouton permet d'interroger la Web Service et de copier les fichiers dans le répertoire de configuration d'OpenVPN (le chemin d'accès au répertoire est récupéré dans la base de registre). Maintenant que la phase de récupération des certificats est passée, il s'agit d'automatiser la configuration d'OpenVPN et de l'installation de l'ensemble.

5 Configuration et déploiement Le fichier de configuration d'OpenVPN est commun à tous les utilisateurs. En effet, l'identification de l'utilisateur se fait grâce aux certificats et les paramètres réseaux du VPN sont passés lors de la connexion. Il s'agit donc que lors de l'installation d'OpenVPN, nos fichiers de configuration soient déjà en place. L'installation de la version Windows du client d'OpenVPN se fait grâce au programme d'installation NSIS. C'est une solution Open Source, scriptable qui permet de créer des programmes d'installation pour Windows. Ainsi on peut modifier l'installation d'OpenVPN en incorporant notre client C#, les fichiers de configuration d'OpenVPN adaptés pour note projet et le certificat SSL permettant de vérifier si le serveur VPN est bien le notre. On retrouve donc avec un seul fichier exécutable avec tout ce qu'il faut pour faire fonctionner notre solution chez un client Windows.

6 Bilan personnel En premier, j'ai pu découvrir OpenVPN durant ce projet. Ce programme m'a conquis par sa facilité à s'intégrer à un environnement réseau existant. La liste des options de ce

programme peut faire craindre de la complexité à le configurer. Néanmoins on arrive vite à une mise en service afin de découvrir ses possibilités. De plus la version serveur et la version client sont en faites les mêmes, seules certaines options permettent de changer de cas d'utilisation. Ceci rend d'autant plus rapide la prise en main de ce logiciel. Par la suite, j'ai pu mettre en pratique un des cours suivis cette année, celui concernant les Web Services. J'ai pu me rendre compte que la majorité des langages de programmation proposent des librairies pour s'interfacer avec le protocole SOAP. Que ce soit au niveau de Php ou de C#, la transformation d'une fonction (ou d'une méthode) en Web Service demande l'écriture de 5 lignes au maximum. En plus, en s'appuyant sur le protocole HTTP, il n'y a pas besoin d'ouvrir de ports exotiques et d'installer de nouveaux services. De plus cette technologie garantit la réutilisation de notre projet en fournissant une API claire et exploitable par tous. Ensuite, la personnalisation du programme d'installation du client OpenVPN pour Windows a pu se faire sans grande difficulté. Le langage utilisé par NSIS n'est pas d'une grande clarté, mais il permet de rajouter des éléments sans trop de soucis. Enfin, concernant l'organisation, j'ai déjà pu la détailler en tant que meneur dans la première partie. Plus particulièrement sur ma partie, je n'ai pu la démarrer rapidement à cause de retard dans la mise à disposition de machines de travail. Néanmoins j'ai été satisfait du travail produit et j'espère qu'il sera intégré au réseau de l'université pour que les utilisateurs réguliers du réseau sans-fil puissent jouir d'une connexion sécurisée avec un outil simple à configurer et à utiliser.

V Cryptographie 1 Technique de chiffrement La sécurisation des échanges entre l’utilisateur et les différents services du réseau de l’université passe par un chiffrement des transactions. Deux systèmes de chiffrement s’offrent à nous, le chiffrement à clé symétrique et celui à clé asymétrique. La cryptographie symétrique, également dite à clé secrète est la plus ancienne forme de chiffrement. Il s’agit de chiffrer le message envoyé grâce à une clé qui sera réutilisée par le destinataire pour déchiffrer le message crypté.

Le problème de cette méthode est que tous les utilisateurs possèdent alors la même clé partagée, la sécurité n’existe plus puisque pour déchiffrer les transactions d’un autre utilisateur il suffit d’utiliser la clé unique que tous les utilisateurs possèdent.

Dans un cryptosystème asymétrique, les clés existent par paires (le terme de bi-clés est généralement employé) : ● ●

Une clé publique pour le chiffrement Une clé secrète pour le déchiffrement

Ainsi, dans un système de chiffrement à clé publique, les utilisateurs choisissent une clé aléatoire qu'ils sont seuls à connaître (il s'agit de la clé privée). A partir de cette clé, ils déduisent chacun automatiquement un algorithme (il s'agit de la clé publique). Lorsqu'un utilisateur désire envoyer un message à un autre utilisateur, il lui suffit de chiffrer le message à envoyer au moyen de la clé publique du destinataire. Ce dernier sera en mesure de déchiffrer le message à l'aide de sa clé privée (qu'il est seul à connaître).

A titre d'image, il s'agit pour un utilisateur de créer aléatoirement une petite clé en métal (la clé privée), puis de fabriquer un grand nombre de cadenas (clé publique) qu'il dispose dans un casier accessible à tous (le casier joue le rôle de canal non sécurisé). Pour lui faire parvenir un document, chaque utilisateur peut prendre un cadenas (ouvert), fermer une valisette contenant le document grâce à ce cadenas, puis envoyer la valisette au propriétaire de la clé publique (le propriétaire du cadenas). Seul le propriétaire sera alors en mesure d'ouvrir la valisette avec sa clé privée.

2 Comparaison des deux méthodes, du point de vu de la sécurité, appliqué au contexte de la faculté 1 Chiffrement symétrique Comme nous l’avons dit précédemment, dans ce système, chaque utilisateur posséderait la même clé, qui est également la même que celle du point d’accès. Dans ce cas de figure, un utilisateur mal intentionné pourrait écouter le trafique qui passe entre un autre utilisateur et le réseau de la faculté. Cet échange est chiffré, cependant il est aisé pour n’importe quel utilisateur de le déchiffrer puisqu’il suffit pour cela d’utiliser la clé secrète que tout le monde possède.

2 Chiffrement asymétrique Dans ce système, chaque utilisateur possède la clé publique du destinataire. Cependant seul le destinataire possède la clé privée qui permet de déchiffrer le message. Dans ce cas de figure un utilisateur mal intentionné qui essayerait d’écouter le trafique transitant sur le réseau capturerait des messages chiffrés. Il lui serait impossible de les déchiffrer car il ne possède pas la clé privée nécessaire à ce déchiffrement.

Au vu de ces éléments, la solution qui s’est imposé à nous était la mise en place du chiffrement asymétrique afin de garantir la confidentialité des échanges entre les utilisateurs et les divers services du réseau.

3 Bilan personnel Mon travail a consisté à mettre en place la partie génération de certificats et de clés privées via l’interface web de notre solution. Toute cette partie devant être en quelques sorte un add-on de nocat plutôt qu’une refonte du logiciel. Nocat est entièrement développé en langage perl, et son code est fiable et reconnu par la communauté. Cependant PHP est plus connu et utilisé sur les serveurs web à travers le monde. De ce fait, j’ai décidé de développer ma partie en PHP ce qui m’a permis d’utiliser un langage déjà étudié plus tôt dans l’année et donc de ne pas avoir à effectuer tout le travail d’apprentissage nécessaire lorsque l’on développe avec un langage de programmation jamais utilisé auparavant. De même, ayant suivit un cours relatif à la cryptographie, j’étais déjà au fait du fonctionnement des systèmes à clé asymétriques. Cela m’a également permis de ne pas perdre trop de temps dans la compréhension du système d’échange des clés et donc dans le fait de savoir ce qui importait de conserver ou non pour les administrateurs réseau de la faculté. Lors de mon développement j’ai choisit de ne pas trop me concentrer sur la partie esthétique de l’interface puisque celle-ci est à façonner selon l’envie de l’administrateur. Je n’allais pas mettre en place une interface esthétiquement belle pour mon goût mais qui par la suite, dans le cadre d’une utilisation professionnelle ne répondrait pas aux attentes du CRI. Je me suis donc principalement focalisé à développer un code simple à analyser et à réutiliser. De plus, notre projet pourrait également être utilisé par une entreprise qui n’aurait pas les mêmes souhaits de présentation que le CRI ou d’autres personnes. Partant de ces bases, je me suis documenté sur le site officiel de php (http://www.php.net/) pour consulter la documentation relative à la génération de certificats

et clés via openssl, le tout commandé par PHP. Il a fallut ensuite se pencher sur le développement en lui-même. J’ai décidé de créer le code de telle façon à ce qu’il soit beaucoup commenté pour être éventuellement repris par un membre du CRI si le besoin était. Il était important de bien segmenter également le code, ainsi la partie qui concerne la génération du certificat et de la clé est développée sous forme de fonction qui est ensuite appelée dans le code principal. Ainsi si le CRI décide de restructurer le code, la fonction sera réutilisable sans la modifier et sans devoir entrer dans les détails des fonctions permettant la génération d’un certificat et d’une clé. Les difficultés rencontrées tout au long de cette année au sein de ce projet n’ont pas été liées à la technique nécessaire à l’élaboration de certaines phases. La principale difficulté a résidé dans l’organisation du travail avec parfois des périodes où il nous était impossible de rencontrer notre tuteur, par exemple car il était à l’étranger. D’autres fois, la charge de travail demandée par les autres matières ne permettaient pas, temporairement, de me consacrer comme je l’aurais souhaité sur le projet. C’est ainsi que j’ai pu mesurer toute la difficulté d’être impliqué dans un projet tel que celui-ci en devant en même temps répondre à d’autres travaux. Cela m’a rappelé mes expériences de stages au sein d’entreprises où il fallait souvent répondre à cette problématique d’avoir plusieurs travaux en parallèles avec pour chacun diverses échéances. Certes, le résultat n’a pas les mêmes conséquences pour les personnes qui demandent à ce que le projet soit réalisé, mais d’un point de vu personnel les conséquences sont directement liés à la réussite de l’année d’étude ce qui engendre un devoir de résultat au moins aussi important qu’en entreprise.

VI Conclusion Tout au long de ce projet, nous avons pu abordé de multiples aspects techniques et organisationnelles. En premier, ce projet est le travail de toute une année. L'organisation qui en découle n'était pas évidente à gérer. Chacun a déjà fait un bilan personnel sur son travail, mais une idée principale s'en dégage: l'organisation de notre projet ne fut pas tout le temps facile. Néanmoins notre répartition s'est avérée un très bon choix tout au long de ce projet et a permis à chacun des participants d'exprimer son savoir-faire. Ensuite, sur le plan technique, nous avons pu découvrir divers logiciels, protocoles et techniques utilisés dans beaucoup de systèmes. Même s'il n'est pas certain que nous les utiliserons dans notre avenir professionnel, l'expérience acquise durant ce projet nous sera utile devant les problématiques que nous rencontrerons plus tard. Enfin nous espérons avoir montrer l'intérêt et la faisabilité de notre travail. Et nous espérons qu'il sera intégré par le CRI afin de fournir une connexion sécurisée, fiable et utilisable par tous.