Rapport de stage de licence R&T Pierre LEONARD

4 Solutions VPN
4.1 Notion de VPN
4.1.1 Introduction au VPN

Les applications et les systèmes distribués font de plus en plus partie intégrante du paysage
d'un grand nombre d'entreprises. Ces technologies ont pu se développer grâce aux performances
toujours plus importantes des réseaux locaux. Mais le succès de ces applications a fait aussi apparaître
un de leur écueil. En effet si les applications distribuées deviennent le principal outil du système
d'information de l’entreprise, comment assurer leur accès sécurisé au sein de structures parfois
réparties sur de grandes distances géographiques ? Concrètement comment une succursale d’une
entreprise peut-elle accéder de façon sécurisé aux données situées sur un serveur de la maison mère
distant de plusieurs milliers de kilomètres comme si elles étaient locales ? Les VPN, Virtual Private
Network ou RPV, Réseau Privé Virtuel en français, ont commencé à être mis en place pour répondre à
ce type de problématique. Mais d’autres problématiques sont apparues et les VPN ont aujourd’hui pris
une place importante dans les réseaux informatique et l’informatique distribuées.

4.1.2 Principe de fonctionnement

Un réseau VPN repose sur un protocole appelé "protocole de tunneling". Ce protocole permet
de faire circuler les informations de l'entreprise généralement de façon cryptée, d'un bout à l'autre du
tunnel; ainsi les utilisateurs ont l'impression de se connecter directement sur le réseau de l'entreprise.
Le principe du tunneling consiste à construire un chemin virtuel après avoir identifié l'émetteur et le
destinataire. Par la suite, la source chiffre les données au moyen d'algorithmes de cryptographie
négociés entre le client et le serveur et les achemine en empruntant ce chemin virtuel. Afin d'assurer
un accès aisé et peu coûteux aux intranets et extranets d'entreprise, les réseaux privés virtuels d'accès
simulent un réseau privé alors qu'ils utilisent en réalité une infrastructure d'accès partagée telle que
l'Internet. Les données à transmettre peuvent être prise en charge par un protocole différent d'IP, mais
dans ce cas le protocole de tunneling encapsule les données en ajoutant un en-tête. Le tunneling est
l'ensemble des processus d'encapsulation, de transmission et de désencapsulation.

4.1.3 Utilisation d'un VPN

Il existe trois types standard d'utilisation des VPNs:

Le VPN d'accès qui est utilisé pour permettre à des utilisateurs itinérants
d'accéder au réseau privé.

L'intranet VPN qui permet de relier deux intranets distants d'une même
entreprise.

L'extranet VPN qui permet d'ouvrir une partie ou la totalité du réseau privé à un
client ou un partenaire de l'entreprise afin de communiquer avec lui.

Un système de VPN doit pouvoir mettre en oeuvre les fonctionnalités suivantes :

Authentification d'utilisateur: Seuls les utilisateurs autorisés doivent pouvoir

s'identifier sur le réseau virtuel. De plus, un historique des connexions et des
actions effectuées sur le réseau doit être conservé.

Mobilité et Sécurité Service RÉAUMUR 19

Rapport de stage de licence R&T Pierre LEONARD

Gestion d'adresses: Chaque client sur le réseau doit avoir une adresse propre.
Cette adresse doit rester confidentielle. Un nouveau client doit pourvoir se
connecter facilement au réseau et recevoir une adresse.

Cryptage des données: Lors de leurs transports sur le réseau public les données
doivent être protégées par un cryptage efficace.

Gestion de clés: Les clés de cryptage pour le client et le serveur doivent pouvoir
être générées et régénérées.

Prise en charge multiprotocole: La solution VPN doit supporter les protocoles

les plus utilisés sur les réseaux publics en particulier IP.

4.1.4 Protocole utilisé pour réaliser une connexion VPN

Il existe plusieurs classes de protocoles permettant de réaliser une connexion VPN:

Protocole de niveau 2 comme PPTP (Point to Point Tunneling Protocol) développé et

soutenu de nos jours par Microsoft (notamment utilisé dans les systèmes d'exploitations
Windows), L2F (Layer Two Forwarding) développé par Cisco et presque disparu aujourd'hui,
L2TP ( Layer Two TUnneling Protocol) qui est une évolution des deux précédents.

Protocole de niveau 3 comme IPSec (Internet Protocol Security), développé par un groupe de
travail du même nom à l'IETF 15 depuis 1992, MPLS (MultiProtocol Label Switching)
principalement utilisé par les fournisseurs d'accès Internet.

Protocole de niveau 4 comme SSL/TLS (Secure Socket Layer/Tranports Layer Security).

4.1.5 Schéma d'un VPN

Figure 4-1: Fonctionnement VPN

15
Internet Engineering Task Force

Mobilité et Sécurité Service RÉAUMUR 20

Rapport de stage de licence R&T Pierre LEONARD

4.2 Openvpn
4.2.1 Présentation

Comme expliqué plus haut, Openvpn est un logiciel libre de droit et il est donc une très bonne
alternative en ce qui concerne la création de tunnels protégés utilisant Internet comme support
physique. Openvpn se base sur le protocole de sécurisation SSL/TLS pour assurer la confidentialité
des échanges, ce protocole a été élaboré dans le but de protéger les données via des navigateurs web
(ex: https 16). L’authentification se fait la plupart du temps à l’aide de certificats accompagnés de clés.

Il existe deux modes d’utilisations principales concernant Openvpvn:

Mode de niveau 2 : utilisation d'une interface TAP (mode bridgé)
Mode de niveau 3 : utilisation d'une interface TUN (mode routé)

Globalement, si l'on ne souhaite gérer que du trafic IP (niveau 3) il faudra s’orienter vers un
mode d’utilisation de niveau 3, tandis que si l’on désire transporter des protocoles autres que IP
(niveau 2) il faudra s’orienter vers le mode d’utilisation de niveau 3.

Les paquetages Debian nécessaires à son installation sont les suivants :

bridge-utils_0.9.6-5_i386.deb -> uniquement pour le serveur (interface TAP)
openssl_0.9.8a-8_i386.deb
libssl0.9.8_0.9.8a-8_i386.deb
liblzo1_1.08-3_i386.deb
openvpn_2.0.6-1_i386.deb
Tous ces paquetages peuvent être installé à l’aide de la ligne de commande "apt-get install
<nom_du_paquet>" sous un environnement Debian.

4.2.2 Création des certificats et des clés RSA

Pour s’authentifier l’un et l’autre, le client et le serveur s’échangent leur certificat et vérifient
chacun de leur côté la validité de celui-ci avec le certificat de l’autorité de certification.
Pour générer ces documents, j’ai utilisé un fichier de configuration d’Openssl joint en annexes.

Voici les commandes Unix nécessaires :

Création d’un certificat autosigné
openssl req –nodes –new –x509 –keyout /path/cacert.pem –days 3650 –
config /path_vers_le_fichier_de_conf_openssl

Création de la clé et de la requête de certificat à faire signer par l’autorité de

certification
openssl req –nodes –new –keyout server.key –out server.csr –config
/path_vers_le_fichier_de_conf_openssl

Vérification et signature de la requête de certificat

openssl ca –out server.crt –in server.csr –config
/path_vers_le_fichier_de_conf_openssl

Ces deux étapes sont à répéter pour créer un certificat pour le client à signer par la même
autorité de certification.

Création des paramètres Diffie Hellman pour le cryptage du tunnel

openssl dhparam –out dh1024.pem 1024

Mobilité et Sécurité Service RÉAUMUR 21

Rapport de stage de licence R&T Pierre LEONARD

4.2.3 Protocole SSL / TLS

4.2.3.1 A propos d’SSL / TLS

C’est le besoin d’éliminer les interceptions sur les réseaux par des personnes non autorisés et
par la même occasion d’empêcher la récupération de données personnels des utilisateurs qui a conduit
à l’élaboration d’un standard permettant des transmissions sécurisées des données via les navigateurs
Web. Netscape Communications est la compagnie qui a conçu le protocole SSL (Secure Socket
Layer), qui fut le premier protocole de sécurisation des communications via les navigateurs Web.
La première version du protocole a été publiée dans le milieu de l’année 1994 et est intégrée
au navigateur Mosaic, puis fin 1994 la seconde version fut intégrée dans le navigateur Netscape
Navigator. La troisième version fut publiée fin 1995 permettant de corriger les faiblesses de son
prédécesseur.
C’est en mai 1996 que l’IETF accepta de faire de SSL un standard universel. Et c’est en 1999
que SSL fut renommé par l’IETF : TLS (Transport Layer Security), TLS v1.0 n’est qu’une extension
de SSL v3.0.
A l’heure actuelle la plupart des navigateurs Web supportent le protocole et c’est ainsi que le
protocole SSL est utilisé dans les transactions sur Internet allant de l’achat de livres jusqu’au transfert
de fonds.

4.2.3.2 Généralités

SSL est donc un protocole à négociation développé à l’origine par Netscape. Son but est de
sécuriser les transactions Internet, par authentification du serveur et éventuellement du client, et par
chiffrement de la session.
Il est une couche optionnelle se situant entre les couches d’application et de transport. Le but
de SSL est d’être un protocole de sécurité facile à déployer assurant une sécurité totale des échanges
de plusieurs applications.
Pour TCP, SSL n’est qu’une application qui utilise ses services.

Application
HTTP, FTP ….

Handshake
SSL/TLS

Alert CCS
TCP

Record
IP

TCP

Figure 4-2 : Le protocole SSL/TLS dans son environnement

SSL ne dépend pas des applications utilisées lors des transactions et s’applique sous les
protocoles HTTP, FTP, Telnet, LDAP, etc.

16
HyperText Transfert Protocol Security

Mobilité et Sécurité Service RÉAUMUR 22

Rapport de stage de licence R&T Pierre LEONARD

La sécurisation des connexions à l'aide du protocole SSL doit assurer que :

La connexion assure la confidentialité des données transmises
La connexion assure l’intégrité des données transmises
L'identité des correspondants peut être vérifiée
La connexion est fiable

Clients et serveurs commencent par s’authentifier mutuellement (pas toujours de manière

symétrique), puis négocient une clé symétrique de session qui servira à assurer la confidentialité des
transactions. L’intégrité de ces dernières est assurée par l’application de HMAC 17.

4.2.3.3 Fonctionnalités

Les principales fonctions assurées par SSL sont :

Authentification : dans SSL v3.0 et TLS, l’authentification du serveur est obligatoire. Elle a
lieu à l’ouverture de la session. Elle emploie pour cela des certificats conformes à la
recommandation X 509 v3. Cela permet au client de s’assurer de l’identité du serveur avant
tout échange de données. Dans la version actuelle de SSL et de TLS l’authentification du
client reste facultative.

Confidentialité : Elle est assurée par des algorithmes de chiffrement symétriques. Bien que le
même algorithme soit utilisé par les deux parties chacune possède sa propre clé secrète qu’elle
partage avec l’autre. Les algorithmes utilisés sont : DES, 3DES, RC2, RC4.

Intégrité : Elle est assurée par l’application d’un algorithme de hachage (SHA ou MD5) aux
données transmises. L’algorithme génère, à partir des données et d’une clé secrète, une
signature pour les données appelée code d’authentification de message. Ainsi tout changement
appliqué aux données provoquera un message d’erreur côté récepteur puisque la signature
contenue dans le message sera différente de celle calculée par le récepteur.

4.2.3.4 Principe de fonctionnement

Le protocole SSL/TLS est composé de 4 sous protocoles qui sont :

Handshake Protocol : Ce protocole permet l'authentification obligatoire du serveur, du client

(optionnelle), et la négociation de la suite du chiffrement qui sera utilisé lors de la session.

CCS (ChangeCipherSpec) Protocol : Ce protocole comprend un seul et unique message (1

octet) qui porte le même nom que le protocole, il permet d'indiquer au protocole Record la
mise en place des algorithmes de chiffrement qui viennent d'être négociés.

Alert Protocol : Ce protocole génère des messages d'alerte suite aux erreurs que peuvent
s'envoyer le client et le serveur. Les messages sont composés de 20 octets, le premier étant soit
fatal soit warning. Si le niveau de criticité du message est fatal, la connexion SSL est
abandonnée.

Record Protocol : Ce protocole intervient après l'émission du message ChangeCipherSpec. Il

permet de garantir la confidentialité à l'aide de chiffrement des données et l'intégrité à l'aide de
génération d'un condensât.

17
Hashed Message Authentification Code

Mobilité et Sécurité Service RÉAUMUR 23

Rapport de stage de licence R&T Pierre LEONARD

Le protocole SSL comporte une phase de négociation où client et serveur peuvent :

définir le niveau de sécurité voulu
s’authentifier

Après cette phase, ils peuvent communiquer (échange de données applicatives : HTTP, FTP, etc.)
Rappelons que les trois fonctionnalités principales de SSL sont l’authentification du serveur,
l’authentification du client et le chiffrement des données. Le protocole se compose de deux couches
principales : le protocole Record qui traite l’encodage des données à envoyer et le protocole
Handshake qui gère la négociation.
Nous allons détailler les diverses étapes du processus de négociation, avec les messages que
s'envoient le client et le serveur qui permettent la construction de la communication sécurisée grâce à
SSL.

4.2.3.5 Processus de négociation client/serveur

Figure 4-3 : Négociation SSL Client/Serveur

Suite à cette phase de négociation, le client et le serveur peuvent s’échanger des données de
façon sécurisée. Celles-ci seront chiffrées par l’algorithme symétrique choisit au cours de la
négociation.

Mobilité et Sécurité Service RÉAUMUR 24