Tunneling ssl/ssh/ipsec - Page Frontière du Site d`Arnaud Valeix

Transcription

Présentation sur le tunneling
Utilisant SSL, SSH, IPSec
Professeur S. VENTURA
Biasino CASSELLA
04 Juillet 2002
ETR_6
TCOM
SSL Tunneling ou Ipsec
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
Biasino CASSELLA
-2-
TCOM
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
Biasino CASSELLA
-3-
TCOM
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.
Biasino CASSELLA
-4-
TCOM
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.
Biasino CASSELLA
-5-
TCOM
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.
Biasino CASSELLA
-6-
TCOM
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.
données utiles
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.
Biasino CASSELLA
-7-
TCOM
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.
Biasino CASSELLA
-8-
TCOM
TCP/IP
IP
TCP / UDP
Logiciel PPTP
GRE
PPP
PPP
PPP
IP
IP
Données
TCP / UDP
GRE
PPP
IP
Données
TCP / UDP
Données
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
IP
TCP / UDP
Logiciel L2TP
UDP
PPP
PPP
PPP
UDP
IP
PPP
Données
TCP / UDP
IP
Données
TCP / UDP
Données
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.
Biasino CASSELLA
-9-
TCOM
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.
Biasino CASSELLA
- 10 -
TCOM
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.
Biasino CASSELLA
- 11 -
TCOM
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.
HTTP LDAP
SMTP
Secure Socket Layer
TCP/IP
Figure 5.1-2 SSL selon le modèle OSI
Biasino CASSELLA
- 12 -
TCOM
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
multipliés entre eux forment un très grand nombre. Ce dernier
Sans la connaissance des deux nombres premiers ayant servis à
possible de pouvoir décrypter un message.
En réalité une manière possible serait de défactoriser le
deux nombres premiers, mais les nombres sont tellement grands,
d'ordinateurs conventionnels.
deux nombres premiers, qui
constitue la clé de cryptage.
générer cette clé, il n'est pas
nombre afin de retrouver les
que cela n'est pas à la portée
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, …
Biasino CASSELLA
- 13 -
TCOM
5.5
Le fonctionnement de SSL
5.5.1 Vue d'ensemble
données
Couche application
SSL Handshake
Gestion de SSL
Couche présentation
Couche session
données
chiffrées
SSL Record
Couche transport
Couche réseau
Couche liaison
Couche physique
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.
Biasino CASSELLA
- 14 -
TCOM
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.
Données
Segmentation des données
en blocs < 16384 octets
Compression
En principe pas utilisé
Ajout de la MAC
Chiffrement à l'aide de
la clé symétrique
Ajout de l'en-tête SSL
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
Biasino CASSELLA
- 15 -
TCOM
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.
Biasino CASSELLA
- 16 -
TCOM
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.
Biasino CASSELLA
- 17 -
TCOM
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é.)
Biasino CASSELLA
- 18 -
TCOM
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.
Biasino CASSELLA
- 19 -
TCOM
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 MAC 2 , 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.
En-tête IP
En-tête AH
En-tête IP
En-tête TCP
données
En-tête IP
En-tête TCP
données
Authentifié
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.
Biasino CASSELLA
- 20 -
TCOM
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.
En-tête IP
En-tête ESP
En-tête IP
En-tête TCP/UDP
Données couches supérieures
En-tête IP
En-tête TCP/UDP
Données couches supérieures
ESP trailer
ESP auth.
Chiffré
Authentifié
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
Biasino CASSELLA
- 21 -
TCOM
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.
Biasino CASSELLA
- 22 -
TCOM
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é.
Smtp (25)
Pop (110)
Imap (143)
Smtp (25)
Pop (110)
Imap (143)
SSH (22)
client
serveur
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.
Biasino CASSELLA
- 23 -
TCOM
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.
Eudora
Outlook
chiffré
Client SSH
En clair
Serveur SSH
Serveur mail
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
Biasino CASSELLA
- 24 -
TCOM
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 ecommerce, 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.
Biasino CASSELLA
- 25 -
TCOM
•
•
8.4
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.
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.
Biasino CASSELLA
- 26 -
TCOM
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
Biasino CASSELLA
- 27 -
TCOM
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
Biasino CASSELLA
- 28 -
TCOM
GLOSSAIRE
GRE
IETF
IPSec
ISP
L2TP
LAN
PPP
PPTP
SMTP
SSH
SSL
TLS
VPN
Internet Generic Routing Encapsulation
Internet Engineering Task Force
IP Security Protocol
Internet Service Provider
Layer 2 Tunneling Protocol
Local Area Network
Point to Point Protocol
Point to Point Tunneling Protocol
Simple Mail Transfer Protocol
Secure Shell
Secure Socket Layer
Transport Layer Security
Virtual Private Network
Le tunneling
Biasino CASSELLA
- 29 -
TCOM
Annexe 1
Ports SSL
nsiiops
https
smtps
nntps
imap4-ssl
sshell
ldaps
ftps-data
ftps
telnets
imaps
ircs
pop3s
msft-gc-ssl
Biasino CASSELLA
261/tcp
443/tcp
465/tcp
563/tcp
585/tcp
614/tcp
636/tcp
989/tcp
990/tcp
992/tcp
993/tcp
994/tcp
995/tcp
3269/tcp
#
#
#
#
#
#
#
#
#
#
#
#
#
#
IIOP Name Service over TLS/SSL
http protocol over TLS/SSL
smtp protocol over TLS/SSL (was ssmtp)
nntp protocol over TLS/SSL (was snntp)
IMAP4+SSL (use 993 instead)
SSLshell
ldap protocol over TLS/SSL (was sldap)
ftp protocol, data, over TLS/SSL
ftp protocol, control, over TLS/SSL
telnet protocol over TLS/SSL
imap4 protocol over TLS/SSL
irc protocol over TLS/SSL
pop3 protocol over TLS/SSL (was spop3)
Microsoft Global Catalog with LDAP/SSL
- 30 -

Tunneling ssl/ssh/ipsec - Page Frontière du Site d`Arnaud Valeix

Transcription

Documents pareils

Document 578151

Série VM - Palo Alto Networks

Portail applicatif sécurisé Connectra

Fiche produit HUBLOT AXIOME T1 E27 1X42W HF SSL

Stormshield SN910

Routeur VPN avec switch 4 ports 10/100Mbps Firewall D

Serveur VPN : Racoon