logo

Knowledge Is Power

 
 

- Reinit des nouveaux posts -

- Recherche -

Messages Privés - Derniers posts
S'enregistrer - Login - Liste des membres
Vous logger : Login Pass

Comment ça marche ? >> Tout sur le Protocole SSL... Newtopic | Reply
poster txt
hyatus
Inscrit le 25-08-2001
Avatar
Posté le 30-11-2001 22:47

Trésssssss instructif mais d'un niveau assez compliqué

Ici c'est trés bien expliqué alors ne vous privez pas !

http://www.esigge.ch/reche98/protoSSL/SSL.htm

Bien Amicalement,
_________________________
Car la liberte n'est pas un Droit mais un Devoir, et que le savoir apporte la Liberte,alors la TAZ est ce qu'elle est, le reflet de la societe qui nait de ce qu'elle sait... ( hyatus copyleft )
profil | mail | Website | edit | quote
japi
Inscrit le 24-08-2001
Avatar
Posté le 30-11-2001 23:51

Très interessant en effet.
_________________________
Modérateur
profil | ICQ | edit | quote
Punisher
Inscrit le 04-08-2009
Posté le 30-08-2009 16:17

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







Introduction

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.



Processus

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.



Fonctionnement

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.



Démonstration par l’exemple

(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.



Certificats

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.



Certificat pour client

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.


Sources & divers liens pouvant vous intéresser :

Université de Genève (en Français)
http://cuisung.unige.ch/TechInternet/Securite/SSL.html

Netscape (en Anglais)
http://help.netscape.com/products/server/enterprise/3x/manual/encrypt.htm

Ecole Polytechnique Fédérale de Lausanne (en Français)
http://www.epfl.ch/SIC/SA/publications/FI95/fi-7-95/7-95-page3.html

Mersch Online Research (en Allemand)
http://www.mersch.com/research/xchange/ssl.htm



dernière mise à jour: 22 mai 1998

Baitan - Berger - Maia

bY PUN!SHER
profil | edit | quote
jehv
Inscrit le 29-08-2006
Posté le 30-08-2009 19:28

8 ans putain fallait le faire , t'etait saoul ou quoi.
_________________________
it's all about life
profil | edit | quote
Punisher
Inscrit le 04-08-2009
Posté le 31-08-2009 00:42

Nan mais jme suis dit que comme le lien sa donne rien que j'allé justement faire partager le contenu du lien mort après récup: SSL toujour d'actualité pi pour la nostalgie
profil | edit | quote
Newtopic | Reply

Online : Anthonypaino, aqifozi, Chriscor, Josephvob, Kvwcftousy, LorenHop, LsbdxfVussy, Michaelexcat, MiguIdeomy, Thomasdiz et 82 Guests


Retour Index NewFFR Repository : http://taz.newffr.com
Cagades à Stick : http://alcane.newffr.com
Forum HTML et Archive -> ici
ForumFR Sql/Xml (2006/04) (SF pas à jour du tout...) - Alive since 2001 Newffr.com
Pour toute plainte ou problème -> Contacter Borax, Hyatus, Tweakie ou Stick par message privé (ou Gueulez sur le forum :) )
Retour haut de page