Sous-sections
Protocoles sécurisés. OpenSSL.
SSL utilise les fonctionnalités
offertes par TCP/IP pour
permettre aux couches
supérieures d'accéder à un mode
d'accès sécurisé. Les protocoles utilisant le plus
couramment ce mode, sont bien sûr HTTP mais
aussi LDAP, SMTP, NNTP ou encore IMAP, etc.
Les trois fonctionnalités de SSL sont :
|
___________________________________________________________________ |
|
Authentification du serveur |
Cela permet à un utilisateur d'avoir une confirmation de l'identité d'un serveur.
En effet un programme client SSL utilise des méthodes de chiffrement à clé publique pour vérifier si le
certificat et l'identité publique fournis par le serveur sont valides et ont été fournis par un fournisseur
de certificat présent dans la liste de ceux connus du client. Cette fonctionnalité est importante dans la mesure
où le client doit envoyer des données confidentielles comme son numéro de carte bleue.
|
___________________________________________________________________ |
|
Authentification du client |
La technique est ici exactement la même que pour l'authentification du serveur.
Cela peut servir si le serveur envoie des informations importantes à un client, qui doit, dans ce cas être authentifier.
|
___________________________________________________________________ |
|
Chiffrement des données |
Toutes les données issues de l'entité émettrice sont chiffrées et déchiffrées par
l'entité réceptrice, ce qui permet de garantir la confidentialité des données. Un mécanisme permet également de
garantir l'intégrité des données.
|
___________________________________________________________________ |
|
Le protocole SSL peut être divisé en 2 sous protocoles |
L'encodage (record) et la négociation (handshake).
Le premier définit tout ce qui touche à l'envoi des données. Le second est utilisé pendant toute la phase de
négociation entre le client et le serveur jusqu'à ce que tous les paramètres soient validés par l'un et l'autre.
SSL est capable d'utiliser différents mécanismes de chiffrement créés pour
l'authentification, l'envoi de certificats ou l'établissement des clés. Le
choix des mécanismes de sécurité mis en oeuvre dépend de plusieurs
paramètres : la politique de sécurité de l'entreprise possédant le serveur,
la version du protocole SSL ou encore les lois gouvernementales. Le but du
sous-protocole de négociation est en outre d'obtenir un accord entre le
client et le serveur pour le chiffrement utilisé.
Lors de la phase de négociation, le client et le serveur vont se mettre
d'accord sur le meilleur algorithme de chiffrement utilisable entre les
parties. La table ci-dessous rend compte des différents algorithmes pouvant
être utilisés :
- 3DES
- qui supporte un chiffrement à 168 bits couplé avec SHA-1 pour l'intégrité. Ce mécanisme n'est
autorisé qu'à l'intérieur des USA et est approprié aux banques car 3DES est nettement moins rapide que
RC4 (Supporté par SSL 2.0 et 3.0).
Ce chiffrement est suffisamment fort pour garantir la
plupart des transactions électroniques
- RC4
- avec un chiffrement 128 bits couplé à MD5 pour l'intégrité. RC4 est le plus rapide des modes
de chiffrement offert. Supporté par SSL 2.0 et 3.0.
- RC2
- avec un chiffrement 128 bits couplé à MD5 pour l'intégrité. RC2 est plus lent que RC4 et n'est
plus supporté que par SSL 2.0.
- DES
- qui permet un chiffrement sur 56 bits couplé avec SHA-1. Ce chiffrement reste moins performant
que RC4 ou RC2. Il est supporté par SSl 2.0 et 3.0 à la différence que SSL 2.0 utilise MD5 pour authentifier les messages.
C'est le chiffrement qui procure la plus haute sécurité pour une exportation internationale
- RC4
- avec un chiffrement 40 bits et MD5. Supporté par SSL 2.0 et 3.0
- RC2
- avec un chiffrement 40 bits et MD5. Supporté par SSL 2.0 et 3.0
Ce mécanisme garantit l'intégrité des données, mais les
données qui circulent ne sont pas chiffrées.
- MD5
- Authentification des messages avec MD5 sans chiffrement. Cette méthode permet seulement de
garantir l'intégrité des données échangées. Elle est typiquement utilisée dans le cas où le serveur
et le client n'ont aucun chiffrement en commun.
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 :
[pic]
- 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écifié (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.
|
