Le HSTS protège-t-il contre une AC non autorisée délivrant un certificat valide illégitime?
HSTS protège-t-il un domaine contre une autorité de certification de confiance publique qui est devenue un voyou émettant un certificat valide illégitime? Des exemples d'autorités de certification de confiance publique seraient l'un des membres de Mozilla CA Bundle .
Existe-t-il un moyen de protéger un domaine contre le fait qu'une autorité de certification illégitime mais de confiance publique émette un certificat valide?
Non, HSTS ne protège pas contre les erreurs de délivrance de certificats. HSTS indique simplement au navigateur de n'autoriser la connexion à ce site que via HTTPS, cela n'a rien à voir avec la vérification de la fiabilité du certificat.
Il y a deux choses qui peuvent aider dans une certaine mesure à éviter les erreurs, la transparence du certificat (CT) et l'autorisation de l'autorité de certification (CAA).
La transparence des certificats n'empêchera pas les erreurs d'émission par une autorité de certification, mais elle nécessite que les certificats soient enregistrés publiquement, afin que vous puissiez vérifier et voir si des certificats ont été émis pour votre domaine qui n'auraient pas dû l'être. Depuis 2018, Google Chrome a exigé que tous les nouveaux certificats émis soient enregistrés CT pour être fiables. Firefox ne le fait pas encore malheureusement, mais dans la pratique, tous les certificats émis ces jours-ci sont enregistrés CT comme sinon ils le feraient ne fonctionne pas avec Chrome.
L'autorisation de l'autorité de certification vous permet d'indiquer les autorités de certification autorisées à émettre des certificats pour votre domaine à l'aide d'un enregistrement DNS. Cela empêchera l'émission accidentelle par une autorité de certification, mais bien sûr, un mauvais acteur l'ignorera. Étant donné que CAA est uniquement destiné à indiquer quelles autorités de certification sont autorisées à émettre un certificat à un moment précis, et non pendant la durée de vie du certificat (c'est-à-dire si l'enregistrement CAA change, le certificat est toujours valide), il ne s'agit que d'un contrôle utile. pour les autorités de certification qui ne sont pas de mauvais acteurs, car cela peut les empêcher d'émettre un certificat qu'ils ne devraient pas avoir, ce qui pourrait éventuellement conduire à leur méfiance. En fait, le RFC requiert spécifiquement que les navigateurs ne vérifient pas les enregistrements CAA.
Une troisième option est HPKP, qui vous permet d'épingler un certificat spécifique qui doit être utilisé pour votre domaine (il ne doit pas être un certificat feuille, épingler la racine de votre autorité de certification serait quelque peu similaire à l'utilisation de CAA, mais plus efficace), mais il est tombé en disgrâce et n'est plus pris en charge par Chrome.
EDIT: curiousguy souligne une attaque intéressante pour contourner la journalisation CT dans certains cas. Si un attaquant a un homme au milieu, il peut être en mesure de savoir quel navigateur établit une connexion très tôt (par exemple en raison de différences de comportement mineures dans la pile TLS). Cela pourrait leur permettre de décider de ne pas attaquer les connexions des navigateurs connus pour vérifier les journaux CT, en transférant simplement la connexion au serveur légitime, mais de présenter un certificat mal émis et non enregistré CT aux autres navigateurs afin d'usurper l'identité du serveur légitime. Il semble que la seule façon d'empêcher cela serait que tous les navigateurs vérifient les journaux CT.