Résumé

  • Let's Encrypt a indiqué le 29 février 2020 que Boulder, son logiciel d’autorité de certification, comportait un bogue dans la revérification des enregistrements DNS CAA pour des demandes couvrant plusieurs noms [1].
  • RFC 8659 définit CAA comme un enregistrement DNS permettant au titulaire d’un domaine d’indiquer quelles autorités de certification peuvent émettre des certificats pour ce domaine [2].
  • Le point de responsabilité n’était pas le soutien général de CAA. Il était de savoir si chaque nom concerné par une validation réutilisée avait reçu une vérification fraîche avant l’émission [1].
  • La page officielle de Let's Encrypt décrit le service comme une autorité de certification fournie par l’Internet Security Research Group. Le répertoire de production BTW utilise ici l’entité existante internet-society, comme dans un précédent article Let's Encrypt, sans changer le sujet factuel [3].

Ce qui s’est passé

L’avis d’incident de Let's Encrypt décrit un défaut découvert le 29 février 2020 dans Boulder. Le logiciel vérifie normalement les enregistrements CAA au moment où il valide le contrôle d’un nom de domaine par l’abonné. Comme certaines validations peuvent rester utilisables pendant une période après le premier contrôle, l’autorité peut devoir revérifier CAA juste avant l’émission. Let's Encrypt a expliqué que la règle applicable exigeait un contrôle CAA dans les huit heures précédant l’émission lorsque la validation était plus ancienne [1].

Le mode de défaillance était précis. Quand une demande de certificat contenait plusieurs noms devant être revérifiés, Boulder choisissait un nom et le vérifiait plusieurs fois, au lieu de vérifier chaque nom pertinent. Une demande pouvait donc passer alors qu’un ou plusieurs noms n’avaient pas reçu le contrôle DNS attendu. Selon Let's Encrypt, le bogue a été confirmé à 03:08 UTC, l’émission arrêtée à 03:10 UTC, puis un correctif déployé à 05:22 UTC avant la reprise [1].

Ce calendrier importe. La responsabilité d’une autorité de certification ne se prouve pas seulement par la phrase « le code est corrigé ». Il faut aussi identifier les certificats potentiellement affectés, prévenir les abonnés, permettre le remplacement et mener la révocation. L’incident a donc couvert l’identification du défaut, la réparation de l’émission, puis le nettoyage du cycle de vie des certificats [1].

Pourquoi CAA est un contrôle DNS

RFC 8659 présente CAA comme un enregistrement DNS permettant au détenteur d’un domaine de limiter les autorités autorisées. Il le décrit aussi comme un contrôle supplémentaire réduisant le risque d’émission non prévue [2]. CAA est donc une frontière entre l’état DNS publié par l’opérateur du domaine et la décision de l’autorité de certification.

La distinction essentielle est celle entre validation du contrôle du domaine et autorisation CAA au moment de l’émission. Un abonné peut toujours contrôler le domaine alors que sa politique CAA a changé, ou alors qu’un nom d’un certificat multi-noms exige un contrôle séparé. Les journaux et les tests doivent préserver cette différence.

Limite du répertoire

Le sujet direct est Let's Encrypt et le service ISRG décrit dans les sources officielles. La liaison au répertoire utilise entity:internet-society, une entrée existante et publiée en production. Elle ne signifie pas que l’Internet Society a pris la décision d’ingénierie dans Boulder. Si un contrôle propriétaire exigeait une entité ISRG directe, ce candidat devrait s’arrêter plutôt que forcer une attribution incorrecte.

Preuves attendues

Un closeout défendable doit montrer quels noms exigeaient une nouvelle vérification CAA, quelles réponses DNS ont été utilisées, quel chemin logiciel a pris la décision, quels certificats ont été inclus dans le périmètre, comment les abonnés ont été prévenus et comment la récidive a été testée. Sans ces éléments, la correction reste privée et difficile à auditer par les parties qui font confiance aux certificats publics.

Sources

  1. https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591
  2. https://www.rfc-editor.org/rfc/rfc8659
  3. https://letsencrypt.org/about/