ÉCOLE SUPERIEURE DE GÉNIE INFORMATIQUE

MINI-MEMOIRE

Présenté en vue d’obtenir

LE TITRE INGENIERIE INFORMATIQUE ET RESEAUX

Par

CHRISTOPHE YAYON
&
FABRICE ROMELARD

LE PROTOCOLE SSL/TLS

Soutenu à PARIS en Janvier 2002

JURY

MONSIEUR MONLOUIS
 PLAN

INTRODUCTION

I. PRINCIPE DE FONCTIONNEMENT

II. ANALYSE DU PROTOCOLE SSL

III. CAS PRATIQUE

IV. PROBLEMES EFFECTIFS ET POTENTIELS

CONCLUSION
GLOSSAIRE
WEBOGRAPHIE & BIBLIOGRAPHIE

2
- Etude du protocole SSL/TLS [SSL 02] et de son implémentation au sein des échanges
d’informations sécurisés.
Mini mémoire ESGI 2002

Aujourd'hui la solution la plus répandue pour sécuriser les transactions est SSL (Secure
Socket Layer, créé par Netscape [NSC 02]).

Son succès s'explique par sa simplicité d'utilisation et par son intégration dans tous les
navigateurs du marché : vous remarquerez en bas à gauche de votre navigateur une petite
clé (ou un cadena ), qui apparaît automatiquement si le serveur qui vous envoie les
informations utilise SSL.

SSL est un protocole de communication d'informations qui permet d'assurer

l'authentification, la confidentialité et l'intégrité des données échangées.

Le but recherché par les entreprises commerciales est un moyen permettant une
communication sûre avec leurs clients, et plus précisément, une façon sûre d'obtenir le
paiement des biens/services vendus.
Les transactions commerciales qui s'effectuent sur Internet sont généralement
ponctuelles. C'est-à-dire qu'elles ne sont ni régulières, ni périodiques. Un système de
cryptographie permettant d'assurer ce type de communication doit tenir compte de ces
éléments.

L’objet de ce mémoire est d’aborder les différents problèmes que peut poser
l’implémentation du protocole SSL pour la sécurisation de données dites sensibles, et
SSL est-il vraiment un moyen efficace d’assurer la sécurité des échanges ?

Mots clés : SSL – OpenSSL – RSA – TLS

Keywords : SSL – OpenSSL – RSA – TLS

3
 REMERCIEMENTS

Nous remercions Monsieur Monlouis, directeur de l’ESGI [ESG 02] de nous avoir fait
l’honneur de présider le Jury.

Nous remercions Monsieur Ollivier Robert, membre de l’équipe de développement

FreeBSD [FRE 02] de nous avoir apporté toute l’aide nécessaire à l’élaboration du
projet .

Nous remercions Mademoiselle Sylviane Dupire pour sa relecture et son aide.

4
INTRODUCTION

SSL est un protocole à négociation (on parle du « handshake » SSL), développé à

l'origine par Netscape. La version 2.0 vient de Netscape et la version 3.0, qui est
actuellement la plus répandue, à reçue les contributions de la communauté internationale.
TLS (Transport Layer Security protocol), développé par l'IETF [IET 02], correspond à la
version 3.1 de SSL.

Ce protocole utilise un moyen de cryptographie reconnu : 'algorithme

l à clé publique
RSA (du nom de ses concepteurs - Rivest - Shamir – Adleman [RSA 02) qui est le
résultat d'opérations entre nombres premiers.
SSL a pour but de sécuriser les transactions Internet, par authentification du client (un
navigateur la plupart du temps) et du serveur, et par chiffrement de la session.

La sécurisation des connexions à l’aide du protocole SSL doit assurer que:

- La connexion assure la confidentialité des données transmises
- La connexion assure que les données transmises sont intègres
- L’identité des correspondants peut être authentifiée
- La connexion est fiable

Dans un cadre commercial, les données qui sont primordiales de protéger lors de la
transmission sont constituées des informations concernant la carte de crédit du client
(généralement). Dans le cas de vente de contenu électronique ou de service électronique
il faut également protéger la transmission de ces données. La libre circulation non-
protégée de ces données annulerait une partie des ventes des marchands.

De quelle manière fonctionne cette implémentation ? Comment les applications utilisent

SSL/TLS ?

5
I. PRINCIPE DE FONCTIONNEMENT

SSL ne dépend pas des applications utilisées lors des transactions et s'applique à les
protocoles HTTP, FTP, Telnet, SSH [SSH 02], etc…

Clients et serveurs commencent par s'authentifier mutuellement, puis négocient une clé
symétrique de session qui servira à assurer la confidentialité des transactions.
L'intégrité de ces dernières est assurée par l'application de MAC (Message
Authentification Code). Ce sont en fait des HMAC [HMC 02] (Hashed Message
Authentification Code) qui sont utilisés.

MAC - Message Authentification Code :

Cette méthode consiste à utiliser un algorithme de chiffrement par blocs en mode chaîné.
On peut par exemple chiffrer les données à l’aide d’un DES (Data Encryption Standard)
[ALG 02] en mode CBC (Cipher Block Chaining Mode) [ALG 02], puis considérer le
dernier bloc comme étant le MAC. Le destinataire ne pourra vérifier l’intégrité des
données que s’il possède la clé symétrique ayant servi à la gé nération du MAC.
Contrairement à la signature digitale, seul un destinataire particulier sera en mesure de
faire cette opération. L’utilisation de MAC (monde bancaire) n’assure pas vraiment la
non-répudiation (l'émetteur des données ne peut pas nier être à l'origine du message ) : les
destinataires possèdent en effet la même clé symétrique que l’expéditeur. Ce dernier peut
donc légitimement nier avoir signé telles données en générant un MAC, arguant du fait
qu’il n’est pas le seul à pouvoir le faire. Il faut s’assurer d’un canal sûr pour transmettre
la clé symétrique.
HMAC - Hashed Message Authentification Code :
On peut aussi joindre aux données à signer une chaîne aléatoire de bits, puis passer le tout
au travers d’une fonction de hachage pour obtenir le HMAC, ou « keyed-MAC ». Le
destinataire recalcule un HMAC à l’aide du code qu’il partage avec l’expéditeur. Si les
deux MACs sont égaux, il est assuré de l’intégrité des données et de l’authenticité de la

6
signature (encore faut-il que chaque code soit associé de façon non équivoque à deux
identités). L’utilisation de HMAC n’assure pas non plus la non-répudiation, et l’échange
sécurisé des codes est aussi à gérer.

Les clés asymétriques utilisées lors des transactions SSL sont encapsulées dans des
certificats (X.509) [X509 02], générés par bon nombre d'autorités de certification, ou de
PKI (Public Key Infrastructure) [PKI 02], l’un des plus connu étant sans doute VeriSign
[VER 02].

On distingue deux phases lors du déroulement du handshake SSL: authentification du

serveur et authentification optionnelle du client.

1. Première phase:

Suite à la requête d'un client, le serveur envoie au client son certificat et lui liste les
algorithmes qu'il souhaite utiliser. Le client vérifie la validité du certificat (à l'aide de la
clé publique du CA contenue dans son navigateur, des dates de validité et,
éventuellement, en consultant une signature (rarement dans la pratique), puis, si le
certificat est valide, génère une clé maître (symétrique), la chiffre à l'aide de la clé
publique du serveur et la lui envoie. Les données échangées par la suite entre le client et
le serveur sont chiffrées et authentifiées à l'aide de clés dérivées de la clé maître.

2. Deuxième phase, optionnelle (et souvent non utilisée):

Le serveur envoie au client un challenge (une petite série de bits) que le client doit signer,
à l'aide de sa clé privée correspondant à son certificat, et le renvoyer au serveur pour
s'authentifier. Il lui envoie de même son certificat, que le serveur vérifiera avant de
poursuivre les transactions.

7
Figure 1 : Authentification du serveur et authentification optionnelle du client

8
II. ANALYSE DU PROTOCOLE SSL

Une session SSL est définie par les paramètres suivants partagés entre un client et un
serveur:

Session identifier : un octet fixé par le serveur pour identifier la session

Peer certificat : un certificat pour le serveur, éventuellement un autre pour le client
Cipher Spec : définit l'algorithme de chiffrement symétrique et l'algorithme de
condensation
Master secret : clé de 48 octets négociée entre le serveur et le client
Compression method : NULL pour l'instant (SSLv3/TLS)
Is resumable : flag qui indique si de nouvelles connexions peuvent être créées à partir de
cette session

Une connexion SSL est définie par les paramètres suivants partagés entre un client et un
serveur :
Server and client random : des octets aléatoires determinés par le client et le serveur pour
chaque connexion
Server write (send) MAC secret : clé secrète utilisée par le serveur pour faire les MAC
Client write (send) MAC secret : clé secrète utilisée par le client pour faire les MAC
Server write (send) key : clé symétrique utilisée par le serveur pour chiffrer les données
Client write (send) key : clé symétrique utilisée par le client pour chiffrer les données
Initialization vectors : pour un algorithme de chiffrement par bloc en mode CBC. Le
premier est fixé lors du handshake, les suivants sont les derniers blocs des précédents
fragments chiffrés
Sequence number : chaque message est numéroté de part et d'autre

9
Le protocle SSL est constitué des sous protocoles :

Le protocole SSL handshake

Le protocole SSL Change Cipher Spec
Le protocole SSL Alert
Le protocole SSL Record

10
1. Le protocole SSL handshake

Ce protocole permet au client et au serveur de s'authentifier mutuellement, de négocier

les algorithmes de chiffrement, de négocier les algorithmes de MAC et enfin de négocier
les clés symétriques qui vont servir au chiffrement. Chaque message échangé entre le
client et le serveur contient trois champs:
Type : indique l'objet du message (1 octet)
Lenght : indique la longueur du message (3 octets)
Content : contient les données transmises (plus d'1 octet)

11
Figure 2 : handshake SSL

12
Phase 1: Etablissement des paramètres de sécurité

Cette phase à pour but d'établir le lien sécurisé. Les paramètres du premier message,
client_he llo, envoyé par le client, sont :

Version : la plus haute version de SSL que puisse utiliser le client.

Random : un horodatage de 32 bits et une valeur aléatoire de 28 octets générée par le
client. Ces valeurs servent de sel et sont utilisées pour se prémunir contre les rejets de
paquets.
Session ID : Un nombre, qui identifie la connexion. Un zéro signifie la volonté du client
d'étabir une nouvelle connexion sur une nouvelle session. Un autre nombre signifie la
volonté de changer les paramètres ou de créer une nouvelle connexion sur la session
existante.
CipherSuite : Une liste, par ordre décroissant de préférence, des algorithme s que supporte
le client. Il s'agit des algos d'échange de clé et de chiffrement.
Key Exchange : RSA clé symétrique chiffrée avec clé RSA contenue dans un certificat.
Diffie-Hellman : si le certificat serveur contient des paramètres D-H [ALG 02]. Le client
n'est pas obligé de présenter un certificat si l'authentification du client n'est pas demandée
par le serveur.
Diffie-Hellman temporaire : Une clé symétrique D-H est négociée, les transactions étant
signées par des clés RSA ou DSS certifiée par un CA (Certificate). C'est la plus sûre des
méthodes parce que la clé générée est unique et authentifiée.
Diffie-Hellman anonyme :(Un simple échange D-H est effectué, sans authentification des
partenaires. Vulnérable à "l'attaque du milieu".

Après avoir envoyé ces requètes, le client attend que le serveur réponde en générant une
valeur aléatoire, en indiquant la version, et les meilleurs algorithmes qu'il peut utiliser: ce
sera la réponse server_hello du serveur.

13
Phase 2: Authentification du serveur et échange des clés

Lors de cette phase, le serveur commence par envoyer son certificat. Ce message peut
contenir une chaîne de certificats. L'échange de clés entre serveur et client n'est possible
sans que le serveur n'envoie son certificat que dans le cas d'un Diffie-Hellman anonyme;
dans tous les autres cas, le serveur présente son certificat.
Le serveur envoie un message server_key_exchange si le client et le serveur veulent
utiliser du D-H anonyme (un nombre premier, un nombre qui lui est relativement premier
et la clé publique D-H du serveur), du D-H temporaire (les paramètres D-H et une
signature), du RSA key exchange (ou le serveur n'a qu'une clé RSA pour signer et veut
établir une clé RSA temporaire) ou Fortezza (norme de sécurité du gouvernement
américain) [F RZ 02]. Les signatures sont effectuées en utilisant les fonctions de
condensation, comprennent les sels initiaux et sont chiffrées grâce aux clés privées (ceci
assure que le serveur détient la clé privée associée à la clé publique que contient le
certificat).
Ensuite, le serveur peut demander au client un certificat: c'est le message
certificate_request (rarement implémenté dans la réalité), qui comprend les champs
certificate_type (algo public utilisé) et certificate_authorities (liste des CA valides).
Finalement, le serveur envoie le message server_done, qui signifie la fin de cette phase et
que le serveur se met en attente.

14
Phase 3: Authentification du client et échange des clés

Le client doit vérifier que le certificat envoyé par le serveur est valide (c'est souvent là
que le système est bancal), et que les autres paramètres sont corrects. Si le serveur à
demandé au client d'envoyer un certificat, le client envoie un message certificate,
contenant le certificat (s'il n'a pas de certificat, il envoie un message no_certificate).
Le client envoie ensuite un message client_key_exchange, qui dépend de l'algorithme
choisi :
RSA : le client génère une clé secrète de 48 octets qui servira à générer la définitive, et la
chiffre avec la clé publique du serveur.
D-H anonyme ou temporaire : ce sont les paramètres D-H du client qui sont envoyés.
Diffie-Hellman : Dans ce cas les paramètres D-H ont été envoyés avec le certificat, et ce
message est donc vide.
Fortezza : les paramètres Fortezza....
Pour finir cette phase, le client envoie un message certificate_verify (sauf si le certificat
ne contient que des paramètres D-H, qui ne peut servir à signer). Ce message consiste en
un condensat des messages échangés pendant le handshake, et de la clé symétrique
générée, le tout signé avec la clé privée du client. Le but de ce message est de s'assurer
que le client est bien en possession de la clé privée correspondant à la clé publique
envoyée dans le certificat (c'est bien beau de présenter un certificat si on ne prouve pas
que l'on possède la clé privée correspondante).

Phase 4: Fin

Le client envoie le message (1 octet) change_cypher_spec, qui est en fait l'unique

message du protocole Change Cipher Spec, et active pour la session courante les algos,
clés et sels du handshake. Puis le client envoie le message finished, qui authentifie le
client et valide l'échange de clé (le message est constitué d'un condensat de la clé
symétrique échangée, de l'ensemble des messages échangées durant le handshake, du pad
et d'un identificateur de l'expéditeur).
Le serveur répond en envoyant son propre change_cypher_spec et clot le handshake.

15
16
2. Le pro tocole SSL Alert

Ce protocole spécifie les messages d'erreur que peuvent s'envoyer clients et serveurs. Les
messages sont composés de 2 octets, le premier est soit warning soit fatal. Si le niveau est
"fatal", la connexion est abandonnée. Les autres connexions sur la même session ne sont
pas coupées mais on ne peut pas en établir de nouvelles.
Le deuxième octet donne le code d'erreur.

Les erreurs fatales sont:

unexpected_message : message non reconnu
bad_record_mac : MAC non correct
decompression_failure : la fonction de décompression à recu une mauvaise entrée
handshake_failure : impossible de négocier les bons paramètres
illegal_parameter : un champs était mal formaté ou ne correspondait à rien

Les warnings sont:

close_notify : annonce la fin d'une connexion
no_certificate : réponse à une demande de certificat s'il n'y en a pas.
bad_certificate : le certificat recu n'est pas bon (e.g. signature non valide)
unsupported_certificate : le certificat recu n'est pas reconnu...vive la compatibilité:)
certificate_revoked : certificat révoqué par l'émetteur
certificate_expired : certificat expiré ...
certificate_unknown : tous les problèmes concernant les certificats et non listés au-
dessus...

17
3. Le protocole SSL Record

Ce protocole permet de garantir:

La confidentialité des données transmises (c'est le Handshake qui permet de négocier une
clé symétrique partagée)
L'intégrité des données transmises (c'est encore le Handshake qui négocie une clé
partagée qui sert à faire des MAC sur les données)

18
Figure 3 : SSL Record

19
Dans l'entête qui est ajoutée:
Content Type : le plus haut protocole utilisé pour traiter ce fragment
Major Version : plus haute version de SSL utilisée (3 pour SSLv3)
Minor Version : plus basse version utilisée (0 pour SSLv3)
Compressed Lenght : la longueur en octets des données (éventuellement compressées) à
chiffrer.

A titre indicatif, voici les formules appliquées :

Le MAC est fait de la facon suivante (effectué avant chiffrement, puis chiffré):
HASH(clé partagée||pad_2||HASH(clé partagée||pad_1||numéro de ce massage||protocole
pour ce message||longueur de ce message||les données (comp ressées))
La fonction de condensation (HASH()) est soit MD5 soit SHA-1
Avec :
pad_1 = 0x36
pad_2 = 0x5C (répétés 40 fois pour SHA-1 et 48 fois pour MD5) [ALG 02]

Les algorithmes autorisés sont:

3-DES 168 ; IDEA 128 ; RC4 128 ; Fortezza 80 ; DES 56 ; DES-40 ; RC4-40 ; RC2-40.
Nous de détaillerons pas ces algorithmes car ce n’est pas l’objet de ce mini- mémoire.
Toutefois des informations sur ces algorithmes de cryptage sont disponibles. [ALG 02].

20
4. Assemblage des protocoles

Modèle OSI [OSI 02]:

Figure 4 : Assemblage SSL – OSI

TCP/IP :

Figure 5 : Assemblage SSL - OSI

21
III. CAS PRATIQUE

Pour accéder aux services SSL d'un serveur on ajoute habituellement un " s " lors de la
spécification du protocole.
Exemple: https://www.monsite.org

Le trafic SSL ne s'acomode pas de l'utilisation de serveurs proxy classiques (cache et

réplication) parce que SSL à été concu pour contrer les attaques " du milieu ".

22
Figure 6 : Proxy non-SSL, vu comme une attaque

23
Pour qu'un serveur proxy puisse gérer du trafique SSL, il doit supporter le protocole
SOCKS (qui travaille au niveau socket) ou un protocole spécial de tunneling SSL.

Liste des numéros de ports associés à SSL:

Protocole Port TCP Description

Nsiiops 261 IIOP Name Service sur TLS/SSL

https 443 http sur TLS/SSL

ddm-ssl 448 DDM-SSL

Smtps 465 smtp sur TLS/SSL

Nntps 563 nntp sur TLS/SSL

Sshell 614 SSLshell

Ldaps 636 ldap sur TLS/SSL

ftps-data 989 ftp données sur TLS/SSL

Ftps 990 ftp controle sur TLS/SSL

Telnets 992 telnet sur TLS/SSL

Imaps 993 imap4 sur TLS/SSL

Ircs 994 irc sur TLS/SSL

pop3s 995 pop3 sur TLS/SSL

24
1. Exemple d’un certificat auto-généré et non-approuvé par une autorité :
https://webmail.pgsm- group.com
CA correspondant :

Serial number : 01
Signature : algorithm md5RSA
Issuer : support@pgsm -group.com, pgsm -group, mail service, pgsm-group, PARIS IDF, FR
Valid from : Tuesday, December 04,2001 12:46:49
Valid to : Wednesday, December 04,2002 12:46:49
Subject : [email protected], pgsm-group, mail service, pgsm-group, PARIS IDF, FR
Public Key : RSA (1024 Bits)
Basic Constraints Subject : Type=End Entry, Path Length Constraint=none
Netscape Comment : OpenSSL Generated Certificate
Subject Key Identifier : 6d c6 63 ab 31 f7 3b ...
Authority Key Identifier : KeyID=e6 c2 d2 f4 74 ...
Thumbprint algorithm : sha1
Thumbprint : 42 7d f5 b8 bd 05 ...

pgsm -group :
This certificate cannot be verified up to a trusted certification authority.
This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store.

2. Exemple d’un certificat généré et approuvé par une autorité :

https://www.selftrade.fr
CA correspondant :

Version : V1
Serial number : 33 4f ...
Signature algorithm : md5RSA
Issuer : Secure Server Certification Authority, RSA Data Security,INC., US
Valid from : Tuesday, April 06,2001 12:46:49
Valid to : Wednesday, April 21,2002 12:46:49
Subject : www.selftrade.com SELF TRADE, Member, VeriSign Trust Network, Authenticated by Certplus
SA, www.certplus.com/RPA
Public Key : RSA (1024 Bits)
Thumbprint algorithm : sha1
Thumbprint : a2 fe b2 94 ...

25
IV. PROBLEMES EFFECTIFS ET POTENTIELS

Problèmes liés au client SSL: le navigateur.

Les navigateurs n'ont pas (encore) de fonctionnalités évoluées de gestion des clés. Les
certificats ne peuvent, par exemple pas être automatiquement renouvelés et l’historique
des clés n’est pas conservé. Quand un certificat expire, l’utilisateur reçoit un message et
doit obtenir manuellement un nouveau certificat, ce qui n'est pas forcément trivial pour
un utilisateur lambda. Ces problèmes seront probablement résolus lorsque les navigateurs
deviendront des clients de PKI à part entière.

La cryptographie utilisée par les navigateurs peut être soumise à des restrictions
d'exportation (hors des Etats-Unis par exemple pour Netscape et Microsoft) cela force les
utilisateurs à utiliser des clés de longueur insuffisante. Dans le cas de Netscape, on peut
renforcer la crypto (http://www.fortify.com [FOR 02]) tout en veillant à rester en
conformité avec la législation...

La relation de confiance est définie par la liste codée en dur des autorités de certification.
Les navigateurs du commerce sont livrés avec de nombreuses clés publiques pré-
installées (Netscape 6 en contient 33). Celles-ci sont utilisées pour la vérification de la
signature de l’autorité de certification pour les certificats d’autres navigateurs ou
serveurs. Pour être confirmé, un certificat doit être signé par n’importe lequel des 33 CA.
Par conséquent, si l’une quelconque parmi les 33 autorités de certification certifie un site
frauduleux, ce certificat sera vérifié correctement par des millions de navigateurs. En tant
qu'utilisateur, il est important d'aller voir dans les propriétés « sécurité » de son
navigateur et de valider la confiance que l'on attribue aux diverses autorités de
certification.
Par défaut, les navigateurs font confiance à toutes...

26
Sur Microsoft Internet Explorer (jusqu'a la version 5.0) le mot de passe protégeant les
certificats est optionnel (comme beaucoup de choses...) alors que protéger sa clé privée
est vital.

Problèmes intrinsèques au protocole:

Le système est fondé sur une seule paire de clés. Le principal problème que cela pose
vient de la différence entre les contraintes qui pèsent sur les clés de signature /
authentification et celles de chiffrement. Avoir la possibilité de sauvegarder en central les
clés de chiffrement peut s'avérer très pratique (si un utilisateur oublie son mot de passe il
n'est par exemple pas nécessaire de régénérer une paire de clé et de la certifier à nouveau,
mais on peut simplement lui renvoyer ses clés, en l'obligeant à re-saisir un mot de passe).
Si les services d’un tiers sont utilisés pour la sauvegarde d'une unique paire de clé
(service offert par certaines autorités de certification ou tiers de confiance), le client ne
sera plus le seul à avoir accès à sa clé privée de signature et la non-répudiation n'est alors
plus assurée. Certes, gérer deux paires de clés est plus lourd que d'en gérer une seule. La
sauvegarde des clés est importante là où celles-ci sont utilisées pour chiffrer des données
stockées, comme des courriers électroniques par exemple. Si les clés ne sont pas
sauvegardées et que l’accès aux clés est perdu, les données chiffrées n’ont plus aucune
utilité (et si en essayant d'en briser la protection on les récupère quand même, c'est alors
l'application crypto qui n'est d'aucune utilité...). Ce défaut est un peu théorique parce que
SSL, dans la pratique, ne chiffre que des flux. Pour un utilisateur "isolé", il est au
contraire souhaitable qu'aucune de ses clés privées ne soit ailleurs qu'en sa possession.
Mais il est probable que dans l'avenir un mê me certificat servira à plusieurs types
d'opérations crypto, auquel cas ce problème se posera.
Le protocole SSL ne prévoit pas de vé rification systématique. Lorsqu'un serveur Web
présente un certificat, le navigateur en vérifie sa validité; cela consiste pour lui à vérifier
que les dates de validité sont valides vérifier que la signature appliquée au certificat est
valide

27
Mais le protocole SSL n'impose pas qu'un certificat ne soit utilisé que suite à la
consultation de la signature qui lui correspond. Un serveur Web peut donc présenter aux
navigateurs un certificat révoqué. Netscape v6 permet de vérifier automatiquement les
signature, grâce au protocole OCSP (Online Certificate Status Protocol, désactivé par
défaut...) La vérification manuelle des signature est laborieuse et quasiment jamais faite.

Attaques possibles contre SSL:

On peut imaginer de construire un site très similaire à un site que l'on souhaite abuser. Il
est ensuite possible d'ache ter un certificat chez l’une des 33 autres autorités de
certification reconnues par les navigateurs. Le site est mis en place en utilisant un DN
(Domain Name) similaire (par exemple « www.monsite.org » au lieu de «
www.monsite.com »), voir même en trompant un serveur DNS (Domain Name Server)
pour créer un duplicata de « www.monsite.com ». Les utilisateurs ne verront aucune
différence, ils croiront être sur le site valide puisque son certificat est vérifié avec succès
par le navigateur, et ceci même si le site réel utilise un certificat valide. Vu l'absence de
consultation automatique des signatures par les navigateurs, l'autorité de certification qui
à émis le certificat pour le site contrefait peut mê me ensuite révoquer ce certificat sans
que les utilisateurs cessent d'en vérifier la validité.

28
CONCLUSION

Le besoin de gagner en confiance sur l'authentification d'entités communicantes et

d'assurer la confidentialité des messages échangés a poussé à l'utilisation de mécanismes
de sécurité évolués. Ils permettent lorsqu'ils sont mis en oeuvre, l'identification
d'individus agissant à l'autre bout d'une connexion, rendant ainsi difficile la vie des
usurpateurs et autres pirates du Net. Ainsi identifiés, gageons que certains perdraient pas
mal de leur ardeur à utiliser des outils tels que les programmes de Mail- Bomb ou de
Spamming.
Nous avons vu que les certificats numériques pouvaient être utilisés pour authentifier des
informations en y apposant une signature appartenant à un tiers de confiance. C'est à
partir de là qu'il peut exister un intérêt à réfléchir sérieusement à quelques questions :

Quelle confiance accorder à l'autorité signataire d'un certificat lorsque celle-ci déclare ne
pas pouvoir être tenue pour responsable des problèmes liés à l'emploi des certificats
qu'elle délivre ?
Est-ce que le "Jean Martin" du certificat est bien celui que vous cherchez à identifier ou
est-ce un homonyme ?
Ma clé privée est-elle en sécurité lorsque je l'installe dans des applications aussi
complexes que les navigateurs web qui sont connus pour leurs nombreuses failles de
sécurité ? Suis-je légalement responsable de l'utilisation qui est faite de ma clé privée en
cas de perte, de vol ou d'abus par un programme malicieux ? Puis-je répudier une
signature ?

En tenant compte de ces considérations il semble intéressant d'employer ces techniques

de signatures pour des applications assez anodines comme le courrier électronique ou
l'authentification de logiciels, aller au-delà ne paraît pas être une démarche sans danger
dans le contexte actuel. Tout cela changera peut-être avec l'apparition de cartes à puces

29
offrant des services cryptographiques et garantissant le confinement de la clé privée dans
leurs entrailles. L'emploi de certificats en vue d'assurer la confidentialité ne semble pas
poser autant de problèmes et s'est d'ailleurs très largement répandu au niveau des serveurs
Web et tous les serveurs tirant parti du protocole SSL.

Afin d’élargir l’emploi du protocole SSL/TLS, il faudrait augmenter l'automatisation du

traitement des demandes de certificats en écrivant des scripts qui autor isent l'envoi de
messages possédant des extensions MIME [MIM 02]. Les listes de révocation de
certificats perdus ou compromis devraient aussi faire partie des services offerts à la
communauté des utilisateurs de certificats; bien que très peu d'applications en fassent
usage. Mentionnons que la récente ordonnance 784.103 sur les services de certification
électronique définit les conditions auxquelles les fournisseurs de services de certification
peuvent être reconnus et que les exigences y figurant semblent difficiles à satisfaire; il y a
donc peu de chances que nos certificats numériques "faits maison" soient un jour
reconnus par d'autres organisations.

30
GLOSSAIRE

SSL : Secure Socket Layer

méthode de sécurisation des communications.

TLS : Transport Layer Security

Evolution de SSL.

RSA : Rivest Shamir Adleman

Algorithme de cryptage.

IETF : Internet Engineering Task Force

Groupement gérant Internet

HTTP : HyperText Transfer Protocol

Protocole permettant la consultation de pages au format HTML

HTML : HyperText Markup Language

Langage servant à générer des pages web.

FTP : File Transfer Protocol

Protocole permettant la transmission de fichiers.

SSH : Secure SHell

Protocole permettant l’administration à distance des serveurs de manière sécurisée.

MAC : Message Authentification Code

Norme d’interconnexion.

31
HMAC : Hashed Message Authentification Code
Norme d’interconnexion.

CBC : Cipher Block Chaining Mode

Mode de cryptage utilisé pour les fichiers.

PKI : Public Key Infrastructure

Organisme gérant les certificates.

CA : Certificate
Certificat.

D-H : Diffie-Hellman
Inventé en 1976 par Whitfield Diffie et Martin Hellman c'est le plus ancien crypto -
sytème à clé publique.

OSI : Open Systems Interconnexion

Modèle réseau de réference en 7 couches.

TCP : Transfert Control Protocol

Protocole de transport de la suite TCP/IP.

DN : Domain Name
Nom de domaine déposé auprès d’un organisme (registrar).

DNS : Domain Name Service

Service internet faisant correspondre une adresse et un nom.

OCSP : Online Certifica te Status Protocol

Protocole permettant de vérifier la validité des signatures.

32
RFC : Request For Comment
Document officiel de description des normes.
MIME : Multipurpose Internet Mail Extensions
Spécification librement distribuée du monde Internet permettant d’échanger librement
des documents et données entres des langues et systèmes différents.

33
BIBLIOGRAPHIE & WEBOGRAPHIE

[NSC 02] home.netscape.com/eng/ssl3/ssl-toc.html (visité au 01/01/2002) – site

officiel de Netscape

[RSA 02] www.rsasecurity.com (visité au 05/01/2002) – site officiel de RSA

[ESG 02] www.esgi.fr (visité au 05/01/2002 ) – site officiel de l’ESGI

[FRE 02] www.freebsd.org (visité au 03/01/2002 ) – site officiel de FreeBSD

[IET 02] www.ietf.org (visité au 05/01/2002 ) – site officiel de l’IETF

[FRZ 02] www.armadillo.huntsville.al.us (visité au 05/12/2001) – site officiel de

Fortezza

[ALG 02] sw00d.free.fr/crypto/pages (visité au 05/01/2002) – site de référence pour

la cryptographie

[OSI 02] www.opensystemsinc.com (visité au 05/01/2002) – site officiel de

l’organisme Open System Interconnexion

[FOR 02] www.fortify.com (visité au 05/01/2002 ) – site de l’organisme de gestion

des clés 128bits pour les anciennes versions de Netscape Navigator

[HMC 02] andrew2.andrew.cmu.edu/rfc/rfc2104.html (visité au 20/12/2001) - site

hébergeant la rfc2104 HMAC

[SSH 02] www.openssh.com (visité au 02/01/2002) - site officiel de OpenSSH

34
[SSL 02] www.openssl.org (visité au 02/01/2002) - site officiel de OpenSSL

[X509 02] openssl.org (visité au 02/01/2002) www.openssl.org/docs/apps/x509.html

[VER 02] www.verisign.com (visité au 02/01 /2002) - site officiel de VeriSign

[PKI 02] www.securiteinfo.com/crypto/pki.shtml (visité au 02/01/2002) - site

officiel de l’information sur la sécurité français

[MIM 02] wwwchimie.u-strasbg.fr/membres/GB/MIME.html (visité au 02/01/2002)

35