Quand vos certificats TLS vous trahissent

Un besoin de transparence

Pour comprendre pourquoi vos certificats peuvent être un vecteur d’attaque, nous allons nous pencher sur le fonctionnement même d’un certificat TLS, du point de vue de votre navigateur.

Fonctionnement du TLS « classique »

Sur un certificat classique, voici ce qui va se passer lorsque vous allez vous connecter à un site web exploitant une négociation chiffrée.

Votre navigateur se connecte à l’adresse demandée, puis récupère son certificat.

Ensuite, il va se connecter à l’autorité de certification qui a délivré ledit certificat pour contrôler si le certificat est bien valide.

Fonctionnement du TLS avec transparence des certificats

Lorsque votre navigateur supporte la transparence des certificats, le flux de contrôle est plus complet.

En effet, en plus de vérifier le certificat auprès de l’autorité de certification qui l’a émis, il va aussi le contrôler via un serveur de log tiers.

Il existe plusieurs serveurs de logs, vous pouvez d’ailleurs voir la liste actuelle.

Cela permet de confronter plusieurs informations afin de ne pas valider un certificat auprès d’une seule source. C’est une précaution importante dans le cas où une autorité serait compromise, mais permet aussi de mieux gérer la révocation des certificats, sur laquelle nous reviendrons plus bas.

Voici d’ailleurs la description qu’en fait l’ANSSI (Autorité Nationale de la Sécurité des Systèmes d’Information) :

Certificate Transparency vise à renforcer les contrôles sur les certificats émis par des autorités de certification, notamment ceux utilisés par HTTPS. Initié par Google, ce mécanisme est désormais standardisé par l’IETF.

L’objectif de cette technologie est de faciliter la détection de certificats frauduleux ou invalides. Pour cela, les certificats émis par les autorités de certification reconnues par les navigateurs sont enregistrés dans des journaux en ajout seul.

Les serveurs de logs obéissent à certaines règles importantes pour garantir la transparence des informations :

• On peut uniquement pousser des nouvelles informations, jamais modifier ou supprimer une information
• Les informations doivent exploiter la cryptographie Merkle tree pour leur transmission
• Tous les logs sont auditables publiquement

On retrouve ici certains préceptes que les amateurs de blockchain reconnaîtront, le but est le même : assurer la traçabilité des certificats.

Ainsi, dans le cas où un certificat serait révoqué, il suffit de pousser l’information de sa révocation sur le registre public et votre navigateur saura que malgré le fait que le certificat soit « techniquement » valide, il n’est en réalité plus utilisable. Cela permet aussi de suivre la chronologie du certificat (création, invalidation, etc.).

Quand la transparence vous expose

Si on suit le raisonnement que j’ai eu plus haut, la transparence des certificats apporte énormément d’avantages.

Toutefois, de par sa nature publique, il est facile de manipuler les logs pour extraire et exploiter des informations.

Il existe pour cela de nombreux outils, parmi lesquels :

• crt.sh : Un site web sur lequel on peut retrouver les certificats émis pour un domaine donné
• Les outils fournis par Google

Le fonctionnement restera le même pour un domaine, dont on peut extraire les certificats associés.

Prenons l’exemple du très populaire hashicorp.com, site de l’éditeur d’outils et de solutions d’automatisation et de gestion pour le cloud dont vous pouvez retrouver nombre de billets les concernant sur ce blog.

En allant sur crt.sh, on retrouve donc les certificats émis pour ce domaine :

À partir de là, un attaquant va chercher à trouver les ressources qui sont plus susceptibles d’être mal protégées, comme :

• Des sites hors production, où la sécurité est parfois perçue comme non nécessaire
• Des applicatifs connus comme étant des portes d’entrée et avec de gros privilèges, comme les outils de CI/CD par exemple (GitLab, Jenkins, etc.)
• Des projets « confidentiels », qui sont encore en R&D ou non annoncés

Pour poursuivre l’exemple, sur HashiCorp, un domaine a attiré mon attention, recherchant un mot clé « staging » :

En essayant d’accéder au dit domaine, surprise, ça fonctionne !

Dans cet exemple, rien de grave, le site contient une authentification et les ressources présentes ne sont pas jugées critiques par Hashicorp. Il m’est arrivé cependant de trouver des serveurs Jenkins exposés publiquement par cette méthode lors d’un simple audit.

Mes conseils pour gérer vos certificats

Scanner régulièrement vos domaines

Vu que ces listes sont publiques, je vous recommande fortement de scanner régulièrement vos propres domaines pour identifier rapidement les nouveaux certificats et les dangers associés.

Ne pas utiliser de vrai nom ou type de solutions en R&D

C’est la technique utilisée par énormément de gros acteurs du web : utiliser des noms de code pour vos projets en cours de développement.

En cas de divulgation, cela permet de complexifier l’identification de la solution que votre domaine cache et éviter qu’un concurrent puisse se positionner face à vous.

Sensibiliser les équipes

Comme souvent en sécurité, le point majeur est le même : sensibiliser les équipes.

Si vous n’expliquez pas à vos équipes DevOps ce vecteur d’attaque, elles continueront de créer des certificats sans appréhender ce risque. Il faut aussi rappeler que les environnements hors production doivent respecter les mêmes critères de sécurité que la production (par exemple avec une authentification obligatoire, ségrégation du réseau, etc.).

Utiliser des certificats wildcard, une bonne idée ?

L’une des solutions que l’on peut voir serait aussi d’exploiter des certificats wildcard sur vos applications.

Dans le cas d’HashiCorp évoqué ci-dessus, cela donnerait « *. hashicorp.com ».

Sur le papier, cela limite les risques évoqués plus haut, mais en crée en réalité de nouveaux.

L’un des plus importants étant qu’en cas de compromission et révocation de votre certificat, l’impact sera bien plus large et vous obligera à redéployer un certificat sur un plus grand nombre d’applications.

De plus, mutualiser un certificat augmente aussi les risques que celui-ci soit exfiltré.

Pour finir

Vous l’aurez compris, un attaquant cherchera toujours la moindre information disponible. Il faut garder à l’esprit que la transparence des certificats est l’un des premiers vecteurs d’attaque exploités, car il donne souvent bien trop d’informations.

Il est donc important de le protéger autant que possible comme chaque information publique que vous mettez à disposition.

Dans les faits, la transparence des certificats reste un outil très puissant et sécurisant pour vous et vos utilisateurs, avec les limites évoquées plus haut.

Remerciements

Merci à notre partenaire HashiCorp avec qui nous avançons chaque année pour échanger et partager nos expertises et solutions. La sécurité fait partie de nos valeurs communes et ils nous ont permis de les citer comme exemple pour partager cette culture.