Protocoles de sécurité : un état des lieux

Ni SSL ni SET n’ont atteint la perfection par enchantement. Des organismes privés
ont conçu les deux protocoles et les ont proposés à  l’usage public sans droits
de licence. Mais les protocoles avaient également des objectifs initiaux modestes
qui se sont bien étendus depuis.

TLS et SET donnent tous deux satisfaction quand on les utilise dans l’esprit
de leurs concepteurs

Protocole SSL (Secure Sockets Layer)
En 1993, Netscape Communications a conçu et mis en oeuvre SSL. La version 1.0 n’existait
que sur papier. C’est en 1994 que Netscape a livré la première mouture à  grande
diffusion, basée sur la version 2.0 du protocole. SSL a tout de suite rempli sa
mission, cryptant les sessions entre un navigateur Web d’un acheteur et le serveur
Web d’un vendeur. Après quelques années d’expérience, Netscape a lancé la version
3.0 en 1996, qui corrigeait quelques failles de sécurité théoriques et améliorait
les performances.

Comme son nom l’indique, SSL est destiné à  travailler au niveau du socket (ce
qui se situe au niveau de la demande de connexion entre un et un serveur). Généralement,
le client (au sens client/serveur du terme) est le navigateur HTML du client (au
sens acheteur du terme), et le serveur est un serveur HTTP du vendeur. Au moyen
de certificats digitaux publics (le processus d’authentification qui utilise le
cryptage à  clé publique pour vérifier l’identité d’un serveur), SSL authentifie
le vendeur auprès de l’acheteur. De son côté, le vendeur doit authentifier l’acheteur
par d’autres moyens si c’est nécessaire, comme la validation de la carte de crédit
(cette étape ne fait pas partie du protocole SSL). A défaut, on suppose que le
client est anonyme (figure 2). Pour une description détaillée de SSL et des certificats
digitaux, voir l’article  » Une introduction à  SSL « , NEWSMAGAZINE, décembre 1997.

Le serveur détermine ce que SSL doit protéger dans la transaction, et seule une
partie de la transaction est cryptée. Généralement, le serveur crypte au moins
le numéro de la carte de crédit, le nom du possesseur et la date d’expiration,
en veillant à  ce qu’aucune oreille indiscrète ne puisse voler ces informations
pendant l’échange.

L’AS/400 accepte SSL version 3.0 quel que soit le serveur Web installé. L’OS/400
offre gratuitement tout ce qui est nécessaire pour SSL sur HTTP, même s’il n’est
pas si simple de rendre SSL opérationnel. Pour une explication plus détaillée
sur la mise en place de SSL sur AS/400, voir les articles  » Création et mise en
service d’un site Web AS/400 « , NEWSMAGAZINE, juin 1999 et  » Configurer les serveurs
TCP/IP de l’AS/400 pour SSL « , NEWSMAGAZINE, janvier 2000.

En 1999, Netscape a remis SSL à  l’IETF (Internet Engineering Task Force) afin
qu’il puisse devenir un standard public. L’IETF a quelque peu modifié SSL et l’a
rebaptisé Transport Layer Security. La RFC (Request For Comments) correspondante,
qui est un document de normalisation, est la RFC 2246 (www.rfc.net). Dans cet
article, nous ne de SSL que sous le nom de TLS.

Protocole SET (Secure Electronic Transactions)
En 1995, deux grandes sociétés de cartes de crédit, Visa et Mastercard, en collaboration
avec plusieurs éditeurs de logiciels, ont développé SET. Le but était de limiter
la fraude à  la carte de crédit dans toutes les transactions électroniques, tant
sur le Web que sur un autre support. Contrairement à  TLS, capable de crypter des
données entre un client et un serveur, SET ne protège que la transaction de paiement
proprement dite. De même, contrairement à  TLS, SET protège le paiement jusqu’à 
son arrivée à  la banque, en surveillant de près la fraude à  la carte de crédit
à  plusieurs niveaux.

SET repose sur l’idée d’un porte-monnaie électronique détenu par le client. Ce
porte-monnaie contient des informations d’authentification sous la forme d’un
certificat digital et d’un numéro de carte de crédit. Tous deux sont cryptés et
signés numériquement pour empêcher qu’on ne puisse subrepticement les divulguer
ou les altérer. Une transaction SET implique trois intervenants : l’acheteur,
le vendeur et la banque (figure 3). Une fois que l’acheteur et le vendeur se sont
mutuellement authentifiés, l’acheteur transmet sa commande au vendeur en y incluant
le numéro de sa carte de crédit crypté au moyen de la clé publique de la banque.
Le vendeur retransmet le certificat digital et le numéro de carte de crédit crypté
de l’acheteur à  la banque, laquelle autorise ou refuse le paiement.

Le cryptage garantit qu’aucun intrus n’intercepte les détails du paiement pour
s’en servir frauduleusement plus tard. Le vendeur ne voit jamais le numéro de
carte de crédit de son client, ce qui élimine l’une des sources les plus courantes
de transactions frauduleuses : la malhonnêteté du commerçant ou d’un des ses employés.
Pour une description détaillée de SET, voir le Redbook SG24-4978 : Secure Electronic
Transactions: Credit Card Payment on the Web in Theory and Practice.

TLS et SET donnent tous deux satisfaction quand on les utilise dans l’esprit de
leurs concepteurs. Malheureusement, une grande partie du commerce électronique
sur Internet ne peut pas utiliser l’un ou l’autre de ces protocoles en respectant
strictement l’intention des concepteurs. Voyons de plus près les problèmes de
chacun d’eux et avançons quelques solutions possibles.