' Entre les protocoles IPSec et SSL, l'union est inéluctable '

Avec sa course permanente à l'innovation, l'informatique suscite souvent des querelles entre anciens et modernes, entre défenseurs d'une technologie éprouvée et partisans de celle censée la remplacer. C'est à ce type de démêlé que se confrontent aujourd'hui les protocoles de sécurité des réseaux privés virtuels (RPV, ou VPN en anglais) IPSec ?" l'ancien ?" et SSL ?" le moderne ?" sur le terrain du nomadisme. Même si, sur la question des réseaux privés virtuels site à site, l'affaire est entendue : IPSec représente le seul protocole viable.Pour tenter de clarifier ce débat, pas toujours exempt de considérations marketing, faisons un retour en arrière. Pour que le protocole IP puisse s'imposer dans les entreprises, il lui était nécessaire de s'appuyer sur une solution de chiffrement et d'authentification des données. Introduit en 1998, IPSec répondait à ce besoin, devenant rapidement le protocole de ' tunnellisation ' de choix pour les réseaux privés virtuels IP : les messages empruntaient certes des voies publiques, mais seul le récepteur, une fois reconnu, était en mesure de les lire. Pour cela, IPSec nécessite l'installation d'un logiciel sur le poste client et le recours à des ports de communication spécifiques. Ces deux caractéristiques peuvent se révéler parfois contraignantes : par exemple, dans le cas où s'interpose un pare-feu ou lorsque l'utilisateur distant, tel un partenaire ou un client, n'a pas la possibilité d'installer le logiciel adéquat sur son poste.Simple, pratique, fonctionnant avec des ports normalisés et ne nécessitant aucune installation, le protocole SSL est alors apparu comme un recours idéal et, pour beaucoup, le fossoyeur d'IPSec. Toutefois, la situation ne se montre pas forcément aussi évidente. SSL fonctionne en effet selon trois modes : le ' standard ', qui autorise la connexion aux applications de l'entreprise via un portail web (la ' webisation ' des applications) ; le ' réseau ', qui offre une connectivité complète ; et le ' bureau virtuel ', où l'on recrée un environnement de travail complet sur le poste distant. Or, de ces trois possibilités, seul le standard ne nécessite en réalité aucune installation sur le poste client, et un RPV SSL perd beaucoup de sa convivialité dans les cas le plus sophistiqués (les applications à ports multiples, entre autres).

L'atout : simplicité de SSL et performances d'IPSec

Comme souvent dans ce genre de débat, c'est finalement la réalité qui aide à trancher, et les deux adversaires sont renvoyés dos à dos. Suivant les besoins, l'un ou l'autre s'avérera en effet le mieux adapté. Si l'on souhaite une connexion vers quelques applications ciblées, depuis des machines non contrôlées (comme ouvrir à un partenaire l'accès à une application), SSL s'impose sans conteste. Si, en revanche, il s'agit d'accorder un accès complet aux applications via des postes distants mais appartenant bel et bien au parc de l'entreprise (travailleurs nomades ou à domicile, succursales, etc.), IPSec reste la meilleure option. En outre, suivant les circonstances, il est tout à fait possible, et même recommandé, de panacher les deux solutions au sein de la même organisation. C'est pourquoi il faut en réalité examiner au cas par cas IPSec et SSL, deux solutions complémentaires disponibles sur le marché.Toutefois, toujours en quête d'unification et de simplification, le marché est demandeur de solutions intégrées. L'évolution vers une solution unique alliant les performances et le prix d'IPSec à l'ouverture et la simplicité de SSL paraît donc inéluctable. Dès à présent, nous assistons à une bataille rangée entre les acteurs de ces deux marchés, avec des approches différentes entre les éditeurs IPSec ?" qui positionnent des produits mixtes pour étendre leur activité ?" et les constructeurs de boîtiers SSL ?" qui tendent vers du ' IPSec Like ' afin de remplacer le parc existant. Celui qui se montrera le plus innovant offrira alors la solution tant attendue, au plus grand bénéfice des utilisateurs.*consultant sécurité chez Dimension Data France. Il a démarré sa carrière chez Matra, où il a participé au développement d'un pare-feu. Puis, il sest orienté vers des projets de déploiements internationaux de réseaux privés virtuels.