Au niveau du web, ces certificats sont utilisés pour sécuriser les échanges entre un navigateur client et un/des sites sensibles (banques, sites commerciaux, ....).

L'une des premières propriétés d'un certificat est de pouvoir authentifier le site distant ou le client. Pour cela, le navigateur s'appuie sur les informations contenues dans le certificat présenté (par le serveur web ou le client) et la confiance accordée au signataire de ce certificat (généralement une autorité de certification (CA) digne de confiance comme Verisign, Thawte, … ou une CA interne comme celle du Cert-IST).

Cette authentification s'effectue alors en 2 phases :

• vérification des informations contenues dans le certificat (sujet, période de validité...),
• vérification de l'autorité de certification qui a signé le certificat.

Si le premier contrôle est correct et si l'autorité de certification (CA) est connue du navigateur (chaque navigateur intègre une banque de CA qui inclut les CA les plus connues), le certificat est accepté ; sinon, un message d'erreur est affiché.

Pour des facilités de gestion des certificats (en fonction de la localisation des entités par exemple ou pour des besoins de hiérarchisation), il peut exister plusieurs CA intermédiaires à qui sont délégués le pouvoir de signature.

Une "CA_globale" signe le certificat "CA1_intermédiaire" en lui accordant le droit de signature. Cette "CA1_intermédiaire" peut alors signer les certificats "Certificat_Utilisateur_1", "Certificat_ Utilisateur _2", etc… Ce principe de délégation simplifie donc la tâche de l'autorité globale, tout en permettant à la "CA_intermédiaire" de générer des certificats reconnus par tout navigateur faisant confiance à "CA_globale".

Ainsi lorsque le certificat "Certificat_Utilisateur_1" est présenté à un navigateur, ce dernier vérifie la chaîne de signatures du certificat ("Certificat_Utilisateur_1" signé par "CA1_intermédiaire" signé par "CA_globlale"). Si le dernier signataire "CA_globlale" est une autorité de certification reconnue alors, par transitivité, le certificat utilisateur est reconnu comme valide.

Dans la norme X509, un contrôle sur l'attribut "Basic Constraints" du certificat doit être effectué pour vérifier que le certificat de la CA intermédiaire "CA1_intermédiaire" est autorisée à signer ou non d'autres certificats.

Cependant, sur certains navigateurs, dont Internet Explorer (voir en fin d'article la liste des navigateurs vulnérables), ce contrôle n'est pas effectué de manière correcte, ce qui fait que ces derniers considéreront comme valides des certificats qui ne le sont pas.

Prenons l'exemple suivant :

• Une personne malveillante se fait signer un certificat X.509 "Hack_CA" par Verisign.Verisign valide ce certificat, mais positionne l'attribut "Basic Constraints" pour indiquer que ce certificat est un certificat utilisateur seulement (et ne peut être utilisé pour signer d'autres certificats) .
• La personne malveillante utilise "Hack_CA" pour signer un autre certificat de nom "certificat_Banque_XXX", et utilise ce certificat pour monter un site Web sécurisé (HTTPS) vers lequel il détourne les clients légitimes de la banque.
• Lors qu'une victime se connectera à ce serveur web sécurisé (détourné) avec un navigateur vulnérable, la chaîne de signature sera analysée, et par transitivité, ce certificat sera reconnu comme valide puisque signé par Verisign en bout de chaîne ("Verisign_CA" signe "Hack_CA" qui signe "certificat_Banque_XXX").
• L'attribut " Basic Constraints" n'a donc pas été correctement vérifié. Cette même connexion à partir d'un navigateur non vulnérable aurait par contre généré un message d'erreur du fait de la non validité de la chaîne de signature par rapport à l'attribut "Basic Constraints" du certificat "Hack_CA".

En pratique, ce type d'attaque reste très difficile à mettre en œuvre, car il faut substituer le trafic du serveur légitime vers le serveur pirate, ce qui nécessite par exemple de corrompre les tables de routage ou le DNS. De même, des informations, disponibles dans le certificat X509 appartenant au site pirate et présenté au navigateur client (voir les propriétés du certificat du site HTTPS), peuvent permettre de confondre les auteurs de cette "fraude".

Microsoft a réalisé une information sur ce problème (Cf. partie "Pour plus d'information") et travaille actuellement sur un correctif.

Dans l'attente de ce correctif , le Cert-IST vous recommande de contrôler de manière plus approfondie les certificats proposés par des sites sécurisés (HTTPS).

Il semblerait aussi que ce comportement soit aussi présent dans :

• la vérification des certificats clients par le serveur IIS 5.0. Selon l'auteur de la vulnérabilité, le Service Pack 3 corrigerait ce problème. Cet aspect reste moins critique que le précédent car les contrôles au niveau des authentifications par certificat clients sont plus draconiens.
• la vérification des certificats S/MIME sous Outlook (S/MIME s'appuie sur les certificats X.509 et Outlook "délègue" la gestion des certificats à Internet Explorer).

Microsoft a été contacté par le Cert-IST et travaille actuellement sur ces aspects.

Remarques :

• Les navigateurs Netscape et Mozilla ne semblent pas impactés par ce problème.
• L'environnement SSL de KDE, notamment utilisé par le navigateur "Konqueror", est également vulnérable à ce problème (Cf. section "Failles n'ayant pas fait l'objet d'avis")

Pour plus d'information :

• Information de Microsoft : http://www.microsoft.com/technet/security/news/IARWSV.asp
• Information de VeriSign : http://www.verisign.com/support/vendors/browseralertsteps.html
• Article de Microsoft sur la gestion des certificats : http://www.microsoft.com/technet/security/prodtech/dbsql/tshtcrl.asp
• RFC 2459 : http://www.ietf.org/rfc/rfc2459.txt?number=2459