Le protocole SSL
(Secure Socket Layer)
Baitan - Berger - Maia
Introduction - Processus - Fonctionnement
Démonstration par l'exemple - Certificats - Certificats pour client
SSL et les logiciels de communications - Sources et liens
Aujourd'hui la solution la plus répandue pour sécuriser les transactions est SSL (Secure Socket Layer, créé par Netscape).
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 Netscape une petite clé, qui devient automatiquement entière si le serveur qui vous envoit les informations utilise SSL.
SSL (Secure Socket Layer) est un protocole de communication d'information qui permet d'assurer l'authentification, la confidentialité et l'intégrité des données échangées.
Ce protocole utilise un moyen de cryptographie reconnu : l'algorithme à clé publique RSA (du nom de ses concepteurs - Rivest - Shamir - Adleman - ). Une clé RSA est le résultat d'opérations entre nombres premiers.
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.
Dans un tel 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 grugerait une partie des ventes des marchands.
Les transactions commerciales qui s'effectuent sur Internet sont généralement ponctuelles. C'est-à-dire qu'elle 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.
Le browser Navigator de la compagnie Netscape Communications Corporation utilise l'implantation du protocole SSL. Ce protocole effectue la gestion des clés et l'authentification du serveur avant que les informations ne soient échangées.
Le processus est le suivant :
Un utilisateur quelconque utilise le logiciel Netscape client et entre en communication avec un logiciel serveur de type commercial. Le serveur possède déjà sa paire de clés publique/privée. C'est cette paire de clés qu'il utilise dans ses communication avec tous les logiciels clients.
Le logiciel client, une fois reconnu par le logiciel serveur, génère une paire de clés publique/privée.
Le logiciel client demande au logiciel serveur de lui fournir sa clé publique (celle du serveur).
La clé publique du client est aussitôt encryptée avec la clé publique de serveur et transmise au serveur.
Le serveur décode le message avec sa clé privée serveur et authentifie la clé publique de l'utilisateur.
Le serveur envoie ensuite au logiciel client une confirmation, encryptée, du bon déroulement de l'opération.
Toutes les informations suivantes qui seront transmises entre l'utilisateur et le serveur commercial seront désormais encryptées. De plus, il n'y a que ce serveur qui est en mesure de communiquer avec cet utilisateur puisqu'il n'y a que ce serveur qui connaît la clé publique de cet utilisateur. L'utilisateur et le serveur commercial peuvent maintenant échanger toutes les données voulues de façon sûre.
L'ensemble de ce processus est maintenant complètement transparent pour l'utilisateur.
Avec ce protocole, une nouvelle paire de clés est générée à chaque établissement de la communication entre le logiciel client de l'utilisateur et le logiciel serveur. La communication est donc entièrement sûre, mais en aucun cas le serveur commercial ne peut s'assurer de l'identité de l'utilisateur à l'autre extrémité.
Une façon de résoudre ce problème, est de joindre à ce processus un système de validation, comme par exemple un numéro d'identification personnel (NIP) qui s'obtient par une inscription préalable.
Le système repose sur l'algorithme RSA (Rivest, Shamir et Adleman, les trois concepteurs comme indiqué plus haut), un standard utilisé pour le cryptage des données et la signature de messages électroniques. Cet algorithme est très utilisé pour l'authentification et le cryptage des données dans le domaine informatique.
Deux paires de clés - une pour le verrouillage et l'autre pour le déverrouillage - à 40 bits sont utilisées.
Chaque paire est composée d'une clé publique et d'une privée. La clé publique est faite afin d'être distribuée alors que la clé privée n'est jamais distribuée, elle est toujours gardée secrète. Les données qui sont cryptée avec la clé publique peuvent seulement être décryptées avec la clé privée. Et inversement, les données qui sont cryptée avec la clé privée peuvent seulement être décryptées avec la clé publique. C'est cette asymétrie qui fait que la clé publique est si utile.
(L’exemple ci-dessous provient du site Netscape)
L'authentification est la procédure de vérification d'identité, pour que chacun soit sûr que l'autre soit bien celui qu'il prétend être. Dans l'exemple suivant la notation {SOMETHING} KEY signifie que {SOMETHING} a été crypté ou décrypté en utilisant une clé KEY.
Imaginons que Alice (A) désire authentifier Bob (B). B a une paire de clés, une publique et une privée. Il révèle à A sa clé publique. A génère un message aléatoire et l'envoie à B :
Aà B RANDOM-MESSAGE
Bob utilise sa clé privée pour crypter le message reçu et le retourne à Alice :
Bà A {RANDOM-MESSAGE} BOB'S-PRIVATE-KEY
Alice reçoit le message et le décrypte en utilisant la clé publique révélée précédemment. Elle compare le message décrypté avec l'original qu'elle a envoyé à Bob ; s'ils correspondent, elle sait qu'elle est entrain de parler à Bob. Un imposteur n'aurait pas pu connaître la clé privée de Bob et par conséquent serait incapable de crypter correctement le message envoyé à Alice pour validation.
Une fois qu'Alice a authentifié Bob, elle peut alors lui envoyer des messages que seul Bob peut décoder.
Aà B {SECRET} BOB'S-PUBLIC-KEY
Seule la clé privée de Bob est capable de décoder le message. Et par conséquent, même si quelqu'un d'autre est entrain d'observer la communication entre Alice et Bob, il ne peut pas déchiffrer ce message.
NB: Il est a savoir que Alice et Bob sont des prénoms utilisés dans presque tous les livres traitant de la cryptologie.
Un certificat est un document électronique qui atteste qu'une clé publique est bien liée à une organisation ou personne. Il permet la vérification de la propriété d'une clé publique pour prévenir la contrefaçon de clés publiques. Un certificat contient généralement une clé publique, un nom ainsi que d'autre champs pour identifier le propriétaire, une date d'expiration, un numéro de série, le nom de l'organisation qui contresigne le certificat et la signature elle-même. Le format des certificats est définie par la norme X509.
Le certificat est donc une attestation que les informations qu'il contient sont exactes. Pour cela, le certificat doit être généré par un tiers de confiance, c'est-à-dire un organisme indépendant qui contrôle la véracité de ces informations. Le CA (Certifying Authority, autrement dit l'organisme certificateur) donne la crédibilité au certificat.
Il existe typiquement deux types de certificats utilisés avec SSL : pour serveur et pour client. Techniquement ils utilisent le même format mais diffèrent par l'information qu'ils contiennent. Ainsi un certificat coté client sert à identifier un utilisateur, il contiendra donc des information sur cet utilisateur. Coté serveur, le certificat a pour but d'authentifier le serveur et l'organisme qui l'exploite. C'est ce type de certificat dont vous avez besoin pour mettre en place un serveur "sécurisé" HTTPS. Il ne sera pas expliqué ici comment obtenir un certificat serveur. Il existe plusieurs fournisseurs de certificats serveurs SSL. Pour plus d'informations sur ce sujet, consulter le site de Netscape et celui de SSL hosting.
Un certificat client est un certificat qui identifie l'utilisateur d'un navigateur web, et qui a vocation à identifier avec certitude un unique individu. Ce certificat est basé sur une clé publique/privée qui est stockée par le navigateur (à l'avenir, cette clé sera probablement sur carte à puce). De la même façon qu'un certificat pour serveur n'a pas de sens tant qu'il n'est pas authentifié par un tiers, le certificat client à besoin d'être signé.
On peut différencier deux types de certificats suivant leurs signatures: les certificats signés par un serveur ou un organisme local (par exemple l'entreprise qui exploite un serveur SSL) et les certificats signés par un tiers certificateur reconnu de tous.
Les certificats signés par un organisme local prennent tout leur sens dans la cadre d'un intranet/extranet. Ainsi certaines entreprises au lieu de donner des couples username/password à leurs employés leur font générer une clé SSL qu'ils vont ensuite signer.
Il suffira alors d'indiquer au serveur de n'accepter les connexions SSL que de possesseurs de certificats signés par l'entreprise. On peut bien sur aller plus loin et utiliser les champs que contiennent les certificats pour créer des ACLs, et autoriser l'accès à des zones spécifiques du serveur en fonction de l'appartenance à tel ou tel service, par exemple.
Ces certificats signés par une entité locale ont leurs limites dès qu'il s'agit de travailler avec des clients d'origines différentes. Ainsi un consommateur qui utilise des banques et des centres commerciaux SSL se retrouve rapidement avec des dizaines de certificats différents, fournis par chacun des serveurs. Aussi les certificats signés localement ne conviennent pas au grand public.
La solution est que chaque individu souhaitant s'identifier sur plusieurs serveurs utilise un certificat signé par un tiers de certification. Ce dernier aura effectué toutes les vérifications nécessaires pour prouver que le certificat est authentique (qu'il identifie bien la bonne personne). L'individu fournira alors aux serveurs qu'il veut utiliser son certificat personnel signé par le tiers. Le serveur utilisera alors ce certificat pour assurer la sécurité (l'affectera dans les ACLs qui conviennent). L'utilisateur n'aura à stocker qu'un seul certificat (le sien, qui est en quelque sorte sa signature électronique) et n'aura à retenir qu'un seul mot de passe, celui qui protège son certificat.
Ce système simplifie la vie de l'utilisateur, mais aussi de l'administrateur des serveurs. En effet, même si à l'échelle d'une entreprise il est simple d'attribuer avec certitude un certificat à la bonne personne, ce n'est plus le cas pour un magasin virtuel. Comment être sûr à distance que l'on signe le certificat de son client (que l'on n'a jamais vu)?
Ce problème d'attribution des certificats signés se pose dès lors que les acteurs ne sont pas locaux et ne se connaissent pas. Il est donc nécessaire d'utiliser un tiers certificateur. Il existe d'ores et déjà plusieurs tiers qui fournissent des certificats SSL clients, dont Thawte.
SSL et les logiciels de communications
SSL est un protocole de communication qui est indépendant du protocole de communication de plus haut niveau qui repose sur lui. Il est donc possible de porter les logiciels de communications usuels (ftp, telnet, http, etc.) sur SSL sans grande modification, et de façon quasiment transparente pour l'utilisateur. SSL peut alors négocier la méthode de chiffrement à utiliser, authentifier les acteurs de la communication, et chiffrer au vol tout ce qui transite par son canal.
Les spécifications de SSL sont publiques, mais son implémentation de référence (SSLREF) n'est pas exportable des USA. Heureusement, il en existe une implémentation librement accessible à partir de l'Australie. Il existe des patchs pour intégrer SSL aux logiciels de communications usuels: http (Mosaic et NCSA httpd), telnet, ftp, etc.
dernière mise à jour: 22 mai 1998