Comparatif entre VPN SSL et VPN IPSec

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.