Pourquoi utiliser CAA?
Une autorité de certification 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.
Comment CAA fonctionne
CAA utilise DNS
La 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 et Plus-value, 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 le drapeau (zéro est la valeur par défaut - nous en parlerons ci-dessous). 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 must comprendre complètement la balise de propriété pour continuer. La RFC 6844 laisse d'autres possibilités ouvertes pour l'utilisation d'indicateurs définis par l'utilisateur (nous en parlerons également 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.)
La aide Étiquette
La 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).
La 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 tous 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…
La 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 sont un type spécial de sous-domaine fourre-tout, et une attention et une attention particulières sont méritées lors de la délivrance de certificats génériques. le 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 TOUTE 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.
La 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.)
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
Avantages…
Il existe plusieurs excellentes raisons d'utiliser CAA. Le principal et le plus important avantage est la capacité de la CAA à réduire considérablement le risque de mauvaise émission de certificat. Cela permet de protéger votre domaine, votre entreprise et votre identité en ligne. Les attaquants potentiels susceptibles d'avoir trouvé un bogue dans le logiciel d'une autorité de certification particulière 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 si un exploit est tenté.
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.
… Et les inconvénients
Le plus gros problème avec la CAA est qu'elle n'a pas été adoptée par tous les CA. Les exigences de base du forum CA / B (auxquelles toutes les autorités de confiance de confiance remplissent) ordonnent à une autorité de certification de spécifier dans quelle mesure elle prend en charge la CAA dans sa documentation en ligne. Au moment d'écrire ces lignes, cependant, l'utilisation de la CAA est uniquement recommandé, non requis. Les autorités de certification qui ne sont pas conformes à CAA peuvent toujours être ciblées, et jusqu'à ce que la CAA soit plus largement utilisée, un pirate de l'air sera probablement en mesure de trouver une autorité de certification non conforme disposée à émettre un certificat frauduleux.
Un inconvénient connexe est que même lorsque des 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 must 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 de l'autorité de certification a un potentiel formidable dans le cadre d'un écosystème de sécurité plus large, et l'adoption et la mise en œuvre généralisées de la CAA protègeront contre la mauvaise délivrance des certificats. S'il est malheureux que toutes les autorités de certification ne prennent pas en charge actuellement CAA, il y a des discussions pour rendre cela plus fortement suggéré ou obligatoire pour toutes les CA. Bien que la CAA seule n'empêchera pas chaque émission erronée de certificats, c'est un bon pas dans la bonne direction, et SSL.com vous invite à envisager d'utiliser vous-même les enregistrements CAA.
Bibliographie
- 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
