Racoon Installation et Configuration

Transcription

1 Racoon Installation et Configuration Documentation version 1.1 créée le 21 avril 2005 Dernière mise à jour le 20 juin 2005 Licence : GNU FDL Copyright : CRI74 Auteurs : EMONET Jean-Bruno jbemonet@ext.cri74.org Le CRI dépend de l'agence Économique Départementale - BP F ANNECY CEDEX

2 Table des matières 1 Présentation L'objectif La configuration réseau L'environnement Installation Paquetages Modules Configuration Gestion automatique des clé Clés RSA Le fichier de configuration setkey.conf Exemples : setkey.conf de la passerelle Lancer Setkey Le fichier de configuration racoon.conf Exemple de racoon.conf sur la passerelle Lancer Racoon Certificats X Les certificats Le fichier de configuration setkey.conf Le fichier de configuration racoon.conf Exemple de racoon.conf sur la passerelle Les erreurs possibles Lors du démarrage de setkey Lors du démarrage de racoon ERROR: glob found no matches ERROR: failed to bind to address Lors d'un ping d'une machine Connect: Resource temporarily unavailable Si racoon est lancé sur les 2 machines Connect: No such process ERROR: failed to get my CERT ERROR: the peer's certificate is not verified ERROR: ISAKMP-SA has not been established yet Webliographie...13 Copyright CRI74 GNU Free Documentation Licence Page 2 sur 17

3 1 Présentation 1.1 L'objectif Cette documentation a pour but d'expliquer clairement l'installation, la configuration et l'utilisation des IPSec-Tools(Setkey + Racoon + Librairies + Documentation) afin de mettre en place un VPN entre 2 sous-réseaux. Elle expliquera aussi comment utiliser les certificats avec racoon pour l'authentification des 2 passerelles. 1.2 La configuration réseau 1.3 L'environnement Dans notre cas, les deux passerelles( et ), fonctionnent sous une distribution Debian Sarge avec un noyau 2.6 permettant les fonctionnalités IPSec suivantes : PF_KEY socket interface de communication permettant de définir les politiques de sécurité et les associations de sécurité propres à IPSec. AH transformation : implémentation du protocole AH de IPSec ESP transformation : implémentation du protocole ESP de IPSec IPComp transformation : implémentation du protocole IPComp (compression) de IPSec. IPSec user configuration interface : interface avec les outils de configuration en mode utilisateur. Les clients fonctionnent sous Linux avec n'importe quelle distribution. Copyright CRI74 GNU Free Documentation Licence Page 3 sur 17

4 2 Installation 2.1 Paquetages Il faut tout d'abord télécharger le paquetage IPSec-Tools disponible sur le site : Ce paquetage contient les éléments suivants : l'exécutable setkey : pour créer les associations de sécurité et les politiques de sécurité. l'exécutable racoon : pour implémenter le protocole IKE et faisant partie du projet Kame. la librairie libipsec : pour l'interfaçage avec le noyau. des pages de man : pour les exécutables et fichiers de configuration. des fichiers de configuration de base : racoon.conf et psk.txt Pour l'installer, il faut avoir les droits root et ensuite: # dpkg -i ipsec-tools_0.5-5_i386.deb 2.2 Modules Pour utiliser la commande setkey, il faut charger des modules noyau assurant les fonctionnalités IPSec. Ces modules ne sont pas chargés automatiquement par setkey. Il faut donc les charger à la main. # modprobe esp4 # modprobe ah4 # modprobe ipcomp Copyright CRI74 GNU Free Documentation Licence Page 4 sur 17

5 3 Configuration 3.1 Gestion automatique des clé La configuration qui suit met en place une gestion automatique des clés. Cela permet un renouvellement des clés de sessions (chiffrement) afin d'améliorer le niveau de sécurité. Il y a plusieurs cas de fonctionnement. Le premier cas est l'utilisation de clés RSA générées avec Openssl pour l'authentification des 2 passerelles VPN. Le second cas est la création de certificats à l'aide d'une PKI(Public Key Infrastructure) Clés RSA Openssl permet de générer facilement des clés RSA. Chaque passerelle possède : une bi-clé (clé publique+clé privée). la clé publique de la passerelle distante. Chaque clé publique est envoyée à l'hôte distant, cela permet l'authentification. Pour générer une bi-clé, voici les étapes : Cette commande crée une requête de certificat pour l'hôte «vpn1» et génère la clé privée. # openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout vpn1.private -outform PEM -out request.pem On autosigne cette requête, on obtient la clé publique. # $ openssl x509 -req -in request.pem -signkey vpn1.private -out vpn2.public Le fichier request.pem peut-être maintenant effacé. Vous avez maintenant 2 clés RSA : vpn1.private vpn1.public Celles-ci sont stockées dans /etc/racoon/clersa Le fichier de configuration setkey.conf Tous les fichiers de configuration pour racoon sont stockés dans : /etc/racoon. Le fichier de configuration setkey.conf va contenir toutes les politiques de sécurité (SP). Ce sont ces politiques qui permettent de dire quel type de traitement à appliquer aux flux entrants et sortants Exemples : setkey.conf de la passerelle On efface toutes les politiques de sécurité ainsi que les associations de sécurité. #pc002.vpn1.stagiaires.tst #/etc/racoon/setkey.conf flush; spdflush; Les flux entrants #Le trafic entre vpn1 et vpn2 necessite IPSec #Entree Copyright CRI74 GNU Free Documentation Licence Page 5 sur 17

6 Nous allons définir toutes les politiques de sécurité pour les flux entrants syntaxe: spdadd src_range dst_range upperspec policy ; src_range et dst_range : adresses réseaux que l'on souhaite sécuriser. upperspec : protocoles à encapsuler : ip, tcp, icmp,esp... policy : politique de sécurité à utiliser spdadd / /24 any -P in ipsec esp/tunnel/ /require; - spdadd : ajout d'une politique de sécurité dans la base de données (Security Policy Database) : / /24 correspond aux 2 réseaux auxquels s'appliquent la SP. Il s'agit d'une SP pour un flux entrant donc le premier réseau à spécifier est le réseau distant. any : indique que tous les protocoles seront encapsulés par IPSec -P ipsec esp/tunnel/ /require : correspond à la politique de sécurité. Cela veut dire que tout paquet en provenance du réseau à destination du réseau devra utiliser IPSec en mode ESP en créant un tunnel entre les 2 passerelles d'adresse et Le «require» signifie que c'est obligatoire. Cette entrée est utilisée pour relier les 2 sous-réseaux privés. Les machines de ces sousréseaux sont reliées par un tunnel IPSec et ne sont plus invisibles les une envers les autres. Elles peuvent donc communiquer. Cette entrée est indispensable pour que le sous-réseau puisse communiquer de façon sécurisée avec la passerelle du sous-réseau : spdadd / /32 any -P in ipsec esp/tunnel/ /require; Cette entrée est indispensable pour que la passerelle puisse communiquer de façon sécurisée avec la passerelle du sous-réseau : spdadd / /24 any -P in ipsec esp/tunnel/ /require; Cette entrée est indispensable pour que la passerelle puisse communiquer de façon sécurisée avec la passerelle : spdadd / /32 any -P in ipsec esp/tunnel/ /require; Les flux transitants Les règles Forward sont les mêmes que celles pour les flux entrants. Il suffit de remplacer «-P in» par «-P fwd». Si lorsque vous lancez setkey et qu'il vous indique que des fichiers existent déjà, c'est que les règles forward sont ajoutées automatiquement, on peut donc les enlever de ce fichier de configuration : #Forward cree automatiquement #spdadd / /24 any -P fwd ipsec esp/tunnel/ /require; #spdadd / /32 any -P fwd ipsec esp/tunnel/ /require; #spdadd / /24 any -P fwd ipsec esp/tunnel/ /require; #spdadd / /32 any -P fwd ipsec esp/tunnel/ /require; Copyright CRI74 GNU Free Documentation Licence Page 6 sur 17

7 Les flux sortants Les règles pour les flux entrants sont suffisamment détaillées pour comprendre l'exemple cidessus. Les règles pour les flux sortants sont symétriques, on obtient cela (toujours sur la passerelle ) : #Sortie spdadd / /24 any -P out ipsec esp/tunnel/ /require; spdadd / /32 any -P out ipsec esp/tunnel/ /require; spdadd / /24 any -P out ipsec esp/tunnel/ /require; spdadd / /32 any -P out ipsec esp/tunnel/ /require; Lancer Setkey On utilise la commande setkey. Pour appliquer le fichier de configuration setkey.conf : $ setkey -f /etc/racoon/setkey.conf Voici quelques options utiles : -D : affiche toutes les SA de la BDD. -DP : affiche les SA et les SP -F : efface les SA -FP : efface les SA et les SP Le fichier de configuration racoon.conf Le fichier racoon.conf est décomposé en plusieurs parties. Seules les parties «remote» et «sainfo» sont intéressantes, les autres étant plus statiques. La partie «remote» précise le comportement de racoon pour la phase I d'authentification pour une machine distante donnée. La partie «sainfo» définit le comportement de racoon pour la phase II(négociation des algorithmes et des clés et création des SA correspondantes) Exemple de racoon.conf sur la passerelle #/etc/racoon/racoon.conf #repertoire des clés RSA path certificate "/etc/racoon/clersa"; Partie listen Cette partie indique à racoon sur quelle adresse IP écouter : listen { isakmp [500]; Partie remote On utilise le mode d'échange normal : remote { exchange_mode main; Les machines locales et distantes s'identifient par leur nom qualifié. Il s'agit du DN (Distinguished Name) contenu dans les certificats des machines : Copyright CRI74 GNU Free Documentation Licence Page 7 sur 17

8 my_identifier asn1dn; peers_identifier asn1dn; Active la vérification de la machine distante. Off pour désactiver : verify_identifier on; On précise le nom de la clé publique et le nom de la clé privée : certificate_type x509 "vpn1.public" "vpn1.private"; Durée de vie de la phase 1. Après ce temps, la phase d'authentification est relancée : lifetime time 10 min; Voici les paramètres à définir pour les algorithmes utilisés lors de la phase 1 : proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method rsasig; dh_group 2; #algorithme de chiffrement #algorithme de hachage #methode d'authentification pour la phasei Partie sainfo Il faut définir les SA dans les 4 cas de communication. Définition de la SA pour la liaison entre les 2 machines du sous-réseau : sainfo address /24 any address /24 any { Groupe utilisé pour l' exponentiation de Diffie-Hellman : pfs_group 2; Durée de vie de la phase 2 : lifetime time 2 min; Type d'algorithme de chiffrement : encryption_algorithm 3des; Type d'algorithme de signature : authentication_algorithm hmac_md5; Utilisation de la compression des paquets IPSec compression_algorithm deflate;. sainfo address /24 any address /32 any { idem sainfo address /32 any address /24 any { idem sainfo address /32 any address /32 any { idem Copyright CRI74 GNU Free Documentation Licence Page 8 sur 17

9 voir le man pour plus de détails Lancer Racoon Pour lancer racoon : racoon -F -d -f /etc/racoon/racoon.conf. Les options : - F permet d'afficher à l'écran les messages de racoon. - d affiche les messages de debug de racoon : permet de détecter plus facilement les erreurs. - f : permet de passer un fichier en paramètre. OU /etc/init.d/racoon start /etc/init.d/racoon stop Certificats X Les certificats Racoon supporte l'utilisation des certificats X.509 pour le processus d'authentification des 2 passerelles VPN. Avec des certificats, il n' y a plus de partage de secret : une partie reste secrète uniquement sur la machine et une partie publique est diffusée. Chacune des passerelles possède un certificat d'authentification signée par une authentification de certification (CA) en qui elles ont confiance et qui certifie que le contenu du certificat appartient bien à la passerelle définie par ce certificat. De plus, chaque partie doit posséder le certificat de l'autorité pour pouvoir vérifier la signature du certificat de la passerelle VPN distante. Chaque passerelle possède 2 certificats : son certificat signé par la CA et celui de la CA. Ceux-ci sont stockés dans le répertoire : /etc/racoon/certs. Il doit avoir un accès limité puisqu'il contient la clé privée de la machine locale(le fichier qui contient la clé privée devra être, lui aussi, limité en lecture). Ce répertoire peut aussi contenir une liste de révocation(liste des certificats ne pouvant plus être utilisés pour l'authentification) Le fichier de configuration setkey.conf Il est identique à celui détaillé précédemment Le fichier de configuration racoon.conf Le fichier va subir quelques modifications pour que les certificats soit utilisés pour l'authentification Exemple de racoon.conf sur la passerelle #/etc/racoon/racoon.conf #repertoire des certificats path certificate "/etc/racoon/certs"; Partie listen Cette partie ne change pas. Copyright CRI74 GNU Free Documentation Licence Page 9 sur 17

10 Partie remote remote { exchange_mode main; my_identifier asn1dn; peers_identifier asn1dn; verify_identifier on; certificate_type x509 "pc002_vpn1_stagiaires_tst.pem" "vpn1key.pem"; On précise le type du certificat, le nom du certificat et le nom de la clé privée. Attention : racoon est incapable de déchiffrer la clé privée. Il faut donc la déchiffrer en utilisant openssl avec la passphrase. # openssl rsa -in vpn1.key -out vpn1key.pem De plus, il faut créer des liens pointant sur le certificat de la CA et sur la liste de révocation. # ln -s Cafile.pem `openssl x509 -noout -hash < Cafile.pem`.0 # ln -s CRLfile.pem `openssl x509 -noout -hash < CRLFile`.r0 Durée de vie de la phase 1. Après ce temps, la phase d'authentification est relancé : lifetime time 10 min; Voici les paramètres à définir pour les algorithmes utilisés lors de la phase 1 : proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method rsasig; dh_group 2; #algorithme de chiffrement #algorithme de hachage #methode d'authentification pour la phasei Partie sainfo Cette partie ne change pas. Copyright CRI74 GNU Free Documentation Licence Page 10 sur 17

11 4 Les erreurs possibles Voici des erreurs qui peuvent survenir lors de la configuration des racoon. 4.1 Lors du démarrage de setkey Cette commande ne pose pas souvent de problème. Il s'agit généralement d'erreur de syntaxe ou de paramètres( lorsque l'on passe en paramètre un fichier inexistant ou placé ailleurs ). 4.2 Lors du démarrage de racoon Au démarrage, les erreurs courantes sont des erreurs de syntaxe ou d'emplacements de fichiers ERROR: glob found no matches 1. racoon ne trouve pas le fichier de configuration passé en paramètre. Solution : Vérifier le chemin du fichier passé en paramètre ERROR: failed to bind to address Cette erreur arrive lorsqu'on lance racoon une deuxième fois. 4.3 Lors d'un ping d'une machine Connect: Resource temporarily unavailable Cela arrive quand une des 2 machines n'a pas lancé racoon. Solution : lancer racoon sur les 2 machines Si racoon est lancé sur les 2 machines Le ping n'a pas fonctionné mais il a servi à initialiser les phase 1 et 2. Le tunnel IPSec est maintenant créé. Solution : il faut renouveler le ping Connect: No such process Cette erreur se produit lorsque racoon n'est lancé sur aucune des 2 machines et que les politiques de sécurité sont en place. Solution : flusher SAD ==> ping banal sans tunnel IPSec lancer racoon sur les 2 machines ==> tunnel IPSec ERROR: failed to get my CERT. Racoon n'arrive pas à récupérer son propre certificat. Solution: Copyright CRI74 GNU Free Documentation Licence Page 11 sur 17

12 vérifier que le certificat de la machine est présent dans /etc/racoon/certs vérifier dans le fichier /etc/racoon qu' il y ait bien la ligne : path certificate "/etc/racoon/certs"; ERROR: the peer's certificate is not verified. Cette erreur indique que la machine locale n'arrive pas à vérifier la signature du certificat qu'elle reçoit. Solution : Demander un certificat auprès de la CA qui a signée le certificat de la machine distante. Le stocker dans /etc/racoon/certs ERROR: ISAKMP-SA has not been established yet. Si cette erreur n'apparaît que sur la machine locale(avec répétition), alors c'est la machine distante qui a un problème. Solution : Résoudre le problème sur l'autre machine. Copyright CRI74 GNU Free Documentation Licence Page 12 sur 17

13 5 Lexique AES : AES est le sigle d'advanced Encryption Standard, en français «standard de chiffrement avancé». Il s'agit d'un algorithme de chiffrement symétrique, choisi en octobre 2000 par le NIST pour être le nouveau standard de chiffrement pour les organisations du gouvernement des États-Unis. Authentification: Il y a plusieurs types d'authentification. L'authentification des connexions et l'authentification des données. Lors d'une interconnexion entre sites distants, les interlocuteurs sont des équipements réseau, tels que des routeurs et/ou des firewalls. Dans ces conditions, l'authentification consiste à s'assurer que chacune des extrémités de la communication est bien celle qui est attendue, et qu'elle le reste tout au long de sa communication. La procédure doit évidemment être automatisée. En revanche, s'il s'agit de la connexion d'un utilisateur nomade(roadwarrior), il est nécessaire de s'assurer qu'il s'agit bien de l'utilisateur en question(et non plus seulement de son ordinateur) avant «d'ouvrir» le réseau de l'entreprise. Concernant l'authentification des données, l'objectif est de s 'assurer que l'émetteur des données en question est bien celui qu'il prétend être. Le mécanisme de signature des données permet cela. Autorité de certification : entité qui crée des certificats. C'est une autorité morale qui définit les règles d'entrée des ressources et des individus dans la PKI. En pratique, il s'agit de définir les critères et les modalités d'attribution de certificats numériques. Autorité d'enregistrement : entité chargée de recueillir les demandes de certificats et de contrôler l'identité de la personne ainsi que les critères d'attribution. Bi-clé : couple de clés composé d'une clé privée et d'une clé publique Blowfish est un algorithme de chiffrement symétrique par blocs conçu par Bruce Schneier en Certificat : Une identité électronique qui est émise par une tierce partie de confiance pour une personne ou une entité réseau. Chaque certificat est signé avec la clé privée de signature d'une autorité de certification. Il garantit l'identité d'un individu, d'une entreprise ou d'une organisation. En particulier, il contient la clé publique de l'entité et des informations associées à cette entité. Certificat Auto signé : un certificat auto signé contient comme tout certificat une clé publique. Sa particularité réside dans le fait que ce certificat est signé avec la clé secrète associée. Dans ce cas précis, l'autorité de certification est donc le détenteur du certificat. Certificat X.509 : Il s'agit d'une norme sur les certificats largement acceptée et conçue pour supporter une gestion sécurisée et la distribution des certificats numériquement signés sur le réseau Internet sécurisé. Le certificat X.509 définit des structures de données en accord avec les procédures pour distribuer les clés publiques qui sont signées numériquement par des parties tierces. Certificat X.509v3 : Les certificats X.509v3 ont des extensions de structures de données pour stocker et récupérer des informations pour les applications, des informations sur les points de distribution des certificats, des CRLs et des informations sur les politiques de certification. Chaque fois qu'un certificat est utilisé, les capacités de X.509v3 permettent aux applications de vérifier la validité de ce certificat. Il permet aussi à l'application de vérifier si le certificat est dans une CRL. Ces certificats et CRLs sont normalisés auprès de l'ietf dans la RFC Clé : Une quantité utilisée en cryptographie pour chiffrer/déchiffrer et signer/vérifier des données. Copyright CRI74 GNU Free Documentation Licence Page 13 sur 17

14 Contrôle d'intégrité : Le contrôle d'intégrité a pour objectif de garantir que les données n'ont pas été modifiées (volontairement ou non) au cours de leur transmission. Un code spécifique (MAC : Message Authentication Code) est généré pour chaque message et transmis avec ce dernier. A l'issue de la transmission, le MAC est régénéré par le destinataire et doit correspondre à celui reçu avec le message correspondant. Un tel système n'est cohérent que si le mécanisme de génération de MACs s'appuie sur un mécanisme de hashage irréversible et dont les probabilités de collisions sont acceptables. C'est la raison pour laquelle les algorithmes tels que SHA-1 et MD5 sont le plus utilisés. CRL : (Certificat Revocation List) se sont les listes de révocations de certificats. Clé Publique : quantité numérique, attachée à une ressource ou un individu, qui la distribue aux autres afin qu'ils puissent lui envoyer des données chiffrées ou déchiffrer sa signature. Clé Privée : quantité numérique secrète attachée à une ressource ou à un individu, lui permettant de déchiffrer des données chiffrées avec la clé publique correspondante ou d'apposer une signature au bas de messages envoyés vers des destinataires. Le Data Encryption Standard (DES) est une méthode de chiffrement utilisant des clés de 56 bits. Son emploi n'est plus recommandé aujourd'hui, du fait de sa lenteur en logiciel et de son espace de clés trop petit permettant une attaque systématique en un temps raisonnable. Quand il est encore utilisé c'est généralement en Triple DES, ce qui ne fait rien pour améliorer ses performances. DES a notamment été utilisé dans le système de mots de passe Unix. Le Triple DES (aussi appelé 3DES) est un algorithme de chiffrement symétrique enchaînant 3 applications successives de l'algorithme DES sur le même bloc de données de 64 bits, avec 2 ou 3 clés DES différentes. Même quand 3 clés de 56 bits différentes sont utilisées, la force effective de l'algorithme n'est de que 112 bits et non 168 bits, à cause d'une attaque rencontre au milieu. Cette attaque reste cependant peu praticable, en effet elle nécessite un stockage de données de l'ordre de 2 56 mots de 64 bits, de plus ce stockage doit être «interrogeable» en un temps très court. C'est pour éviter ce genre d'attaque que le Double DES est simplement proscrit et que l'on passe directement à du Triple DES, le Double DES n'assure en effet qu'une force effective de 57 bits. Diffie-Hellman : W. Diffie et M. Hellman sont les inventeurs de la cryptographie à clé publique; ce concept a été présenté en 1976 comme faisant intervenir une paire de clés (une pour le chiffrement et une pour le déchiffrement). Ils ont démontré qu'on ne pouvait pas déduire la première de la seconde. Il existe beaucoup d'algorithmes basés sur leur travaux mais peu sont sûrs (au le sens mathématique). DH n'est pas utilisé pour chiffrer mais est un algorithme de gestion de clés. DSA : le Digital Signature Algorithm, plus connu sous le sigle DSA, est un algorithme de signature numérique standardisé par le NIST aux États-Unis, du temps où le RSA était encore breveté. Cet algorithme fait partie de la spécification DSS pour Digital Signature Standard adoptée en 1993 (FIPS 186). Une révision mineure a été publiée en 1996 (FIPS 186-1) et le standard a été amélioré en 2002 dans FIPS Il est couvert par la patente n aux USA (26 juin 1991), attribuée à David Kravitz, ancien employé de la NSA. IGC(Infrastructure de Gestion Clés) IPSec : IPSec est un protocole (couche 3 modèle OSI) permettant le transport de données chiffrées sur le réseau IP. Il est définit par la RFC 2401 MD5 : L'algorithme de signature MD5, pour Message Digest 5, est une fonction de hachage encore très populaire, mais qui n'est plus considéré comme un algorithme sûr. On suggère maintenant d'utiliser plutôt un algorithme basé sur le SHA-1 ou de type RIPEMD-160. Le MD5 a été inventé par Ronald Rivest. Noyau (en anglais «kernel») : le noyau est la partie fondamentale d'un système Copyright CRI74 GNU Free Documentation Licence Page 14 sur 17

15 d'exploitation, il est le gestionnaire de ressources de la machine, qui permet aux éléments matériels et logiciels de fonctionner ensemble. Pour ces raisons, il est le premier logiciel chargé en mémoire (hors gestionnaire de boot). PKI (Public Key Infrastructure), aussi communément appelée IGC (Infrastructure de Gestion de clés) ou ICP (Infrastructure à clés Publiques), est un ensemble de composants physiques (des ordinateurs, des cartes à puces), de procédures humaines (vérifications, validation) et de logiciels (système) en vue de créer et de gérer le cycle de vie des certificats numériques. RSA : RSA est un algorithme asymétrique de cryptographie à clé publique, très utilisé dans le commerce électronique, et plus généralement pour échanger des données confidentielles sur Internet. Cet algorithme a été décrit en 1977 par Ron Rivest, Adi Shamir et Len Adleman; les lettres RSA sont les initiales de leurs noms. RSA a été breveté par le MIT en 1983 aux États- Unis d'amérique, mais le brevet a expiré le 21 septembre SHA-1 : Secure Hash Algorithm Number 1.SHA est un algorithme de hachage Signature électronique : C'est un mécanisme qui permet de prouver l'identité de l'émetteur d'un message. L'expéditeur chiffre l'empreinte du message avec sa clé privée = signature Le destinataire déchiffre la signature avec la clé publique de l'expéditeur Le destinataire crée une empreinte du message. Si celle-ci est identique à celle déchiffrée alors l'expéditeur est bien celui qu'il prétend être. Pour la signature, l'algorithme asymétrique couramment utilisé est DSA. SSL : (Secure Socket Layer), c'est un protocole de sécurisation conçu par Netscape qui se situe entre la couche transport (TCP) et les protocoles de la couche application. Il assure les services de sécurité suivantes : confidentialité, 'intégrité et 'authentification du serveur et du client. VPN : (Virtual Private Network ou Réseau Privé Virtuel), un réseau privé virtuel repose sur un protocole, appelé protocole de tunnelisation (tunneling), c'est-à-dire un protocole permettant aux données passant d'une extrémité du VPN à l'autre d'être sécurisées par des algorithmes de cryptographie. Le terme de «tunnel» est utilisé pour symboliser le fait qu'entre l'entrée et la sortie du VPN les données sont chiffrées et donc incompréhensible pour toute personne située entre les deux extrémités du VPN, comme si les données passaient dans un tunnel. Dans le cas d'un VPN établi entre deux machines, on appelle client VPN l'élément permettant de chiffrer les données à l'entrée et serveur VPN (ou plus généralement serveur d'accès distant) l'élément déchiffrant les données en sortie. De cette façon, lorsqu'un utilisateur nécessite d'accéder au réseau privé virtuel, sa requête va être transmise en clair au système passerelle, qui va se connecter au réseau distant par l'intermédiaire d'une infrastructure de réseau public, puis va transmettre la requête de façon chiffrée. L'ordinateur distant va alors fournir les données au système pare-feu de son réseau local qui va transmettre la réponse de façon chiffrée. À la réception sur le proxy de l'utilisateur, les données seront déchiffrées, puis transmises à l'utilisateur Copyright CRI74 GNU Free Documentation Licence Page 15 sur 17

16 6 Webliographie vpn.html Copyright CRI74 GNU Free Documentation Licence Page 16 sur 17

17 Copyright CRI74 GNU Free Documentation Licence Page 17 sur 17