SSL (pour Secure Socket Layer) est un protocole d'échange sécurisé sur Internet établi initialement par Netscape en 1994. De nouvelles versions ont ensuite été implémentées pour pallier aux quelques failles du protocole (SSL 2.0 en 1994 et SSL 3.0 en 1995). Depuis le rachat du brevet par IETF (Internet Engineering Task Force) en 2001, une nouvelle version du protocole SSL a vu le jour sous le nom de TLS (Transport Layer Security). Elle apporte uniquement quelques évolutions mineures en réponse aux dernières failles de sécurité détectées dans la version 3 de SSL. Cela étant, beaucoup considèrent le TLS comme la version 3.1 de SSL ce qui est tout à fait légitime.

Positionnement du protocole SSL dans le modèle TCP/IP

Dans la pile de protocoles TCP/IP, le protocole SSL s'intercale entre les couches "application" et "transport" permettant ainsi de sécuriser n'importe quel protocole utilisant TCP/IP (SMTP, POP3, HTTP, FTP, NNTP, SSH...), de manière totalement transparente.

HTTPS est un des exemples les plus parlants d'application du protocole SSL. Il s'agit de la combinaison HTTP et SSL qui a permis aux sites de E-commerce d'assurer la sécurité des paiements en ligne. Aujourd'hui, le protocole HTTPS est supporté par la plupart des navigateurs (sites en https:// signalés par un cadenas) et est considéré comme inviolable.

Utilité du protocole SSL

Le protocole SSL permet d'assurer les services de sécurité suivants :

• Authentification du serveur (et optionnellement du client) basé sur les certificats X.509. Ces certificats sont validés par des entreprises externes, les « Autorités de Certifications », dont le navigateur a connaissance. Concrètement, cela permet au client de prendre connaissance de l'originalité du site sur lequel il se trouve.
• Confidentialité : les données échangées entre le client et le serveur sont cryptées selon un chiffrement symétrique dont la clé est transmise par un chiffrement asymétrique (comme RSA ou Diffie-Hellman). Lors de l'établissement de la connexion, serveur et client se mettent d'accord sur l'algorithme de cryptage qui sera utilisé et s'échangent leur clé de chiffrement. On a ainsi la certitude que les données transmises ne pourront pas être interceptées par un tiers.
• Intégrité des données: assurée par l'utilisation de MAC (Message Authentification Code) basés sur les fonctions de hachages comme le MD5 ou le SHA-1. Cela permet d'éviter toute altération des données lors du transfert.

SSL est totalement transparent pour l'utilisateur, les données transmises sont cryptées sans qu'il n'ait besoin d'intervenir.

Les certificats

Utilité des certificats

Les certificats permettent l'authentification sur internet. Beaucoup de protocoles de sécurité, comme SSL, se basent dessus.

Un certificat est une véritable carte d'identité numérique : elle regroupe toutes les informations sur le titulaire, qu’il s’agisse d’un particulier ou d’une société, dans un fichier numérique respectant un format spécifique. Il permet de mettre en relation une clé publique avec l'identité du titulaire. Cette clé publique est destinée à être utilisée lors d’une connexion sécurisée pour crypter les données transmises.

Le standard le plus utilisé pour la création de ces certificats numériques est le X. 509, il s'agit d'une norme définie par les infrastructures à clés publiques (PKI pour Public Key Infrastructure).

Pour obtenir un certificat, il faut fournir un certain nombre d’informations sur son identité puis le faire signer auprès d’une « Autorité de Certification » (AC). La signature, fournie par la société de confiance, prouve ainsi la validité des informations rentrées.

Les certificats peuvent servir dans plusieurs cas :

• certificat client : il permet d'identifier le client auprès d'un serveur. Ce dernier peut ainsi attribuer des droits particuliers à son interlocuteur.
• certificat serveur : utilisé notamment dans le protocole SSL, il permet au client de s'assurer de l'identité de la société auquel il a affaire.
• certificat VPN : il permet de chiffrer une communication entre deux entités de confiance.

Structure d'un certificat

Un certificat X. 509 est composé de plusieurs informations réparties dans deux sections :

• Section data pour les informations :
  • Version
  • Numéro de série (unique parmi les certificats émis par le signataire)
  • Validité (dates limites)
    • Pas avant
    • Pas après
  • Détenteur du certificat
  • Informations sur la clé publique :
    • Algorithme de la clé publique
    • Clé publique proprement dite
  • Nom du signataire du certificat
  • Identifiant unique du signataire (optionnel, à partir de X.509 version 2)
  • Identifiant unique du détenteur du certificat (optionnel, à partir de X.509 version 2)
  • Extensions (optionnel, à partir de X.509 version 3, permet de rendre les certificats plus flexibles en donnant des informations sur le contexte d’utilisation de ces derniers)
    • Liste des extensions
• Section signature :
  • Algorithme de la signature
  • Clé publique de la signature
  • Signature numérique du signataire, obtenue par le hachage de toutes les données contenues dans le certificat et chiffrée avec la clef privée du signataire

Certificats signés

Selon le principe énoncé par les PKI, les certificats peuvent être signés par un tiers que l'on appelle « l'Autorité de Certification » (ou AC). Cette signature numérique permet d'avoir un gage de confiance sur l'authenticité du certificat.

A noter que ce genre de certificat n'est pas gratuit, les prix variant d'une AC à une autre, en fonction du niveau de sécurité fourni (près de 200€/an pour les plus chères). Voici quelques exemples de sociétés habilités à fournir des certificats numériques : VeriSign, Entrust et GlobalSign.

Certificats auto-signés

Il n'est pas obligatoire de passer par une AC pour obtenir un certificat. On peut également créer des certificats auto-signés dans le cadre des réseaux de confiance comme les intranets. Une connexion SSL sur un serveur "http" utilisant un tel certificat nécessitera au client de l'ajouter manuellement à la liste des certificats de confiance dans son navigateur.

Signature d'un certificat

Pour signer un certificat, l’AC calcule la signature en passant par deux étapes :

• Elle hache toutes les données contenues dans le certificat
• puis elle chiffre le résultat à l'aide de sa clef privée.

Pour vérifier la validité de la signature, il faut alors recalculer le hachage des données contenues dans le certificat, déchiffrer la signature proposée par le signataire à l'aide de sa clé publique (défini dans le certificat par le signataire) puis comparer les deux résultats. En cas de différence, cela signifie que la signature n'est pas valide.

Validation de l'authenticité du certificat par le navigateur

Lorsqu'un serveur "http" se munit d'un certificat fourni par une AC pour sécuriser sa page en SSL, le navigateur du client va vérifier l'authenticité de celui-ci en regardant sa signature et le nom du signataire. S’il se révèle être invalide, le navigateur le fera savoir au client en l'avertissant du danger encouru.

Sous Mozilla Firefox, lorsqu'un certificat n'est pas reconnu, il affiche la page suivante :

En revanche, une connexion SSL sur un serveur détenant un certificat approuvé par une AC connue du navigateur est totalement transparente pour le client.

Pour consulter la liste des AC reconnues par Mozilla Firefox, allez dans vos Préférences, dans l'onglet "Avancé", puis dans "Chiffrement" et cliquez sur le bouton "Afficher les certificats". Vous pourrez également voir les certificats qui ont perdu leur validité dans la liste de révocation.

Hiérarchie de certificats et chaînes de certificats

Dans les grandes organisations (comme Red Hat Certificate System), il peut être judicieux de déléguer la responsabilité de l'émission des certificats à plusieurs autorités de certification. En effet, le nombre de certificats requis peut être trop important à maintenir par une seule AC ; les différents services de l'organisation peuvent avoir différentes politiques d'attribution des certificats ; ou il peut être important pour l'AC d'être physiquement localisée dans la même zone géographique que les personnes auxquelles elle délivre les certificats.

Pour toutes ces raisons, le standard X.509 permet de hiérarchiser l'émission de certificat par les AC.

L'AC racine (« root ») correspond à un certificat auto-signé. Chaque subordonnée (fils) de l'AC racine possède un certificat signé par l’AC racine, les désignant comme AC de confiance. Lors de la vérification d'un certificat, on vérifie alors de père en père si son signataire est valide jusqu'à ce que l'on arrive sur l’AC racine. Ce système revient à désigner de nouveaux AC de confiance grâce à l'AC racine de l'organisation.

La liste de pères définit ainsi une chaîne d’AC, comme décrite dans le schéma suivant :

Pour vérifier la validité d'une chaîne ainsi formée, il faut :

• vérifier la validité des dates du certificat courant.
• localiser l’AC signataire du certificat.
• Vérifier la signature du certificat à l'aide de la clef publique du certificat du signataire localisée. Si cette vérification échoue, cela signifie que le certificat courant n’a pas été signé par l’AC localisée. La chaîne est donc brisée, le certificat n’est pas validé.
• Si le signataire est connu comme une AC de confiance alors le certificat courant est valide. Sinon on doit vérifier la validité du certificat du signataire en réitérant la méthode avec le certificat du signataire

Dans l'exemple du schéma, on devra remonter jusqu’à l’AC racine pour s'assurer de la validité du certificat, car aucun des AC intermédiaires n'est connue comme une AC de confiance.

Cryptologie utilisée par SSL

Introduction

Pour que la communication entre le client et le serveur se fasse de façon confidentielle, il est nécessaire de crypter les données échangées afin qu'aucune personne tierce ne puisse espionner la conversation. Pour cela il est nécessaire que les deux parties se mettent d'accord sur l'utilisation d'une clé publique qui permettra de crypter et de décrypter les messages échangés.

C'est ce qu'on appelle le cryptage symétrique, la fonction de chiffrement est alors bijective : elle permet à la fois de crypter et de décrypter les données.

Cependant, comment faire pour que le client et le serveur se communiquent la clé publique, qu'ils utiliseront pendant la connexion, sans qu'aucune autre personne ne puisse l'intercepter ? En effet, si quelqu’un venait à découvrir la clé utilisée, elle serait en mesure de décrypter tous les messages échangés et d’espionner toute la conversation.

Pour cela le protocole SSL communique le cryptage à clé publique en utilisant du cryptage asymétrique.

Cryptage asymétrique

Principe de Diffie Hellman

Le serveur et le client se mettent d'accord publiquement sur une fonction de cryptage difficilement inversible f telle que :

• f(a.b) est calculable à partir de a et f(b), ou à partir de f(a) et b.
• connaissant seulement f(a) et f(b) il est impossible de déduire f(a.b).
• Le serveur prend aléatoirement une clé secrète "a" et le client une clé secrète "b".
• Le serveur calcule l'élément public f(a) et le client l'élément public f(b).
• Le serveur transmet sa clé publique f(a) au client, et le client transmet sa clé publique f(b) au serveur.

Le serveur et le client calculent f(a.b) grâce à leurs informations respectives. f(a.b) sera alors la clé de chiffrement symétrique utilisée dans la suite de la communication.

Ainsi, un tiers espionnant la communication entre le serveur et le client ne pourrait récupérer que les informations f, f(a) et f(b) ce qui ne permet pas de déduire f(a.b). Il sera donc incapable de déchiffrer la suite de la communication.

Toute la difficulté de ce cryptage réside dans le choix de la fonction f pour qu'elle respecte les conditions précédemment présentées. Un exemple de fonction proposée par Diffie et Hellman est la fonction f(x) = nx mod p (où p est un grand nombre premier et n est un nombre inférieur à p). Les connaissances en mathématiques actuelles ne permettent pas d'inverser cette fonction.

Principe de RSA

A la suite de la découverte de la cryptographie à clé publique par Diffie et Hellman, une nouvelle technique de cryptographie a vu le jour : le RSA.

De nos jours, il est le système cryptographique le plus répandu, il s'agit d'ailleurs de la méthode utilisée par SSL. Il est en effet plus facile à mettre en place que la méthode Diffie Hellman qui nécessitait beaucoup d'échanges d’informations.

RSA repose sur l'utilisation d'un couple de deux fonctions: f et f-1 telle qu’il est très difficile d’inverser f (autrement dit impossible de trouver f-1 à partir de f).

Le serveur s'arrange pour trouver un couple respectant les précédentes conditions. f constituera sa clé publique et f-1 sa clé privée. La clé publique permettra de chiffrer le message et la clé privée permettra de déchiffrer le message ainsi crypté :

Deux entités peuvent alors se mettre d’accord sur une clé sécrète commune en toute sécurité :

1. Le serveur communique sa clé publique au client.
2. Le client génère alors une clé secrète aléatoirement.
3. Le client crypte sa clé secrète avec la clé publique du serveur. Il envoie ensuite sa clé secrète fraichement cryptée au serveur.
4. Le serveur décrypte la clé secrète du client grâce à sa clé privée. En effet, la clé privée du serveur lui permet de décrypter toute information cryptée à partir de sa clé publique.
5. Le serveur et le client utilisent donc la clé secrète comme clé de chiffrement symétrique pour la suite de la communication.

Utilisation du protocole SSL

Dans le protocole SSL, la clé publique du serveur est contenue dans le certificat qu'il communique au client.

Son couple « clé publique / clé privée » est donc toujours le même, tout du moins pendant la durée de validité de son certificat, ce qui l'expose aux techniques « brute-force ». Cependant, le fait que les clés utilisées peuvent être codées sur 128 bits ne permet pas à cette attaque de constituer une réelle menace.

Par contre, ce principe est totalement vulnérable aux attaques du « man-in-the-middle » qui peut facilement usurper l'identité du serveur ou celle du client en proposant ses propres clés.

Le fait que SSL se base sur des certificats pour l'authentification, ne le protège pourtant pas totalement puisque le « man-in-the-middle » peut très bien proposer un certificat valide aux yeux du client. Pour cela il lui suffit de s'attaquer à la configuration du navigateur de sa victime.

L'usurpation de l'identité du client est encore plus simple puisque, même si SSL propose un système d'authentification du client, celui-ci est seulement optionnel. Il est d'ailleurs très rarement utilisé, car peu pratique à mettre en place (il faudrait que tous les clients possèdent leur propre certificat pour se connecter au serveur).

Enfin, la méthode RSA se base sur la difficulté, que l'on a aujourd'hui, à factoriser un grand nombre, facteur de deux nombres premiers. Le jour où les mathématiques permettront de résoudre ce genre de problèmes, toute la sécurité utilisant ce principe se retrouvera sans défense.

Fonctionnement du protocole SSL

Protocole

Une communication sécurisée en SSL se base sur 4 sous-protocoles :

• le SSL Handshake : permet l'authentification du serveur (et du client) avec l'échange des certificats du serveur puis optionnellement du client. Si un des certificats est reconnu comme invalide, la connexion est coupée. Il permet aussi la négociation des suites de chiffrement :
  • détermination de l'algorithme qui cryptera/décryptera les données lors de la communication;
  • détermination de la MasterKey : grâce à la clé publique, obtenue à partir du certificat serveur, et aux clés privées des deux entités.
• le SSL Change Cipher Spec : permet d’avertir de la mise en place des algorithmes de chiffrement qui viennent d'être négociés.
• le SSL Application data : Permet la transmission des données cryptées selon les paramètres de chiffrement définies lors du handshake. Permet également d'avoir un contrôle d'intégrité sur les données transmises.
• le SSL Alert : gestion d'erreurs que peuvent s'envoyer le client et le serveur durant la connexion (trame de 20 octets). le premier octet spécifie s'il s'agit d'une erreur fatale ou un simple warning. En cas d'erreur fatale, la connexion SSL est abandonnée. Le deuxième octet est utilisé pour donner des informations sur l'origine de l'erreur.

Voici comment se déroule l’établissement de la connexion SSL :

• 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.
• 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 a demandé une ressource serveur nécessitant une authentification client, il demande le certificat client.
• Le client utilise les informations envoyées par le serveur pour l'authentifier (vérification de la validité de son certificat). Si le serveur ne peut pas être authentifié, la connexion ne peut pas être établie (voir la partie suivante sur l’authentification du serveur).
• Le client est en mesure d'envoyer au serveur sa clé secrète cryptée à partir de la clé publique du serveur (récupérée à partir du certificat). Si le serveur a requis une authentification du client, le client envoie aussi son certificat.
• Si le serveur a requis une authentification, il authentifie le client. S'il n'arrive pas à l'authentifier, la connexion est interrompue. Le serveur utilise alors sa clé privée pour déchiffrer la clé secrète envoyée par le client.
• 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 et le déchiffrement des données échangées par la suite.
• 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 indiquant que la phase de négociation est terminée.
• 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.
• La phase de négociation est alors terminée.

Authentification

Dans le cas de SSL, il est rare de rencontrer une authentification client. De plus, elle ressemble fortement à celle du serveur, c’est pourquoi nous ne présenterons ici que l’authentification du serveur par le client.

Voici comment se déroule cette authentification :

1. Vérification de la date de validité du certificat du serveur.
2. Vérification que le signataire est une AC connue par le navigateur du client
3. Validation de la signature : Le client vérifie la signature à partir de la clé publique du signataire.
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. Cela permet d'éviter qu'un "man-in-the-middle" ne propose un faux certificat pour se faire passer pour le serveur.

Conclusion

Le protocole SSL est une des façons les plus fiables de sécuriser les échanges sur Internet. Il permet d’assurer tous les services essentiels à la sécurité des échanges comme l’authentification des parties grâce aux certificats, la confidentialité par le cryptage des échanges ainsi que l’intégrité des données échangées.

Ce protocole, vieux de 15 ans, est aujourd’hui de plus en plus utilisé, notamment grâce à la démocratisation des sites de E-commerce.

Ce succès lui vaut d’être la cible de nombreuses attaques comme le « brutes-forces » ou encore le redoutable « man-in-the-middle » qui se joue de l’authentification assez faible du protocole pour espionner les échanges.

Basé sur la cryptologie, comme tous les autres protocoles de sécurité, il est également à la merci des avancées mathématiques.

Toujours est-il, qu’au jour d’aujourd’hui, il sera toujours plus simple d’effectuer un vol à main armée que de récupérer un numéro de carte de crédit sur un réseau sécurisé par SSL.

Références

SSL and TLS Essentials - Securing the Web de Stephen Thomas

http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=/com.ibm.ztpf-ztpfdf.doc_put.cur/gtps5/s5rcd.html

http://www.securiteinfo.com/cryptographie/ssl.shtml

http://sebsauvage.net/comprendre/ssl/

http://www.bibmath.net/crypto/moderne/rsa.php3

http://fr.tech-faq.com/understanding-ssl.shtml

https://developer.mozilla.org/fr/Introduction_%C3%A0_la_cryptographie_%C3%A0_clef_publique/Certificats_et_authentification

https://developer.mozilla.org/fr/Introduction_%C3%A0_SSL

http://www.linux-france.org/~amascret/prj/edu/archinet/systeme/ch24s03.html

http://en.wikipedia.org/

http://linuxfr.org/2008/05/15/24092.html

http://www.clubic.com/actualite-141172-les-logiciels-libres-victimes-d-une-faille-critique.html

http://www.pcinpact.com/actu/news/43598-debian-openssl-faille-cle.htm

Cet article a été publié le Friday 8 January 2010 à 9:04 et est classé dans Web. Vous pouvez en suivre les commentaires par le biais du flux RSS 2.0. Vous pouvez laisser un commentaire, ou faire un trackback depuis votre propre site.