La Transparence des certificats (CT) a connu un tel succès que la plupart des gens la considèrent comme un composant obligatoire de l'écosystème PKI public. C'est probablement parce que la plupart d'entre nous ne traitons généralement que des certificats destinés aux sites web et, pour ceux-ci, la CT est obligatoire… en quelque sorte, mais en réalité pas nécessairement.
La vérité, c'est que la CT n'a jamais figuré à l'ordre du jour du CA/Browser Forum et ne fait pas partie des Baseline Requirements, le document principal utilisé pour encadrer l'émission des certificats. Il existe plusieurs mentions des précertificats (un artefact de la mise en œuvre de la CT), mais aucune indication précisant si les AC doivent utiliser la CT. En théorie, et souvent en pratique, la CT reste optionnelle.
Comment fonctionne la Transparence des certificats ?
La Transparence des certificats est un mécanisme conçu pour imposer un certain niveau de contrôle sur les actions des autorités de certification de confiance (AC). Ces AC sont au cœur de la PKI web et ont le pouvoir d'émettre des certificats pour n'importe quelle propriété dans le monde, sans aucun contrôle technique. Historiquement, cela a causé de nombreux problèmes.
La CT rétablit l'équilibre en exigeant que tous les certificats émis soient enregistrés, c'est-à-dire publiés publiquement. Dans le cadre de l'émission des certificats, les AC soumettent leurs certificats à des journaux CT et y intègrent des signatures des soumissions. Élément crucial, la CT est appliquée par les agents utilisateurs, qui ont le pouvoir de rejeter tout certificat pour lequel il n'existe pas de preuve d'enregistrement suffisante.
En quoi cela nous aide-t-il ? Eh bien, cela force les acteurs malveillants à se dévoiler. Si quelqu'un d'autre que vous obtient un certificat pour l'une de vos propriétés, vous pouvez désormais l'observer dans le flux mondial des certificats publics et réagir. Personne ne se réveille un jour en décidant de surveiller le flux massif de la CT, mais certaines entreprises proposent la surveillance en tant que service. (Red Sift en fait partie.)
Il est essentiel de mettre en place une surveillance : sans elle, rien ne se passe. Par exemple, il y a quelques années, les forces de l'ordre [prétendument] en Allemagne ont obtenu un certificat pour jabber.ru et l'ont utilisé pour intercepter le trafic XMPP. Il figurait dans les journaux CT, mais personne ne surveillait, et l'interception est restée en place, non détectée, pendant longtemps. Dans un autre cas, FINA, une petite AC croate, avait émis à plusieurs reprises des certificats erronés pour l'adresse IP 1.1.1.1 appartenant à Cloudflare, sans être détectée pendant de nombreux mois.
Du côté positif, même si vous ne surveillez pas la CT, vous bénéficiez tout de même d'un effet dissuasif, car les certificats mal émis restent à jamais consignés publiquement. Vos adversaires ne savent peut-être pas réellement si vous surveillez ou non.
Qui exige la Transparence des certificats ?
Nous avons déjà établi que, techniquement parlant, la CT n'est pas obligatoire. Cependant, il se trouve que certains des plus grands consommateurs de certificats l'exigent. Apple, Google, Microsoft et Mozilla exigent tous la CT à différents niveaux dans leurs produits. En pratique, si vous publiez un site web destiné à être consulté par un navigateur, vous devez utiliser un certificat publié dans la CT.
Mais tous les agents utilisateurs ne sont pas des navigateurs, et Internet ne se limite pas aux sites web.
L'un des problèmes inhérents à la CT est qu'elle est appliquée au niveau du client. De nombreux clients qui ne sont pas compatibles avec la CT n'offrent aucune protection. Pour cette raison, vos adversaires peuvent totalement contourner la CT, et vous ne bénéficiez pas de sa protection.
Les navigateurs modernes exigent la CT, tout comme les bibliothèques réseau officielles sur les plateformes d'Apple et, depuis peu, sur Android. Cependant, il existe tout un éventail de langages de programmation et de bibliothèques TLS qui n'en tiennent pas compte. Pratiquement tout ce qui n'est pas un navigateur ignorera la CT. Vos serveurs API, même si vous utilisez aujourd'hui des certificats CT, ne sont en réalité pas protégés par la CT. La communication serveur à serveur (par exemple, le SMTP) est tout aussi exposée. Pour certains cas d'usage, la CT n'apporte aucun bénéfice.
Combler le fossé
À long terme, la seule solution consiste à intégrer la CT dans les Baseline Requirements, ce qui ne se produira probablement que si l'un des magasins racines (root stores) décide de l'exiger.
La situation est compliquée par la migration post-quantique. Pour répondre à la menace imminente d'un ordinateur quantique cryptographiquement pertinent, Google travaille sur un nouveau type de certificat, appelé Certificats Merkle Tree (MTC). Dans le cadre de cet effort, la Transparence des certificats sera reconstruite et combinée à l'émission des certificats. Il est possible qu'à l'avenir, nous ayons deux types de certificats : les MTC et les X.509 utilisant la cryptographie post-quantique. Les premiers bénéficieront de la transparence, mais on ne sait pas encore ce qu'il en sera pour les seconds.
Cependant, il existe une solution.
En l'absence de toute action de votre part, n'importe quelle AC peut émettre un certificat pour l'un de vos noms de domaine. Cependant, il existe un mécanisme qui vous permet de restreindre l'émission par AC, et même par compte d'AC. Cela s'appelle l'Autorisation de l'autorité de certification (CAA). La CAA peut être utilisée pour créer et diffuser des politiques d'émission que toutes les AC doivent respecter. Ce mécanisme n'est pas infaillible, mais son support est obligatoire pour toutes les AC.
Pour combler le fossé de visibilité de la CT, il vous suffit de choisir de travailler avec des AC qui s'engagent à enregistrer tous leurs certificats dans la CT. Let's Encrypt, la plus grande AC en termes d'émission et gratuite, a toujours tout enregistré. D'autres AC font probablement de même ; si vous n'êtes pas sûr, demandez à votre AC une déclaration officielle à ce sujet.
À titre d'exemple d'évolution positive, Amazon et DigiCert se sont récemment engagés eux aussi à tout enregistrer. Leurs décisions pourraient être liées aux changements récemment apportés par Chrome dans ce domaine. Selon le texte de la version 1.8 de leur politique racine, l'enregistrement des précertificats est obligatoire, mais l'enregistrement des certificats reste une simple recommandation (SHOULD).
Si vous souhaitez en savoir plus, nous avons rédigé un livre blanc qui approfondit la manière de combler le fossé de visibilité de la CT et d'utiliser la CAA pour affirmer votre contrôle sur vos parcs PKI publics : High-Assurance Certificate Transparency Monitoring. Ce guide peut vous aider à combler le fossé de visibilité de la CT, mais aussi à traiter d'autres aspects de la sécurité PKI, y compris l'obtention du Saint Graal de la PKI : une validation cryptographique forte de l'émission des certificats.
Ivan Ristic is the Chief Scientist for Red Sift and former founder of Hardenize. Learn more about how Red Sift helps organizations with their Certificate Monitoring.