Accs distants scuriss : un essai de bilan des solutions possibles

Marie Claude Quidoz CNRS/UREC

1 Problmatique
Lors du choix de larchitecture des points daccs des laboratoires Internet, concrtement Renater, la scurit ntait pas un critre prioritaire. Le but principal tait alors que toutes les machines des sites sans exception puissent accder et tre accdes de lInternet avec le meilleur dbit possible. Le choix du tout ouvert , au moment o il a t fait, ntait pas une erreur ; mais rester maintenant dans la mme logique en serait une. Cest la raison pour laquelle lUREC a tabli des recommandations darchitecture de rseau avec des filtrages afin damliorer la scurit1. Cependant, il apparat que de plus en plus de personnels des laboratoires dsirent accder aux ressources internes depuis lextrieur de leur laboratoire. Cest principalement pour accder leur messagerie ou lIntranet du laboratoire, mais parfois aussi pour rapatrier des documents ou pour se connecter leur machine. Ces demandes proviennent des utilisateurs en dplacement ou dutilisateurs travaillant chez eux ; ils utilisent soit un poste personnel (fixe ou portable), soit un poste collectif. Pour des raisons de scurit, ces demandes sont difficiles accepter par les administrateurs informatiques des laboratoires ; la crainte, trs justifie, que lutilisateur se fasse drober son mot de passe lors de sa connexion est forte (dans les applications courantes, le mot de passe circule en clair sur le rseau). Mais une volution apparat, puisquil existe maintenant de plus en plus de solutions pour scuriser les accs distants :

application SSH ( Secure Shell ), protocole SSL ( Secure Socket Layer ), protocole IPSec ( Internet Protocol Security ).

En parallle, un lment complmentaire prendre en compte au niveau de lamlioration de la scurit est larrive moyen terme des certificats2 lectroniques pour les utilisateurs des laboratoires. Ce certificat pourra tre utilis dans les applications avec SSL pour authentifier les utilisateurs (par exemple HTTPS) ou dans la messagerie (par exemple Netscape Messenger) pour assurer les quatre fonctions de base de scurit (intgrit, authentification, confidentialit et non rpudiation). De nombreuses solutions sont possibles, mais lesquelles peut-on prconiser pour les laboratoires ( court terme et plus long terme), cest la question laquelle cet article souhaite apporter quelques lments de rponse. Tout au long de cet article, des produits seront cits titre dexemple, mais il ne sagit en aucune manire dtablir une liste des produits installer pour offrir des accs distants scuriss ; son objectif est plutt damener le

lecteur se poser les bonnes questions sur ces nouvelles technologies, car bien que techniquement trs sduisantes, leur utilisation peut parfois entraner dautres vulnrabilits. Cet article est articul en trois parties ; la premire partie est consacre la prsentation des besoins satisfaire et la deuxime aux technologies (IPSec, SSL, SSH) et aux rappels indispensables faire sur la lgislation. Une fois les rappels faits, nous illustrons, dans la dernire partie, les points forts et les points faibles de chaque technologie et cela partir de quelques exemples concrets.

2 Etude des besoins

Deux populations, trs diffrentes de par leur besoin, leur culture informatique et leur matrise de linformatique, sont concernes par les accs distants scuriss : les utilisateurs et les administrateurs systmes et rseaux. Les besoins exprims par les utilisateurs peuvent tre rsums ainsi :

accder leur messagerie (pour lire et envoyer des messages), accder aux informations internes du laboratoire (Intranet), accder leur poste de travail dans le laboratoire o pour rcuprer des fichiers, o pour travailler sur leur espace (personnel ou non).

Les administrateurs expriment en plus le besoin daccder aux machines du laboratoire pour en assurer la maintenance distance (connexion en root ). Une vision globale des besoins et des limites peut tre schmatise de la faon suivante :

Ainsi rsums, ces besoins semblent assez simples , mais en regardant dans le dtail, nous nous apercevons quils ncessitent dtre affins. Prenons le cas par exemple de la messagerie ; le besoin nest pas seulement de lire des messages et den envoyer, mais peuttre aussi pour certains utilisateurs de les chiffrer ou simplement de les signer pour les envoyer dans une liste de diffusion dont le droit de publier est contrl par certificat (au lieu de ladresse de messagerie). Lapprofondissement des besoins est donc indispensable raliser, car les solutions prconiser ne seront pas les mmes ; par exemple, une simple interface web de consultation et de gestion des messages lectroniques (appele couramment passerelle messagerie ou webmail 3) peut tre suffisante si les fonctionnalits offertes par les certificats ne sont pas ncessaires. Nous prenons conscience quil faudra sans doute offrir toute une panoplie de solutions pour rpondre aux besoins prcis des utilisateurs. Mais, avant de proposer telle ou telle solution, nous devrons tre vigilants pour que la solution, propose aux utilisateurs pour amliorer les services offerts depuis lextrieur du laboratoire, ne soit pas en contradiction avec la politique de scurit dfinie au sein du laboratoire et plus prcisment avec larchitecture scurise mise en place et soit galement la plus possible en adquation avec leurs besoins. Par exemple, admettons quil existe une solution scurise (FTP + SSL) permettant daccder depuis lextrieur chaque serveur de fichiers du laboratoire pour transfrer des fichiers, est ce que nous allons pour autant donner laccs tous ces serveurs ? ou bien limiter laccs des serveurs ddis ? Exemple : les besoins en matire de messagerie En terme de fonctionnalit, les besoins des utilisateurs en matire de messagerie sont : 3

lire les nouveaux messages, envoyer des messages, joindre des pices attaches (de taille illimite ?), accder son carnet dadresses, accder ses anciens messages (si cest leur fonctionnement normal ; cest dire si leur messages sont dhabitude sauvegards), bnficier de ses filtres (si cest leur fonctionnement normal), utiliser son certificat (si cest son fonctionnement normal), retrouver son environnement son retour au bureau (messages lus/archivs/dtruits).

En dehors de ces besoins fonctionnels, certains utilisateurs souhaitent :

concernant loutil de messagerie : o ne pas avoir installer de nouveaux produits, o disposer dun logiciel facile dutilisation (interface intuitive), o disposer du logiciel quils utilisent au sein du laboratoire (ne pas changer leurs habitudes).

concernant lendroit do ils se connectent : o depuis sa maison (portable ou poste fixe), o depuis un endroit hostile (cybercaf, confrence, ..), o depuis un autre laboratoire (endroit souvent considr moins hostile par les utilisateurs !).

concernant la machine partir de laquelle ils se connectent : o depuis un poste personnel (portable ou fixe), o depuis un poste collectif.

concernant la dure (ou la frquence) dutilisation : o utilisation ponctuelle (lors dun dplacement), o rgulire

Ses besoins et souhaits sont comprhensibles et acceptables. A nous dapporter des rponses cohrentes et dexpliquer aux utilisateurs quels sont les souhaits ralistes dans ltat actuel des possibilits de communication et des connaissances en matire de scurit. De plus, il faudra aussi leur apporter des solutions ralistes ; par exemple, depuis une salle en libre accs durant une confrence, lutilisateur naura pas la possibilit dinstaller des logiciels (absence probable de droits administrateurs, absence de lecteur de disquette (ou CDROM), ). Il ne sert rien de lui conseiller dinstaller un produit (style SSH, nouvelle version Eudora, ) pour pouvoir accder sa messagerie de faon scurise. A contrario, si lutilisateur accde depuis sa maison avec un poste personnel et que cette utilisation est assez rgulire, il faudra lui conseiller de sinvestir dans une installation cohrente de sa machine pour lui permettre de bnficier au mieux de sa messagerie.

3 Quelques dfinitions
4

Scuriser les accs distants ne recouvre pas obligatoirement le mme concept pour tout le monde. Pour certains, cela signifie viter que le mot de passe circule en clair et donc ne soit intercept ; pour dautres, cela signifie disposer dune authentification forte permettant dtre sr des machines prsentes aux deux extrmits (serveur et/ou client) et pour dautres encore, cela peut sous-entendre assurer la confidentialit et lintgrit des donnes qui circulent sur le rseau . Dans les faits, scuriser les accs distants recouvre toutes les facettes de la scurit : authentification, non rpudiation, confidentialit et intgrit des donnes. Les rponses peuvent tre apportes diffrents niveaux :

physique : dispositif (matriel) rseau : IPSec, IPV6 transport : SSL/TLS applicatif : SSH, S/MIME,

Ces rponses sont toutes fondes sur lutilisation de la cryptologie, mais comme nous le verrons par la suite, elles ne sont pas quivalentes, donc pas concurrentes, mais plutt complmentaires. Mais avant de vous le montrer sur quelques exemples, nous allons faire un bref rappel des termes (IPSec, SSL/TLS, SSH) ainsi que de la lgislation actuellement en vigueur en France en matire de cryptographie.

3.1 IPSec
IPSec4 (Internet Protocol Security) est un protocole fournissant un mcanisme de scurisation au niveau de la couche rseau (IP) ; cest une extension dIP pour pallier ses faiblesses (coute du rseau et spoofing). De par sa position, il agit sur chaque datagramme IP et permet ainsi doffrir une protection unique pour toutes les applications. Ce protocole, composante indissociable dIPV65, est utilisable aussi sur IPV4 (si le fournisseur a choisi de limplanter dans son produit). Son origine remonte 1995, date des premiers RFC6 sur le sujet ; une seconde version des RFC est disponible depuis 1998 (cf. travaux du groupe de travail au sein de lIETF7). IPSec permet de chiffrer et/ou dauthentifier les changes entre deux quipements (quipements actifs du rseau ou postes de travail). Ces deux services de scurit (confidentialit et authentification) sont assurs par les extensions faites IP : AH (Authentification Header) RFC 2402 et ESP (Encapsulating Security Payload) RFC 2406 et par le protocole dchanges de clefs IKE (Internet Key Exchange) RFC 2409. Comment utiliser IPSec ?

utilis entre deux routeurs, il permet de crer des VPN (Virtual Private Network) scuriss, au dessus dun rseau public pas forcment rput pour sa fiabilit (comme lInternet) ; par exemple pour protger les changes entre les diffrents sites dun laboratoire, utilis entre un serveur et un poste individuel reli par lInternet, il permet un utilisateur daccder des donnes internes sans rduire le niveau de scurit ; par exemple pour un administrateur dsirant administrer ses machines pendant ses vacances ! il peut tre galement utilis en interne pour protger une machine particulirement sensible et pour raliser un contrle daccs fort ; par exemple pour limiter laccs une autorit de certification quelques postes de travail bien identifis et en protger les communications.

Les algorithmes de chiffrement et les mcanismes utiliss peuvent tre divers dans IPSec. Ils sont ngocis au dbut de la connexion entre les quipements. Les algorithmes asymtriques, les fonctions de hachage, les couples de clefs publique/prive et les certificats constituent le cur du systme. Avec IPSec, ce sont les quipements qui possdent des certificats et non les utilisateurs. Cette technologie, trs attrayante, car totalement transparente pour lutilisateur et pour les applications, bute encore actuellement sur le problme de linteroprabilit des quipements en provenance de diffrents constructeurs. Cette situation va sans doute voluer trs rapidement vu le nombre de travaux actuels sur ce sujet. Cependant, avant de dployer cette technologie, une analyse des besoins est ncessaire pour dterminer exactement la portion de communication scuriser et pour ne pas se mprendre sur la portion scurise. Par exemple, si IPSec est utilis entre deux routeurs, toutes les communications, do quelles viennent, qui transiteront entre ces deux routeurs seront chiffres et donc confidentielles entre ces routeurs. Par contre, sur le rseau local, entre le routeur local et la station de lutilisateur, elles ne seront plus chiffres (sauf si IPSec va jusqu la station !) et cest, le plus souvent, sur cette partie l du rseau que les sniffers sont installs par les pirates !

3.2 SSL/TLS
SSL8 (Secure Socket Layer) est un protocole dvelopp initialement par la socit Netscape Communications Corporation , qui a t repris depuis par lIETF sous le nom de TLS (Transport Layer Security) ; ce protocole continue tre plus connu sous le nom de SSL. La version 3 est en cours de normalisation par lIETF. Ce protocole permet dassurer lauthentification des extrmits du circuit de communication ainsi que la confidentialit et lintgrit des donnes changes et cela grce lutilisation des certificats coupls avec des algorithmes forts de chiffrement et de signature. Conceptuellement, il sinsre entre lapplication (HTTP, telnet, ) et les couches logicielles rseau (TCP pour tre prcis), ce qui le rend presque transparent pour le protocole applicatif.

Il sappuie sur des numros de ports spcifiques (443 pour HTTPS au lieu de 80 pour HTTP, 993 pour IMAPS au lieu de 143 pour IMAP, etc.). Lorsque la session est tablie entre le client et le serveur, toutes les donnes qui transitent sur le rseau sont chiffres et signes ; le flux de donnes transmis est segment en enregistrements (cf. SSL Record Protocol Specification) et chaque enregistrement est chiffr. Ce protocole est souvent utilis en mode dissymtrique , o uniquement le serveur possde un certificat, le client nen possdant pas ; cest le cas le plus courant avec HTTPS ou IMAPS.

Le certificat du serveur permet de chiffrer (avec une clef de session) toutes les donnes transmises dans les deux sens et dauthentifier le serveur. Pour authentifier le client, le serveur demandera classiquement un mot de passe ou passera par le biais dautres moyens dauthentification (par exemple un numro de carte bancaire). Lavantage est que ces donnes dauthentification ne circuleront pas en clair sur le rseau, tant donn que tous les changes seront chiffrs. A noter que si le client dispose dun certificat utilisateur , lauthentification pourra se faire avec le certificat de celui-ci ; ainsi aucun mcanisme supplmentaire (par exemple nom dutilisateur et mot de passe) ne sera ncessaire. Cette manire symtrique de fonctionner permet denvisager de nombreuses utilisations (par exemple, pour raliser un Intranet au sein du CNRS, pour permettre le relayage authentifi au niveau dun relais de messagerie) comme nous le verrons dans la partie suivante. Afin de mieux comprendre les mcanismes mis en jeu, nous allons dtailler les changes raliss lors de la connexion dans le cas de HTTPS avec lhypothse que seul le serveur possde un certificat (attention l'identification des serveurs tant fonde sur les DNS, il doit y avoir identit entre le nom DNS et celui du certificat). Gnralement, lorsquun client avec son navigateur se connecte sur un serveur web scuris, ce dernier lui renvoie son certificat (pour fournir sa clef publique). Si ce certificat est dlivr par une autorit de certification reconnue par le navigateur du client, il est accept de manire transparente pour lutilisateur, sinon le navigateur demande lutilisateur sil accepte ce type de certificat ; le client a la possibilit daccepter ce certificat pour la dure de la session, de le refuser ou de laccepter jusqu ce quil expire. A noter que le chargement de ce certificat peut tre fait de manire indpendante, pralablement son utilisation ; cest le cas par exemple pour le certificat de lautorit de certification CNRS-Test (http://igc.services.cnrs.fr/CNRS-Test/recherche.html). Comment cela fonctionne au niveau interne ? Schmatiquement, le client et le serveur s'accordent sur les algorithmes d'authentification et de chiffrement utiliss lors de la session. Ensuite, le client cre une clef de session alatoire. Cette cl est transmise au serveur chiffre avec la cl publique de ce dernier. Le client et le serveur drivent de cette cl de session les quatre cls qui serviront au chiffrement des donnes et l'authentification pour les connexions du serveur vers le client d'une part et du client vers le serveur d'autre part. La seule contrainte rside dans le fait que le client et le serveur doivent possder au moins un algorithme commun. Au niveau de lutilisateur, lutilisation de SSL est transparente la condition quil dispose de logiciels (client et serveur) intgrant ce protocole (par exemple la version 5.1 dEudora avec IMAPS). A ce jour, lutilisation de SSL bute dune part sur labsence de produits intgrant SSL et sur le faible dploiement des certificats utilisateur.

3.3 SSH
SSH9 (Secure Shell) est une application dveloppe initialement par un chercheur finlandais (Tatu Ylonen10). Il sagit dun ensemble doutils permettant des connexions scurises entre des machines. Ces outils ont pour but de remplacer les utilitaires de connexion classiques noffrant pas de confidentialit (par exemple telnet) et qui sont donc beaucoup plus vulnrables. En fait, SSH chiffre et compresse (sur demande) un tunnel de session qui

scurise les donnes transmises. Ainsi non seulement le mot de passe est chiffr lors de la connexion, mais les informations circulant sur le rseau entre les deux machines le sont aussi. Les commandes remplaces sont les remote-commandes (rlogin, rsh, rcp) et telnet. De plus, il existe la possibilit de faire passer toutes les applications TCP lintrieur dun tunnel chiffr, ce qui permet de scuriser de nombreuses applications (par exemple POP, IMAP, X11, VNC, FTP, - noter que dans le cas de FTP, seul le canal de commande est chiffr, les donnes circulant en clair !). De plus, SSH permet une authentification forte des machines (donc pas seulement base sur ladresse IP sensible la mascarade) et permet aussi dutiliser des procdures didentification plus complexe que le basique couple (nom dutilisateur, mot de passe). Pour assurer lauthentification, lintgrit et la confidentialit des changes, SSH utilise des algorithmes de chiffrement asymtrique (pour assurer les mcanismes dauthentification) et des algorithmes de chiffrement symtrique (pour assurer la confidentialit des changes) ainsi quun trousseau11 de clefs, compos de bi-clefs utilisateur, de bi-clefs hte, de bi-clefs serveur et de clefs de session. SSF12 (Secure Shell Franais) est une adaptation de la suite SSH, crite par Bernard Perrot, destine l'usage sur le territoire franais en conformit avec la lgislation franaise ; dune part, la clef de session qui sert au chiffrement est cod sur 128 bits (et non sur plus comme le propose SSH) et dautre part, lapplication a fait lobjet dune dclaration de fourniture auprs du DCSSI. Cette version de SSF est compatible uniquement avec la version 1.x de SSH. SSF existe en version serveur uniquement pour des plateformes Unix ; par contre, en version client, il existe aussi un client Windows 95/NT (TTSSF-128). Depuis cette adaptation, une version 2 du protocole ainsi que de nouvelles implmentations 2.x ont t dveloppes, dans le but de corriger les faiblesses de la version 1 au niveau de la vrification de lintgrit des donnes, de saffranchir des brevets dposs sur les algorithmes et dajouter de nouvelles fonctionnalits. Il est noter que les deux protocoles ne sont pas compatibles, mais que la version 2 peut tre utilise dans un mode dgrad pour permettre aux clients version 1 de se connecter ; linverse ntant pas vrai. Ces nouvelles implmentations sont diffuses par la socit SSH Communication Security13 ( noter que ces produits sont payant, except pour une utilisation au sein dune universit ou pour une installation sur les plateformes Linux, FreeBSD, NetBSD ou OpenBSD). Une implmentation mature Open Source compatible v1 et v2 a t acheve rcemment14. Toutes ces distributions, utilisant des algorithmes de chiffrement dont les clefs ont une longueur suprieure 128 bits (par exemple Blowfish) doivent, pour tre utilises sur le territoire franais, avoir obtenu de la part de la DCSSI une autorisation de fourniture pour le fournisseur ou limportateur et une autorisation dutilisation personnelle, sil ny a pas eu dautorisation de fourniture en vue dune utilisation gnrale. SSH nutilise pas les certificats. Mais conceptuellement, il y aurait peu de dveloppement pour ajouter cette fonctionnalit. Il semblerait dailleurs que la socit SSH Communications Security lenvisage dans sa version commerciale 3.x (dont la diffusion a t annonce quelques jours avant la rdaction de cet article). Ds que possible, des tests seront raliss pour juger de linteroprabilit avec lIGC du CNRS. SSH tant un service fonctionnant au niveau applicatif, son utilisation nest pas transparente pour lutilisateur, il ncessite linstallation du logiciel SSH (ou SSF) sur le poste utilisateur.

3.4 Lgislation
Cest partir de lvolution de la rglementation en matire de cryptologie quil est apparu opportun de sintresser15 aux nouveaux standards et protocoles dcrits prcdemment ; quen est-il de la lgislation ? Depuis trois ans on assiste une volution, presque une rvolution, dans lenvironnement lgislatif16 touchant de prs la rglementation en matire de cryptographie ( art de produire des messages secrets ), donc fortiori tout le contexte authentification et confidentialit. Un premier largissement est apparu suite aux Dcrets du 24 fvrier 1998 et plus particulirement du n98-101 qui dfinit les conditions dans lesquelles sont souscrites les dclarations et accordes les autorisations concernant les moyens et prestations de cryptologie ( art des messages secrets ). Trois rgimes taient alors mis en place en fonction de lusage et de la provenance des moyens ou des prestations de cryptologie (libre dutilisation, assujetti dclaration et assujetti autorisation). Les derniers Dcrets du 17 mars 1999 assouplissent les rgimes de dclaration et dautorisation et surtout donnent dans certains cas une totale libert dutilisation des moyens de cryptologie : N99-199 dfinissant les catgories de moyens et de prestations de cryptologie pour lesquelles la procdure de dclaration pralable est substitue celle dautorisation. N99-200 dfinissant les catgories de moyens et de prestations de cryptologie dispenses de toute formalit pralable Globalement on peut rsumer les possibilits ainsi : libre dutilisation pour authentification, intgrit et non-rpudiation (applicable la signature lectronique) libert, dclaration ou autorisation pour utilisation dans le cadre de la confidentialit (applicable au chiffrement) suivant la longueur des clefs : < 40 bits Aucune formalit 40 128 bits > 128 bits Dispense de formalit si Ncessite une autorisation usage exclusivement priv ou si dclaration pralable

dans le cas de la fourniture : clefs 128 bits soumise dclaration clefs> 128 bits soumise autorisation Enfin ces dcrets sajoute lArrt du 17 mars 1999 dfinissant la forme et le contenu du dossier concernant les dclarations ou demandes dautorisation relatives aux moyens et prestations de cryptologie.

La situation actuelle va sans aucun doute voluer dans les annes futures, cependant ce jour il est impossible den connatre la date. Le seul lment certain est que le projet de loi sur la Socit de lInformation17, dpos au Conseil des Ministres du 13 juin 2001, contient une disposition sur lusage de la cryptologie (cf. Chapitre 2me du Titre V : De la scurit dans la socit de linformation ).
Extrait du Titre V : De la scurit dans la socit de linformation Le projet de loi instaure une libert totale dutilisation des moyens de cryptologie. Cette mesure annonce par le Premier ministre lors du Comit interministriel pour la socit de linformation en janvier 1999 permettra de renforcer la scurit des changes par voie lectronique en mettant disposition du public des moyens de cryptage performants. La loi fixe le cadre gnral applicable aux prestataires de moyens de cryptologie et cadre gnral bas sur trois rgimes : un rgime de libert, un rgime de dclaration et un rgime dautorisation. Comme dans la loi prcdente, la dfinition et le champ dapplication de ces rgimes sont renvoys des dcrets. Toutefois, la loi assouplit les modalits de contrle des moyens de cryptologie par rapport aux dispositions du dcret n 98-101 du 24 fvrier 1998 et des dcrets n99-199 et 99-200 du 17 mars 1999 : - en libralisant totalement lutilisation des moyens de cryptologie quels quils soient ; - en libralisant totalement limportation, la fourniture et lexportation des moyens de cryptologie assurant des fonctions de signature ; - en abrogeant le rgime dautorisation pour la fourniture des autres moyens de cryptologie et en allgeant le rgime de la dclaration.

Si ce projet de loi est vot en ces termes, lutilisation des moyens de cryptologie sera libre, MAIS il faudra toujours que le logiciel ait obtenu une dclaration dutilisation sur le territoire franais de la part du DCSSI18. Prenons un petit exemple pour illustrer la situation actuelle et lvolution prvue : Actuellement, SSH version 2 (socit SSH Communications Security ) utilisant au moins un algorithme de chiffrement dont la clef est suprieure 128 bits (Blowfish 256 bits) ncessite une demande dautorisation de vente ; cette autorisation demande par la socit a t obtenue le 13 Juillet 2000 et est valide jusqu'au 5 juillet 2005 (numro de dossier auprs du SGDN (Ex-SCSSI): 0004133). Pour utiliser ce produit, une demande dautorisation doit aussi tre faite par lutilisateur final. Si la loi est vote telle quelle, la demande dautorisation faite par la socit SSH Communications Security sera transforme en une demande de dclaration, plus facile obtenir (!). Une fois cette demande accepte, les utilisateurs pourront utiliser ce produit, sans devoir faire de dmarche complmentaire. Ce projet de loi va sans aucun doute, favoriser le dveloppement de solutions base de cryptologie, mais il ne favorisera pas lutilisation des produits libres car ils nauront que rarement fait lobjet dune demande de dclaration de la part des dveloppeurs .

4 Inventaire des solutions

Dans le cadre de cet article, nous nallons pas apporter des lments de rponses tous les diffrents besoins exprims (messagerie, connexion distance, accs des fichiers, Intranet), mais nous allons surtout essayer dillustrer les technologies prsentes dans le chapitre

10

prcdent pour montrer ce quelles apportent. Nous nous appuierons le plus souvent sur lexemple de la messagerie. A noter quune rponse partielle aux besoins daccs distants scuriss est disponible sur le site de lInstitut de Mathmatiques de Jussieu19 et quune rponse plus globale sera disponible, dans un futur proche, sur le site de lUREC20, dont laccs sera autoris aux correspondants informatiques disposant dun certificat de lautorit de certification du CNRS. Nous allons traiter brivement le cas de IPSec ; cette technologie ntant pas assez adapte, par son manque dinteroprabilit, lenvironnement souvent trs htrogne des laboratoires. De toute manire, cette technologie ne pourra pas tre dploye de faon globale dans nos laboratoires, car sa mise en uvre ncessite, entre autres, une collaboration troite entre les administrateurs des deux extrmits ; collaboration qui est envisageable dans lenvironnement dune socit, mais qui semble assez irraliste dans un environnement ouvert comme le ntre ; ce bilan sera revoir lors du dploiement dIPV6. Dans nos laboratoires, lutilisation de IPSec, dans un avenir assez proche, sera sans aucun doute limite la protection de serveurs sensibles et la protection de la communication entre deux laboratoires relis par un liaison non fiable et ayant des besoins trs spcifiques ; problmatique qui nest pas lie aux besoins exprims prcdemment. Par contre, cette solution IPSec sera conseiller aux administrateurs qui souhaitent administrer leur machine distance (en remplacement de SSH dont lutilisation est moins transparente et moins universelle) et aux utilisateurs qui souhaitent accder des donnes internes sans rduire le niveau de scurit. Mais il ne faut pas perdre de vue que cette solution, trs sduisante en thorie, est une solution parmi dautres, mais nest pas la solution universelle. Ceci est dautant plus vrai quelle ne permet pas lauthentification des utilisateurs (seules les machines sont authentifies), ce qui la rend complmentaire avec des techniques fondes sur SSL. La solution fonde sur SSL est trs utilise pour raliser des serveurs WEB scuriss. La raison de son succs provient de sa simplicit dutilisation. En effet partir du moment o le serveur et le client se comprennent en parlant SSL, lutilisation de lapplication est transparente (une fois que le certificat de lautorit de certification est intgr au navigateur) pour lutilisateur ; ceci est particulirement vrai si le protocole est utilis en mode dissymtrique o seul le serveur possde un certificat. Pour le mode symtrique par contre, le client doit apprendre grer son certificat personnel (le gnrer, le sauvegarder, lexporter, ..), ce qui rend la solution moins transparente, du moins premire vue. Dans le cas des accs distants scuriss, cette technique est mise en uvre pour offrir un accs la messagerie (passerelle de messagerie) aux utilisateurs itinrants. Ainsi muni uniquement dun navigateur, certes suffisamment volu pour comprendre le mode SSL, la consultation de sa messagerie est possible pour tous, car elle ne requiert aucune installation de logiciel et presque aucune configuration (except quelques paramtres lmentaires). Malheureusement, cette solution nest pas la solution idale pour de nombreux utilisateurs, car dune part linterface utilisateur est parfois droutante et dautre part elle noffre pas les mmes fonctionnalits quun outil vritable de messagerie ; par exemple lutilisateur na pas accs son carnet dadresses interne , et de plus il ne peut pas utiliser son certificat pour signer et chiffrer ses messages, ce qui peut tre un obstacle majeur lutilisation dune telle solution pour certains types dutilisateurs (par exemple, adhrent des listes de diffusion contrles par certificat). Cette situation voluera sans aucun doute dans un avenir proche mais actuellement la solution passerelle de messagerie est surtout conseiller pour les utilisateurs occasionnels de la messagerie distance ou ceux qui ont une utilisation lmentaire de ce service. Cependant ce jour, cest la seule technique qui peut tre disponible dans des milieux hostiles (style cybercaf), elle doit tre courte chance mise en oeuvre dans tous les laboratoires. 11

Pour pallier aux faiblesses dune passerelle de messagerie, il existe dautres solutions fondes elles-aussi sur SSL. La premire consiste utiliser un vritable outil de messagerie (style Eudora 5.1, Nescape Messenger 4.7x, Outlook 5) qui intgrent le mode SSL. Cette solution ncessite qu lautre extrmit le serveur de courrier entrant intgre lui-aussi le mode SSL. Cest le cas ce jour de IMAP et de POP depuis les versions rcentes ( noter que si le serveur IMAP ou POP ne supporte pas directement SSL il est possible d'utiliser stunnel21). Cette solution a lavantage doffrir un environnement de travail identique celui de son laboratoire (surtout si utilisation dIMAP et si les fichiers associs, style carnet dadresses, sont sur des zones accessibles depuis lextrieur), mais a deux inconvnients de taille, dune part, elle ncessite la configuration (voir linstallation) de loutil de messagerie ce qui nest pas forcment la porte de tous les utilisateurs (et pas forcment possible sur toutes les machines car parfois des droits administrateur sont ncessaires), dautre part elle ncessite de connatre le serveur de messagerie sortant disponible sur le rseau sur lequel la machine est connecte ; information parfois impossible connatre dans un environnement hostile. Cette solution nest utilisable quau sein de son laboratoire, dans un environnement moins hostile (par exemple depuis un autre laboratoire du CNRS en utilisant leur serveur de courrier sortant) ou depuis chez soi ; dans ce dernier cas, ladministrateur pourrait en effet envisager dautoriser le relayage de messages depuis certaines machines bien dtermines mais ces critres (adresse ip, nom de machine, etc.) peuvent tre aisment contourns et utiliss par des utilisateurs malveillants des fins de spam . Cest la raison pour laquelle cette autorisation est trs rarement donne et que le plus souvent lutilisateur doit se renseigner auprs de son fournisseur daccs Internet pour connatre le nom du serveur de courrier sortant indiquer dans son outil de messagerie. Pour remdier la faiblesse des critres dauthentification de lutilisateur au niveau de lautorisation de relayage sur le serveur de courrier sortant, il faut utiliser une authentification par certificat et mettre en place une politique de scurit, style tout relais en provenance de machines extrieures est interdit, sauf pour les utilisateurs ayant un certificat client valide appartenant une liste prdfinie ; ce double contrle permet de limiter laccs aux utilisateurs authentifis par certificat et appartenant au laboratoire uniquement. Il sagit en ralit dexploiter une des fonctionnalits du couple SSL et SMTP (appel SMTP-TLS)22, qui au dpart, a plutt t conu pour assurer la confidentialit entre deux serveurs SMTP. Cette dernire solution est la solution idale pour lutilisateur nomade au niveau scurit mais en pratique elle est surtout conseiller pour lutilisation intensive de la messagerie depuis un ordinateur personnel quelque soit la localisation de la machine ( la maison, en dplacement, etc.). En effet, elle ncessite de la mme faon que la solution prcdente une configuration (voir linstallation) dun outil de messagerie. Mais la diffrence de la solution prcdente, cet outil doit en plus de la possibilit dutiliser SSL pour chiffrer et authentifier les communications entrantes et sortantes tre capable de grer des certificats clients. Dans notre environnement, seul Netscape Messenger et Outlook le permettent ce jour, ce qui implique malheureusement pour les utilisateurs dEudora un changement de leurs outils de messagerie. Comme nous lavons vu dans le cas de la messagerie, le protocole SSL apporte une rponse satisfaisante aux besoins de scurit inhrents aux accs distants. Des solutions du mme genre pourraient tre mises en oeuvre pour scuriser dautres services (par exemple telnet, FTP) mais il faut que les produits existants intgrent le protocole SSL (sans forcment intgrer la notion de certificat client, indispensable uniquement pour raliser une authentification forte). Lavenir semble trs prometteur, car des dveloppements sont en cours ; citons par exemple, lajout du module SSL/TLS au niveau du serveur libre

12

 Proftpd 23 (en cours de test) ou la disponibilit du serveur commercial WS_FTP Server 2.0 24 et du client commercial WS_FTP Pro 7.0 25 diffuss par la socit Ipswitch. Mais, en attendant que les solutions fondes sur IPSec et SSL soient totalement oprationnelles et que les certificats personnels soient largement dploys dans notre environnement, nous disposons dune solution trs acceptable : SSH ; elle va encore sans aucun doute perdurer suffisamment longtemps pour scuriser au moins les services telnet et X11 . Cette solution est en effet largement utilise dans nos laboratoires pour rpondre ces deux besoins spcifiques ; la principale raison provient du fait que cest une solution assez simple (par rapport S/KEY One-Time Password System26) mme si elle ncessite linstallation dun logiciel sur chaque machine. En ralit, cest la prsence du mcanisme des canaux virtuels qui rend cette solution intressante pour dune part chiffrer totalement la communication entre deux machines et dautre part envisager de faire passer nimporte quelle application TCP lintrieur de ce tunnel ; ce mcanisme peut tre par exemple utilis pour la messagerie. Et malgr sa lourdeur (louverture du tunnel doit tre faite pralablement lutilisation de loutil de messagerie), cette solution offre lavantage de pouvoir utiliser le serveur SMTP du laboratoire distance. Attention toutefois, au fait que la liaison est scurise uniquement entre le client et le serveur SSH et non entre le serveur SSH et le serveur de messagerie ; situation qui peut tre drangeante si le rseau reliant les deux services est peu sr. Ce mcanisme pourrait tre utilis de la mme faon pour permettre daccder de faon scurise lIntranet du laboratoire. Cette solution des canaux virtuels est trs sduisante premire vue mais pour tre reconnue comme scuritaire, ladministrateur doit avoir la possibilit de matriser les ports quil accepte de rediriger sinon cela revient ouvrir une brche dans larchitecture scurise mise en place dans le laboratoire !

5 Conclusion
Si nous tablissions un bilan des solutions pour scuriser les accs distants la date daujourdhui, nous pourrions faire ressortir les lments suivants : il nexiste pas de solution idale ; des solutions partielles sont dj disponibles ; de nombreuses quipes travaillent sur ce sujet ; la lgislation sassouplit ; les utilisateurs sont de plus en plus sensibiliss ; etc.. Par consquent, si des besoins se font sentir dans les laboratoires ou si nous voulons les anticiper, nous disposons en thorie et mme pour certains en pratique de solutions pour offrir des accs distants scuriss. Mais avant doffrir des services scuriss et de former les utilisateurs leur bonne utilisation, il faut dfinir avec eux les besoins qui semblent ralistes dans leur environnement (et par consquent ceux qui semblent irralistes !). Cette dfinition se fera en fonction des connaissances actuelles en matire de scurit, de la matrise des outils informatiques par les utilisateurs et galement de la classification dfense du laboratoire. Il faut toujours garder lesprit que scuriser les accs distants permet de scuriser la communication en la chiffrant et amliorer la qualit de lauthentification des extrmits communicantes mais naugmente en aucune manire la scurit au niveau des services offerts sur le serveur ; les administrateurs devront toujours veiller appliquer, ds leur parution, les patchs de scurit disponibles. Il est noter que la multiplication des services offerts (et donc de services visibles depuis lInternet) risque de faire crotre trs fortement le risque potentiel dattaque sur ces services et donc par consquent daugmenter potentiellement le travail des

13

administrateurs (si nous considrons quactuellement tous les services non scuriss ne sont pas accessibles de lInternet !). Cest la raison pour laquelle certains se tournent vers dautres solutions ; par exemple, la solution webftp27 propose par Albert Shih qui sappuie sur le protocole HTTPS pour offrir un service scuris de transfert de fichiers depuis lextrieur de son laboratoire. En effet, si de telles solutions taient disponibles, seul le service HTTPS serait visible de lextrieur. Une autre solution, dj disponible, pourrait tre de promouvoir lusage des tunnels SSH pour que les utilisateurs puissent utiliser les services que les administrateurs ne souhaitent pas rendre visibles depuis lInternet (par exemple POP, IMAP, accs au proxy cache), mais il faut tre conscient que cette solution pour tre un peu scurise doit tre limite aux machines internes du laboratoire et mme limite quelques serveurs bien ddis ; ces limitations vont entraner des dsagrments pour les utilisateurs, mais comment faire autrement ? En attendant, il est possible techniquement de limiter au niveau des filtres du routeur les accs distants depuis lextrieur des rseaux (ou numro IP) bien dtermins (mais est-ce vraiment raliste dans nos laboratoires ?). Et il faut aussi prendre conscience que le dveloppement du chiffrement et des canaux virtuels met mal les mthodes habituelles de protection que sont le filtrage de ports au niveau du routeur, les anti-virus, les dtecteurs d'intrusion mais aussi lutilisation de la mtrologie pour analyser le trafic. Cette volution entranera sans aucun doute une redfinition de nos mthodes de protection... A la lecture de cet article, vous avez pris conscience que les solutions technologiques, bien que sduisantes, ne sont pas exemptes deffets pervers et que des analyses et des tests complmentaires sont indispensables afin de les dployer grande chelle dans vos laboratoires. Cest une des raisons pour lesquelles nous avons cr un groupe de travail sur ce thme et nous profitons de cet article pour remercier ses membres du temps quils consacrent ce travail afin dessayer doffrir des solutions adaptes notre environnement. Cet article est inspir du travail dj ralis par certains ; ils reconnatront sans aucun doute leur apport dans cet article.

6 Rfrences
1

Archimbaud Jean-Luc, Recommandations d'architecture de rseau avec filtrages pour amliorer la scurit, Janvier 2000, http://www.urec.cnrs.fr/securite/articles/archi.reseau.pdf
2

Archimbaud Jean-Luc, Certificats (lectroniques) : Pourquoi ? Comment ?, Novembre 2000, http://www.urec.cnrs.fr/securite/articles/certificats.kezako.pdf

3 4 5

Quelques rfrences sur des passerelles HTTP / Messagerie, http://www.cru.fr/http-mail/ Ensemble de documents sur IPSec, http://www.hsc.fr/ressources/veille/ipsec/index.html.fr Internet Protocol version 6 (IPv6), http://www.urec.cnrs.fr/ipv6/

14

RFC 2401, Security Architecture for the Internet Protocol, http://www.pasteur.fr/infosci/RFC/24xx/2401

7 8

Groupe de travail IPSec lIETF, http://www.ietf.org/html.charters/ipsec-charter.html

Quelques rfrences sur SSL : - Introduction to SSL, http://developer.netscape.com/docs/manuals/security/sslin/index.htm, - Baitan, Berger et Maia, Le protocole SSL (Secure Socket Layer), Mai 1998, http://www.esigge.ch/reche98/protoSSL/SSL.htm, - Aumont Serge, Dirlewanger Roland et Porte Olivier, Laccs scuris aux donnes, Tutorial Jres 1999
9

Serveur de documentations et de programmes sur SSH et SSF, http://ccweb.in2p3.fr/securite/ssf/ Tatu Ylonen, SSH - Secure Login Connections over the Internet, Juin 1996, http://www.cs.nps.navy.mil/people/faculty/irvine/classes/cs3690/004/ssh-ylonen.pdf
11 10

Perrot Bernard, Scuriser ses connexions avec SSH, Linux France Magazine, Hors Srie N 8, 2001
12 13 14 15

Serveur de documentations et de programmes sur SSF, http://ccweb.in2p3.fr/securite/ssf/ SSH Communications Security, http://www.ssh.com/ OpenSSH http://www.openssh.org/

Dausque Nicole, Infrastructures de gestion de clefs, Mai 2000, http://www.urec.cnrs.fr/securite/articles/IGC.pdf

16

Rglementation, Cryptologie, DCSSI, http://www.scssi.gouv.fr/fr/reglementation/crypto.html

17

Projet de loi sur la socit de linformation, Juin 2001, http://www.lsi.industrie.gouv.fr/observat/innov/lsi/pl.htm

18

Rglementation, Constitution dun dossier, DCSSI, http://www.scssi.gouv.fr/fr/reglementation/dossier.html

19 20

Institut de Mathmatiques de Jussieu, http://www.math.jussieu.fr/informatique/

Espace rserv aux correspondants scurit CNRS sur le site web de lUREC, https://www.services.cnrs.fr/corres-secu/
21 22

Stunnel - Universal SSL Wrapper, http://www.stunnel.org/

Thivillon Alain, SMTP-TLS : vers la scurisation de SMTP, Septembre 2000, http://www.hsc.fr/ressources/presentations/tls/index.html.en

15

23 24 25 26

TLS patch (for 1.2.1), http://www.proftpd.org/module_news.html WS_FTP Server 2.0, http://www.ipswitch.com/Products/WS_FTP-Server/index.html WS_FTP Pro 7.0, http://www.ipswitch.com/Products/WS_FTP/index.html

The S/KEY One-Time Password System, http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1760.html Albert Shih, WebFTP, disponible dans les actes de Jres 2001

27

16