SSL Présentation Technique

Toni SOUEID
Jacques SEIF
© 2002

Plan
1 – Historique ..................................................................................................................2
2 – Architecture ...............................................................................................................2
3 – Fonctionnement de SSL.............................................................................................3
3.1 – Services assurés ..................................................................................................3
3.2 – Les sous-protocoles de SSL................................................................................4
3.2.1 – Le protocole Handshake ..............................................................................4
3.2.1.1 – Authentification du serveur ...............................................................5
3.2.1.2 – Etablissement d’un canal sécurisé .....................................................6
3.2.2 – Le protocole ChangeCipherSpec .................................................................7
3.2.3 – Le protocole Record ....................................................................................8
3.2.4 – Le protocole Alert........................................................................................8
Le protocole SSL est le champion incontesté de l’authentification des sites WEB et du
chiffrage des données transactionnelles sur Internet. Des informations telles que les
numéros de cartes de crédit et les commandes en ligne sont sécurisées via SSL sur des
centaines de milliers de serveurs autour du globe chaque jour. En tant que un des
premiers et le plus répandu protocole de sécurisation des échanges, SSL est supporté
par pratiquement tous les serveurs et navigateurs WEB.

1 – Historique

Le besoin d’éliminer l’écoute sur le réseau par les parties non autorisées et d’empêcher
la contrefaçon de voler les informations des utilisateurs a conduit au développement
d’un standard permettant la transmission sécurisée des données via les navigateurs
WEB.
Netscape Communications est la compagnie qui a conçu le protocole SSL, le premier
protocole de sécurisation des communications via des navigateurs WEB.
Le protocole décrit une méthode d’authentification et de chiffrement des données entre
clients et serveurs. La technologie sous-jacente est basée sur les principes de la
cryptographie par clés publiques et par clés secrètes.
La première version du protocole a été publiée durant l’été de 1994 et intégrée dans le
navigateur Mosaic. La seconde version du protocole a été ensuite intégrée dans le
fameux navigateur Netscape Navigator fin 1994.
En hiver 1995 Netscape publia une nouvelle version du protocole (SSL v3.0) visant à
supprimer les faiblesses de la version antérieure.
En mai 1996 l’Internet Engineering Task Force (IETF) accepta d’en faire de SSL un
standard universel. Effectivement en janvier 1999, SSL fut renommé Transport Layer
Security (TLS) par l’IETF. En effet TLS v1.0 n’est qu’une extension de SSL v3.0.
De nos jours, la plupart des navigateurs WEB supportent le protocole. Ainsi SSL est
utilisée dans virtuellement toutes les transactions sur Internet des achats de livres aux
transferts de fonds.

2 – Architecture

Le protocole SSL permet de sécuriser tous types d’échanges entre clients et serveurs.
Il est une couche optionnelle se situant entre les couches d’application et de transport.
Le but de SSL est d’être un protocole de sécurité facile à déployer assurant une sécurité
totale des échanges de plusieurs applications.
Dans la pile protocolaire TCP/IP, SSL se situe entre les protocoles d’application et le
protocole TCP. En insérant SSL entre TCP est la couche d’application on évite des
changements significatifs aux protocoles existants tels que HTTP, FTP …
Ainsi le protocole d’application s’interface avec SSL de la même façon dont il s’interface
avec TCP. Pour TCP, SSL n’est qu’une application qui utilise ses services.

La figure ci-dessous illustre ce concept.

3 – Fonctionnement de SSL

3.1 – Services assurés

L’objectif de SSL est de vérifier l’identité des parties impliquées dans une transaction
sécurisée et de s’assurer que les données échangées sont protégées de toute
interception ou modification.
Les principales fonctions assurées par SSL sont décrites ci-dessous.

Ø Authentification : dans SSL v3.0 l’authentification du serveur est obligatoire.

Elle a lieu à l’ouverture de la session. Elle emploie pour cela des certificats
conformes à la recommandation X.509 v3. Cela permet au client de s’assurer de
l’identité du serveur avant tout échange de données. Dans la version actuelle de
SSL l’authentification du client reste facultative.

Ø Confidentialité : Elle est assurée par des algorithmes de chiffrement

symétriques. Bien que le même algorithme soit utilisé par les deux parties
chacune possède sa propre clé secrète qu’elle partage avec l’autre. Les
algorithmes utilisés sont : le DES, le 3DES, le RC2, le RC4 …

Ø Intégrité : Elle est assurée par l’application d’un algorithme de hachage aux
données (SHA ou MD5) transmises. L’algorithme génère à partir des données et
d’une clé secrète appelée code d’authentification de message, une suite de bits.
 Cette suite sert de signature pour les données. Ainsi tout changement appliqué
aux données implique un changement de la suite de bits générée par
l’algorithme de hachage et en conséquence provoquera la génération d’un
message d’erreur côté récepteur du fait que les deux suites sont différentes.

3.2 – Les sous-protocoles de SSL

SSL est composé de quatre sous-protocoles : Handshake, Record, ChangeCipherSpec

et Alert. Ces sous protocoles assurent les fonctions décrites dans le paragraphe
précédent.

Ø Handshake assure l’authentification des parties et la négociation des algorithmes

de chiffrement et de hachage.

Ø Record assure la protection des données des applications et des messages des
autres sous protocoles, en mettant en œuvre les paramètres de sécurité
négociés durant la phase de Handshake.

Ø ChangeCipherSpec a pour rôle de signaler à la couche Record toute modification

de paramètres.

Ø Alert a pour fonction de signaler les erreurs survenant dans les messages.

La figure ci-dessous illustre l’agencement de ces différentes sous-couches.

3.2.1 – Le protocole Handshake

Le SSL Handshake est un processus permettant au client et au serveur de s’authentifier
et de négocier les services de chiffrement. L’authentification du serveur permet au client
de s’assurer de l’identité du serveur avec lequel un échange d’informations
confidentielles aura lieu. Une fois le serveur authentifié un canal de transmission
sécurisé sera établi.

3.2.1.1 – Authentification du serveur

La première fonction de sécurité de SSL est de vérifier l’identité du serveur pour

s’assurer que les données confidentielles sont envoyées à la partie appropriée.
Le client commence la communication avec le serveur en envoyant le message
ClientHello contenant : la version de SSL supportée, un nombre aléatoire client_random
permettant de générer les clés secrètes, les suites de chiffrements choisies et les
méthodes de compression.
Le serveur répond en envoyant un message ServerHello contenant des données
similaires au message envoyé par le client : version retenue du protocole SSL,
identificateur de session, suites de chiffrement et de compression retenues par le
serveur parmi les choix suggérés par le client et un nombre aléatoire server_random.
Le serveur envoie ensuite son certificat X.509 par le biais du message Certificate. Le
certificat contient le nom du serveur, le nom de l’autorité de certification, la clé publique
du serveur et un condensât de ces données scellé par la clé privée de l’autorité de
certification. Le client peut ainsi procéder à la vérification de l’identité du serveur.
Le certificat fourni par le serveur devra alors passer avec succès une série de tests pour
que le client considère le serveur comme authentifié.
En premier le client s’assure que le certificat n’a pas expiré. Ensuite le client s’assure
que l’autorité de certification qui a publié ce certificat est sur la liste des autorités dans
lesquelles il a confiance. Durant la troisième étape le client vérifie la validité du certificat
en utilisant la clé publique de l’autorité de certification pour déchiffrer le condensât inclus
dans le certificat et le comparer à un condensât généré en interne.
Enfin le client vérifie que le nom du domaine du serveur présent dans le certificat est
identique au nom du domaine du serveur avec lequel on communique. Cette dernière
étape permet d’éviter les attaques du type « homme au milieu », situation dans laquelle
un intrus se positionne comme intermédiaire entre le client et le serveur pour intercepter
les données confidentielles qui transitent.
La figure ci-après illustre la procédure d’authentification du serveur par le client.
3.2.1.2 – Etablissement d’un canal sécurisé

Après l’authentification du serveur le client entame une procédure d’établissement d’un

canal sécurisé par le biais du message ClientKeyExchange. Le client génère le
paramètre PreMasterSecret, le chiffre avec la clé publique du serveur et le lui envoie.
Ainsi seul le serveur est en mesure de récupéré ce paramètre.
Aussitôt, les paramètres PreMasterSecret, client_random et server_random permettent
au client et au serveur de générer les secrets de la session ou de la connexion.
En premier un paramètre appelé MasterSecret est généré à partir de ces trois
paramètres comme le montre la figure ci-après.
Ensuite le MasterSecret, le client_random et le server_random sont utilisés pour calculer
les clés de chiffrement (client_write_secret et server_write_secret), les clés de hachage
(client_MAC_write_secret et server_MAC_write_secret) et les vecteurs d’initialisation
conformément à la figure ci-après.

La procédure est schématisée par la figure ci-dessous.

3.2.2 – Le protocole ChangeCipherSpec

Jusqu’à maintenant le travail était effectué par le sous-protocole Handshake. Juste

après cela le sous-protocole ChangeCipherSpec entre en action. Le client et le serveur
envoient alors le message ChangeCipherSpec pour indiquer l’un à l’autre l’entrée en
vigueur des nouveaux paramètres de chiffrement négociés.
Ainsi la couche Record côté récepteur modifie ses paramètres pour pouvoir déchiffrer
les données émises par la couche Record côté émetteur.
Après cela les couches Handshake du client et du serveur procèdent à émettre le
message Finished qui constitue un condensât de tous les messages déjà envoyés et
cela pour déjouer certaines attaques de subtilisation.

3.2.3 – Le protocole Record

Le protocole Record ne commence son intervention qu’après émission du message

ChangeCipherSpec.
Lors de la transmission de données le protocole se charge alors d’effectuer les tâches
suivantes :

Ø Fragmentation des données en des blocs dont la taille maximale est de 214
octets.
Ø Compression de ces données, bien que cette fonctionnalité n’est pas
implémentée actuellement.
Ø Génération d’un condensât des données pour assurer l’intégrité.
Ø Chiffrement des données pour assurer la confidentialité.

Un entête est ajouté indiquant l’origine du message (Handshake, Alert, CSS, HTTP …)
la version SSL et la longueur des données encapsulées.
Côté récepteur l’inverse est effectué : déchiffrement, vérification de l’intégrité,
décompression et réassemblage des données.

3.2.4 – Le protocole Alert

Ce sous-protocole sert à générer des messages suite à toute erreur dans les messages
reçus et d’indiquer tout changement d’état.
Ces messages peuvent constituer des simples avertissements ou au contraire signaler
des erreurs fatales et cela selon la gravité de la situation.
Une erreur fatale provoque la fermeture immédiate de la session.
Cela révèle une faiblesse du protocole SSL qui est la fragilité aux attaques de type
« déni de service » mais le chiffrement des messages de la couche Alert par la couche
Record confère une certaine robustesse au protocole.
Un exemple de message fatal généré par le sous-protocole Alert est le message
bad_certificate que le client émet lorsqu’il n’arrive pas à vérifier l’identité du serveur.