Vous êtes sur la page 1sur 12

Comparatif entre VPN SSL et VPN IPSec

 Publié le 2 mars 2018

Guillaume HUGUES
Network Expert LAN and Security
2 articles Suivre

Cet article a pour but d'étudier les accès distant sécurisés basées sur SSL et IPSec. Il s'agit
de présenter leurs modes de fonctionnements, de situer leur positionnement par rapport
aux solutions VPN et de comparer les différentes offres.

Définition d'un VPN


Le VPN est l'abréviation de Virtual Private Network ou Réseau Privé Virtuel. Il dispose
de la même fonctionnalité qu'un réseau privé (utilisant des lignes spécialisées) mais utilise
Internet pour créer des lignes louées virtuelles qui passent par le réseau public. Il permet
le raccordement de travailleurs mobiles et/ou l'interconnexion de sites distants. Ainsi un
VPN est constitué de liaisons virtuelles sur Internet entre des sites distants appartenant à
une même société ou à un même organisme. En chiffrant les données, tout se passe
exactement comme si la connexion se faisait en dehors d'Internet. Les lignes louées
virtuelles sont protégées par du cryptage et de l'authentification ce qui assure la sécurité
des données. Les moyens d’accès à ces VPN IP sont multiples car ils comprennent toutes
les technologies aujourd’hui disponibles pour accéder à l’Internet : RTC, RNIS, ADSL,
Câble, Liaison Radio, Liaison Spécialisée...

Différents types de VPN


L'on peut énumérer différents types de VPN, parmi lesquels figurent:

 Connexion site à site: une entreprise ayant plusieurs sites


géographiques peut être reliée depuis l'un de ses sites au LAN
d'une autre entité.
 Accès Intranet: les employés en déplacement chez un client, à
l'hôtel ou travaillant à la maison peuvent accéder aux ressources
et applications de l'entreprise.
 Accès Extranet: les partenaires, clients… peuvent accéder à un
ou plusieurs serveurs de l'entreprise ainsi qu'à certains
documents et applications.
 Les solutions d'accès distant sécurisé
En effet, de part leur simplicité de mise en oeuvre, d'utilisation et d'administration, les
VPN conviennent parfaitement aux besoins liés à un accès intranet ou extranet.

Ce document a pour but de présenter et de comparer les technologies impliquées dans ces
VPN et plus particulièrement les avantages et inconvénients d'IPSec et de SSL.

Quelques définitions relatives à la cryptographie


Les techniques de la cryptographie sont déjà éprouvées, les premiers algorithmes sur
lesquels elle repose étant apparus dans les années soixante dix. Ces algorithmes sont basés
sur des mécanismes de transposition et/ou de rotation de blocs de caractères de longueur
fixes avec application de fonctions mathématiques et utilisation d’opérateurs logiques de
type « ou exclusif ». Ces algorithmes sont publics, la validité de la technique repose sur
l’utilisation de clefs secrètes. Les algorithmes les plus utilisés actuellement sont :

 DES (« Data Encryption Standard » 1974), triple-DES (1985) à


clefs symétriques
 RSA (Rivest, Shamir, Adleman 1978) (RFC2437) à clefs
asymétriques
 RC4, RC5 (« Rivest's Code #4, #5 » 1987) à clefs symétriques
 IDEA (« International Data Encryption Algorithm » 1992) à
clefs symétriques
 Blowfish (1993) à clefs symétriques
 AES (« Advanced Encryption Standard » 1997) à clefs
symétriques
 MD5 (« Message Digest#5 » 1992) (RFC1321)
 SHA-1 (« Secure Hash Algorithm » 1993) pour les fonctions de
hachage.
Ces algorithmes mettent en jeu des mécanismes de clefs, celles-ci sont soit symétrique soit
asymétrique. Dans le premier cas l’utilisation entraîne la notion de "sphère de confiance
pour leur partage", dans le second cas on a la notion de bi-clef (couple de clé privée - clé
publique) il y a alors nécessité de "certification et gestion de clés publiques" (PKI).

 La cryptographie symétrique - système de chiffrement à clé


secrète
Elle repose sur une clé unique: Un système de chiffrement à clé secrète, ou symétrique,
repose sur le partage entre deux interlocuteurs en communication, d'une même clé secrète
utilisée à la fois pour le chiffrement d'un message et pour son déchiffrement. La clé
secrète doit être échangée préalablement à la communication par un canal sûr, autre que le
canal à protéger. Pour le stockage de message, le principe est le même avec un seul
interlocuteur.

 Cryptographie asymétrique - systèmes de chiffrement à clé


publique
Elle repose sur le principe de la paire de clés distinctes (une clé publique pour le cryptage
et une clé privée pour le décryptage). Chaque utilisateur possède son propre couple de clés
différentes secrète et publique. La clé "sécrète" est gardée secrète par son propriétaire qui
l'utilise pour sa propre procédure de déchiffrement des messages reçus ou de signature de
messages. La clé "publique", dérivée de la clé secrète par une fonction à sens unique
(c'est-à-dire par une fonction facilement calculable mais dont l'inversion est extrêmement
difficile), est rendue publique. Ainsi, pour chaque système de chiffrement à clé publique,
le choix d'un couple de clés secrète et publique et la publication de la clé publique par un
utilisateur souhaitant recevoir des messages ou émettre des signatures, permettent à tout
autre utilisateur de lui envoyer des messages chiffrés ou de vérifier ses signatures. Il est à
noter que pour émettre un message chiffré, c'est la clé publique du destinataire qui est
utilisée et que l'émetteur n'a besoin d'aucun paramètre qui lui soit propre.

PKI – Public Key Infrastructure


Les infrastructures à clé publique, dites PKI servent à résoudre les problèmes posés par la
création des clés et de leurs certificats, leur gestion, ainsi que l'authentification des
utilisateurs. C'est un système de gestion centralisé des clés pour tous les utilisateurs,
celles-ci devant être certifiées par des autorités. Leur objet est aussi la sécurisation des
applicatifs qui peuvent être soit directement compatibles avec elle, soit par l'intermédiaire
d'agents. Elles servent aussi à définir des politiques sécuritaires pour l'ensemble du
système (spécification des règles de gestion des clés, niveau de contrôle, ainsi que les
modalités d'usage de la cryptographie).Les infrastructures à clé publique, sont composées
de plusieurs éléments : une autorité de certification, une autorité d'enregistrement et un
système de distribution des clés.

IPSec – Internet Protocol Security


IPSec, IP Security Protocol est un protocole développé par l'IETF, dont le but est de
sécuriser la connexion TCP/IP. Cela par l'authentification et le chiffrement des paquets IP.
IPSec permet de sécuriser une transmission TCP/IP, sans devoir comme c'est le cas pour
SSL lancer un processus particulier sur des ports particuliers. IPSec est un protocole de
niveau 3. Configuré en mode tunnel, il permet l'encryptage de la charge utile IP,
l'encapsulation dans un autre paquet IP, et l'envoi à travers un réseau intermédiaire IP
comme Internet.
Ce protocole est surtout employé dans le domaine des VPN. Et de plus en plus des
logiciels implémentent cette fonctionnalité de manière native, à remarquer que IPSec fait
partie intégrante de IPv6. Et malgré sa relative complexité, IPSec se présente comme le
protocole de sécurité en ce qui concerne les réseaux, et cela d’autant plus, vu le rôle
majeur qu’il assume dans IPv6.

Le fonctionnement de IPSec, peut être résumé par le cheminement suivant:

- Une machine A initie un tunnel en envoyant son certificat à l'autre Machine, B.

- B envoie en retour son certificat à A.

- Dès ce moment là, les deux machines utilisent leurs clés privées/publiques afin de se
mettre d'accord sur le protocole d'encryption à utiliser pour cette session, ainsi que
d'autres paramètres afin de rendre la transmission sûre.

Les composants de IPSec


IPSec définit plusieurs protocoles réalisant chacun une tache bien précise.

Ces protocoles sont notamment :

- Les protocoles de transmissions sécurisées, des Security Association (SA).

- Le processus de distribution des clés, des algorithmes de cryptage et d’authentification.

Ces éléments peuvent parfois donner l’impression de se superposer, mais ce n’est pas le
cas. Ainsi le protocole AH se charge notamment de réaliser la phase d’authentification, le
protocole ESP ajoute à cela le cryptage. Une SA définit les paramètres de sécurité qui
vont être utilisés comme la nature des clés, le cryptage utilisé pour le payload, ou bien
celui utilisé pour l’en-tête, la durée de vie des clés.

Les deux protocoles d’acheminement de IPSec


IPSec implémente deux protocoles AH (authentification Header) et ESP (Encapsulating
Security Payload). Si l'on veut sécuriser tant les données que toute la couche IP il faut
utiliser le mode "tunnel" de ces deux protocoles, tandis que si l'on veut sécuriser
seulement les données, on préférera le mode "transport". Le mode transport est utilisé
pour acheminer les données protégées par IPSec (Host-to-Host), le mode tunnel lui est de
généralement de type LAN-to-LAN.

AH procure l'authentification de l'en-tête IP et de ses données, mais pas forcément des


champs ToS, Flags, Fragment Offset, Time to Live, Header Checksum, car ces derniers
peuvent changer en cours du transport. ESP ne protège aucun champ d'en-têtes IP. Il offre
la confidentialité avec un algorithme de cryptage, et l'intégrité des données avec un
algorithme d'authentification. Ces deux transformations représentent les données IP
sécurisées, en une Security Association (SA). Une SA représente une construction qui
permet d'identifier le flux, ainsi l'on peut le reconnaître, et savoir quel algorithme lui
appliquer, ainsi que quelle clé il faut utiliser. Une SA est composée de trois principaux
arguments:

 Un SPI (Security Parameter Index).


 Le protocole IPSec utilisé
 L'adresse de destination.
La SA peut être créée, soit manuellement, soit de manière dynamique. Cela est possible
grâce au protocole IKE.

IKE - Internet Key Exchange


Avant qu'une communication sécurisée puisse s'établir, il est nécessaire que les parties en
présence en négocient les termes, qui seront définis dans la Security Association (SA). Le
protocole utilisé pour négocier (établir, négocier, modifier et effacer) les SA est Internet
Key Exchange (IKE). IKE combine le Internet Security Association et le Key
Management Protocol (ISAKMP) avec l'échange de clés Oaklay utilisant Diffie-Hellman.
ISAKMP est un ensemble de règles pour établir, négocier, modifier et effacer les
paramètres spécifiques à une connexion (la SA, qui n'est en principe pas limité à IPSec
mais c'est pour l'instant son seul domaine d'application). Oaklay est une application de
ISAKMP pour la génération des clés et des SA IPSec.

Le protocole AH
Coté expéditeur, cette transformation consiste en une fonction de hachage MAC, qui est
calculée sur l'ensemble du datagramme, et dont le résultat est ensuite joint au datagramme.
Du coté du destinataire, il suffira de recalculer la Mac du datagramme reçu, et de
comparer le résultat figurant dans le datagramme obtenu. La Figure qui suit indique les
transformations à apporter afin de passer par le mode tunnel.

Le protocole ESP
Les transformations ESP chiffrent des portions des datagammes, et peuvent encapsuler ces
portions de datagrammes dans d'autres datagrammes IP. Le contrôle d'intégrité
s'effectuant par un ICV (Integrity Check Value). En mode tunnel, un nouvel en-tête IP est
généré, précédent le datagramme sécurisé, et ne contenant aucune option IP, même si l'en-
tête initial, en contenait. Le mode tunnel est typiquement utilisé pour les communications
"gateway-to-gateway", où il permet de masquer les adresse IP des expéditeurs et
destinataires originaux:

La Figure suivante permet de visualiser les transformations à apporter afin de passer en


mode

tunnel.
Le protocole ESP utilise le port 50.

Security association (SA)


La security association est un point important de IPSec. En effet c'est elle qui définit les
transformations IPSec qui doivent être appliquées aux datagrammes, et comment les
transformations devront être faites.

Une SA spécifie plusieurs points:

- S'il s'agit d'utiliser AH ou ESP.

- L'algorithme d'authentification.

- L'algorithme de chiffrement.

- Les clés d'authentification.

- La durée de vie des clés de chiffrement.

- La durée de vie de la SA

- L'authentification des parties.

- La période de modification des clés.

- La séquence des nombres "anti-rejeu"

La taille et le contenu d'une SA sont spécifiées par les transformations. Une SA peut être
statique ou dynamique, qui indique respectivement que ses données ne changent pas, ou
alors dynamique qui indique que les données peuvent être mises à jour par la
transformation lorsque le datagramme est utilisé. Lors de la négociation d'une SA, un
nombre de 32 bits appelé Security Parameters Index (SPI) lui est attribué. Par la suite pour
désigner une SA pour les transformations, l'on utilisera un SPI.

SSL – Secure Socket Layer


Introduction

SSL est le protocole de sécurisation le plus répandue et est supporté par pratiquement tous
les serveurs et navigateurs web. Netscape est la compagnie qui l'a conçu. Le protocole
décrit une méthode d'authentification et de chiffrement des données entre clients et
serveurs. La technologie sous-jacente est basée sur les principes de la cryptographie par
clés publiques et clés secrètes. En 1999, SSL fut renommé Transport Layer Security
(TLS) par l'Internet Engineering Task Force (IETF) et devînt un standard universel.
Le protocole SSL 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. Dans la pile protocolaire
TCP/IP, SSL se situe entre les protocoles d'application et le protocole TCP. En insérant
SSL entre TCP et la couche d'application on évite des changements significatifs aux
protocoles existants tels que HTTP, FTP… Ainsi le protocole d'application s'interface
avec SSL de la même façon dont il s'interface avec TCP. Pour TCP, SSL n'est qu'une
application qui utilise ses services.

SSL peut être utilisé pour sécuriser pratiquement n'importe quel protocole utilisant
TCP/IP. Certains protocoles ont été spécialement modifiés pour supporter SSL:

HTTPS correspond à HTTP sur SSL. Ce protocole est inclus dans pratiquement tous les
navigateurs, et permet de consulter des sites web de façon sécurisée.

FTPS est une extension de FTP (File Transfer Protocol) utilisant SSL.

SSH (Secure Shell) permet de se connecter à un ordinateur distant de façon sûre et d'avoir
une ligne de commande. SSH possède des extensions pour sécuriser d'autres protocoles
(FTP, POP3 ou même X Windows).

Il est possible de sécuriser des protocoles en créant des tunnels SSL. Une fois le tunnel
créé, on peut y faire passer n'importe quel protocole (SMTP, POP3, HTTP, NTP...).
Toutes les données échangées sont automatiquement chiffrées.

Les trois fonctionnalités de SSL

L’objectif de SSL est de vérifier l’identité des parties impliquées dans une transaction
sécurisée et de s’assurer que les données échangées sont protégées de toute interception
ou modification. Les principales fonctions assurées par SSL sont décrites ci-dessous.

- Authentification : dans SSL v3.0 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 les versions anciennes de SSL 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 : le DES, le 3DES, le
RC2, le RC4 …

- Intégrité : Elle est assurée par l’application d’un algorithme de hachage aux données
(SHA ou MD5) transmises. L’algorithme génère à partir des données et d’une clé secrète
appelée code d’authentification de message, une suite de bits. Cette suite sert de signature
pour les données. Ainsi tout changement appliqué aux données implique un changement
de la suite de bits générée par
l’algorithme de hachage et en conséquence provoquera la génération d’un message
d’erreur côté récepteur du fait que les deux suites sont différentes.

Le principe de fonctionnement

Le cryptage SSL, fonctionne par le choix aléatoire de deux nombres premiers, qui
multipliés entre eux forment un très grand nombre. Ce dernier constitue la clé de cryptage.
Sans la connaissance des deux nombres premiers ayant servis à générer cette clé, il n'est
pas possible de pouvoir décrypter un message. En réalité une manière possible serait de
défactoriser le nombre afin de retrouver les deux nombres premiers, mais les nombres sont
tellement grands, que cela n'est pas à la portée d'ordinateurs conventionnels. Il est à
relever que déjà à partir de sa version 2.0, SSL a commencé à être utilisé. Raison pour
laquelle encore aujourd’hui, la plupart des intervenants SSL, tentent lors de la phase
d’établissement, de dialoguer avec le protocole v3.0, mais si l’un des deux partenaires ne
supporte que la version 2.0, et bien c’est cette version antérieure qui va être utilisée. A
noter que cette ancienne version contient des clés de cryptage considérées aujourd’hui
comme peu sûres. (Par exemple au niveau de la longueur de la clé, il y a un passage de 40
à 128 bits et plus, pour la version v3.0).

Composition de SSL

SSL se subdivise en quatre sous protocoles; le SSL record Protocol, et le SSL handshake
protocol. Plus deux autres protocoles, mais qui ont un rôle moins essentiel, c’est le SSL
Change Ciffer Spec, et le SSL Alert.

Le SSL record protocol définit le format qui sera utilisé pour l'échange des données. Alors
que le SSL handshake se charge des différents échanges de messages entre le client et le
serveur, au moment où ils établissent la connexion comme l’authentification, le version de
protocole, l’algorithme de cryptage, …

Phases d’authentification

Lors d'une négociation SSL, il faut s'assurer de l'identité de la personne avec qui on
communique. Il faut s'assurer que le serveur auquel on parle est bien celui qu'il prétend
être. C'est là qu'interviennent les certificats. Au moment de se connecter sur un serveur
sécurisé, ce dernier envoie un certificat contenant le nom de l'entreprise, son adresse, etc.
C'est une sorte de pièce d'identité ce sont les PKI (Public Key Infrastructure), des sociétés
externes qui vont vérifier l'authenticité du certificat. (La liste de ces PKI est incluse dans
le navigateur. Il y a généralement VeriSign, Thawte, etc.) Ces PKI signent
cryptographiquement les certificats des entreprises.

Lorsqu’il s’agit pour un client d’identifier un serveur, quatre phases se suivent :

1. Vérification de la validité de la date du certificat.

2. Le certificat est-il issu d’une CA (Certification Autority) reconnue.

3. Est-ce que la clé public attribuée à l’utilisateur valide sa signature.


4. Vérification des noms de domaines.

Pour la situation inverse, lorsque c’est le serveur qui désire vérifier l’identité du client :

1. Vérification de si la clé publique du client authentifie sa signature.

2. Vérification de la date de validité du certificat..

3. Vérification de l’entité qui à remis le certificat.

4. Est-ce que la clé publique du CA valide la signature de l’utilisateur.

5. Vérification du fait que l’utilisateur fait partie d’une LDAP.

SSL Handshake

Cela débute par le protocole SSL Handshake. Suite à la requête d'un client, le serveur
envoie son certificat, ainsi qu'une liste des algorithmes qu'il souhaite utiliser. Pour le client
il s'agit de vérifier la validité du certificat. Cela se fait à l'aide de la clé publique de
l'autorité de certification contenue dans son navigateur. Ainsi que par le fait de vérifier la
date de validité du certificat, et éventuellement un consultant une CRL (certificate
revocation list). Si le résultat des vérifications est positif, le client génère une clé
symétrique, et l'envoie au serveur.

Suite à cela, il est prévu également de pouvoir faire le contraire, c'est à dire que le serveur
envoie au client un test, que le client doit signer avec sa clé privée correspondant à son
propre certificat, de manière à ce que le serveur recevant cela, puisse de son coté vérifier
l'identité du client.

Durant cette phase de nombreux paramètres sont échangés et configurés; comme par
exemple le type de clé, sa valeur, l'algorithme de chiffrage. Toute une série de paramètres
auxquels il s'agit de donner une valeur.

SSL Record

Ce protocole permet de garantir la confidentialité des données transmises, grâce à la clé


symétrique que le protocole Handshake à négocier. Ainsi que l'intégrité des données,
encore une fois grâce à une clé obtenue par le protocole Handshake. Les différentes
phases sont les suivants :

- Segmentation des données en paquets de taille fixe

- Compression (à noter que dans les implémentations actuelles cela n’est pas implémenté)

- Ajout du résultat de la fonction de hachage.


La fonction de hachage étant une suite d’opérations mathématiques permettant d’identifier
de manière unique un paquet (composé de la clé de cryptage, numéro de message,
longueur du message, données,…). Le tout est chiffré à l’aide de la clé symétrique.

Finalement un en-tête SSL est ajoutée au paquet précédemment créé.

Résumé
1/ Le client commence la session

- Indique la version de SSL

- Génère un nombre aléatoire (client_random)

- Suites de chiffrement supportées

2/ Le serveur confirme et envoie son certificat

- Choix de la version SSL

- Génère un nombre aléatoire (server_random)

- Choix de la suite de chiffrement

- Certificat X.509

- Le client vérifie le certificat (date d'expiration, vérification du nom de domaine du


serveur, vérification du certificat par la clé publique de l'autorité de certification)

3/ Le client établit le canal sécurisé

- Génère un paramètre PreMasterSecret qu'il chiffre avec la clé publique du serveur et


qu'il envoie.

- Le serveur décrypte le PremasterSecret, génère le MasterSecret et calcule les clés


secrètes.

- Le client génère le même MasterSecret et calcule les même clés.

- F(client_random, server_random,PreMasterSecret) = MasterSecret

- Puis F(client_random,server_random,MasterSecret) = Clés Secrètes

- Clés secrètes= Clés de chiffrement, Vecteurs d'initialisation et clés de hachage.


Positionnement des solutions SSL par rapport à IPSec
Fonctionnement VPN SSL

Secure Remote Access, Secure Extranet, Virtual Extranet, VPN SSL, Application-layer
VPN sont autant de noms pour parler de solutions d'accès distant sécurisé basé sur SSL.
SSL est un protocole traditionnellement utilisé pour sécuriser les communications web. Il
assure l'encryption et l'authentification. Le protocole SSL étant supporté par la quasi
totalité des navigateurs Web, il n'est pas nécessaire d'installer un client VPN contraignant
pour l'utilisation d'un VPN SSL. C'est un des avantages majeurs de ces nouvelles
solutions. Un simple navigateur web supportant SSL suffit pour accéder de façon
sécurisée aux ressources partagées. Les applications auxquelles il est possible d'accéder
sont principalement les applications web supportant SSL ainsi que l'accès aux
gestionnaires de fichiers et aux serveurs mails. Certaines solutions proposent également
l'accès aux applications Client/Serveur et Legacy (patrimoine applicatif existant) en les
rendant "compatible Internet" (Webification). Pour accéder à ces fonctionnalités, il est
nécessaire pour la plupart des solutions d'installer un applet Java.

Comparaison des protocoles

IPSec et SSL supportent tous deux une grande variété d'algorithmes de cryptographie,
appelés Ciphers. Ces ciphers incluent les algorithmes d'encryption et d'authentification.
Ces algorithmes définissent le niveau d'encryption utilisé et la façon dont le client et le
serveur sont authentifier.

Deux "standards"

SSL et IPSec sont deux protocoles très répandus. SSL est disponible au sein de la quasi
totalité des serveurs et clients web. Majoritairement utilisé avec les applications webs,
l'utilisation de SSL a été étendu à d'autres applications. IPSec a été reconnu et standardisé
comme protocole de sécurisation de tout le trafic IP et est de ce fait bien implanté.

Compatibilité / Interopérabilité

La majeur partie des acteurs du monde de l'internet supporte SSL. Il existe donc une
bonne intéroperabilité entre les navigateurs web et les serveurs. D'un autre côté, les autres
applications qui veulent inclure SSL doivent l'implémenter séparément. Et SSL n'est pas
compatible avec toutes les applications.

IPSec est un standard défini par l'IETF et sera le protocole de sécurité de IPv6. Le
protocole IPSec assure donc en théorie une bonne interopérabilité entre les vendeurs et
leurs matériels. Se situant au niveau de la couche réseau, les applications n'ont pas à se
soucier de l'implémentation d'IPSec. Malgré la théorie, des problèmes d'interopérabilité
subsistent entre les différents vendeurs et les différents OS et plateformes.

IPSec et SSL utilise tout deux la cryptographie pour assurer la confidentialité,


l'authentification et l'intégrité. IPSec utilise des algorithmes de cryptographie très
puissant. SSL supporte la majorité de ces algorithmes. Tout les navigateurs internet ne
fournissent pas les mêmes taille de clés. Il est donc important de configurer les paramètres
acceptés par le serveur pour garantir un niveau de sécurité convenable.

Pour empêcher les attaques de type "man in the middle", il est important que le serveur et
le client s'assure de l'identité de l'autre partie de la conversation. Chaque partie utilise un
certificat digital pour confirmer son identité. Avec IPSec, un certificat pour chaque partie
est requis ou aucun. Avec SSL, le certificat digital du client est optionnel.

Déploiement d'accès distant

Dans ce cas, les utilisateurs peuvent se connecter depuis leur domicile, un hôtel ou depuis
le site d'un client ou partenaire. Ils peuvent utiliser un équipement informatique fourni par
l'entreprise ou un ordinateur personnel ou encore un ordinateur public depuis un cyber
café ou un kiosque.

IPSec n'a pas été conçu initialement pour ce type d'accès distant. En effet IPSec a été à
l'origine pensé pour un monde où les PCs possèdent des adresses statiques. De nos jours la
mobilité est très importante et les utilisateurs changent d'adresse IP même si ils se
connectent toujours depuis le même endroit. De plus IPSec nécessite qu'un logiciel
spécifique (client VPN) soit installé sur l'ordinateur utilisé pour la connexion. Cette
obligation est contraignante et il existe des problèmes de compatibilités entre OS et clients
VPN. Des add-on de sécurité sont très souvent installés en complément du client VPN
pour garantir un niveau de sécurité maximum. Toutes ces contraintes font d'IPSec un
protocole peu adapté dans le cadre d'accès distant.

Les VPN SSL sont au contraire tout à fait adaptés à cette mobilité et cette variété de lieux
d'accès. En effet leur fonctionnement "Clientless" permet aux utilisateurs d'accéder aux
ressources partagées depuis n'importe quel poste munit d'un navigateur internet
compatible SSL et d'un accès internet. De plus l'accès derrière un firewall et les problèmes
liés au NAT avec IPSec ne concernent pas les VPN SSL qui fonctionnent de façon
transparente quelque soit l'architecture du réseau.