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 Interface SOAP avec

un navigateur Web 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.