PROTOCOLE SSL ET TLS

1 Gnralits du protocole SSL et TLS

1.1 Positionnement des protocoles SSL et TLS
SSL signifie Secure Sockets Layer et son quivalent actuel TLS signifie
Transport Secured Layer. Ils sont tous les deux des protocoles situs entre le
niveau Transport et Application.

SSL et TLS se comportent en effet comme une couche intermdiaire

supplmentaire, car ils sont indpendants du protocole utilis au niveau
application. Cela signifie donc quil peut aussi bien tre employ pour scuriser
une transaction web, lenvoi ou la rception demail, etc. SSL et TLS sont donc
transparents pour lutilisateur et ne ncessitent pas lemploi de protocoles de
niveau Application spcifiques.

https://astuces-top.blogspot.com
1.2 Objectifs et moyens mis en oeuvre
SSL et TLS proposent les fonctionnalits suivantes :
Authentification Le client doit pouvoir sassurer de lidentit du
serveur. Depuis SSL 3.0, le serveur peut aussi demander au client de
sauthentifier. Cette fonctionnalit est assure par lemploi de certificats.
Confidentialit Le client et le serveur doivent avoir lassurance que leur
conversationne pourra pas tre coute par un tiers. Cette fonctionnalit
est assure par un algorithme de chiffrement.
Identification et intgrit Le client et le serveur doivent pouvoir
sassurer que les messages transmis ne sont ni tronqus ni modifis
(intgrit), quils proviennent bien de lexpditeur attendu. Ces
fonctionnalits sont assures par la signature des donnes
SSL et TLS reposent donc sur la combinaison de plusieurs concepts
cryptographiques, exploitant la fois le chiffrement asymtrique et le
chiffrement symtrique.
SSL et TLS se veut en outre volutif, puisque le protocole est indpendant des
algorithme de cryptage et dauthentification mis en oeuvre dans une
transaction. Cela lui permet de sadapter aux besoins des utilisateurs et aux
lgislations en vigueur. Cela assure de plus une meilleure scurit, puisque le
protocole nest pas soumis aux volutions thoriques de la cryptographie (Si un
chiffrement devient obsolte, le protocole reste exploitable en choisissant un
chiffrement rput sr).

1.3 Fonctionnement
Le protocole SSL et TLS se dcompose en deux couches principales (quatre en
ralit) :
SSL et TLS Handshake Protocol choisit la version de SSL et TLS qui sera
utilise, ralise lauthentification par lchange de certificats et permet la
ngociation entre le client et le serveur dun niveau de scurit au
travers du choix des algorithmes de cryptage. Cest le protocole de
configuration de la transaction.
SSL et TLS Record Protocol encapsule et fragmente les donnes. Cest le
protocole de transmission des donnes.
Dans une premire phase, le client et le serveur vont effectuer la ngociation
an de configurer la transaction et dchanger les cls de chiffrement. Puis ils
effectueront lchange de donnes proprement dit.

1.4 Plan de ce document

Ce document prsente dans un premier temps lvolution de SSL depuis sa

https://astuces-top.blogspot.com
cration jusqu lapparition du protocole actuel TLS et ses diffrentes
perspectives davenir. Il replace aussi SSL dans le contexte des diffrentes
solutions existantes de scurisation des transactions sur le rseau. Puis nous
rappelleront les concepts cryptographiques mis en oeuvre. Nous dtaillerons
ensuite le fonctionnement technique des protocoles SSL et TLS. Enfin, nous
voquerons les limites de ces protocoles en matire de scurit.

2 Prsentation de SSL et TLS

2.1 Historique
Voici lhistorique des protocoles SSL et TLS par sortie de version :
SSL 1.0
1994
Netscape
SSL 2.0
Fvrier 1995
Netscape
The SSL Protocol Version 2.0
SSL 3.0
Novembre 1996
Netscape
The SSL Protocol Version 3.0
TLS 1.0
Janvier 1999
IETF
RFC 2246
Extensions TLS
Juin 2003
IETF
RFC 3546
Extensions TLS
Avril 2006
IETF
RFC 4366

2.2 Perspectives actuelles

La premire version de SSL a t dveloppe par Netscape Communications en
1994. Lobjectif de Netscape tait de crer un canal scuris o les donnes
pourraient transiter entre un client et un serveur, indpendamment de la
plateforme et du systme dexploitation. Netscape souhaitait aussi pouvoir
bnficier des nouvelles mthodes de chiffrage, telles AES (Advanced
Encryption Standard), qui venait de remplacer le chiffrement DES (Data

https://astuces-top.blogspot.com
Encryption Standard).
Quoique SSL soit destin lorigine uniquement scuriser les transactions entre
un client et un serveur web (HTTP), la spcification a t connue de faon ce
que les autres protocoles de niveau application puissent lexploiter (FTP, Telnet,
etc.). La spcification SSL 1.0 ne fut diffuse quen interne et aucune
application ne supportera SSL 1.0.
Quelques mois plus tard, en fvrier 1995, Netscape publie la version 2.0 du
protocole. Il est implment dans la premire version de son client web
Navigator. SSL 2.0 se fonde sur lauthentification du serveur par le poste client
et sur lutilisation dun certificat serveur au format X.509 v3. Cette
authentification ne ncessite, du ct du poste client, que des calculs en cl
publique.
En novembre 1996, Netscape publie la version 3.0 du protocole. Par rapport
SSL 2.0, SSL 3.0 offre en plus la capacit, pour le serveur, dauthentifier le
client. Dans ce cas, le client doit pouvoir dune part exploiter sa cl prive et
dautre part fournir son certificat au format X.509 v3.
LIETF (Internet Engineering Task Force) propose son tour un protocole de
transfert scuris bas sur les concepts de SSL, baptis TLS 1.0 (parfois
nomme SSL 3.1) et dcrit dans la RFC 2246. Elle rachte le brevet de
Netscape sur le protocole SLL en 2001. Puis en juin 2003, des extensions sont
proposes pour TLS sous la forme dune nouvelle RFC. La dernire RFC 4366,
updatant la prcdente, est sortie en Avril 2006.
A lheure actuelle, les protocoles SSL 2.0, SSL 3.0 et TLS 1.0 sont utiliss. La
version 2.0 de SSL prsente cependant des failles de scurit connues, ce qui
reprsente une contre indication son emploi.

2.3 Contexte technique

Comme il a t mentionn ci-dessus, SSL et TLS sont des protocoles
transparents pour lutilisateur, situs entre les couches Application et
Transport. De nombreux protocoles peuvent donc exploiter SSL et TLS, tels
HTTP (HTTPS), LDAP (LDAPS), etc.
Cependant, si SSL et TLS est transparent au niveau des protocoles, il ne lest
pas au niveau des applications qui lexploitent. Celles ci ncessitent donc
individuellement des amnagements pour prendre en compte SSL et TLS. Lune
des faiblesses de SSL et TLS est de donc disposer dun nombre encore
relativement rduit dimplmentations.

2.3.1 Implmentations de SSL et TLS

Implmentations dans les navigateurs web
La majeure partie des implmentations de SSL et TLS se trouve dans les
navigateurs et serveurs web. Le serveur Apache, notamment, peut
exploiter SSL grce une implmentation base sur OpenSSL.
OpenSSL

https://astuces-top.blogspot.com
 Implment en C, OpenSSL est une bote outils de chiffrement
comportant deux bibliothques (une de cryptographie gnrale et une
implmentant le protocole SSL), ainsi quune commande en ligne.
OpenSSL supporte SSL 2.0, SSL 3.0 et TLS 1.0. OpenSSL est distribu
sous une licence de type Apache.
GnuTLS
Le projet GnuTLS propose une implmentation du protocole TLS
conforme aux spcifications de lIETF. GnuTLS supporte TLS 1.1, TLS 1.0,
SSL 3.0 et les extensions TLS. Il permet lauthentification via les
certificats X509 et PGP. A la diffrence dOpenSSL, GnuTLS est
compatible avec les licences GPL.

2.3.2 Certification
Ainsi que nous le verrons dans la prsentation des concepts cryptographiques,
le principal risque associ lutilisation de SSL et TLS est le dtournement des
certificats. An de parer ce risque, il importe de se doter dautorits de
certifications,destines valider ou invalider les certificats. Deux philosophies
saffrontent.
La certification X.509
La certification X.509 repose sur le principe dautorits centralises, dont
le rle est dtenir jour une liste des certificats valides. Elle doit aussi
rvoquer les certificats expirs, douteux, etc. Lutilisateur se rfre cette
autorit chaque fois quil veut contrler la validit dun certificat. Ces
autorits sont organises hirarchiquement, de faon que la plus haute
soit une autorit de confiance maximale. Le rle dune autorit
suprieure est de valider les autorits qui dpendent delle.
La certification PGP
La certification PGP (Pretty Good Privacy) est base sur la philosophie
Les amis de mes amis sont mes amis . En effet, la validit des certificats
se transmet de pair pair : si un utilisateur valide ou invalide un certificat,
il transmet linformation aux utilisateurs avec lesquels il est directement
en relation (il sagit donc dutilisateurs de confiance). De proche en
proche,la certification se transmet.
Les inconvnients majeurs de PGP, sont dune part la difficult invalider
un certificat sil a t au pralable reconnu par beaucoup dutilisateurs et
dautre part le problme savoir si les rseaux de confiance peuvent tre
suffisamment fiables.
Les protocoles SSL et TLS ont choisi de se baser sur les certifications X.509.

2.3.3 SSL et TLS par rapport aux autres solutions

Dautres protocoles permettent dassurer la scurit sur le rseau. Bien que
proposant des fonctionnalits concurrentes de SSL et TLS, ils sont plutt
considrs comme complmentaires.
SSH

https://astuces-top.blogspot.com
 SSH est un protocole de niveau application qui propose une alternative
scurise aux utilitaires classiques (rlogin, rsh, telnet) qui noffrent pas
de confidentialit. La possibilit dexploiter un mcanisme de tunneling
rend SSH, comme SSL et TLS compatible avec les autres protocoles de
niveau application dj existant. Tout comme SSL et TLS, SSH assure
lauthentification des machines, la confidentialit et lintgrit des
donnes. Il assure aussi lauthentification des utilisateurs par mot de
passe.
SSH souffre de faiblesses par rapport SSL et TLS : il nintgre pas la
notion de certificats X509 v3, ncessite linstallation dune application
cliente spcifique (pas de transparence).De plus, la notion de tunneling
reste difficile apprhender.
Cependant, SSH est moins vulnrable que SSL et TLS en matire
didentification du client. En effet, la protection du certificat sur un poste
client ne peut pas toujours tre correctement assure.
IPSec
IPSec fournit un mcanisme de scurisation au niveau de la couche
rseau (IP). Il est utilis notamment pour la mise en oeuvre de rseaux
privs virtuels (VPN). Les fonctionnalits dIPSec sont lauthentification
des machines, la confidentialit et lintgrit des transactions.
Son implmentation indissociable de la prochaine version du protocole IP,
IPv6, entre en concurrence avec les fonctionnalits de confidentialit et
dintgrit de SSL et TLS. Elle offre en outre une scurisation du rseau
dans sa globalit et non des applications au cas par cas.
Cependant, IPSec ne peut assurer lauthentification des utilisateurs, ce
qui pose le problme de la fiabilit des postes individuels. De plus, tant
encore une technologie jeune,il se pose les problmes de manque de
recul et dinteroprabilit.
A ce jour, donc, les fonctionnalits de scurit dIPSec et IPv6 sont vues
comme un important complment la scurit offerte par SSL et TLS.
SET/3D-Secure
Bas sur SSL et TLS, les protocoles SET (aujourdhui obsolte) et 3D-
Secure proposent une authentification valide par un tiers. Ces
protocoles sont principalement destins aux applications de paiement en
ligne (ils sont dvelopps par des institutions bancaires). Si SSL et TLS et
SET/3D-Secure assurent chacun un haut degr de confidentialit, seul le
SET permet une pleine identification rciproque des deux parties grce
un tiers de confiance,en loccurrence la banque du vendeur. Ainsi, elle
assure le vendeur que la carte est bonne et quelle na pas t vole et le
client quaucune utilisation malveillante ne sera faite de ces informations.
On voit ici que, quoique souffrant de limitations, lunivers SSL et TLS est vaste
et stable.

2.4 Les ports et applications utilisant SSL et TLS

Voici la liste des applications exploitant SSL et TLS avec leurs ports

https://astuces-top.blogspot.com
TCP associs :
Protocole : NSIIOPS
Port TCP : 261
Description : IIOP Name Service sur SSL et TLS
Protocole : HTTPS
Port TCP : 443
Description : HTTP sur SSL et TLS
Protocole : DDM-SSL
Port TCP : 448
Description : DDM-SSL
Protocole : SMTPS
Port TCP : 465
Description : SMTP sur SSL et TLS
Protocole : NNTPS
Port TCP : 563
Description : NNTP sur SSL et TLS
Protocole : SSHELL
Port TCP : 614
Description : SSL Shell
Protocole : LDAPS
Port TCP : 636
Description : LDAP sur SSL et TLS
Protocole : FTPS-DATA
Port TCP : 989
Description : FTP donnes sur SSL et TLS
Protocole : FTPS
Port TCP : 990
Description : FTP controle sur SSL et TLS
Protocole : TELNETS
Port TCP : 992
Description : Telnet sur SSL et TLS
Protocole : IMAPS
Port TCP : 993
Description : IMAP4 sur SSL et TLS
Protocole : IRCS
Port TCP : 994
Description : IRC sur SSL et TLS
Protocole : POP3S
Port TCP : 995
Description : POP3 sur SSL et TLS

https://astuces-top.blogspot.com
3 Aspects cryptographiques
Les concepts mis en oeuvre dans SSL et TLS reposent sur des notions de
cryptographie usuelles. SSL et TLS utilise en effet des mthodes de chiffrement
symtrique et asymtrique pour assurer ses diverses fonctions :
authentification, signature, intgrit et identification.
Sans aborder les algorithmes exploits, il est nanmoins intressant de se
pencher sur les bases cryptographiques qui ont donn naissance aux
protocoles.
Mathmatiquement, les protocoles dchange de messages, appels
cryptosystmes, sont reprsents sous forme dun quintuplet

M reprsente lensemble des messages clairs

C lensemble des messages cods
K lensemble des cls
E lensemble des fonctions de chiffrement (cest dire un ensemble de la forme :

D lensemble des fonctions de dchiffrement (cest dire un ensemble de la

forme :

3.1 Chiffrement symtrique ou cl secrte

Le chiffrement symtrique, dit aussi cl secrte est la forme la plus ancienne
de cryptage. Elle consiste utiliser une valeur courte (la cl) pour rendre un
message inintelligible aux tierces parties.
Elle est dite symtrique car cette mme cl permet ceux qui en ont
connaissance de dchiffrer le message et ainsi daccder son contenu.
Mathmatiquement, un cryptosystme clef secrte est donc dni par la
condition :

https://astuces-top.blogspot.com
Concernant limplmentation dun protocole de scurit, le chiffrement
symtrique est intressant car il est simple mettre en oeuvre et requiert un
faible temps de calcul. Il valide la contrainte de confidentialit,aussi longtemps
que la cl reste secrte.
Cependant, il prsente un inconvnient majeur : la difficult de protger le
secret dune cl. En effet, au moment ou les deux parties changent leur cl
secrte, ils ne peuvent pas sassurer que celle ci nest pas intercepte par un
tiers. Cette solution savre donc, seule, insuffisante.

3.2 Chiffrement asymtrique ou cl publique

3.2.1 Chiffrement
Le chiffrement asymtrique, dit aussi cl publique dcoule de dcouvertes
thoriques relativement rcentes dans le domaine mathmatique. Il repose sur
lexistence de fonctions mathmatiques difficiles inverser, sauf en exploitant
une brche secrte.
La cl du cryptosystme est ici un couple (kprivate, kpublic). kprivate est
connue du seul rcipiendaire des messages et kpublic est universellement
connue.
Les fonctions de codage et de dcodage deviennent alors respectivement
ekpublic et dkpublic, kprivate, cest dire quil est possible toute personne de
coder un message, mais que seul le dtenteur de la cl prive
(rcipiendaire du message) est capable de le dcoder.
On lappelle donc asymtrique, car il est facile pour un utilisateur quelconque
de coder un message, mais difficile de dcoder ce message. Le chiffrement
asymtrique permet donc de sassurer de lidentit du destinataire.

3.2.2 Signature
La signature permet de sassurer de lidentit de lexpditeur dun message.
Les mthodes de signature, exploitent en ralit un protocole inverse de celui
du chiffrement.
Lexpditeur va coder un message donn avec sa cl prive. Lui seul en est
capable. En revanche, nimporte qui peut vrifier que le message a t cod
par lexpditeur, en le dcodant avec la cl publique et en vrifiant quil
correspond bien au message dorigine.
En effet, on utilise pour la signature une fonction brche secrte telle que :

https://astuces-top.blogspot.com
Comme seul lexpditeur souhait connais d(), le rcipiendaire peut sassurer
que la communication reue en vrifiant que :

Cependant, si ce procd identifie lexpditeur, il possde linconvnient de

rendre le message transmis dchiffrable par tous.

3.2.3 Une premire limite

Il est donc thoriquement possible dutiliser un empilement de deux
cryptosystmes, lun de signature cl publique, lautre de chiffrement cl
publique : ainsi, les deux parties sidentifient lune et lautre, chacune
connaissant la cl publique de leur interlocuteur.
Cependant, les algorithmes a cl secrte sont gourmands en ressources, tant
pour le codage que le dcodage et cest pourquoi cette solution ne pouvait tre
adopte dans le protocole SSL et TLS. Le cryptage asymtrique a donc t
associ aux tapes critiques du protocole : lchange des cls secrtes,
permettant lemploi scuris de chiffrements symtriques (beaucoup plus
lgers) et, sous une forme allge, la signature et la vrification de lintgrit
des donnes.

3.2.4 Signature et hachage

Le principe de signature et de vrification dintgrit est simplifi par lemploi
pralable dune fonction de hachage. Une fonction de hachage calcule le
rsum dun texte. Ce rsum doit tre sens unique, pour viter de
reconstituer le message initial connaissant seulement le rsum. Il doit tre
trs sensible, cest dire quune petite modification du message entrane une
grande modification du rsum. En expdiant un message accompagn de son
rsum (on dit aussi son hach), on peut sassurer de lintgrit du message,
en recalculant le rsum larrive.
En associant hachage et signature, il devient possible dassurer les
fonctionnalits de contrle dintgrit et didentification de lexpditeur de faon
simple est performante. La signature devient facile calculer (car le hacher est
beaucoup plus court que le message),et son intgrit, ainsi que celle du
message, deviennent interdpendantes. Cest ce procd qui sera utilis dans
SSL et TLS, sous le nom de signature MAC.

https://astuces-top.blogspot.com
3.3 Apparition de la notion de Certification

3.3.1 Lattaque par le milieu

Un problme reste cependant : la fiabilit du systme dcrit ci-dessus repose
sur la confiance accorde aux cls publiques. Or celles-ci doivent elles mme
se faire connatre des participants une transaction. Ainsi, toute la scurit vole
en clat si un tiers malintentionn est capable de diffuser, linsu des
participants, des cls publiques contrefaites.
Cas normal
1 Alice et Bob changent leur cl publique. Charles peut les lire,
il connat donc kapublicet kbpublic.
2 Si Alice veut envoyer un message Bob, elle chiffre ce message
avec kbpublic. Bob le dchiffre avec kbprivate.
3 Charles, qui ne possde que kbpublic, ne peut pas lire le
message.
Attaque, Admettons maintenant que Charles soit en mesure de modifier
les changes entre Alice et Bob.
1 Bob envoie sa cl publique Alice. Charles lintercepte et renvoie
Alice sa propre cl publique kcpublic en se faisant passer pour Bob.
2 Lorsque Alice veut envoyer un message a Bob, elle utilise
donc, sans le savoir, la cl de Charles.
3 Alice chiffre le message avec la cl publique de Charles et
lenvoie celui quelle croit tre Bob.
4 Charles intercepte le message, le dchiffre avec sa cl prive
kcprivate et peut lire le message.
5 Puis il chiffre nouveau le message avec la cl publique de Bob
kbpublic, aprs lavoir ventuellement modifi.
6 Bob dchiffre son message avec sa cl prive et ne se doute
de rien puisque cela fonctionne.
Ainsi, Alice et Bob sont chacun persuads dutiliser la cl de lautre, alors quils
utilisent en ralit tous les deux la cl de Charles.

3.3.2 Se prmunir contre lattaque par le milieu

On peut se prmunir contre cette attaque de diverses faons. Les deux
principales sont la mthode des rseaux de confiance, la mthode de
certification par un tiers de confiance. On trouve aussi des mthodes
dchange direct (main propre, tlphone) et dauthentification par mot de
passe.

https://astuces-top.blogspot.com
3.3.3 La certification X.509
Le principe de la certification par une autorit repose sur la confiance accorde
des organismes centraux. Lentit souhaitant obtenir une certification sadresse
une autorit,en lui fournissant sa cl publique. Lautorit, aprs avoir vrifi
lidentit du demandeur, va fournir un certificat, auquel il adjoint sa propre
signature : celle-ci permet alors de sassurer que le certificat a bien t mis
par une autorit comptente.
Lorganisme de certification fait alors office de tiers de confiance. Le protocole
retenu pour la certification sous SSL et TLS est X.509 v3.
Les certificats racine (cest dire manent dautorits hautement ables) sont
implments directement dans les navigateurs Web. Le problme lheure actuel
reste surtout labsence de mise jour des certificats, en cas de compromission
(de la cl prive, par exemple).
Structure dun certificat X.509
Version
Numro de srie
Algorithme de signature du certificat
Signataire du certificat
Validit (dates limite)
Pas avant
Pas aprs
Dtenteur du certificat
Informations sur la cl publique
Algorithme de la cl publique
Cl publique
Identifiant unique du signataire (Facultatif)
Identifiant unique du dtenteur du certificat (Facultatif)
Extensions (Facultatif)
Liste des extensions

4 Le protocole SSL et TLS

Le protocole SSL et TLS est subdivis en quatre sous protocoles :
Handshake Protocol Ce protocole ngocie les paramtres de cryptage
qui seront loeuvre lors de la connexion.
Change Cipher Spec Protocol Ce protocole annonce la n du protocole
de ngociation.
Alarm Protocol Cest le protocole de signalement derreurs et dalertes.

https://astuces-top.blogspot.com
 Record Protocol Ce protocole se place entre les autres et la couche 4.
Cest lui qui assure le rle de communication de SSL et TLS.
Ils sorganisent comme prsent dans le schma suivant :

Commenons par le protocole de ngociation, car cest le premier utilis.

4.1 Le protocole Hanshake

Il permet au client et au serveur de sauthentifier mutuellement, de ngocier
les algorithmes de chiffrement, de ngocier les algorithmes de MAC (Message
Authentification Code) et enfin de ngocier les cls symtriques qui vont servir
au chiffrement.

4.1.1 Format dchange

Chaque message chang entre le client et le serveur contient trois champs :
Type indique lobjet du message (1 octet)
Length indique la longueur du message (3 octets)
Content contient les donnes transmises (plus dun octet)

https://astuces-top.blogspot.com
4.1.2 Dtail des changes

1 Le client envoie un message HELLO_CLIENT, en clair, au serveur. Ce

message contient :
Version La plus haute version de SSL que puisse utiliser le client.
Random Un horodatage de 32 bits et une valeur alatoire de 28 octets
gnre par le client. Le nombre obtenu va servir la signature des
messages.
Session ID Un nombre, qui identifie la connexion. Un zro signifie la
volont du client dtablir une nouvelle connexion sur une nouvelle
session. Un autre nombre signifie la volont de changer les paramtres
ou de crer une nouvelle connexion sur la session existante.
CipherSuite Une liste, par ordre dcroissant de prfrence, des
algorithmes que supporte le client. Il sagit des algorithmes dchange de
cl et de chiffrement.
Compression Method Liste, par ordre dcroissant de prfrence, des
algorithmes de compression supports par le client.
Puis le client attend une rponse du serveur

https://astuces-top.blogspot.com
2 Le serveur rpond au client en clair : HELLO_SERVER. Le message contient
:
Version La plus haute version de SSL que puisse utiliser le client.
Random Un horodatage de 32 bits et une valeur alatoire de 28 octets
gnre par le client.
Session ID LIdentifiant de la session qui dbute.
CipherSuite La squence dalgorithmes choisis pour la session. Le
serveur slectionne la premire suite quil connait dans la liste transmise
par le client.
Compression Method La mthode de compression qui va tre utilise.
Maintenant que les algorithmes sont choisis, le serveur va sauthentifier auprs
du client. Il envoie pour cela son ou ses certificats (X.509) au client. Il peut
pendant cette tape demander un certificat au client. Le client vrifie
lauthenticit du serveur : si cette authenticit est mise en doute, la
transaction est interrompue.
3 Gnration des cls de chiffrement symtrique. Le client gnre de son
ct une prcl qui servira a produire les cls utilises
par la suite. Cette cl est envoye au serveur,crypte a laide de sa cl
publique. A laide de cette pr cl, le serveur et le client gnrent quatre cls
pour la session :
Server write mac secret utilise dans la signature des messages du
serveur.
Client write mac secret pour les messages du client.
Server write key pour chiffrer les donnes mises par le serveur.
Client write key pour le client.
Ces cls ne sont pas changes. Si besoin est, le serveur vrifie lauthenticit
du client.
4 Le client envoie le message CLIENT_FINISHED au serveur. Ce message est
chiffr et sign a laide des cls ci-dessus. Cela signifie qu partir de
maintenant, le client communique de cette manire.
5 Le serveur procde de mme. Ces messages sont dnis par le sous
protocole Change Cipher Spec (cest dailleurs tout ce que dfinit ce protocole).

4.2 Le protocole Change Cipher Spec

Ce protocole contient un seul message : change_cipher_spec. Il est envoy par
les deux parties la n du protocole de ngociation. Ce message transite chiffr
par lalgorithme symtrique prcdemment ngoci.

4.3 Le protocole Alarm

Ce protocole spcifie les messages derreur que peuvent senvoyer clients et

https://astuces-top.blogspot.com
serveurs. Les messages sont composs de deux octets. Le premier est soit
warning soit fatal. Si le niveau est fatal, la connexion est abandonne. Les
autres connexions sur la mme session ne sont pas coupes mais on ne peut
pas en tablir de nouvelles. Le deuxime octet donne le code derreur.
Les erreurs fatales sont :
Unexpected_message indique que le message na pas t reconnu
Bad_record_mac signale une signature MAC incorrecte
Decompression_failure indique que la fonction de dcompression a
reu une mauvaise entre
Handshake_failure impossible de ngocier les bons paramtres
Illegal_parameter indique un champ mal format ou ne correspondant
rien.
Les warnings sont :
Close_notify annonce la fin dune connexion
No_certificate rpond une demande de certificat sil ny en a pas
Bad_certificate le certificat reu nest pas bon (par exemple, sa
signature nest pas valide)
Unsupported_certificate le certificat reu nest pas reconnu
Certificate_revoked certificat rvoqu par lmetteur
Certificate_expired certificat expir
Certificate_unknown pour tout problme concernant les certificats et
non list ci-dessus.

4.4 Le protocole Record

Ce protocole chapeaute les autres protocoles de SSL et TLS, en fournissant une
interface unifie pour la transmission des donnes.

4.4.1 Rle
Encapsulation Permet aux donnes SSL et TLS dtre transmises et
reconnues sous une forme homogne.
Confidentialit Assure que le contenu du message ne peut pas tre lu
par un tiers : les donnes sont chiffres en utilisant les cls produites
lors de la ngociation.
Intgrit et Identit Permet de vrifier la validit des donnes
transmises, grce aux signatures MAC : cette signature est elle aussi
gnre laide des cls produites lors de la ngociation.

https://astuces-top.blogspot.com
4.4.2 Processus dencapsulation
Segmentation Les donnes sont dcoupes en blocs de taille infrieure
16 384 octets
Compression Les donnes sont compresses en utilisant lalgorithme
choisi lors de la ngociation. A partir de SSL 3.0, il ny a plus de
compression.
Signature MAC (0, 16 ou 20 octets) Une signature des donnes est
gnre laide de la cl MAC. Comme elle exploite une fonction de
condensation, on parlera en ralit de HMAC (Hashed MAC). Elle est
calcule de la manire suivante :
HASH(
write mac secret
| pad_2
| HASH(
write mac secret
| pad_1
| numro de ce message
| protocole pour ce message
| longueur de ce message
| donnes compresses
)
)
La fonction de condensation HASH() est soit MD5 soit SHA-1.
Pad_1 et pad_2 sont des mots de remplissage (pad_1 = 0x36 et pad_2 = 0x5C
(rpts 40 fois pour SHA-1 et 48 fois pour MD5))
Chiffrement Le paquet obtenu est chiffr laide de la fonction dnie lors
de la ngociation et de la write key. Les algorithmes actuellement
possibles pour le chiffrement sont 3-DES 168, IDEA 128, RC4 128,
Fortezza 80, DES 56, DES-40, RC4-40, RC2-40.
Ajout de len tte (5 octets) Lentte SSL est ajoute et le paquet est
pass la couche infrieure. Il contient :
Content-Type (1 octet) Indique le type de paquet SSL et TLS
contenu dans lenregistrement :
0x20 Paquet de type Change Cipher Spec
0x21 Paquet de type Alert
0x22 Paquet de type Handshake
0x23 Paquet de type Application Data : ce type correspond
aux donnes effectives de la transaction SSL.
Major Version (1 octet), Minor Version (1 octet) Numros de
versions principal et secondaire du protocole SSL et TLS utilis. Par
exemple, le protocole TLS1.0 sera identifi avec la paire
(0x03,0x01), car TLS 1.0 est considr comme la version 3.1 de
SSL.
(Compressed) Length (2 octets) Taille (compresse sil y a lieu)

https://astuces-top.blogspot.com
 du fragment SSL et TLS.

4.4.3 Rceptions des paquets

A la rception des paquets, le destinataire effectue les oprations suivantes :
1 Vrification de lentte SSL
2 Dchirage du paquet
3 Vrification du champ HMAC (en appliquant la mme fonction que ci-
dessus aux donnes dchiffres puis en comparant le rsultat au HMAC
reu)
4 Dcompression des donnes
5 Rassemblage des parties
Si au cours de ces vrifications se passe mal, une alarme est gnre.

5 Faiblesses et attaques envisageables

5.1 Limites
Les navigateurs nont pas de fonctionnalits volues de gestion des cls : les
certificats ne peuvent par exemple pas tre automatiquement renouvels et
lhistorique des cls nest pas conserv. Quand un certificat expire, lutilisateur
reoit un message et doit obtenir manuellement un nouveau certificat, ce qui
nest pas forcment trivial pour un utilisateur lambda.
La relation de confiance est dnie par la liste pr installe des autorits de
certification :Les navigateurs du commerce sont livrs avec de nombreuses
cls publiques pr installes (Netscape en contient 33). Celles-ci sont utilises
pour la vrification de la signature de lautorit de certification pour les
certificats dautres navigateurs ou serveurs. Pour tre confirm, un certificat
doit tre sign par nimporte laquelle des AC prsentes dans le navigateur. Par
consquent, si lune quelconque parmi les autorits de certification certifie un
site frauduleux, ce certificat sera vrifi correctement par des millions de
navigateurs.
Ce problme prend toute son ampleur quand il sagit de certificats rvoqus.
En effet, le protocole SSL et TLS (1.0) ne prvoit pas lobtention de la liste des
certificats rvoqus (CRL, Certificates Revoked List) par lautorit de
certification avant dutiliser un certificat (ou priodiquement). Un certificat ainsi
sign par une autorit peut tre rvoqu (utilisation frauduleuse du certificat,
cl divulgue) sans que lutilisateur nen soit inform.
On peut alors imaginer lattaque suivante :

5.2 Un scnario dattaque

Un utilisateur malintentionn peut crer un site portant un nom similaire un
autre, connu, par exemple www.goggle.com. Cet utilisateur obtient alors un

https://astuces-top.blogspot.com
certificat pour son site et peut ainsi piger dautres utilisateurs par fishing, ou
autre. Dans ce cas, mme si lautorit rvoque le certificat, le site pirate
continuera dtre peru comme sr par les navigateurs internet.

6 Conclusion
Les caractristiques de SSL sont donc :
Lindpendance vis vis des couches infrieures et suprieures
Le fonctionnement en mode Client/Serveur
Lassurance aux deux parties dune transaction authentifie (certificats),
prive (cryptage) identifie et intgre (MAC).
Lge de SSL lui confre une maturit certaine et dune longue exprience.
Malgr ses dfaillances au niveau de lauthentification, son utilisation est trs
rpandue et cela prouve sa robustesse. Son volutivit, ainsi que son volution
lui promettent un bel avenir.

https://astuces-top.blogspot.com