Magazine Internet

Non, le certificat public du CA n’est pas un certificat client !!!

Publié le 03 octobre 2014 par Jeremy.jeanson

Si le titre ne vous dit rien ou que l'affirmation vous semble étrange, il y a des chances que le contenu qui suit vous concerne.

De manière générale, pour les services ou un site web on utilise des certificats pour sécuriser des échanges ou authentifier un tiers. À plusieurs reprises déjà, j'ai été confronté à de mauvais usages de certificats, mais très récemment j'ai été confronté à un cas qui dépasse tout. Cela n'est pas la première fois que j'observe cette situation. Je profite donc de cet article pour tenter d'endiguer cette pratique qui compromet la sécurité de vos applications.

  1. L'objectif visé (mais non atteint) consiste à vouloir authentifier les applications autorisées à se connecter à un service. Pour se faire, les applications clientes doivent disposer de certificats signés par une autorité de certificat (CA).
  2. Dans le cas présent, les certificats sont fournis par les administrateurs en charge de l'hébergement des services.
  3. Chaque équipe de développeurs reçoit le certificat public du CA pour le reconnaitre comme une autorité de certificat de confiance + un certificat qui lui est propre.
  4. Les développeurs de l'application cliente 1 doivent utiliser le certificat 1
  5. Les développeurs de l'application cliente 2 doivent utiliser le certificat 2
  6. … etc…

En soi, la chose est classique.

Note : Je ne sais pas pourquoi, cette démarche est confondue avec l'utilisation de certificats d'authentification mutuelle. Pour rappel, dans le cas de certificats d'authentification mutuelle, il faut que chaque partie (client et serveur) fournisse un certificat pour s'identifier. Rien à voir donc avec ce cas. Une présentation propre du sujet peut se trouver ici.

Là où le bât blesse, c'est que les développeurs n'arrivent pas à s'authentifier quand ils utilisent leurs certificats d'applications. Et là on me sort la solution folle qui marche : « utiliser le certificat de l'autorité de certificat »… oui, le certificat public que tout le monde connait et qui sert à dire « en tant que client je fais confiance aux certificats fournis par ce serveur », (oui, le fameux certificat avec CA dans son nom !)…. Mais cela ne choque personne… (hors mis moi...peut être...)

Une erreur de configuration a certainement été opérée sur le serveur.

Les conséquences sont énormes :

  • On ne peut plus interdire une application ou une autre.
  • Il suffit de fournir le certificat du CA pour se connecter.

À partir du moment que quelqu'un connait l'autorité de certificat, il a le droit de se connecter. C'est fou !

Certains défendront la chose en disant « oui, mais il faut déjà connaitre le certificat ». À ceux-ci je répondrai :

  • Imaginer dans le cas d'une autorité de certificat d'entreprise, toutes les machines d'un AD peuvent utiliser le service !
  • Pour faciliter l'administration, le certificat du CA est généralement public et fourni via un site web (que ce soit sous Apache ou IIS)

D'autre diront, « il y a peu de chance que quelqu'un essai d'utiliser ce certificat comme cela ». Pour ceux-ci mes réponses seront basées sur l'expérience.

  • Une chance de contourner la sécurité, c'est une chance de trop.
  • Cela fait déjà 3 fois que je suis confronté à ce cas et qu'aucun développeur n'est choqué par ce qu'il fait en utilisant un certificat CA comme ClientCredential.

Moralité : Attention lors de vos développements, ce qui fonctionne n'est pas forcément bon. Et une information publique comme ce certificat public de CA ne doit surtout pas être utilisée de la sorte. On doit toujours utiliser une information « privée, valide », et donc un certificat non révoqué généré par une autorité de certificat de confiance.


Retour à La Une de Logo Paperblog

A propos de l’auteur


Jeremy.jeanson 1573 partages Voir son profil
Voir son blog

l'auteur n'a pas encore renseigné son compte l'auteur n'a pas encore renseigné son compte