Présentation sur le tunneling Utilisant SSL, SSH,...

Présentation sur le tunneling Utilisant SSL, SSH, IPSec

Professeur S. VENTURA

Biasino CASSELLA 04 Juillet 2002

ETR_6

TCOM SSL Tunneling ou Ipsec

Biasino CASSELLA - 2 -

TABLE DES MATIERES Table des matières ............................................................................................................. 2 Table des illustrations ........................................................................................................ 3 Résumé .............................................................................................................................. 4 1 Introduction................................................................................................................ 4 2 Tour d'horizon des VPN............................................................................................. 5

2.1 Qu'est-ce qu'un VPN? ........................................................................................ 5 2.2 Types de VPN .................................................................................................... 5 2.3 Utilité d'un VPN................................................................................................. 5 2.4 Mise en place d’un VPN .................................................................................... 6

3 Tunneling, (Stunnel) ................................................................................................... 7 3.1 Qu'est-ce que le tunneling? ................................................................................ 7 3.2 Qu'est-ce que le mode "Tunnel" ?...................................................................... 9 3.3 Stunnel.............................................................................................................. 10

4 Le cryptage à clé publique ....................................................................................... 11 4.1 Principe général................................................................................................ 11 4.2 Phase initiale de négociation............................................................................ 11

5 SSL........................................................................................................................... 12 5.1 Présentation de SSL ......................................................................................... 12 5.2 Les trois fonctionnalités de SSL....................................................................... 13 5.3 Le principe de fonctionnement......................................................................... 13 5.4 Composition de SSL......................................................................................... 13 5.5 Le fonctionnement de SSL............................................................................... 14 5.6 Les problèmes "techniques" de SSL ................................................................ 17 5.7 Exemple de certificat obtenu par SSL.............................................................. 17

6 IPSec......................................................................................................................... 19 6.1 Présentation de IPSec ....................................................................................... 19 6.2 Les composants de IPSec ................................................................................. 19 6.3 Les deux protocoles d’acheminement de IPSec ............................................... 19 6.4 Security association (SA)................................................................................. 21

7 SSH........................................................................................................................... 23 7.1 Présentation de SSH......................................................................................... 23 7.2 Comment cela fonctionne ................................................................................. 23 7.3 Exemple d'utilisation de SSH........................................................................... 24 7.4 Remarques concernant SSH............................................................................. 24

8 Comparaisons ........................................................................................................... 25 8.1 IPSec et PPTP................................................................................................... 25 8.2 STunnel et ses possibilités (limitées ?) ............................................................ 25 8.3 SSL vs SSH concernant l’e-mail ...................................................................... 25 8.4 Que choisir et quand ? ...................................................................................... 26

9 Conclusion................................................................................................................ 27 Annexe ............................................................................................................................. 28 Bibliographie ................................................................................................................... 28 Glossaire .......................................................................................................................... 29



TABLE DES ILLUSTRATIONS

Figure 3.1-1 Tunneling............................................................................................................... 7 Figure 3.1-2 Connexion au travers d'un modem (double PPP) .................................................. 8 Figure 3.1-3 Encapsulation PPTP .............................................................................................. 9 Figure 3.1-4 Encapsulation L2TP .............................................................................................. 9 Figure 5.1-1 Cadenas non-verrouillé et verrouillé ................................................................... 12 Figure 5.1-2 SSL selon le modèle OSI..................................................................................... 12 Figure 5.5-1 Les couches OSI et les protocoles SSL ............................................................... 14 Figure 5.5-2 Protocole SSL Record ......................................................................................... 15 Figure 5.7-1 Certificat explicité par le navigateur ................................................................... 18 Figure 6.3-1 Encapsulation AH en Mode Tunnel .................................................................... 20 Figure 6.3-2 Encapsulation ESP en mode tunnel..................................................................... 21 Figure 7.2-1 Tunnel SSH ......................................................................................................... 23 Figure 7.3-1 e-mail protégé par SSH ....................................................................................... 24



RESUME Destiné à donner un aperçu des techniques adoptées pour la mise en place de la sécurité

sur un réseau partagé et notamment sur IP. Cette présentation donne un aperçu des solutions offertes par le tunneling avec ou sans VPN, ainsi que les principaux protocoles offrant ce mécanisme; que sont Stunnel au travers l’emploi de SSL, et IPSec concernant les VPN, sans oublier SSH pour le monde Unix, notamment.

1 INTRODUCTION Désormais, Internet à franchi de nombreuses étapes, et est arrivé dans la phase, où il ne

s'agit plus uniquement de chercher à faire du développement afin que le réseau soit plus fiable, ou d'une manière générale soit plus efficace dans son fonctionnement global. Aujourd'hui une large partie des utilisateurs sont des personnes utilisant Internet dans des buts divers et variés, et non plus vraiment de lien avec les créateurs de ce réseau, qui pour eux, était le moyen de pouvoir échanger des informations concernant des domaines de pointe de la recherche. Au contraire, l'on se retrouve actuellement à ce que tous les secteurs d'activités soient représenter, ainsi que tout ce qui en général fait partie de la vie courante de tout un chacun. L'on remarque en effet une transposition de ce qui fait partie de la vie quotidienne de la population, sur Internet. Et cette dernière remarque, hélas, implique également ce qu'il y a de moins glorieux, comme par exemple les problèmes de sécurité.

Au même titre lorsqu'une personne ferme la porte à clé en quittant son domicile, ou qu'une personne préfère telle banque (ou assurance) à une autre car elle lui semble plus "sûre", ou encore le fait que l'on préfère ne pas s'aventurer dans certains quartiers car ils sont réputés "risqués", ces problèmes se retrouvent également sur Internet. En effet le voleur à été remplacé par le "hacker", et le pistolet par un clavier, mais les risques sont les mêmes si ce n'est supérieurs, du fait qu'il est plus difficile de les déceler. Par exemple en faisant les courses dans votre supermarché, il peut vous arriver de vous faire dérober votre carte de crédit, et bien sur Internet c'est la même problématique en payant vos commandes sur un site de e-commerce, vous avez également le risque de vous faire dérober votre carte, plus exactement le numéro de cette dernière.

Il a été question du commerce électronique, car cela représente une des applications les plus en vogue actuellement, et dont la sécurité et très marquée dans ce domaine. Mais la sécurité, qui peut dans certains cas être liées à l'authentification, s'applique dans de nombreux autres cas; par exemple comment empêcher l'accès à certaines parties d'un site contenant des données confidentielles.

Aux quelques remarques ci-dessus, l'on peut répondre: "en devant introduire un mot de

passe". Mais ce qui pose problème ce n'est pas tant le fait de devoir insérer le mot de passe, mais plutôt de faire en sorte que l'acheminement de ce mot de passe au travers du réseau Internet se fasse de manière sécurisée, c'est à dire que si une personne se trouve à ce même moment à écouter (sniffer) sur le même média physique que vous utiliser, qu'elle ne puisse pas comprendre (déchiffrer) ce que vous avez transmis. Et donc pouvoir le réutiliser par la suite à vos dépend.

Comme indiqué ci-dessus, ce document présente la manière dont l'on peut sécuriser le transport des informations de bout en bout (end-to-end). Et cela au travers de différents mécanismes et de variantes qui leurs sont appliquées. C'est notamment l'utilisation de VPN (Virtual Private Network), et surtout le mécanisme de Tunneling. Les sujets vont être présentés en prenant l’approche d’énoncer ce que l’on veut réaliser pratiquement, puis de donner théoriquement les protocoles permettant cela.



2 TOUR D'HORIZON DES VPN

2.1 Qu'est-ce qu'un VPN?

VPN, Virtual Private Network, est comme l'acronyme l'indique un réseau virtuel privé. Réseau ne pose pas de problème à la compréhension, alors que virtuel et privé, sont sujets à débat.Une définition qui leur est communément attribuée, est celle de pouvoir relier depuis un point quelconque, géographiquement situé à l'extérieur d'un réseau local. Par exemple une PME ayant plusieurs sites géographiques, peut depuis l'un de ses sites, être reliées sur le LAN d'une autre entité, et ce sans être physiquement "plugué", sur ce dernier. Cela laisse entrevoir la signification du mot virtuel. Concernant le privé, il est évident que si une entité à son propre réseau local, elle ne désire pas forcément que tous ceux relier à Internet par exemple, puissent avoir accès à son réseau interne, raison pour laquelle, il faut également mettre en place des mécanismes pour prévenir cela.

En synthèse, un VPN est, fournir à quelqu'un d'autorisé et étant géographiquement ailleurs, la possibilité d'avoir accès à un réseau local comme s'il était plugué directement dessus.

Il s'agit encore de faire une précision concernant ce qui vient d'être dit. Il a souvent été dit qu'il s'agit de relier deux sites géographiquement distants, mais il existe également le cas où l'on relie deux hôtes sur le même site au travers d'un VPN, mais cette fois-ci pour d'autres raisons; la sécurité, notamment sur un LAN qui n'est pas sûr.

2.2 Types de VPN

L'on peut énumérer différents types de VPN, et généralement, l'on en distingue trois: • Les communications internes à l'entreprise (Intranet). • Les communications externes à l'entreprise (Extranet). • Les accès itinérants réalisés souvent au moyen d'un réseau commuté par des

utilisateurs distants. Ces différents cas de VPN, n'ont pas tous besoin des mêmes services, et surtout, ont des

niveaux de sécurité différents.

2.3 Utilité d'un VPN

En effet si la sécurité doit être absolument respectée, pourquoi vouloir utiliser Internet, alors que c'est un des médias les plus facilement accessible du public, et partant très peu sûr de prime abord ?

Une première réponse à cela, est le fait qu’en utilisant des lignes communes cela et économiquement moins cher que d’avoir des lignes privées (lignes louées). Mais ce qui fait la force des VPN, est qu'ils permettent de se connecter depuis n’importe quel point, ( pour autant que l'on soit autorisé par l'autre extrémité), et il est utopique (pour ne pas dire impossible) de réaliser cela par des lignes privées.



2.4 Mise en place d’un VPN

Un exemple d'utilisation de VPN, est par exemple son déploiement au niveau d'une école. Où tous, professeurs et étudiants auraient accès, d'une part à leur compte (ou machine) se trouvant dans l'école. Mais aussi et surtout, à toutes les informations et dossiers accessibles lorsque l'on se trouve physiquement sur le LAN. Cela évite par exemple de devoir sauver des fichiers sur des supports amovibles, ou de les envoyer par e-mail, si l'on désire travailler chez soit.

Un autre exemple est le télétravail, l'on imagine qu'un ingénieur pourrait écrire des logiciels à son domicile, et envoyer le fruit de son travail sur le réseau de son entreprise, sur un poste doté de capacités techniques plus évoluées (mainframe, PC multimédia), s'il requière plus de puissance.

Concernant ces deux exemples, le point crucial est la sécurité qu'il faut garantir, afin que

seuls les autorisés accèdent à la partie interne d'un réseau. L'implémentation d'un VPN peut se baser sur différents types de protocoles, concernant

la liaison depuis un point à un autre; PPTP (Point-to-Point Tunneling Protocol), L2TP (Layer 2 Tunneling Protocol) ou IPSec (IP Security Protocol).

Ces différents protocoles font appel au mécanisme de tunneling, afin d'établir des connexions à l'abri de personnes malveillantes, désirant s'introduire dans un réseau. Ce mécanisme est décrit dans le chapitre 3.



3 TUNNELING, (STUNNEL)

3.1 Qu'est-ce que le tunneling?

Il s'agit premièrement de préciser la notion de "tunneling". Il s'agit en fait de créer un tunnel dans lequel par la suite, transiterons des informations sans que ces dernières doivent à chaque fois créer le chemin d'accès. Exactement comme cela advient dans le trafic ferroviaire, l'on creuse une fois un tunnel dans la roche, et ensuite les trains peuvent emprunter ce tunnel sans devoir pour chaque convoi creuser à nouveau. Mais attention à ne pas trop simplifier le concept, car contrairement au trafic ferroviaire, lorsqu'il s'agit de trafic de données, pas tous ont la possibilité de pouvoir creuser un tunnel, et de plus lorsque l'on n'utilise plus un tunnel, celui-ci est fermé afin d'empêcher à quiconque de traverser sans aucun contrôle.

Ce qu'offre le tunneling, c'est d'aménager une voie d'accès qui est privée, et dont seuls ceux autorisés peuvent l'emprunter. Cela notamment sur un réseau public. En effet tous empruntent un réseau public, en revanche ces derniers n'ont pas tous un droit de regard sur ce qui transite dans le tunnel.

Figure 3.1-1 Tunneling

Les données à transférer peuvent être des trames d'un autre protocole. En effet plutôt que

d'envoyer une trame directement, cette dernière est encapsulée dans une autre, qui se charge elle, d'implémenter le tunnel. L'en-tête supplémentaire fourni les informations de routage, afin que la charge (payload contenant les données), de ce nouveau paquet puisse traverser le tunnel.

Le tunneling comprend les phases d'encapsulation, de transmission, et de

désencapsulation des données. Le tunneling peut être appliquer aux couches 2 ou 3 du modèle OSI, suivant les systèmes

d’implémentations. L'on peut énumérer à nouveau les trois protocoles de tunneling précédemment cités dans le chapitre des VPN:

Niveau 2 : PPTP et L2TP encapsulation et encryptage de la charge utile dans une

trame PPP et envoi au travers d'un réseau intermédiaire. Niveau 3 : IPSec encryptage de la charge utile IP, encapsulation dans un

paquet IP, et envoi au travers d'un réseau IP. A noter que le protocole IPSec est décrit au chapitre 6.

tunnel données utiles



Quelques précisions encore, concernant les deux protocoles de niveau 2. Ces deux protocoles sont basés sur le protocole PPP Point to Point Protocol, qui est un protocole de niveau 2 également. Ce dernier est utilisé pour se connecter par un accès point-à-point sur des lignes séries. Ce qui est le cas le plus répandu lorsque quelqu’un se connecte depuis son domicile au travers d’un modem.

Ce qui est intéressant de constater, c'est le fait qu'il faille établir deux connexions PPP

(voir Figure 3.1-3 et Figure 3.1-4, le paquet PPP y figure deux fois). En effet, après que le client aura obtenu une connexion PPP initiale avec l'ISP (Internet Service Provider), il établit une deuxième connexion sous forme de datagrammes IP contenant des paquets PPP. Cette deuxième liaison crée la liaison VPN avec le serveur.

La première connexion PPP par modem est à destination du fournisseur d'accès Internet. La deuxième est une connexion VPN PPTP utilisant la première pour créer un tunnel à travers Internet, vers un dispositif VPN sur le serveur PPTP, (même démarche s’il s’agit de L2TP).

Il est à relever que c'est le serveur PPTP qui permet l'accès au réseau privé surlquel l’on désire ouvrir un VPN, et pour ce faire, il demande aux clients PPTP un nom et un mot de passe utilisateur.

Figure 3.1-2 Connexion au travers d'un modem (double PPP)

Le mécanisme de création d'un tunnel est intéressant, car l'on voit qu'il s'agit de

combiner divers protocoles qui sont déjà existants, et que l'on adapte afin de pouvoir créer un tunnel. La technique pour ce faire, est explicitée concernant les paquets dans les deux chapitres suivants.

Le fait d’utiliser des protocoles déjà existants, et encapsuler à l’intérieur de nouvelles fonctionnalités, permet de mettre en place ces services sans devoir investir dans l’achat de nouveaux équipements, si ce n’est en adaptant ceux qui le doive être.

3.1.1 PPTP PPTP, Point to Point Tunneling Protocol a été mis en œuvre par Microsoft. Le

fonctionnement, est le suivant, l’on encrypte tout ce qui provient de la couche TCP/IP, ainsi que les infos PPP qui proviennent de PPP servant à établir la connexion avec le VPN. Suite à cela, le tout est encapsulé par le protocole GRE, qui ne fait rien de particulier, si ce n’est de véhiculer les paquets IP sur le réseau. (Il est intéressant de remarquer l’emploi du protocole GRE, qui est un protocole IP très peu connu.)

PPTP autorise une session PPP à être tunnelée au travers une connexion IP existante. Le tunneling est faisable par le fait que PPTP encapsule les données des différents

paquets. Comme le montre la Figure 3.1-3 page 9.



TCP/IP

Logiciel PPTP

PPP

Figure 3.1-3 Encapsulation PPTP

Il est intéressant de remarquer le principe d’encapsulation.

3.1.2 L2TP L2TP, Layer 2 Tunneling Protocol est décrit dans la RFC 2661, c’est Cisco et Microsoft

qui ont donné naissance à ce protocole. Ils ont pour cela mis en commun ce qu'il y avait de meilleur parmi d'autres protocoles déjà existants, parmi lesquels PPTP.

A l’heure actuelle le protocole PPTP, est encore utilisé en majorité, mais de plus en plus L2TP est offert dans les nouveaux logiciels est équipements, l’on peut imaginer qu’à terme, il prenne le dessus sur PPTP.

TCP/IP Logiciel L2TP PPP

Figure 3.1-4 Encapsulation L2TP

Un élément intéressant de L2TP, est l'utilisation de UDP. Ce qui laisse entrevoir une

vitesse d’acheminement supérieure. Cela implique également le fait que UDP offre des services moindres que TCP, il s’agit de les compenser ailleurs.

3.2 Qu'est-ce que le mode "Tunnel" ?

Il y a une précision à apporter lorsque l'on parle de mode tunnel. Le mode "Tunnel", est le fait de sécuriser l'échange de données, ainsi qu'en fait toute la couche IP qui sert à transmettre ces données. En revanche si l'on s'intéresse uniquement à la sécurité des données, l'on peut choisir le mode Transport.

IP TCP / UDP Données

GRE PPP IP TCP / UDP Données

PPP IP GRE PPP IP TCP / UDP Données

IP TCP / UDP Données

IP TCP / UDP Données PPP UDP

IP TCP / UDP Données PPP UDP PPP



3.3 Stunnel

3.3.1 Présentation de Stunnel Stunnel est une application passablement diffuse implémentant un tunnel. Mais Stunnel

ne contient pas de cryptographie lui-même, il fait appel pour cela à une librairie SSL externe. Il travail avec le librairie OpenSSL, ainsi que son précurseur SSLeay.

Le point principal dans Stunnel étant l’emploi du protocole SSL, ce dernier est explicité

dans le chapitre 5. Stunnel est un programme permettant l'encryptage de données au travers des connexions

TCP à l'intérieur de SSL. Cela étant faisable sur les machines Unix et Windows. Ainsi que sur les derniers OS de Mac.

Un serveur Stunnel a deux fonctions;

• Premièrement, il prend le trafic non encrypté, il l'encrypte avec SSL, et l'envoie sur le réseau.

• Deuxièmement, il prend le trafic encrypté avec SSL, le désencrypte et le passe sur le réseau à une autre application. (Généralement l'autre application se trouve sur la même machine, afin d'éviter de faire circuler les infos sur le réseau.)

Il est possible d'utiliser Stunnel afin de sécuriser des applications qui nativement

n'implémentent pas SSL. Par exemple comme POP, SMTP, IMAP. La contrepartie, c'est que si l'on fait cela sur les serveurs, il faut que les clients soient compatibles SSL.

A noter que si l'on se connecte autravers d'un ISP (Internet Service Provider), il faut

d'abord cliquer (ou lancer) Stunnel avant de lancer l'application de messagerie.

3.3.2 Composants de Stunnel Stunnel peut être obtenu gratuitement sur le site www.STunnel.org, il est à relever

cependant qu’il est sous licence GNU. Stunnel n'est pas un produit fini ou complet en tant que tel. Pour qu'il fonctionne, il faut également installer une librairie SSL. Et la librairie de référence pour cela, est OpenSSL, qui peut elle aussi être obtenu sans frais, sur le site www.OpenSSL.org.

Stunnel est un exemple de logiciel utilisant des connexions sécurisées, ainsi qu’un

cryptage des données. Ceci est rendu possible par l’emploi de librairies implémentant des algorithmes de cryptage, c’est à dire des séquences de nombres qui multipliée avec la valeur ASCII de ce qui est transmis rend ce qui va circuler entre les deux partenaires d’une communication, totalement incompréhensible si l’on ne parvient à décrypter le message.

Afin de comprendre comment ces mécanismes de cryptage sont mis en place, le chapitre

4, donne un bref cas de figure de comment deux partenaires peuvent échanger de manière cryptée leurs communications.



4 LE CRYPTAGE A CLE PUBLIQUE

4.1 Principe général

Dans les différents protocoles de tunneling qui vont être présentés, est utilisé le principe de cryptage par clé publique. Le fonctionnement (dans les grandes lignes) est le suivant ; une personne par un algorithme de codage, met au point deux clés de chiffrement. Une qu’il appelle clé publique, et l’autre clé privée. En principe tout ce qui est encrypté avec la clé publique, peut être décrypté uniquement si l’on détient la clé privée. Les noms de ces deux clés, expriment bien ce que sont ces clés, l’une est celle que le site va communiquer à tous ceux désirants se connecter à lui, et l’autre celle gardée précieusement secrète afin de garantir que seul le serveur peut décripter un message encrypter avec sa clé publique.

Ainsi le principe veut que lorsque l’on se connecte à un serveur par exemple, ce dernier

transmet sa clé publique au client, qui s’en sert pour encrypté la clé symétrique1 qu’il désire utiliser, et envoie cela au serveur. Le serveur reçoit ce paquet, le décrypte par le biais de sa clé privée, et découvre ainsi quelle clé symétrique va être employée par la suite pour encrypter et décrypter tous les messages échangés.

Cela est un exemple, car il existe d’autre cas de figures, ainsi qu’une importante phase de

négociation lors de l’établissement de la connexion, sur le type de chiffrage appliquer, et quel algorithme choisir.

En résumé, cela donne sous forme de diagramme fléché:

à Envoi de la clé publique. ß Info cryptée avec la clé publique, éventuellement clé symétrique. à Décryptage des infos avec la clé privée. ßà Echange de messages cryptés.

4.2 Phase initiale de négociation

La phase d’ouverture de connexion, est très importante. En effet, c’est à ce moment que les deux partenaires se découvrent, et constate quels algorithmes implémente l’autre. Ainsi qu’une autre phase cruciale, qui est l’authentification. En effet jusqu’à présent il a été question de transmettre de manière cryptée des informations, mais qui ou quoi, peut garantir qu’à l’autre extrémité de la connexion, est effectivement présent la personne à qui le message est destiné.

Ces divers aspects vont être abordés dans les chapitres suivant au travers de l’analyse des protocoles implémentant les tunnels.

1 Clé symétrique : clé unique permettant d’encrypter et de décrypter un message.



5 SSL

5.1 Présentation de SSL

SSL ou, Secure Socket Layer, permet l'accès sécurisé à un site web ou à certaines pages d'un site web. Ces connexions se différencient par des connexions "normales" c'est à dire non sécurisées, par le fait que l'adresse n'est plus "http:// " mais "https:// ", où le s indique sécurisé.

Il y a deux manières de vérifier si le site visité est sécurisé ; d'une part en essayant de s'y connecter avec l'adresse https qui dans le cas où le site dispose d'une connexion sécurisée permettrait la connexion avec le site. Et d'autre part en vérifiant si le cadenas figurant à droite de la barre d'état d'un navigateur est fermé.

Figure 5.1-1 Cadenas non-verrouillé et verrouillé

SSL v3.0 est devenu un standard "de facto", sur Internet, et comme tous les standards de

fait, souffre ou risque de souffrir, de diverses petites adaptations ici et là, provoquant à terme, le risque d'une compatibilité réduite.

Il faut également noter que Netscape qui à développer le produit, fournit des références de manière publique, et à développer SSL avec de nombreux partenaires afin d'obtenir une large reconnaissance, et cela a été le cas. Il est a souligner que ce qui a principalement motivé Netscape, c’est le commerce électronique.

Mais afin que SSL devienne une "norme", c'est l'IETF, qui se charge actuellement d'en définir les critères. Et plus précisément le groupe de travail "TLS" Transport Layer Security, raison pour laquelle l'on trouve les informations concernant SSL sous le sigle TLS, qui revêt la forme de SSL v.3.1. Ce qui concerne la version TLS 1.0 se trouve dans la RFC 2246.

SSL est très largement adopté par les messageries existantes comme: Qualcomm Eudora

5.1r, Microsoft Outlook, entre autre, toutes supportent les connexions SSL sur leurs serveurs. SSL se situe au sommet de la couche TCP/IP, et au-dessous de la couche d'application.

Pour mettre en place une connexion SSL, il faut d'abord établir une connexion TCP/IP, car SSL utilise certaines "primitives" de TCP/IP. Ainsi SSL peut être vu comme un canal sûr au sein de TCP/IP, où tout le trafic entre deux applications "peer to peer" est échangé de manière cryptée. Tous les appels de la couche d'application à la couche TCP, sont remplacés par des appels de l'application à SSL, et c'est SSL qui se charge des communications avec TCP.

Figure 5.1-2 SSL selon le modèle OSI

TCP/IP

Secure Socket Layer

HTTP LDAP SMTP



5.2 Les trois fonctionnalités de SSL

SSL a trois fonctions: • Authentification du serveur

Qui permet à un utilisateur d'avoir une confirmation de l'identité du serveur. Cela est fait par les méthodes de chiffrement à clés publiques qu'utilise SSL. Cette opération est importante, car le client doit pouvoir être certain de l'identité de son interlocuteur à qui par exemple, il va communiquer son numéro de carte de crédit.

• Authentification du client Selon les mêmes modalités que pour le serveur, il s'agit de s'assurer que le client est bien celui qu'il prétend.

• Chiffrement des données Toutes les données qui transitent entre l'émetteur et le destinataire, sont chiffrées par l'émetteur, et déchiffrées par le destinataire, ce qui permet de garantir la confidentialité des données, ainsi que leur intégrité grâce souvent à des mécanismes également mis en place dans ce sens.

5.3 Le principe de fonctionnement

SSL est un protocole qui utilise différents algorithmes de cryptographie afin de garantir "la sécurité", au travers de l'authentification avec des certificats, des sessions d'échanges des clés d'algorithmes, de l'encryptage, et de la vérification de l'intégrité des données.

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érieur 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).

5.4 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, …



5.5 Le fonctionnement de SSL

5.5.1 Vue d'ensemble

Figure 5.5-1 Les couches OSI et les protocoles SSL

La Figure 5.5-1 explicite comment intervient le protocole SSL, en comparaison au

modèle de couches OSI. A noter que toutes les couches ont été représentées, mais cela ne veut pas dire que toutes sont implémentées de la même manière, cela notamment pour les applications qui s'apparentent au modèle DOD.

5.5.2 Phases d’authentification Lorsqu’il s’agit pour un serveur d’identifier un client, 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.

Couche physique

Couche liaison

Couche réseau

Couche transport

Couche session

Couche présentation

Couche application

SSL Record

SSL Handshake

Gestion de SSL

données

données chiffrées



5.5.3 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) dont la définition est donnée dans le chapitre 5.6. 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.

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

symétrique que le protocole Handshake à négocié. Ainsi que l'intégrité des données, encore une fois grâce à une clé obtenue par le protocole Handshake.

8 bits Content Type

8 bits Major Version

8 bits Minor Version

16 bits Compressed length

Données

MAC

Figure 5.5-2 Protocole SSL Record

Données

Segmentation des données en blocs < 16384 octets

Chiffrement à l'aide de la clé symétrique

Ajout de l'en-tête SSL

Compression En principe pas utilisé

Ajout de la MAC



La Figure 5.5-2 montre les différentes encapsulations et traitements effectués par le protocole SSL Records.

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éé.

5.5.5 Particularités Les flux de trafic SSL ne s'accommode pas de l'utilisation de serveurs proxy classiques

(caches et réplications), car SSL a été conçu afin de lutter contre les attaques "du milieu", le fameux "man-in-the-middle". De ce fait, le proxy va être considéré comme voulant attaquer les communications SSL. Raison pour laquelle un serveur proxy voulant permettre un trafic SSL, doit supporter le protocole SOCKS, ou un protocole spécial de tunneling SSL. A noter qu'il y a des serveurs qui supportent les deux.

SSL change également de port de destination, en effet afin de sécuriser l'envoi et les

réceptions, et puisque SSL se situe en dessus de TCP, des ports spécialement réservés pour SSL ont été mis en place, par exemple le port 443 pour https.

Concernant le fait d'avoir de nouveau ports à disposition, cela n'est pas uniquement là

afin de permettre à l'application SSL de pouvoir gérer elle-même un port. Si l'on se place dans un réseau, il est fort probable (pour ne pas dire indispensable) que ce réseau soit protégé par un firewall, qui peut suivant les cas, bloquer le trafic lui parvenant sur certains ports. Par exemple tout ce qui vient par le port 21 qui est le port de FTP pourrait être bloqué, alors que ce qui vient par les ports 989 et 990 qui sont les ports FTPS pour les données et les contrôles pourrait être laissé passer.

A remarquer que ce qui est dit ci-dessus semble sécuriser de manière forte le firewall, mais il suffirait que quelqu'un à l'intérieur du réseau mette en place sa propre connexion malveillante au travers de ce port, et il peut par la suite traverser les firewall qu'il souhaite. Il est en effet impossible de distinguer le trafic, la seule manière de contrer cela, est pour l'administrateur réseau de fermer également ce port.



5.6 Les problèmes "techniques" de SSL

SSL souffre tout de même de quelques problèmes; Les navigateurs qui par exemple sont des applications incluant nativement SSL, peuvent

poser problème. En effet lorsqu'un certificat expire, le client reçoit un message, et il doit aller manuellement chercher un nouveau certificat. Dans certains pays, les navigateurs peuvent être soumis à des restrictions gouvernementales. De plus dans SSL tout se base sur la relation de confiance qu'il y entre le navigateur, et l'autorité de certification (CA). En effet, si une de ces autorités qui émettent les certificats, le fait pour un site dont les objectifs ne sont pas honnêtes, et bien ce certificat sera considéré par les navigateurs comme tout ce qu'il y a de plus réglementaire.

(A noter que les pays qui restreignait le domaine de la sécurité assouplissent ces dernières années leur législation. Concernant les CA, pour l'heure rien n'est à signaler concernant un manquement à leur bonne fois).

La CRL, ou liste des certificats révoqués, est une liste de ceux à qui ont été attribué des

certificats, mais pour qui l'autorité qui les a certifié, ne veut plus les garantir. Par exemple, une entreprise fait un certificat pour cinq ans, à un de ses employés, et ce dernier, au bout de trois ans quitte l'entreprise. Le problème est que son certificat est encore valide, et selon la date, il le sera encore durant deux ans. La solution pour l'entreprise est d'inscrire le numéro du certificat attribué à son ex-employé dans la CRL, et ainsi, lorsque quelqu'un va vérifier le certificat (de l'ex-employé), il va dans un premier temps constater que le certificat est tout à fait valable, mais dans un deuxième temps vérifier la CRL, est la remarquer que ce numéro y figure, et ainsi refuser le certificat.

Un point négatif concernant CRL, est le fait que la consultation de la CRL, et par défaut non activé dans les navigateurs. A noter qu'il est possible sur des sites, de charger dans son navigateur une liste mise à jour de CRL.

Sur le même principe des CRL, il est possible de mettre à jour la liste des CA.

5.7 Exemple de certificat obtenu par SSL

Afin d’expliciter de manière pratique sous qu'elle forme peut se concrétiser un certificat, obtenu par le biais de SSL, une connexion avec un établissement bancaire du canton de Vaud a été réalisé, et ce au travers de son site sécurisé. L'adresse est donc la suivante https://www.bcv.ch.

Afin de pouvoir établir une liaison avec le serveur où sont stockées les informations relatives à cette adresse, il y a lieu de vérifier le certificat de l'entité bancaire. Ses informations, peuvent ensuite être consultées au travers du navigateur.

La Figure 5.7-1 page 18, donne un extrait de la représentation des informations qui sont connues, et vérifiables concernant cette banque.



Figure 5.7-1 Certificat explicité par le navigateur

L'on peut remarquer qu'il s'agit d'un certificat SSL, cela est inscrit en haut de la capture,

un autre élément intéressant, est l'autorité qui a délivré le certificat à cette banque. Ainsi que les champs de validité, car un certificat et bien évidemment limité dans le temps.

A remarquer que le menu d'aide des navigateurs fournis des informations quant à la signification des champs, ainsi que de nombreux conseils concernant la sécurité. Cela est particulièrement vrai sur la version 6.2 de Netscape.

Clés utilisées par la BCV ; Toujours à titre d’exemple, cette banque propose les clés de cryptage suivantes, qui

d’après l’avis d’experts en la matière, semblent être difficiles à découvrir. IDEA-CBC-MD 5128 bit DES-CBC3-MD5 168 bit DES-CBC3-SHA 168 bit RC4-MD5 128 bit

A noter encore, que la banque précise que les points faibles concernant la sécurité,

viennent notamment du PC du client. Sur lequel pourrait être introduit un virus, et ainsi découvrir des informations permettant d’être à même de pouvoir s’immiscer dans la connexion privilégiée qui existe entre un client et sa banque.

La sécurité se base sur une double sécurité. D’une part la sécurité et l’authentification. Et

d’autre part l’utilisation d’une accès card, ou l’utilisation d’une calculette, générant un code bien définit.

A noter que les banques, proposent toujours l’accès par ligne directe sans passer par

Internet. (Cette dernière met un peu à mal la confiance que les banques ont dans leur système de sécurité.)



6 IPSEC

6.1 Présentation de IPSec

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.

6.2 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 sécurity 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.

Dans les chapitres suivants sont données des informations plus précises concernant ces différents protocoles.

6.3 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, tendis 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é, • et 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. (remarque pour Ipv6, ce sera SSL qui remplira les fonctions de IKE)

La SA est explicitée au chapitre 6.4

6.3.1 Le protocole AH Coté expéditeur, cette transformation consiste en une fonction de hachage MAC2, 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 6.3-1 indique les transformations à apporter afin de passer par le mode tunnel.

Figure 6.3-1 Encapsulation AH en Mode Tunnel

A noter que le protocole AH utilise le port 51.

2 MAC fonction mathématique de hachage effectué sur les données, qui retourne un résultat unique

prouvant que c’est l’auteur qui en la source, et que ces données n’ont pas subi d’altérations.

En-tête IP

En-tête AH En-tête IP En-tête IP

En-tête TCP

En-tête TCP

données

données

Authentifié



6.3.2 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'affectuant 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 6.3-2 permet de visualiser les transformations à apporter afin de passer en mode tunnel.

Figure 6.3-2 Encapsulation ESP en mode tunnel

Le protocole ESP utilise le port 50.

6.4 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

En-tête ESP En-tête IP En-tête IP En-tête TCP/UDP Données couches supérieures ESP trailer ESP auth.

En-tête IP En-tête TCP/UDP Données couches supérieures

Chiffré

Authentifié



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.



7 SSH

7.1 Présentation de SSH

SSH, ou Secure Shell, sécurise la connexion depuis l'ordinateur local jusqu'au serveur distant. Cela en établissant une connexion cryptée.

Et plus encore, car sous le terme SSH, sont inclus le protocole, ainsi que l'ensemble de programmes utilisant ce protocole

Pour mettre en place le cryptage SSH, il faut d'une part que le serveur l'autorise, et d'autre part, il faut disposer sur la machine locale d'un "client" SSH.

Il est à relever que SSH s'est imposé surtout dans le monde UNIX. Mais il existe également des clients SSH pour Windows et Mac.

7.2 Comment cela fonctionne

La sécurité est garantie par le fait qu'à chaque établissement de connexion TCP, une authentification est faite, ainsi que par l'encryptage des données qui sont transportées sur le réseau au travers de tunnels. Il faut également souligner que les mots de passe sont bien entendus cryptés. SSH utilise la cryptographie à clés publiques ce qui permet aux clients et au serveur, de s'authentifier mutuellement.

Le principe de fonctionnement est le suivant, lorsque vous voulez établir une connexion sécurisée, vous envoyez vos informations sur votre logiciel SSH (coté client), et de l'autre coté, le serveur SSH se charge de réceptionner ses données, sur un port adéquat.

SSH remplace les applications sur des terminaux peu sûr comme Telnet ou FTP, par des

connexions distantes authentifiées et des échanges de messages cryptés. Les programmes de connexion à distance de Unix, (rlogin, rsh, rcp,..) sont substitués par leur équivalents sécurisés; slogin, ssh, scp.

Bien que conceptuellement il est possible d'acheminer également des trames UDP, la

plupart des livraisons standards de SSH n'offrent pas cette possibilité. Figure 7.2-1 Tunnel SSH

A noter que de ce fait, l'application SSH, tient à jour un "port-mapping" afin de pouvoir

établir les correspondances des différents ports, et datagrammes.

SSH (22)

Smtp (25) Pop (110) Imap (143)

Smtp (25) Pop (110) Imap (143)

client serveur



7.3 Exemple d'utilisation de SSH

Un service qui serait par exemple intéressant de configurer afin de le rendre plus sûr, c'est notamment le service de e-mail. En effet lors d'un forum, ou d'un séminaire, concernant par exemple la VoIP, l'on peut imaginer que tous les plus grands experts soit présents. Rien de plus simple pour un hacker, que de mettre un sniffer sur les lignes auxquelles vont se connecter les intervenants, pour simplement relever leur e-mail. Et en très peu de temps, l'on est ainsi à connaissance du contenu des e-mails, mais surtout du mot de passe pour y accéder. Pour éviter cela, une solution est de sécurise tous ce qui passe par le réseau public, avec une connexion SSH, jusqu'au serveur SSH, puis acheminer en clair les e-mails jusqu'au serveurs de courier.

Figure 7.3-1 e-mail protégé par SSH

7.4 Remarques concernant SSH

Comme déjà dit, SSH se développe surtout dans le monde UNIX. Car il répond à la philosophie et au besoin qu’ont ces personnes de pouvoir aller « sur la machine ». C’est à dire pouvoir depuis un terminal distant, se connecter à un poste, et effectuer toutes les actions, manipulations, ou encore accès aux fichiers, qu’il est possible de faire lorsque l’on est assis devant la machine. Il est certain que pour ces utilisateurs, SSH représente la meilleure implémentation possible du tunneling.

Un autre fait qu’il est important de signaler est qu’il y a différentes versions de SSH. La

version qui est actuellement encore la plus utilisée est la v2, et depuis peu est disponible la version 3 (qui souffre de quelques petits bugs de jeunesse). Il faut souligner que la version précédente la v1, a quelques lacunes, qui permettent d’introduire des vers (technique utilisée par les hackers3 pour s’introduire et propager des dégâts sur un réseau). La version actuelle a corrigé ces bugs, paraît être pour l’heure non attaquable. Cependant pour ceux qui utilisent la v2, il ne faut pas, par soucis de compatibilité, permettre encore à ceux utilisant la version précédente de pouvoir se connecter à eux, sans quoi le risque d’infiltration de la v1, est à nouveau présent.

3 Hacker: pirate informatique

chiffré

Eudora Outlook

Client SSH Serveur SSH

En clair

Serveur mail



8 COMPARAISONS

8.1 IPSec et PPTP

Le tunneling sur des VPN, peut être considéré comme une meilleure réponse que SSL au fait qu'une entreprise désire rendre toutes ses communications entre deux end-point sécurisés. De même, le tunneling VPN, permet d'accéder à plusieurs serveurs, sans que ces derniers doivent être des serveurs SSL.

IPSec implémente des algorithmes plus sûrs que PPTP. Par défaut dans L2TP, c'est IPSec qui est utilisé. C'est seulement si le end-point distant

ne le supporte pas, qu’alors un protocole moins sûr de PPP est utilisé. Du point de vue pratique, il est reconnu qu’il est plus simple de se connecter avec L2TP

ou PPTP au travers d’un dial-up pour des particuliers, afin de se connecter au ISP (Internet Service Provider). En effet, IPSec travail au niveau de l’identification de la machine, et non pas une identification au niveau de l’utilisateur. Il est plus simple d’implémenter pour une entreprise une seule machine qui gère IPSec (placée sur une artère principale), alors que pour un utilisateur externe, qui de plus dispose de plusieurs postes, il est plus simple de s’identifier lui, plutôt qu’une machine. De ce fait, pour une entreprise disposant de serveurs, il est aisé d’implémenter IPSec, et ainsi garantir un niveau de sécurité élevé, mais surtout la création de tunnels multiples et variés.

8.2 STunnel et ses possibilités (limitées ?)

Le principe de Stunnel est très intéressant, et paraît n’avoir rein à se reprocher, les applications utilisant SSL qui ont été présentées dans le domaine de l’e-mail et du e-commerce, peuvent cependant paraître réductrices en confrontation des possibilités qu’offre Stunnel. En effet du moment que l’on "lance" l’application avant de commencer à émettre des paquets. L’on peut pour autant que cela soit configuré, sécuriser tout ce que l’on envoi par des tunnels.

Mais si l’on fait le rapprochement avec IPSec et la construction de VPN, l’on se rend compte que pour mettre en place un VPN, il faut également mettre en place des mécanismes, mais que dans ce dernier cas, les mécanismes mis en place doivent permettre outre la sécurité, d’avoir ensuite lors de l’utilisation une très grande souplesse d’emploi, sur l’autre extrémité du end-point.

8.3 SSL vs SSH concernant l’e-mail

En fait, il est difficile de réellement comparer ces deux mécanismes, car certes si l'on prend l'exemple de l'e-mail l'on obtient le même résultat, mais l'approche n'est pas la même. L’on a d’un coté SSL qui est nativement dans les messageries utilisées, alors que SSH requiert que l’on l’installe.

Avantages de SSL sur SSH :

• SSL est implémenté dans la messagerie, l'e-mail du client, ce qui garantit une configuration et fiabilité dans le temps meilleure.



• Authentification du serveur e-mail, uniquement la première fois, il n'y a pas besoin de charger à chaque fois le certificat du serveur jusqu'au client.

• Peut-être le principal avantage, est le fait que SSL est beaucoup plus largement utilisé que SSH, et il est de plus en plus intégré aux nouveaux logiciels.

8.4 Que choisir et quand ?

Il est difficile de répondre à cette question, tant les trois protocoles vus, IPSec, SSL, SSH, peuvent selon l’emploi et la configuration, offrir les mêmes services.

Mais s’il faut tout de même donner des indications: L’on peut indiquer d’utiliser IPSec, s’il s’agit de créer des VPN pour avoir accès à un

réseau local, et notamment à ses ressources tant matérielles que surtout au niveau informationnel. Il ne s’agit pas tant ici de sécuriser la connexion proprement dite (bien que cela doive être fait afin de garder secret les informations collectées), mais surtout l’accès au réseau, c’est à dire faire en sorte que seuls les autorisés puisse avoir accès au réseau privé, et que cela soit possible d’être fait depuis le domicile d’une personne, et au travers d’un réseau quelconque, puisque le VPN + IPSec, garantissent la confidentialité.

Il est préférable d’utiliser SSL pour les emplois qui ont été décris, à savoir la messagerie,

le e-commerce, qui sont des applications qui mettent en contact un très grand nombre de personnes, et pour lesquelles le mécanisme de certificats mis en place dans le navigateur coté client, et sur les serveurs de l’autre coté, fonctionne passablement bien.

Enfin concernant SSH, ce protocole semble être destiné aux "aficionados" du monde

Unix, qui soit dit en passant contient de nombreux administrateurs de réseaux. En effet, de part les possibilités de terminal à distance qu’il offre, il a les caractéristiques idéales, de la connexion qui permet de configurer à distance les paramètres d’un réseau. A noter que SSH va peut-être avoir un regain d’intérêt, du fait qu’actuellement de nombreuses implémentations offrent la possibilité de pouvoir travailler avec X-Window, ce qui indéniablement permet un confort accru. Il faut ajouter encore parmi ceux qui emploient SSH, les concepteurs de sites Internet, car il est vrai que de nombreuses implémentations de SSH offre un confort et une palette d’outils pour l’administration de sites.



9 CONCLUSION Sujet de présentation très intéressant, et relevant d'un domaine – la sécurité sur LE, ou

les réseaux – qui est d'actualité, et qui si l'on prend par exemple le commerce électronique ou le télétravail ne va cesser de prendre de l'importance face aux risques mais également aux possibilités qui sont offertes.

Domaine intéressant, où nombreux sont ceux à connaître les principes de manière

générale, et notamment du point de vue théorique, mais peux sont à même de mettre en pratique, les différents mécanismes. Cela notamment du fait qu’avant de pouvoir mettre en pratique des protocoles destinés à la sécurité, il faut disposer d’une connaissance assez vaste dans le domaine des algorithmes, des protocoles, et des configurations de sockets. L’auteur de ce document s’est retrouvé dans la situation où afin d’expliquer certains aspects, il a fallut au préalable comprendre logiquement quelle était la séquence des différentes étapes.

Cela étant dit, il ne faut pas non plus donner l’impression qu’installer des logiciels

permettant d’établir des tunnels, et donc des connexions sécurisées, relève de l’exploit. En effet, si l’on prend un simple utilitaire SSH permettant d’accéder de manière sécurisée à un serveur http, une fois téléchargée l’application, l’on peut se contentant d’insérer l’adresse IP du serveur le login et le mot de passe, et c’est là à peu près tout ce qu’il s’agit de faire.

En revanche si l’on prend la mise en place d’un VPN utilisant IPSec, là il s’agit d’une configuration plus délicate, car bien souvent l’on autorise une assez large liberté à celui qui utilise le VPN, et c’est souvent dans les trop nombreux privilèges qui sont accordés qu’un hacker trouve la faille.

En effet, outre les bugs des différents logiciels, il est toujours plus facile pour un hacker de scanner votre disque dur à la recherche d’un fichier texte « codeCarteCrédit.txt » (fichier contenant le numéro de votre carte de crédit que vous prenez en faisant les opérations "copier/coller" !), que d’essayer de casser le chiffrement de 128 ou 168 bits par lequel vous l’avez transmis.

En synthèse l’on peut dire que des outils efficaces pour mettre en place la sécurité

existent, que le mécanisme de tunneling permet de garantir un assez bon niveau de sécurité. Pour une personne désirant sécuriser ses connexions, les outils existent en version libre, il suffit de les installer et de les configurer.

Yverdon-les-Bains, le 16 juillet 2002. Biasino CASSELLA



ANNEXE • Annexe 1 liste des numéros de ports utilisant une connexion sécurisée SSL

BIBLIOGRAPHIE Documents:

• "Tutorial VPN" de Christian Tettamanti ©TCOM 2000

Sites Internet: • http://www.Stunnel.org • http://www.OpenSSL.org • http://www.openssh.com • http://www.ietf • http://sw00d.free.fr/crypto/pages/ssl.htm • http://www.Netscape.com • http://www3.tsl.uu.se/~micke/ssl_links.html • http://www.guill.net • http://www.bugbrother.com/security.tao.ca/ssl.html

RFC • IPSec è 2401,2402, 2406 • TLS è 2246 • SSH è 793



GLOSSAIRE GRE Internet Generic Routing Encapsulation IETF Internet Engineering Task Force IPSec IP Security Protocol ISP Internet Service Provider L2TP Layer 2 Tunneling Protocol LAN Local Area Network PPP Point to Point Protocol PPTP Point to Point Tunneling Protocol SMTP Simple Mail Transfer Protocol SSH Secure Shell SSL Secure Socket Layer TLS Transport Layer Security VPN Virtual Private Network

Le tunneling



Annexe 1 Ports SSL nsiiops 261/tcp # IIOP Name Service over TLS/SSL https 443/tcp # http protocol over TLS/SSL smtps 465/tcp # smtp protocol over TLS/SSL (was ssmtp) nntps 563/tcp # nntp protocol over TLS/SSL (was snntp) imap4-ssl 585/tcp # IMAP4+SSL (use 993 instead) sshell 614/tcp # SSLshell ldaps 636/tcp # ldap protocol over TLS/SSL (was sldap) ftps-data 989/tcp # ftp protocol, data, over TLS/SSL ftps 990/tcp # ftp protocol, control, over TLS/SSL telnets 992/tcp # telnet protocol over TLS/SSL imaps 993/tcp # imap4 protocol over TLS/SSL ircs 994/tcp # irc protocol over TLS/SSL pop3s 995/tcp # pop3 protocol over TLS/SSL (was spop3) msft-gc-ssl 3269/tcp # Microsoft Global Catalog with LDAP/SSL

Présentation sur le tunneling Utilisant SSL, SSH,...

Documents

Transcript of Présentation sur le tunneling Utilisant SSL, SSH,...