SSL : negociation SSL
La
négociation dans SSL
Le SSL combine simultanément
l'utilisation de clés publiques et de clés symétriques. Les clés publiques
privées ou clés asymétriques procurent en effet une très bonne méthode pour
l'authentification mais son utilisation est coûteuse en terme de bande passante.
A l'opposé, le mécanisme de clé symétrique (identique pour chiffrer et
déchiffrer) est extrêmement rapide mais pas réellement adapté à
l'authentification d'un tiers. Ainsi SSL va utiliser son protocole de
négociation qui va être apte à partir des clés publiques et privées du client et
du serveur d'établir une communication entre les deux entités avec une clé
secrète (symétrique) de taille nettement inférieure à celle rencontrée pour des
clés publiques (128 bits contre 1024 ou plus).
Mécanisme
1- Le client envoie au serveur sa
version du protocole SSL, ses paramètres de chiffrement, des données générées
aléatoirement et d'autres informations dont le serveur a besoin.
2- Le serveur renvoie sa version de
SSL, ses paramètres de chiffrement, des données générées aléatoirement et
d'autres informations dont le client a besoin. Le serveur envoie également son
propre certificat, et si le client demande une information nécessitant un
certificat, il demande également un certificat client. 3- Le client utilise les informations
envoyées par le serveur pour l'authentifier. Si le serveur ne peut pas être
authentifié, la connexion n'a pas lieu. 4- Avec les données préalablement échangées,
le client est en mesure d'envoyer au serveur une pré clé secrète, qu'il chiffre
avec la clé publique du serveur. Si le serveur a requis une authentification du
client, celui ci (le client) renvoie également au serveur un bloc de données
signé ainsi que son certificat. 5- Si le serveur a requis une
authentification, il authentifie le client. Le serveur utilise alors sa clé
privée de façon à pouvoir déchiffrer la pré clé secrète. Le serveur effectue
alors une suite d'actions (également effectuées par le client) pour obtenir une
clé secrète à partir de la pré clé secrète. 6- Le client et le serveur utilisent la clé
secrète pour générer des clés de session qui seront les clés symétriques
utilisées pour le chiffrement, déchiffrement des données et
l'intégrité. 7- Le
client envoie alors un avertissement au serveur le prévenant que les prochains
messages seront chiffrés avec la clé de session. Puis il envoie un message
chiffré indiquant que la phase de négociation est terminée.
8- Le serveur envoie alors un
avertissement au client comme quoi les prochains messages seront chiffrés avec
la clé de session. Puis il envoie un message (chiffré cette fois) indiquant que
la phase de négociation est terminée. 9-La phase de négociation est alors
terminée.
Authentification
Dans le cas du SSL il est pour le
moment assez rare de rencontrer une authentification du client. En effet, la
plupart des applications utilisées sur Internet ne requièrent pas un tel niveau
de sécurité. De plus, l'authentification du client ressemble très fortement à
une authentification du serveur. L'authentification serveur a lieu comme suit
:
1- Vérification de la date de
validité du certificat du serveur. 2- Est-ce que l'autorité de certification est
une autorité de confiance ? Pour vérifier cela, chaque client maintien une liste
de noms de domaines. Si le nom spéficié (nom émetteur) correspond à un nom
rentré dans la liste, le client passe à l'étape suivante.
3- Vérification de la clé publique
à partir de la signature. Le client vérifie la validité de la signature
(chiffrée avec la clé privée) fournie dans le certificat grâce à la clé publique
qui a été fournie elle aussi dans le certificat. A partir de ce point, le
certificat du serveur est considéré comme valable. 4-Vérification du nom de domaine du serveur.
Cette étape permet de vérifier que le nom de domaine du serveur défini dans le
certificat correspond bien à la même adresse Internet. Cette étape n'est pas
obligatoire et dépend de l'implémentation du client SSL. Elle permet cependant
d'éviter qu'un usurpateur vienne jouer les intermédiaires entre le client et le
serveur et se fasse passer pour l'un et l'autre auprès des deux entités.
Vérifier la validité du nom de domaine est le seul moyen d'éviter ce genre de
faille qui permet, dans ce cas, à la personne malveillante d'intercepter les
informations transitant pendant la négociation et donc ultérieurement de prendre
la place du client une fois cette phase passée. Pour usurper l’identité du
serveur, le pirate devra également se procurer la clé privée du
serveur. 5- Le
serveur est maintenant authentifié, la phase de négociation se
poursuit.
|