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

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

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Mel Beckman
Sécurisez vos transactions électroniques en suivant de près l'évolution des protocoles de sécurité du commerce électronique Lorsque le protocole SSL (Secure Sockets Layer) est arrivé sur le marché il y a 6 ans, les experts y ont vu la solution au problème de sécurité du commerce électronique. Et il est vrai que SSL a beaucoup contribué à  rassurer les internautes utilisant leurs numéros de cartes de crédit pour les achats en ligne, faisant ainsi exploser les ventes grand public sur le Web. SSL remplit bien sa fonction de cryptage des données circulant entre l'acheteur et le vendeur, pour déjouer l'interception par les voleurs des informations contenues sur les cartes de crédit.

Si la sécurité du commerce électronique se limitait à  cela, SSL aurait donc résolu la totalité des problèmes. Mais si la protection des numéros de cartes de crédit et d'autres informations sensibles dans les transactions HTTP est le problème le plus visible, ce n'est que le sommet de l'iceberg. Toutes les composantes d'une transaction de paiement électronique ne passent pas par HTTP. Le vendeur peut utiliser d'autres protocoles (courrier électronique, FTP (File Transfer Protocol), LDAP (Lightweight Directory Access Protocol) par exemple) comme moyen de règlement et pour s'assurer que l'argent aboutit bien dans son compte en banque. Une fois le numéro de carte de crédit reçu par le vendeur, il faut valider le numéro, faire approuver l'achat par l'organisme émetteur de la carte, et débiter l'organisme financier de l'acheteur (figure 1).
L'ensemble du processus de transaction n'a pas de protection standard. Pis encore, une faille du dispositif de sécurité peut intervenir dans l'une des étapes suivant la commande HTTP sans que l'acheteur n'en ait connaissance. Les acheteurs en ligne se croient donc plus en sécurité qu'ils ne le sont réellement.

Heureusement, les standards des protocoles Internet sont en train de changer pour combler ces lacunes en matière de sécurité. Malheureusement, ils ne changent pas assez vite et aucun standard de sécurité à  lui seul ne répond aujourd'hui à  tous les besoins. SSL est en train de devenir un transport multiprotocoles et a été rebaptisé TLS (Transport Layer Security) mais son adaptation au cryptage autre que HTTP pose des problèmes. L'autre principal protocole de sécurité, SET (Secure Electronic Transactions), est très efficace mais tellement lourd à  mettre en oeuvre que peu d'entreprises l'utilisent.

Pour arriver à  une bonne sécurité des transactions, il est important de bien comprendre les avantages et les limites de chaque protocole. De plus, une petite connaissance de l'historique de chaque protocole donne un peu plus d'éclairage et peut aider à  choisir le cryptage le mieux adapté au commerce électronique. Enfin, il est bon de savoir ce que l'AS/400 propose dans ce domaine.

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.

Téléchargez gratuitement cette ressource

Les 7 étapes d’un projet de dématérialisation RH

Les 7 étapes d’un projet de dématérialisation RH

Dans ce livre blanc, nous vous donnons les clés pour concevoir votre projet de dématérialisation RH. Vous découvrirez chacune des étapes qui vous permettront d’apporter de nouveaux services aux collaborateurs, de vous adapter aux nouvelles pratiques et de renforcer la marque employeur.

Tech - Par iTPro.fr - Publié le 24 juin 2010