Chapitre II : Les protocoles de sécurité LAN et Internet

1 LE CRYPTAGE A CLE PUBLIQUE

1.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étrique (clé unique permettant d’encrypter et de décrypter
un message) 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.

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

2 SSL

2.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 2.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 2.1-2 SSL selon le modèle OSI

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 afin de
cryptographie garantir
"la sécurité", au travers de l'authentification avec des d'échanges
certificats, des sessions 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

données
Couche SSL
application Handshake
Gestion de
SSL
Couche
présentation SSL Record
données
Couche session chiffrées
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.

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.
Figure 5.5-2 Protocole SSL Record

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

IPSe définit protocoles chacun tache précise.

c plusieurs réalisant une bien Ces
Protocole sont les protocoles transmissi sécurisé des
s notamment ; de ons es, 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.

En-tête IP En-tête TCP données

 En-tête IP En-tête AH En-tête IP En-tête TCP données

Authentif
ié

Figure 6.3-1 Encapsulation AH en Mode Tunnel

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.

n-tête En-tête Données couches

IP TCP/UDP supérieures

En-tête En-tête En-tête En-tête Données couches ESP ESP

IP ESP IP TCP/UDP supérieures trailer 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
dynamique qui indique que lespeuvent être mises à jour par la
données 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é

Smtp
Smtp (25) (25)
Pop (110)
Pop
 (110)
Imap
Imap (143) (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.

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é
En clair

Client SSH 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.

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.