|
Les principes du Secure Socket
Layer (Deuxième partie)
Second volet de notre tutoriel sur le protocole de sécurité sans doute le plus connu: comment fonctionne la négociation ?
Suite de notre article sur l'encodage
SSL, ce deuxième volet s'attarde sur la phase de négociation
SSL. Rappelons que les trois fonctionnalités principales de SSL
sont l'authentification du serveur, l'authentification du client
et le chiffrement des données. Le protocole se compose de deux couches
: le SSL Record Protocol concerne l'encodage (envoi des données)
et le SSL Handshake protocol la négociation (phase qui précède la
validation des données par l'un ou par l'autre), qui nous intéresse
donc à présent.
Parmi les algorithmes de codage, le SSL possède la particularité
de combiner l'utilisation de clefs symétriques et clefs asymétriques.
Les clefs asymétriques sont mieux adaptées à
l'authentification. Le protocole de négociation SSL est en
mesure, à partir des clefs publique et privée du client
et du serveur, d'établir une communication entre les deux
parties avec une clef "secrète" publique, dont
la taille (128 bits) est bien inférieure à celle des
clefs publiques traditionnelles (1024 bits).
Différentes étapes
Détaillons les huit étapes du processus, avec les
messages que s'envoient le client et le serveur qui construisent
la communication sécurisée grâce à SSL.
Les messages échangés entre les deux parties sont
notés en majuscules BLEUES quand
le message est en clair, ROUGES quand
le mesage est chiffré.
1. Le client se connecte au serveur. Il lui envoie le message
CLIENT-HELLO, qui contient entre autres
sa version du protocole SSL et ses paramètres de chiffrement.
2. Le serveur répond au client en envoyant le message
SERVER-HELLO.Il contient également
sa version SSL et ses paramètres de chiffrement, entre autres
informations. Il envoie également son propre certificat et
en demande un au client si nécessaire (message REQUEST-CERTIFICATE).
3. Le client authentifie le serveur grâce aux informations
qu'il vient de recevoir. Cette authentification est la condition
sine qua non de la connexion.
4. Le client envoie le message CLIENT-MASTER-KEY.
Celui-ci contient une pré-clef secrète, chiffrée
avec la clé publique du serveur. S'il lui a été
demandé de fournir un certificat, le client en envoie un
dans un message CLIENT-CERTIFICATE.
5. Le serveur et le client mettent au point chacun de leur
côté une clef secrète à partir de la
pré-clef secrète. De plus, si le serveur a demandé
un certificat au client, il vérifie son identité et
l'authentifie.
6. Le client et le serveur utilisent ensuite cette clef secrète
pour générer des clefs de session. Ces clefs symétriques
(server read key & server write key) seront dorénavent
utilisées pour chiffrer, déchiffrer et authentifier
les données.
7. Le client envoie le message CLIENT-FINISHED
au serveur. De cette manière il le prévient que les
prochains messages seront chiffrés avec les nouvelles clefs.
Il indique également qu'il est satisfait du serveur et que
la phase de négociation est terminée.
8. Le serveur, lui aussi satisfait du handshake du client, répond
par un message SERVER-FINISHED. Il
est prêt à passer au niveau supérieur de chiffrement
proposé par le client. Il indique lui aussi que la phase
de négociation est terminée.
Dans ces échanges, il est également possible d'inclure
des protocoles d'alarmes pour qualifier les messages. Ces protocoles
informent de la sévérité du message et de la
nature de l'alarme. Un message d'alarme de niveau fatal entraîne
la clôture immédiate de la connexion et l'impossibilité
de la rétablir avec les mêmes paramètres.
Il se peut que des bruits viennent empêcher le bon fonctionnement
de la communication entre le client et le serveur. Lorsque l'un
des deux détecte une erreur, il envoie une message pour en
informer l'autre. Comme pour l'alarme fatale, les erreurs dites
irrécupérables entraînent la clôture de
la connexion sans pouvoir la rouvrir avec les mêmes paramètres.
Il existe quatre messages d'erreurs différents:
- NO-CIPHER-ERROR est envoyé au serveur lorsque le
client ne peut pas trouver une clé de chiffrement valable
pour lui et le serveur. Cette erreur est irrécupérable.
- NO-CERTIFICATE-ERROR est envoyé par le client s'il
ne possède pas de certificat. Cette erreur est récupérable.
- BAD-CERTIFICATE-ERROR est envoyé par le destinataire
d'un certificat jugé inadequat. Cette erreur est récupérable.
- UNSUPPORTED-CERTIFICATE-TYPE-ERROR est renvoyé par
le destinataire d'un certificat qu'il ne peut accepter. Cette erreur
est récupérable.
Nous poursuivrons cette série d'articles avec un inventaire
des principales vulnérabilités du protocole SSL.
[Serge Descombes
4 septembre 2002
, JDNet]
|
