Nouvelles technologies r seaux
SSH et TLS
Beno t Lamotte
Vincent Robert
Alexis Seigneurin
Ing nieurs 2000 Informatique & R seau 3
Ann e 2005
Table des mati res
Introduction................................................................................................... 3
1. S curiser une transaction......................................................................... 4
1. Quelle est l'utilit ?...........................................................................................4
2. Chiffrement sym trique................................................................................... 5
3. Chiffrement asym trique................................................................................. 5
4. La combinaison des deux............................................................................... 7
5. Attaque Man in the middle .........................................................................8
6. Les Certificats...................................................................................................9
2. SSH : Secure SHell.................................................................................. 11
1. SSH version 1................................................................................................. 11
1. Description du protocole........................................................................................ 11
2. Structure des paquets............................................................................................ 11
2. SSH version 2................................................................................................. 12
1. Transport............................................................................................................... 12
2. Authentification...................................................................................................... 16
3. TLS : Transport Layer Security............................................................... 18
1. Description de TLS.........................................................................................18
2. Le protocole de communication : TLS Record Protocol............................ 19
1. D roulement typique d'une connexion................................................................... 20
2. Param trage de la connexion : Handshake protocol et Change cipher spec
protocol...................................................................................................................... 21
3. Signalisation : Alert protocol.................................................................................. 24
4. Transmission de donn es : Application data protocol........................................... 25
3. Code dauthenticit des messages : HMAC................................................ 25
4. volutions r centes de TLS.......................................................................... 27
1. TLS version 1.1...................................................................................................... 27
2. S curit WiFi......................................................................................................... 27
3. WAP (Wireless Application Protocol).................................................................... 27
4. FTP........................................................................................................................ 28
Conclusion................................................................................................... 29
INTRODUCTION
Internet est un gigantesque r seau sur laquelle la confidentialit des changes n'est
pas assur e. Or, la plupart des protocoles de communication utilis s sont non s curis s.
SSH (Secure Shell) et TLS (Transport Layer Security) sont deux protocoles destin s
pallier ce probl me. Ils s'intercalent entre les protocoles habituels de transport et les
protocoles applicatifs, et proposent ainsi une couche de s curit pour tout type
d'application.
SSH est particuli rement utilis pour r aliser de l'administration de machines
distance. TLS, quant lui, est plus g n ralement utilis dans un contexte Web
(s curisation des changes sur un site Web) ou mail (POP et SMTP).
Nous pr senterons tout d'abord les diff rents probl mes de s curit s ainsi que des
m canismes cryptographiques destin s y rem dier. Dans un second temps, nous
pr senterons le protocole SSH. Enfin, nous pr senterons le procole TLS.
1.S CURISER UNE TRANSACTION
Quelle est l'utilit ?
1
Lorsque vous surfez sur Internet, la plupart du temps vous ne faites que de la
consultation d'information publique (site d'information, etc...). Il n'est pas n cessaire de
s curiser ce type de dialogue, mais alors que faut il s curiser ?
Il faut tout simplement s curiser toutes les informations n' tant pas publiques mais
personnelles ( une personne ou un groupe de personnes).
Prenons pour exemple les transactions commerciales. Pour valider votre achat vous
allez envoyer vos informations bancaires (num ro de carte de cr dit, etc.) au site de vente
en ligne. Si cette transaction n'est pas s curis e, voil ce qu'il peut se passer :
Lorsque vous envoyez ces informations au serveur du site de vente, une personne
malintentionn e (pirate) peut couter votre envoi et r cup rer vos informations pour les
utiliser ensuite votre insu. Ceci est tr s facile r aliser l'aide d'outils appel s
sniffeurs permettant de r cup rer les trames circulant sur un r seau donn . Il ne reste
plus ensuite qu' analyser les trames pour r cup rer les informations d sir es.
Il faut donc que votre message soit crypt pour que seul le serveur puisse comprendre
votre message. Nous allons donc nous int resser des m thodes de cryptage de
l'information utilis es dans les protocoles SSH, SSL et TLS.
Chiffrement sym trique
2
Le principe de chiffrement sym trique (aussi appel chiffrement cl priv e ou
chiffrement cl secr te) utilise une seule cl de cryptage pour encoder le message et
pour le d coder.
Cette m thode fonctionne en 5 tapes :
" L'exp diteur g n re une cl sym trique (alogrithme DES, tripleDES...).
" L'exp diteur encode son message avec la cl sym trique.
" L'exp diteur envoi la cl .
" L'exp diteur envoi le message crypt .
" Le destinataire n'a plus qu'a d crypter le message avec la cl re ue.
Cette m thode est assez simple et permet d'envoyer un message crypt .
Cependant, elle poss de quelques inconv nients, Claude Shannon d montr dans
les ann es 80 que pour que ce syst me soit totalement s r qu'il fallait que la longueur de
la cl g n r e soit au moins gale la longueur du message encoder.
De plus la la cl sym trique doit tre envoy e au destinataire par un canal s curis .
En reprenant l'exemple du pirate qui coute sur le r seau pour r cup rer les informations,
avec cette m thode il r cup rerait la cl sym trique et donc le message d crypt . Si ce
message contenait des informations vous identifiant sur le destinataire (login, mot de
passe), il pourrait ensuite se faire passer pour vous et acc der vos informations.
Chiffrement asym trique
3
Contrairement au chiffrement sym trique cette m thode utilise deux cl s, une cl
publique pour l'encodage et une cl priv e pour le d codage.
La cl priv e est connue seulement par le destinataire. Toutes personnes voulant lui
envoyer le message r cup re la clef publique pour encoder le message (disponible
g n ralement dans un serveur de cl , de type LDAP g n ralement).
Il y a donc 4 tapes cette m thode :
" L'exp diteur r cup re la cl publique.
" L'exp diteur encode le message l'aide de cette cl .
"
Il envoie le message au destinataire.
" Le destinataire d code le message avec la cl priv e que lui seul poss de.
Ce principe repose sur des fonction faciles calculer dans un sens, mais qui est tr s
difficile math matiquement calculer dans l'autre sens sans poss der la cl priv
(algorithme RSA). Cette m thode est extr mement co teuse en ressource lors des calcul
d'encodage et de d codage du message.
Ainsi notre pirate ne pourra pas d crypter le message qu'il aura r cup r en coutant
le canal car il ne poss dera pas la cl priv e.
Cependant pour que ce syst me soit s r il faut s'assurer que la cl publique l'on
poss de appartient bien au destinataire du message (voir attaque Man in the middle ).
La combinaison des deux
4
Il existe une m thode utilisant la fois le chiffrement sym trique et le chiffrement
asym trique. Cette m thode est appel e cl de session.
Comme dans le chiffrement asym trique, le destinataire g n re une cl priv ainsi
qu'une cl publique. Cette derni re est transmise aux exp diteurs.
De son c t , l'exp diteur g n re une cl sym trique (algorithme DES, tripleDES...)
qu'il encode l'aide de la cl publique du destinataire.
Il transmet ensuite sa cl crypt . Ainsi, les deux protagonistes poss dent tous les
deux une cl qui leur est propre. Il peuvent donc ensuite communiquer l'aide de cette cl
de fa on s curis e.
L' change de cl sym trique ne se fait donc qu'une seule fois, limitant le nombre de
cryptage et d cryptage de type asym trique (co teux en temps processeur).
La cl chang e est valable seulement pour une session, il faudra donc, la
prochaine connexion, tablir une nouvelle cl sym trique pour voluer de nouveau dans
un syst me s curis .
Comme pour la m thode asym trique, il faut tre s r que la cl publique utilis e
appartient bien au destinataire voulu.
Attaque
5
Man in the middle
Les m thodes de chiffrement asym trique et sym trique permettent d' voluer dans un
syst me s curis emp chant les logiciels d' coute de r cup rer le message et de le
Publicité
d crypter.
Cependant, la technique du Man in the middle (attaque du milieu, ou attaque de
l'intercepteur en Fran ais) permet de contourner cette s curit .
Le principe est simple m me si il n'est pas toujours vident mettre en place.
Le pirate se place sur le r seau entre les deux machines (exp diteur et destinataire)
pour intercepter et modifier les messages qu'elles s' changent.
Nous allons prendre l'exemple de la m thode asym trique pour illustrer ce syst me,
mais il fonctionne de la m me fa on avec les autres m thodes. Son but tant de se faire
passer pour le destinataire aupr s de l'exp diteur et pour l'exp diteur aupr s du
destinataire.
Dans le syst me asym trique, le destinataire envoyez sa cl publique l'exp diteur.
Le pirate la r cup re et transfert sa propre cl publique l'exp diteur.
L'exp diteur envoie ensuite son message encod avec la cl publique du pirate. Le
pirate d code le message, il r cup re ainsi les informations de l'exp diteur (login et mot
de passe par exemple). Il ne lui reste plus qu'a encoder ces informations avec la v ritable
cl publique du destinataire et de lui transmettre le message.
Le pirate est ainsi connect sur le destinataire avec les informations de l'exp diteur
sans que l'exp diteur et le destinataire ne soient au courant de la substitution.
Les Certificats
6
La m thode Man in the middle est possible car l'exp diteur bien voulu utiliser la
clef publique du pirate au lieu de celle du destinataire.
Les certificats permettent de s'assurer que la cl publique r cup r e appartient bien
au destinataire souhait .
Les certificats sont comme une pi ce d'identit prouvant que la cl appartient telle
ou telle personne, organisme ou autre.
Lorsque vous acheter sur un site de vente en ligne et que vous vous appr tez
envoyer vos coordonn es, vous devez tre s r que le destinataire est bien le site de
vente.
Pour cela, il suffit de v rifier son certificat. Un certificat est compos de deux parties :
"
"
les informations
la signature.
Le site de vente en ligne, pour assurer ses clients que la cl publique qu'il utilise
appartient bien au site, a envoyer ses informations et sa cl publique un organisme de
certification (VeriSign, par exemple).
L'organisme v rifie que les informations soumises sont correcte puis ajoute celle-ci
ses propres informations. Ensuite, il ajoute une signature au certificat. Cette signature est
un hachage du r sum des informations encod avec la cl priv e de l'organisme de
certification.
Autorit de certification ; veriSign
Nom: ebay
Email: [email protected]
Validit : 16/2/2005 au 16/2/2005/
Cle publique : 1a:5b:c3:a5:32:4c:d6:df:42
Algorithme : RC5
---------------------------------------------------------
Signature : 3b:c5:cf:d6:9a:bd:e3:cb
Hachage
des
informations
Encodage avec la cl
priv de lorganisme
de certification
Lorsque l'exp diteur r cup re le certificat il n'a plus qu'a calculer le hachage du
r sum des informations, et d coder la signature avec la cl publique de l'organisme de
certification. Ensuite il n'a plus qu'a comparer les deux r sultats pour savoir si le certificat
est un vrai. Si oui, les informations sont donc exactes.
Cette m thode permet d' viter d'encoder son message avec une cl publique
inconnue et donc de r v ler ses informations des personnes malveillantes.
2.SSH : SECURE SHELL
SSH version 1
1
Ce protocole est la premi re version du protocole Secure Shell. Il existe aujourdhui
une version 2 corrigeant une faille de s curit de ce protocole. Bien que SSH2 soit encore
l tat de brouillon (draft), lIETF recommande de ne plus utiliser SSH1.
Nous allons tout de m me pr senter rapidement ce protocole afin de conna tre la
base qui a donn naissance SSH2.
1
Description du protocole
La connexion seffectue avec TCP/IP selon la sp cification. Il serait possible deffec-
tuer cette connexion sur dautres protocoles mais cela nest pas pr vu par la RFC.
Au d but de la connexion, le serveur envoie une cha ne dauthentification puis le client
r pond par sa cha ne didentification. Cette cha ne contient le port de connexion, la ver-
sion du protocole ainsi que la version du logiciel pour des raisons de d veloppement. Si le
client ou le serveur naccepte pas cette cha ne, la connexion est ferm e.
Le serveur commence par envoyer sa clef RSA (cette clef est reg n r e toutes les
heures) ainsi que dautres informations. Le client g n re alors une clef de session de 256
bits et la crypte en utilisant les 2 clefs RSA (client et serveur), puis lenvoie au serveur
avec le type de cryptage s lectionn . Les 2 parties activent alors le cryptage des donn es
en utilisant le type de cryptage et la clef de session sp cifi s par le client. Le serveur en-
voie alors un message de confirmation crypt au client.
2
Structure des paquets
0 - 7
8 - 15
16 - 23
24 - 31
Taille du paquet
Bourrage
Type de paquet
Donn es...
...
CRC32
La taille du paquet doit tre cod en big endian.
Le bourrage est une suite dentre 1 et 8 octets dont la valeur est al atoire (ou 0 sil ny
a pas de cryptage)
Le type de paquet est un octet non sign , la valeur 255 est r serv e aux extensions
futures
Le CRC32 utilise le polyn me 0xedb88320. Il est calcul partir du bourrage, du type
de paquet et des donn es avant tout cryptage.
SSH version 2
2
Cest un protocole en cours de d veloppement par lIETF. Ce protocole est encore
l tat de brouillon (draft) mais a d j majoritairement remplac SSH1 chez les utilisateurs
du fait des probl mes de s curit que peut poser ce protocole.
Le protocole SSH2 se d coupe en 3 niveaux. Un premier niveau transport charg d -
tablir la communication entre le client et le serveur. Cest ce niveau qui est responsable de
la manipulation des paquets et donc de leur cryptage et du m canisme dint grit des
donn es.
Un second niveau est responsable de lauthentification des utilisateurs. Il se base sur
le protocole de transport qui est charg d tablir une communication s curis entre le
client et le serveur en ayant effectuer une authentification des machines.
Un troisi me niveau est responsable de la gestion des connexions pouvant circuler via
SSH, notamment le transfert de port.
1
Transport
Il est recommand dans la sp cification de transmettre SSH2 via un protocole poss -
dant un contr le derreur. De telle erreurs sont en effet d tect es par le protocole SSH et
impliquent une coupure imm diate de la connexion. Il est donc pr f rable dutiliser le cont-
r le derreur du protocole de transport afin de garantir les connexions.
Le protocole principalement utilis est TCP/IP. Avec ce protocole de transport, le ser-
veur coute g n ralement sur le port 22 qui a t officiellement assign SSH par lIANA.
I.
Initialisation de la
connexion
Quand la connexion a t tablie, les deux parties doivent envoyer une cha ne diden-
tification. Cette cha ne doit tre :
SSH-Protocole-Logiciel [<SP> Commentaire] <CR> <LF>
Protocole doit contenir la version du protocole. Pour SSH2, cette cha ne doit tre 2.0.
Logiciel doit contenir la version du logiciel. Les num ros de version doivent tre com-
pos s de caract res US-ASCII lexception des caract res despacement et du caract re
moins (-).
Commentaire est optionnel. Si ce champs est omis, lespace le s parant des champs
Publicité
pr c dents peut tre omis aussi. Il ne doit pas contenir le caract re NULL (0).
La taille maximum de la cette cha ne est 255 caract res y compris le retour chariot et
le caract re de nouvelle ligne de fin.
Il est possible denvoyer des lignes suppl mentaires avant denvoyer la cha ne diden-
tification. Ces lignes ne doivent pas commencer par SSH- et doivent tre g r es par le
client. Cependant ce dernier peut simplement les ignorer ou les afficher lutilisateur.
Compatibilit
II.
Un client SSH1 peut se connecter un serveur SSH2.
Il est possible pour un serveur de supporter les 2 version de SSH, il devra alors en-
voyer la cha ne 1.99 comme version de protocole. Un client SSH2 devra interpr ter cette
version comme tant gale 2.0.
Un serveur compatible avec une ancienne version ne devra pas envoyer le caract re
nouvelle ligne lors de lenvoi de la cha ne didentification, et devra attendre un envoi du
client avant tout envoi afin didentifier la version avec laquelle le client discute.
Un serveur SSH2 seulement ne peut pas accepter de connexions de client SSH1 et
doit les rejeter automatiquement.
Structure dun paquet
III.
0-7
8-15
16-23
24-31
32-39
40-47
48-55
56-63
Longueur paquet
Longueur
bourrage
Donn es...
...
Bourrage al atoire
Code dauthentification du message
La longueur du paquet ninclut pas le code dauthentification du message ni le
champs de longueur du paquet lui-m me.
Les donn es peuvent utiliser un syst me de compression. Cependant, initialement, il
ny a aucune compression.
Le bourrage al atoire est une s rie de donn es choisies al atoirement. Leur lon-
gueur doit tre un multiple de la longueur du code de cryptage ou de 8, en prenant le plus
grand. La longueur du bourrage ne peut pas d passer 255 octets.
Le code dauthentification du message est le code n goci afin de crypter les mes-
sages. Initialement, le cryptage est d sactiv .
Un paquet ne peut pas d passer 35000 octets. Cette valeur a t arbitrairement choisi
dans la sp cification de SSH2. Il est possible dutiliser des paquets plus grands si besoin,
mais les parties doivent annoncer quelles le supportent en passant par le syst me dex-
tensions.
Compression
IV.
La compression seffectue exclusivement sur les donn es. Elle se fait en utilisant lal-
gorithme de compression qui a t n goci entre le serveur et le client. Il est possible de
choisir une m thode de compression diff rente pour les 2 sens de la communication,
mais la sp cification recommande dutiliser la m me m thode de compression pour toute
la communication.
Voici les m thodes de compression d finies par la sp cification :
" aucune, cet algorithme est forc ment requis ;
" zlib, la compression bien connue, cet algorithme est optionnel.
Cryptage
V.
Le cryptage se fait au moyen dun algorithme de cryptage n goci lors de l change
des clefs entre le client et le serveur. Lorsque le cryptage est effectif, toutes les donn es
dun paquet sont crypt es sauf le code dauthentification du message. Le cryptage se fait
toujours apr s la compression.
Lors dune communication, les 2 directions doivent utiliser des algorithmes ind pen-
dants. Les client et serveur doivent dailleurs permettre de choisir le type dalgorithme pour
chaque direction de la communication. Cependant, la sp cification recommande dutiliser
le m me algorithme dans les 2 directions.
Les algorithmes suivants sont d finis par la sp cifications :
Nom
Description
Requis ?
3 clefs 3DES en mode CBC
3des-cbc
Cet algorithme utilise des clefs de 112 bits
seulement mais est requis car cest le plus r pan-
du dans le monde de la cryptographie
requis
blowfish-cbc
Blowfish en mode CBC
twofish256-cbc
Twofish en mode CBC avec clef de 256 bits
twofish-cbc
Alias de twofish256-cbc conserv pour des
raisons de compatibilit
twofish192-cbc
Twofish en mode CBC avec clef de 192 bits
twofish128-cbc
Twofish en mode CBC avec clef de 128 bits
aes256-cbc
aes192-cbc
AES en mode CBC avec clef de 256 bits
AES en mode CBC avec clef de 192 bits
aes128-cbc
AES en mode CBC avec clef de 128 bits
recom-
mand
serpent256-cbc
Serpent en mode CBC avec clef de 256 bits
serpent192-cbc
Serpent en mode CBC avec clef de 192 bits
serpent128-cbc
Serpent en mode CBC avec clef de 128 bits
arcfour
idea-cbc
cast128-cbc
none
Le cryptage de flux ARCFOUR
IDEA en mode CBC
CAST-128 en mode CBC
Aucun cryptage - D conseill
VI.
Int grit des donn es
Chaque h te participant la communication doit effectuer un comptage des paquets
de mani re secr te. Ce comptage permet ensuite de calculer le code dauthentification de
chaque message (ou Message Authentication Code : MAC) en utilisant lalgorithme MAC
n gocier en d but de communication.
La sp cification propose plusieurs algorithmes MAC :
Nom
hmac-sha1
Description
HMAC-SHA1
hmac-sha1-96
96 premiers bits de HMAC-SHA1
hmac-md5
hmac-md5-96
none
HMAC-MD5
96 premiers bits de HMAC-MD5
Aucun algorithme, d conseill
Requis ?
requis
recom-
mand
change de clefs
VII.
Publicité
Lors de la connexion, les 2 parties doivent n gocier un algorithme de g n ration des
clefs de sessions qui serviront pour le cryptage et lauthentification aupr s du serveur.
La sp cification d finit 2 m thodes d changes des clefs que les logiciels doivent pos-
s der : diffie-hellman-group1-sha1 et diffie-hellman-group14-sha1.
Algorithmes des clefs publiques
VIII.
Le protocole a t con u pour travailler avec de nombreux formats de clef publique. Il
y a plusieurs aspects qui d finissent une clef publique :
" le format de clef, cest dire comment la clef est encod et comment les certifi-
cats sont repr sent s ;
" les algorithmes de signature et/ou cryptage, certains types de clefs peuvent ne
pas supporter la fois la signature et le cryptage ;
" codage des signatures et/ou des donn es crypt es.
La sp cification d finit les formats de clefs publiques et/ou de certificats suivants :
Nom
ssh-dss
ssh-rsa
Description
Clef DSS brut
Clef RSA brut
Requis ?
requis
recom-
mand
spki-sign-rsa
spki-sign-dss
Certificats SPKI avec clef RSA
Certificats SPKI avec clef DSS
pgp-sign-rsa
Certificats OpenPGP avec clef RSA
pgp-sign-dss
Certificats OpenPGP avec clef DSS
Pour s changer les clefs publiques, chaque machine va annoncer les algorithmes de
clefs quil supporte. Une fois les m thodes annonc es, les 2 machines vont choisir une
m thode d change des clefs et senvoyer leurs clefs publiques respectives.
2
Authentification
Le protocole dauthentification SSH permet lauthentification des utilisateurs en utili-
sant le protocole de transport SSH d finit plus haut.
change initial
IX.
Lauthentification est d clench par le client avec lenvoi dun paquet SSH_MSG_USE-
RAUTH_REQUEST.
La langue est d pr ci et doit tre la cha ne vide.
Les sous-m thodes est une liste s par e par des virgules de sous-m thodes dau-
thentification. Il est notamment possible pour le client de sp cifier un certains nombres de
sous-m thodes utiliser bas sur une configuration de lutilisateur.
Quand ce message est envoy au serveur, lutilisateur na pas encore sp cifi de mot
de passe de connexion et le mot de passe nest pas encore inclue dans ce message
(contrairement la m thode password).
la r ception de ce message, le serveur doit renvoyer un des messages suivants :
" SSH_MSG_USERAUTH_SUCCESS, pour accepter lauthentification ;
" SSH_MSG_USERAUTH_FAILURE, pour refuser lauthentification ;
" SSH_MSG_USERAUTH_INFO_REQUEST, pour demander des informations suppl men-
taires afin de poursuivre lauthentification.
La sp cification ne conseille pas de r pondre le message SSH_MSG_USERAUTH_FAILURE
au premier message dauthentification par nom dutilisateur. Il est pr f rable de r pondre
la r ponse la plus probable (SSH_MSG_USERAUTH_INFO_REQUEST), puis denvoyer un mes-
sage SSH_MSG_USERAUTH_FAILURE apr s quelques secondes. Ce comportement permet
demp cher les algorithmes brute force qui validerait un nom dutilisateur par un
simple message envoy au serveur.
De m me, il est pr f rable de ne pas r pondre le message SSH_MSG_USERAUTH_SUCCESS
m me si lutilisateur est correctement authentifi , mais denvoyer le message
SSH_MSG_USERAUTH_INFO_REQUEST et de ne pas tenir compte des r ponses.
Demandes dinformations
X.
Comme nous lavons vu, le serveur peut demander des informations dauthentification
au client avec un message SSH_MSG_USERAUTH_INFO_REQUEST.
Un serveur ne doit jamais envoyer plu-
sieurs requ tes au client en parall le mais
doit attendre la r ponse du client. Cepen-
dant, le nombre de requ tes est inconnu
et le client doit sattendre en recevoir un
nombre ind fini.
Le message d finit un tableau de va-
leur r cup rer avec pour chaque valeur :
un prompt afficher lutilisateur et un
bool en pr cisant si la r ponse de lutilisa-
teur doit safficher. Cest au client de d fi-
nir cette notion.
1 octet
SSH_MSG_USERAUTH_REQUEST
cha ne
Nom de lutilisateur
cha ne
Nom de service
cha ne
keyboard-interactive
cha ne
Langue
cha ne
Sous-m thodes
Une fois toutes les valeurs renseign es, le client r pond alors avec un message
SSH_MSG_USERAUTH_INFO_RESPONSE.
Ce message contient un tableau des r ponses du client chacune des requ tes du
serveur.
Le nombre de r ponses dans ce message doit tre gale au nombre de requ tes
dans le message du serveur et doivent tre dispos es dans le m me ordre que les re-
qu tes respectives dans le message du serveur.
ces requ tes, le serveur doit r pondre imm diatement par une des 3 r ponses pos-
sibles : succ s, chec ou demande dinformations suppl mentaires, notamment en cas de
succ s.
En cas d chec, la sp cification recommande de nenvoyer le message d chec quau
bout de quelques secondes dattentes, g n ralement 2 secondes.
Protocole de connexion
XI.
SSH2 d finit un 3e protocole sutilisant au dessus de protocole dauthentification. Ce
protocole permet lex cution de commandes distance, le transfert de connexions TCP/IP
et de connexions X11.
Toutes ces fonctionnalit s passent
par la cr ation de canaux. Ces canaux
peuvent tre initi s par lune ou lautre
des parties de la communication mise
en place par un change de messages.
1 octet
cha ne
cha ne
cha ne
entier
SSH_MSG_USERAUTH_INFO_RE-
QUEST
Nom
Instruction
Langue (d pr ci )
Nombre de requ tes
cha ne
Prompt 1
bool en
Affichage 1
...
1 octet
SSH_MSG_USERAUTH_INFO_RESPONSE
entier
Nombre de r ponses
cha ne
Publicité
R ponse 1
...
3.TLS : TRANSPORT LAYER SECURITY
Description de TLS
1
TLS est un protocole permettant de s curiser des communications. Il s'appuie sur un
protocole de transport fiable (TCP, par exemple). TLS est ind pendant des protocoles de
la couche sup rieure et peut ainsi s curiser tout type de trafic : HTTP, FTP, etc.
TLS est le prolongement de SSL (Secure Socket Layer). SSL a initialement t
d velopp par Netscape et a fait l'objet de trois versions. La version 1.0, publi e en juillet
1994, n'a pas t utilis e. Elle a t suivie de la version 2.0 en novembre de la m me
ann e, puis de la version 3.0 en ao t 1996. Ces deux versions proposent sensiblement
les m mes fonctionnalit s.
L'IETF (Internet Engineering Task Force) a poursuivi les travaux de Netscape sur base
de SSL 3.0 et a publi TLS 1.0 (consid r comme tant SSL 3.1). TLS 1.0 fait l'objet de la
RFC 2246 publi e en janvier 1999. Notons que l'IETF standardise le protocole mais ne
standardise pas l'API (Application Programming Interface, interface de programmation
d'applications) offerte par les impl mentations.
S curit apport e par TLS
La s curisation porte sur plusieurs points. Tout d'abord, le protocole assure que la
connexion est priv e, c'est- -dire qu'un tiers ne peut pas r cup rer les donn es
(eavesdropping). Pour cela, les donn es transmises sont crypt es.
Le protocole permet galement de s'assurer de l'identit des acteurs (authentification
du client et du serveur) gr ce l' change de certificats sign s par une autorit de
certification. Cela permet galement d'assurer la non-r pudiation des changes
(l' metteur ne peut pas nier avoir envoy les donn es).
La protection contre l'alt ration des donn es est quant elle assur e gr ce
l'utilisation d'un code d'authenticit des messages (code MAC obtenu par hachage). Enfin,
le rejeu des communications est vit gr ce l'introduction de param tres chang s
l'ouverture de session dans le calcul de ce code.
Technologies utilis es
TLS utilise un chiffrement sym trique (chiffrement cl secr te) car cela est moins
co teux qu'un chiffrement cl publique du point de vue du temps de calcul. La cl
secr te est quant elle calcul e partir d'une pr -cl secr te , laquelle est chang e
gr ce un chiffrement cl publique.
De nombreux algorithmes de hachage, de chiffrement et de compression peuvent tre
utilis s. En effet, TLS est modulaire afin de permettre l'utilisation de nouveaux algorithmes
sans devoir standardiser un nouveau protocole. Une n gociation entre le client et le
serveur est alors op r e afin de d terminer les algorithmes qui seront utilis s.
Les algorithmes les plus couramment utilis s sont :
" MD5 et SHA-1 pour le hachage ;
" RSA, Diffie-Hellman pour le chiffrement de la pr -cl secr te ;
" 3DES, RC4 et DES pour le chiffrement sym trique.
Le protocole de communication : TLS Record Protocol
2
Le protocole TLS est con u de telle sorte pouvoir s curiser des donn es pour tout
type d'application. Dans le mod le en couches OSI, TLS d finit la couche TLS Record
Protocol. Celle-ci s'appuie sur un protocole de transport fiable et offre ses services une
couche sup rieure.
TLS Record Protocol assure que la connexion est priv e, et peut galement assurer
l'identit des interlocuteurs ainsi que l'int grit et la compression des donn es.
Les fonctions suivantes sont assur es lors de l' mission de messages :
"
"
"
"
la fragmentation des donn es en blocs ;
la compression (optionnel) ;
le calcul d'un code d'authenticit des donn es (optionnel) ;
le cryptage.
la r ception, les fonctions sym triques sont assur es :
"
"
"
"
le d cryptage ;
la v rification l'aide du code d'authenticit ;
la d compression ;
le r assemblage des paquets fragment s.
TLS Record Protocol se subdivise en quatre protocoles, lesquels n'interviennent pas
aux m mes moments dans la communication :
"
"
"
"
le protocole Handshake protocol initie la connexion et permet la n gociation
ainsi que l' change des param tres de connexion ;
le protocole Change cipher spec protocol indique l'autre interlocuteur le
passage en mode chiffr ;
le protocole Application data protocol transmet les donn es chiffr es ;
le protocole Alert protocol assure la fermeture s curis e de la connexion.
Illustration 1 : TLS dans le mod le en
1
D roulement typique d'une connexion
Une connexion typique comporte trois phases :
couches OSI.
"
"
"
l'initialisation de la connexion l'aide des protocoles Handshake et Change
cipher spec ;
l' change de donn es l'aide du protocole Application data ;
la fermeture de la connexion l'aide du protocole Alert.
Ce d roulement est d crit par l'illustration 2 et est celui qui est obtenu, par exemple,
lorsque l'on se connecte au site d'une banque pour g rer ses comptes en ligne. Les
diff rents types de messages sont d crits ci-apr s.
Illustration 2 : D roulement d'une connexion typique
2
Param trage de la connexion :
spec protocol
Handshake protocol
Change cipher
et
Le protocole de Handshake est responsable de l'initialisation de la connexion. A l'issue
de cette tape, les deux partis auront choisi des param tres qui seront utilis s tout au
long de la communication :
" un vecteur d'initialisation (voir la partie traitant du code d'authenticit des
messages) ;
" un algorithme de chiffrement ;
" un algorithme de compression (optionnel) ;
" un algorithme de v rification de l'authenticit des messages (optionnel).
L'initialisation se d roule de la mani re suivante :
"
"
"
le client envoie un message Client hello indiquant les protocoles (chiffrement...)
qu'il supporte ;
le serveur r pond par un message Server hello indiquant les protocoles choisis
et attribuant un num ro de session la communication. Il y joint son certificat
(Server certificate) et fait ventuellement une demande de certificat au client
(Certificate request). Il termine par un message Server hello done ;
le client v rifie l'identit du serveur l'aide du certificat ;
"
"
"
"
le client envoie ensuite son certificat (Client certificate, si le serveur le lui a
demand ) et envoie galement une pr -cl secr te (Client key exchange). Cette
cl va servir calculer la cl secr te (cl de session) qui sera utilis e pour
chiffrer les donn es ;
le client et le serveur calculent la cl de session partir de la pr -cl secr te ;
le client annonce le passage en mode chiffr (Change cipher spec suivi de
Finished) ;
le serveur annonce galement le passage en mode chiffr .
Notons que les param tres de connexion peuv...