L'interception SSL/TLS : le fonctionnement, entre enjeux et risques, les bonnes pratiques

2.5 Authentification: un principe de confiance

Le dernier objectif auquel TLS doit répondre est « l'authentification ». Mais pas n'importe laquelle. Puisque le TLS est censé répondre à un comportement de « client-serveur », il doit pouvoir permettre aux clients d'authentifier de façon sûre le serveur à joindre. L'authentification des clients est également

6. Nous ne prendrons pas en compte les diverses attaques par collisions permettant de retrouver éventuellement une donnée.

Edouard Petitjean M2 MIAGE SIID 13

TLS : un protocole compliqué? - Authentification: un principe de confiance

FIGURE 2.2 - Structure d'un certificat X.509

prévue par le TLS mais d'une manière optionnelle, aussi, seule la présentation de l'authentification du serveur sera expliquée.

Comme dit précédement, les systèmes à chiffrement asymétrique permettent de répondre au besoin d'« identification ». Or, quelle est la différence entre « identification » et « authentification »? Dans le cas présent, le premier va permettre de s'assurer qu'un message a bien été envoyé à partir d'une clef privée précise (conjointe de la clef publique connue). Mais nous nous retrouvons dans un problème de sécurité important : comment peut-on être sûr de l'identité derrière ce couple de clefs? En reprenant l'exemple d'Alice et Bob, comment Alice peut-elle être sûre que c'est bien Bob qui soit derrière la clef publique? Inversement, comment Bob peut s'assurer que c'est Alice qui lui envoie un message? C'est là qu'intervient le principe d'« authentification » : s'assurer de l'identité derrière une clef publique.

Cette partie d'« authentification » va être gérée par un certificat. Le rôle d'un tel certificat est de jouer la carte d'identité numérique.

2.5.1 Certificat X.509 : La carte d'identité numérique

Un certificat X.509 suit une structure spécifique décrite dans la RFC 5280. Elle se compose de champs basiques, et de champs d'extensions. Cela permet une véritable évolutivité de ce type de certificat, au même titre que le TLS. En effet, l'utilisation d'extension permet de rajouter des rôles à ce type de certificat, sans pour autant perturber l'objectif de base qui est d'authentifier son propriétaire. Par ailleurs, le certificat sera signé par une AC . La figure fig. 2.2 p.13 montre la structure d'un certificat X.509.

Un certificat signé est donc conçu de trois champs majeurs :

7. Autorité de Certification : est une entité ayant pour rôle de délivrer des certificats et d'attester de l'identité précise derrière ces certificats

Edouard Petitjean M2 MIAGE SIID 14

TLS : un protocole compliqué? - Authentification: un principe de confiance

· Un certificat regroupant toutes les informations permettant d'établir l'identité publique de son propriétaire.

· L'algorithme de signature utilisé par l'AC, défini dans le certificat, pour signer ledit certificat. Ce champ sera généralement défini par deux algorithmes : un algorithme de hash⁸ et un algorithme asymétrique.

· La valeur de la signature qui sera utilisée pour confirmer la relation de confiance entre le certificat et l'AC.

Le certificat est donc défini par:

· Version: désigne un numérique, utilisé selon l'implémentation visée du certificat.

· Numéro de série : un numéro qui doit être unique parmi tous les certificats délivrés par une AC. Le but étant que le couple d'information (numéro de série, AC) doit être unique pour tous certificats.

· Signature: désigne les algorithmes utilisés par l'AC pour créer la signature. Ce champ doit être identique à « L'algorithme de signature » vu précédemment.

· Émetteur : est le DN⁹ (Distinguished Name) de l'AC qui a signé et délivré le certificat.

· Validité : va définir une date de début et de fin pour le certificat.

· Sujet : est le DN pour lequel le certificat a été créé. Souvent, le CN ¹⁰ du DN sera le nom de domaine pour lequel le certificat a été créé.

· Info clef publique du sujet : contient deux champs, l'un contient la clef publique, l'autre indique les algorithmes qui seront utilisés avec la clef de chiffrement.

· Identifiant unique émetteur/sujet : sont deux champs optionnels. Ils permettent de donner un deuxième nom à l'émetteur ou au sujet, si le premier peut-être commun à plusieurs AC.

· Extensions : va regrouper plusieurs champs qui définiront des paramètres optionnels. En règle général, ces paramètres ont pour but de faciliter et optimiser la gestion des certificats. Une des extensions la plus utile est sans doute le « Noms alternatifs de sujet de certificat » qui permet de rendre le certificat compatible avec plusieurs noms de domaines, au lieu d'un seul à la base.

2.5.2 La relation de confiance

Maintenant, voyons comment l'utilisation d'un certificat peut permettre d'accéder à un site web sécurisé (fig. 2.3 p.14). C'est le cas le plus classique et le plus simple à comprendre. Dans ce schéma, la signature d'une AC ne sera pas prise en compte.

FIGURE 2.3 - Echange avec un serveur utilisant un certificat non signé

Dans cet exemple simple, la relation de confiance entre le client et le serveur est très forte. En effet, le client ne va reposer sa confiance que sur la correspondance entre le nom de domaine qu'il a demandé

8. Un algorithme de chiffrement irréversible permettant de générer une empreinte numérique

9. Distinguished Name : l'identifiant unique d'un objet situé dans un ensemble de données hiérarchisé (ex : LDAP). Le DN d'un objet est aussi appelé le chemin de l'objet.

10. Common Name: nom commun d'un objet dans un ensemble de données hiérarchisé. Permet d'appeler rapidement un objet quand le CN est unique.

Edouard Petitjean M2 MIAGE SIID 15

TLS : un protocole compliqué? - Authentification: un principe de confiance

et le sujet du certificat qu'il aura reçu. Or, cette forte confiance pose un problème majeur : comment repérer une usurpation d'identité? Prenons le cas d'un serveur malveillant qui serait configuré pour répondre au même nom de domaine que notre exemple, soit « www.edouard.petitjean.com ». Celui-ci proposerait également un certificat valide pour le nom « www.edouard.petitjean.com » mais avec une clef publique complètement différente. Dans ce cas, comment Bob peut s'assurer de communiquer avec le bon serveur et non pas le malveillant? Dans le contexte de l'exemple, c'est impossible. Pour pallier ce défaut, un système basé sur plusieurs relations de confiance fut pensé : la PKI (Public Key Infrastructure).

2.5.3 PKI : La confiance via un tiers

Le système de PKI a été pensé pour renforcer la confiance qu'un client peut avoir envers un certificat. Le principe de base est simple et se repose sur une chaîne de relation de confiance. Lorsqu'un client voudra vérifier l'authenticité d'un certificat, il vérifiera l'entité qui l'a signé (l'entité s'engage donc sur l'authenticité du certificat). Si cette entité fait partie de la liste de confiance du client, alors le client fera confiance au certificat.

Pour cela, la PKI à plusieurs fonctions : la création, le renouvellement et la publication des certificats, gérer une liste de révocation et la publier pour définir les certificats n'étant plus de confiance. Pour remplir ses fonctions, une PKI reposera sur plusieurs entités :

· Autorité de certification (AC) : signe les demandes de certificats (CSR¹¹) et gère la liste de révocation. Cette entité est la plus critique car les clients en ont besoin pour vérifier les certificats. Il est aussi important de noter que dans les PKI publiques, il existe des AC racines et des AC intermédiaires. Les clients font confiance aux AC racines mais afin de se protéger¹², ces dernières vont déléguer la signature de certificats à une ou plusieurs AC intermédiaires.

· Autorité d'enregistrement (AE) : vérifie les informations sur l'identité des propriétaires de certificats.

· Autorité de dépôt : stocke les certificats et les listes de révocation.

· Entité finale (EE : End Entity) : est l'entité qui va utiliser le certificat (serveur web, mail, client, etc...).

· Autorité de séquestre 13 : stocke les clefs privées liées aux certificats.

Le schéma fig. 2.4 p.16 montre en détail le déroulement des étapes qui sont effectuées pour que la relation de confiance entre un serveur et un client soit à l'oeuvre.

Ce schéma n'est pas exhaustif dans l'ensemble des vérifications qui sont réellement faites dans la réalité, mais il donne une bonne image du mécanisme de confiance qui est mis en jeu. En effet, avec l'ajout d'une entité tierce, les clients ne font pas confiance au serveur directement, mais aux entités qui ont attesté de l'identité du serveur. Aussi, les risques qu'un serveur malveillant se fasse passer pour un serveur légitime sont très limités, car il existe peu de chance qu'il parvienne à avoir une signature d'une AC de confiance.

11. Certificate Signing Request : requête envoyée à une AC pour signer un certificat. L'AC renvoie un nouveau certificat avec sa signature.

12. La protection évoquée ici est la mise hors ligne de l'AC racine. Celle-ci est remise en ligne uniquement pour la création d'une AC intermédiaire.

13. Contrairement aux quatre précédents, cette entité n'est pas définie par l'IETF.

Edouard Petitjean -- M2 MIAGE SIID 16

TLS : un protocole compliqué ? - Authentification : un principe de confiance

Certiica client final

Sujet: wwe .edouard.petitjean.com
E metteu r : petitj ean. interm ediaire

Certtica signé par

« petitjean. intermédiaire »

www.edouard.petitjean.com

3-- L'AC renvoi le certiftat sgné

--Le certificat est valide.
Bob peut établir une rely ion de
confiance avec

r www.edouard.petitjeancom

A -- Bob veut établir une con nation sécurisée avec

evvrw.edouard.petitjean.com e

2 --Le serveur envoi un CSR pour

saner son certifica

5-- Le serveur envoi son certificat et la

chaire de

certification

7 -- Bob demande l liste de révocaion auprés de rAC intermédiaire

AC intermédiaire :
petit jean.intermédiaire

Bob

8 - L'AC intermédiaire envoi sa liste de révocation

1 - Délégation de la gestion

des oertificetsé une ^AC Irrtermediaire	6 -- Le certificat reçu est signé par uneAC Intermédiaire dé pende nt ô un AC Racine. Bob va vérifier la signature de l'AC Racine avec celle de sa base de connaissances erti lccA sur sorti poste 1
	Base c rAC Racine de confiance

FIGURE 2.4 - Echange avec un serveur utilisant un certificat signé

Edouard Petitjean M2 MIAGE SIID 17

TLS : un protocole compliqué? - TLS : le protocole en détail