Pourquoi utiliser CAA?
Les informaticiens Phillip Hallam-Baker et Rob Stradling ont développé la CAA en réponse aux préoccupations croissantes concernant la sécurité des autorités de certification publiques. Cette initiative relève de l'Internet Engineering Task Force (IETF), une organisation de normalisation (SDO) de premier plan pour Internet. L'IETF élabore des normes volontaires largement adoptées par les utilisateurs, les opérateurs de réseau et les fournisseurs d'équipements, influençant ainsi l'évolution d'Internet.
L'IETF documente ses normes techniques dans des publications appelées RFC (Requests for Comments). Ces documents décrivent les aspects clés de l'infrastructure Internet, notamment les technologies d'adressage, de routage et de transport. La CAA est spécifiquement définie dans RFC 6844.
Une autorité de certification (CA) utilise toujours des méthodes de validation de domaine pour vous assurer que chaque SSL /TLS la demande de certificat est autorisée (généralement en s'assurant qu'elle est liée d'une manière ou d'une autre à un site particulier utilisant ce domaine).
Par exemple, une autorité de certification peut fournir un fichier de vérification spécial au demandeur. Le fait de placer ce fichier sur le site Web prouve que le demandeur contrôle également ce site, mais il ne peut garantir la légitimité de ce contrôle. Un pirate informatique qui prend le contrôle d'un site peut se faire passer pour le propriétaire légitime, puis demander et recevoir un SSL /TLS certificat qui passe les contrôles standard de toute autorité de certification et donc semble légitime. Ils pourraient alors se retourner et utiliser ce SSL /TLS certificat de méfait, sur ce site ou ailleurs.
CAA aide à bloquer ce type d'exploit en définissant quelles autorités de certification sont autorisées à émettre des certificats pour un domaine (ou même en limitant complètement l'émission de certificats). Cela limite les dommages qu'un pirate de l'air peut infliger - même s'ils contrôlent un site, ils auront considérablement moins d'options pour marquer un SSL /TLS certificat.
Qu'est-ce qu'un CNAME ?
Un enregistrement CNAME est un type de configuration DNS qui autorise un domaine, tel que store.mybusiness.com, pour servir d'alias à quelqu'un d'autre, comme monentreprise.comAu lieu de gérer plusieurs enregistrements A pour refléter les changements d'adresse IP, un CNAME simplifie la tâche en pointant l'alias vers le domaine cible. Cette approche est très avantageuse pour les entreprises qui changent régulièrement d'hébergeur web ou de fournisseur de CDN. De plus, les enregistrements CNAME sont précieux pour la mise en place de systèmes de secours, où le trafic est redirigé d'un serveur principal vers un serveur secondaire, garantissant ainsi la continuité du service en cas de panne.
Dans le cadre de l'autorisation d'autorité de certification (CAA), les enregistrements CNAME influencent le processus en redirigeant les vérifications CAA vers le domaine cible. Par exemple, si boutique.monsite.net utilise un CNAME pour pointer vers monsite.net, une autorité de certification effectuant une vérification CAA évaluera les enregistrements pour monsite.net pour vérifier l'autorisation de délivrer un certificat. Si l'enregistrement CAA sur monsite.net Si l'autorité de certification n'est pas autorisée, le certificat ne peut pas être émis. Cela garantit une application cohérente des politiques de l'autorité de certification, même lorsque les domaines utilisent des enregistrements CNAME pour l'aliasing DNS.
Comment CAA fonctionne
CAA utilise DNS
Le Domain Name System (DNS) est un élément crucial de l'infrastructure d'Internet. Le propriétaire d'un domaine conserve des enregistrements DNS (à l'intérieur de ce qu'on appelle fichiers de zone) pointant leur nom de domaine vers l'adresse IP où leur site est hébergé, et nous permet de taper google.com dans une fenêtre de navigateur au lieu de 216.58.194.46.
Les enregistrements DNS sont couramment utilisés comme «répertoire téléphonique pour Internet», mais DNS permet également d'autres types d'enregistrements spéciaux qui peuvent attribuer d'autres informations à un nom de domaine.
Dossiers CAA
La CAA utilise un type particulier d'enregistrement appelé Enregistrement des ressources d'autorisation de l'autorité de certification (Dossier CAA). Ceux-ci sont publiés à l'aide de DNS, et le propriétaire du domaine ajoute simplement des enregistrements CAA aux côtés de ses autres enregistrements DNS. Un dossier CAA comprend un Étiquette , l’aspect économique La valeur, et la paire étiquette-valeur est appelée propriété. Il ya aussi un drapeau indiquant à quel point cette propriété est critique. Voici à quoi on ressemble:
example.com. Problème CAA 0 "ssl.com"
Ici, example.com est le domaine auquel s'applique cet enregistrement, et CAA nous fait savoir de quel type d'enregistrement il s'agit. le 0 est l'indicateur (zéro est la valeur par défaut). La balise est aide et la valeur (entre guillemets) est ssl.com, qui constituent ensemble la propriété.
Drapeaux
Les drapeaux n'ont actuellement que deux états strictement définis: 0 (non critique) et 1 (critique). Un indicateur critique indique à l'AC qu'il doit Il est important de bien comprendre la balise de propriété pour continuer. La RFC 6844 laisse d'autres possibilités d'utilisation d'indicateurs définis par l'utilisateur (plus d'informations ci-dessous).
Tags
La RFC 6844 définit l'utilisation de trois balises courantes: aide, issue et iodéf. (Comme avec les drapeaux, il permet d'autres types de balises personnalisées potentielles.)
Le aide Étiquette
Le aide tag spécifie quelle autorité de certification (le cas échéant) est autorisée à émettre des certificats pour ce domaine. Par exemple, le propriétaire du domaine example.com peut limiter l'émission de certificats à une autorité de certification (ici, SSL.com) à l'aide du fichier de zone DNS suivant:
example.com. Problème CAA 0 "ssl.com"
Un propriétaire de domaine peut choisir de configurer plusieurs fichiers de zone pour un domaine:
example.com. CAA 0 issue "ssl.com" example.com. Numéro CAA 0 "comodoca.com"
Les enregistrements ci-dessus limitent SSL /TLS délivrance de certificat pour example.com à deux CA (SSL.com et Comodo.com).
Le aide record autorise également l'autorité de certification nommée à émettre des certificats pour tous les sous-domaines du domaine spécifié. Un enregistrement autorisant SSL.com peut ainsi permettre l'émission de certificats pour example.com et des sous-domaines comme www.example.com, Mail.example.com et même le sous-domaine générique spécial * .example.com.
Un enregistrement CAA peut être utilisé pour restreindre émission de certificats également - cet enregistrement indique aux autorités de certification utilisant CAA que aucune SSL /TLS les certificats doivent être délivrés pour example.com et sous-domaines par tout CALIFORNIE:
example.com. Problème CAA 0 ";"
(Le point-virgule dans cet exemple signifie "ne permettez rien ici", Mais comme nous le montrerons plus tard, il est également utilisé pour définir des paramètres personnalisés.)
Notez qu'une balise d'émission standard permet à l'autorité de certification d'émettre un certificat pour un caractère générique à moins qu'il ne soit modifié par…
Le issue Étiquette
Cette balise spécifie qu'une autorité de certification est autorisée à émettre des certificats génériques pour le domaine du propriétaire (c.-à-d. * .example.com).
Les caractères génériques peuvent représenter un nombre illimité de sous-domaines. Il est donc important de prêter une attention particulière lors de l'émission de certificats génériques. issue La balise permet au propriétaire du domaine de définir les autorités de certification qui peuvent émettre des certificats pour les caractères génériques séparément du domaine principal ou d'autres sous-domaines. issue les balises ont priorité sur tout aide Mots clés. Ils utilisent la même syntaxe que le aide marque. Quelques exemples:
example.com. CAA 0 issue "ssl.com" example.com. CAA 0 issuewild ";"
Ce qui précède permet à SSL.com d'émettre des certificats pour example.com et tous les sous-domaines sauf pour le caractère générique * .example.com. (Ni SSL.com ni aucune autre autorité de certification n'est autorisée à émettre des certificats génériques pour example.com.)
example.com. Problème CAA 0 ";" example.com. CAA 0 issuewild "ssl.com"
Cet exemple interdit tous Autorités de certification auxquelles délivrer des certificats example.com et ses sous-domaines, mais crée une exception pour permettre à SSL.com d'émettre des certificats génériques (et uniquement certificats génériques) pour example.com.
Le iodéf Étiquette
La troisième balise définie est iodéf. Cette balise peut être utilisée pour signaler des demandes de certificat non valides au propriétaire du domaine, et elles ressemblent à ceci:
example.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
L'enregistrement supérieur donne à l'autorité de certification les informations nécessaires pour envoyer une notification par e-mail à l'adresse certissues@exemple.com. Le second demande à l'autorité de certification de publier un message d'incident sur un service Web (configuré à cet effet par le propriétaire du domaine) à l'adresse certissues.exemple.com. (L'une ou les deux méthodes peuvent être utilisées, selon la façon dont l'autorité de certification et le propriétaire du domaine ont configuré leurs opérations.)
iodéf les messages postaux utilisent un format standard appelé Format d'échange de la description de l'objet incident ou IODEF - d'où le nom. (IODEF est défini dans RFC 6546.)
La balise issuemail pour S/MIME
Un développement important dans la CAA est l'extension à S/MIME Certificats (Secure/Multipurpose Internet Mail Extensions), formalisés dans la RFC 9495. S/MIME Les certificats assurent la sécurité des e-mails grâce à l'authentification, la confidentialité des données et l'intégrité des messages. Le CA/Browser Forum a introduit une nouvelle balise de propriété CAA appelée « issuemail », spécifiquement destinée au contrôle de l'émission des certificats. S/MIME certificats.
À compter du 15 septembre 2024, il est recommandé aux autorités de certification de mettre en œuvre la vérification CAA pour S/MIME certificats, avec mise en œuvre obligatoire requise d'ici le 15 mars 2025. Le formulaire d'enregistrement CAA standard pour les adresses e-mail ressemblerait à ceci :
mail.client.example CAA 0 issuemail "authority.example"
Cette extension de CAA aux certificats de messagerie électronique offre aux propriétaires de domaines le même niveau de contrôle sur S/MIME délivrance de certificats comme ils l'ont fait pour TLS certificats, réduisant le risque d'émission de certificats non autorisés.
Indicateurs et balises définis par l'autorité de certification
Le CAA tel que décrit dans la RFC 6844 ne définit spécifiquement que deux états d'indicateur (0 et 1) et trois étiquettes (aide, issue et iodéf). Cependant, il laisse la conception suffisamment ouverte pour que les autorités de certification puissent créer et utiliser des balises et des indicateurs personnalisés pour définir leur processus d'émission de certificat. Des exemples pourraient être:
example.com. Problème CAA 0 "SSL.com; policy = ev"
Cet enregistrement utilise une norme aide avec un paramètre supplémentaire qui indique à l'autorité de certification d'utiliser sa stratégie de validation étendue (EV) lors de l'émission d'un certificat pour ce domaine.
example.com. CAA 128 pca "PCA = 12345"
Le propriétaire du domaine pourrait utiliser cet enregistrement avec une nouvelle définition définie par l'autorité de certification pca pour montrer qu'ils ont un compte client préféré et définit le numéro de compte comme paramètre. (L'indicateur peut également être une valeur personnalisée pouvant aller jusqu'à 255.) Selon la façon dont l'autorité de certification configure le compte, cela peut permettre des méthodes de facturation particulières, une vérification supplémentaire définie par le compte ou d'autres traitements spéciaux.
Avantages et inconvénients
Il existe plusieurs excellentes raisons d'utiliser CAA. Le principal avantage de CAA est sa capacité à réduire considérablement le risque d'émission de certificats erronés. Cela contribue à protéger votre domaine, votre entreprise et votre identité en ligne. Les attaquants potentiels qui auraient découvert une faille dans le logiciel d'une autorité de certification ne peuvent pas l'exploiter pour émettre des certificats SSL pour votre domaine. De plus, l'utilisation de la balise iodef vous permet d'obtenir un rapport en cas de tentative d'exploitation.
La conception de CAA augmente la sécurité, mais peut également permettre une allocation plus détaillée des ressources - par exemple, une entreprise pourrait créer des enregistrements pour permettre (ou limiter) le service des ventes et du marketing à acheter des certificats SSL pour sales.example.com auprès d'une source désignée.
De plus, CAA offre une grande flexibilité. Pour un propriétaire de domaine, il utilise des enregistrements de ressources DNS qui sont sous leur propre contrôle et peuvent être modifiés au besoin, de sorte qu'ils ne sont pas liés à une autorité de certification spécifique (et peuvent avoir plus d'une autorité de certification autorisée avec des enregistrements de problème pour un nom de domaine donné) . Pour les autorités de certification, même en dehors des utilisations personnalisées, les règles récemment adoptées par le forum CA / B (le groupe qui définit les normes en matière de sécurité des autorités de certification et des navigateurs) peuvent autoriser l'utilisation des enregistrements CAA à des fins de validation, ce qui constitue une autre bonne raison de les utiliser.
L’un des inconvénients est que même lorsque les enregistrements CAA sont en place, un utilisateur ne peut pas imposer son utilisation par une autorité de certification. Une autorité de certification doit être conforme à la RFC 6844 pour que ces enregistrements soient traités, et une autorité de certification non conforme peut simplement ignorer les souhaits exprès du propriétaire du domaine tels qu'ils sont déclarés dans ses enregistrements CAA.
CAA doit également être correctement configuré par le propriétaire du domaine et une autorité de certification. Let's Encrypt (qui prend en charge CAA) récemment a signalé un problème mineur avec leur base de code ce qui a malheureusement conduit au non-respect des règles de la CAA et à la mauvaise délivrance de six certificats. Aucune de ces exceptions n'était malveillante (et félicitations à l'équipe Let's Encrypt pour avoir résolu et signalé le problème dans les heures suivant la découverte). Cependant, cela souligne qu'une autorité de certification conforme doit mettre en œuvre CAA sans faille.
Un autre problème potentiel est la dépendance de la CAA envers le DNS. À moins qu'un propriétaire de domaine ne sécurise ses services de noms, cela peut être un vecteur d'attaque. La RFC 6844 suggère de mettre en œuvre Extensions de sécurité du système de noms de domaine (DNSSEC), qui utilise des enregistrements DNS signés numériquement pour authentifier les données et lutter contre la menace d'usurpation DNS.
Enfin, même avec CAA en place et correctement implémenté, un enregistrement CAA ne peut à lui seul empêcher complètement l'émission de certificats non fiables. Bien que CAA soit un outil utile et important pour limiter les options d'un attaquant, un pirate de l'air disposant d'un accès suffisant (par exemple, en contrôlant le DNS ou via l'ingénierie sociale) peut être en mesure de le contourner.
Conclusion
L'autorisation d'autorité de certification (CAA) présente un potentiel considérable dans le cadre d'un écosystème de sécurité plus large. Son adoption et sa mise en œuvre généralisées permettront de prévenir les erreurs d'émission de certificats. Bien que la CAA ne suffise pas à elle seule à empêcher toutes les erreurs d'émission de certificats, elle constitue un pas dans la bonne direction. SSL.com vous encourage vivement à envisager d'utiliser vous-même les enregistrements CAA.
Références
- RFC6844: enregistrement de ressource d'autorisation de l'autorité de certification DNS (CAA)
- RFC5070: format d'échange de description d'objet incident
- RFC6546: Transport de messages de défense inter-réseau (RID) en temps réel sur HTTP /TLS
- RFC4033: Introduction à la sécurité DNS et exigences
- CA / B Forum Ballot 125 - Dossiers CAA
- Entrée Wikipedia sur l'autorisation de l'autorité de certification DNS
Guides relatifs
- Quelles sont les exigences pour SSL.com SSL /TLS Validation du domaine du certificat?
- Quelle est la « valeur unique » utilisée dans la validation de domaine (DV) ?
- Nom de domaine SSL /TLS Pré-validation
