Je me demandais juste. Nous utilisons beaucoup de certificats SSL. De nos jours, nous utilisons presque exclusivement letsencrypt (merci!). L'essentiel de ces certificats est que la preuve de la propriété du ou des noms de domaine sur le certificat provient du pouvoir de manipuler les enregistrements DNS ou le site Web sous ces domaines. La preuve DNS vient de l'ajout d'une clé (donnée par letsencrypt) en tant qu'enregistrement TXT au DNS.

Donc, si c'est une preuve suffisante pour pouvoir modifier les enregistrements DNS d'un domaine, pourquoi ne pas utiliser des certificats auto-signés avec l'empreinte digitale dans le DNS?

Je dirais que cela donne exactement la même quantité de confiance que la procédure basée sur DNS de letsencrypt (et d'autres autorités de certification):

1. Créez une CA auto-signée (suivez simplement les étapes des différentes procédures)
2. Créer un certificat pour certains domaines
3. Signez le certificat de l'étape 2 avec l'autorité de certification de l'étape 1. Vous disposez maintenant d'un certificat de base, signé par une autorité de certification non approuvée
4. Ajoutez un enregistrement TXT (ou dédié) au DNS de chacun des domaines, déclarant: nous avons signé le certificat de ce domaine avec cette autorité de certification. Comme: 'CA = -fingerpint of CA-'
5. Un navigateur télécharge le certificat et le vérifie en comparant l'empreinte digitale de l'autorité de certification / de l'autorité de certification avec les données du DNS pour le domaine donné.

Cela permettrait de créer des certificats auto-signés de confiance sans intervention de tiers, du même niveau de confiance que n'importe quel certificat SSL de base. Tant que vous avez accès au DNS, votre certificat est valide. On pourrait même ajouter du DNSSEC comme le chiffrement, de faire un hachage à partir de l'AC plus l'enregistrement SOA, pour s'assurer que la confiance disparaît lors des changements dans l'enregistrement DNS.

Cela a-t-il déjà été envisagé?

Jelmer

L'infrastructure de base, qui rendrait cela possible, existe et est appelée authentification basée sur DNS des entités nommées (DANE) et spécifiée dans la RFC6698 . Il fonctionne au moyen d'un TLSAenregistrement de ressource, qui spécifie le certificat ou sa clé publique de l'entité finale ou l'une de ses autorités de certification dans la chaîne (il existe en fait quatre types différents, voir le RFC pour plus de détails).

Adoption

DANE n'a cependant pas encore été largement adopté. VeriSign surveille l' adoption de DNSSEC et DANE et suit sa croissance au fil du temps :

À titre de comparaison, selon VeriSign, il existe environ 2,7 millions de zones DNS, ce qui signifie qu'un peu plus de 1% de toutes les zones ont au moins un enregistrement TLSA.

Je ne peux pas donner de réponse faisant autorité, pourquoi DANE, mais voici mes spéculations:

DANE souffre du même problème que les listes de révocation de certificats (CRL) et le protocole OCSP (Online Certificate Status Protocol). Afin de vérifier la validité d'un certificat présenté, un tiers doit être contacté. Hanno Böck donne un bon aperçu , pourquoi c'est un gros problème dans la pratique. Cela se résume à la question de savoir quoi faire, lorsque vous ne pouvez pas joindre le tiers. Les fournisseurs de navigateurs ont opté pour un échec logiciel (aka permit) dans ce cas, ce qui a rendu le tout plutôt inutile et Chrome a finalement décidé de désactiver OCSP en 2012.

DNSSEC

On peut dire que le DNS offre une bien meilleure disponibilité que les serveurs CRL et OCSP des autorités de certification, mais il rend toujours impossible la vérification hors ligne. De plus, DANE ne doit être utilisé qu'en association avec DNSSEC. Comme le DNS normal fonctionne sur UDP non authentifié, il est assez sujet à la falsification, aux attaques MITM, etc. L'adoption de DNSSEC est bien meilleure que l'adoption de DANE, mais est encore loin d'être omniprésente.

Et avec DNSSEC, nous nous heurtons à nouveau au problème de l'échec logiciel. À ma connaissance, aucun système d'exploitation serveur / client majeur ne fournit par défaut un résolveur DNSSEC de validation.

Il y a aussi la question de la révocation. DNSSEC n'a pas de mécanisme de révocation et s'appuie plutôt sur des clés de courte durée.

Support logiciel

Tous les logiciels participants doivent implémenter le support DANE.

En théorie, vous pourriez penser que ce serait le travail des bibliothèques de crypto et les développeurs d'applications n'auraient pas à faire grand-chose, mais le fait est que les bibliothèques de cryptographie ne fournissent généralement que des primitives et que les applications doivent faire beaucoup de configuration et d'installation elles-mêmes (et il y a malheureusement de nombreuses façons de se tromper).

Je ne suis pas au courant que n'importe quel serveur Web majeur (par exemple Apache ou nginx), par exemple, a implémenté DANE ou a des plans pour le faire. Les serveurs Web sont d'une importance particulière ici, car de plus en plus de choses reposent sur les technologies Web et sont donc souvent les premiers, où les choses sont implémentées.

Lorsque nous regardons les listes CRL, OCSP et OCSP Stapling à titre de comparaison, nous pourrions être en mesure de déduire comment se déroulera l'adoption de DANE. Seules certaines applications, qui utilisent OpenSSL, libnss, GnuTLS, etc. prennent en charge ces fonctionnalités. Il a fallu un certain temps pour que des logiciels majeurs comme Apache ou nginx le prennent en charge et se référant à nouveau à l'article de Hanno Böck, ils se sont trompés et leur mise en œuvre est défectueuse. D'autres projets logiciels majeurs, comme Postfix ou Dovecot , ne prennent pas en charge OCSPet ont une fonctionnalité CRL très limitée, pointant essentiellement vers un fichier dans le système de fichiers (qui n'est pas nécessairement relu régulièrement, vous devrez donc recharger votre serveur manuellement, etc.). Gardez à l'esprit qu'il s'agit de projets qui utilisent fréquemment TLS. Ensuite, vous pouvez commencer à regarder les choses, où TLS est beaucoup moins courant, comme PostgreSQL / MySQL par exemple et peut-être qu'ils offrent au mieux des CRL.

Je n'ai donc même pas mis en œuvre de serveurs Web modernes et la plupart des autres logiciels n'ont même pas eu le temps d'implémenter OCSP et CRL, bonne chance avec votre application ou appareil d'entreprise de 5 ans.

Applications potentielles

Alors, où pourriez-vous réellement utiliser DANE? Pour l'instant, pas sur Internet en général. Si vous contrôlez le serveur et le client, c'est peut-être une option, mais dans ce cas, vous pouvez souvent recourir à l'épinglage de clé publique.

Dans l'espace de messagerie, DANE obtient une certaine traction, car SMTP n'avait aucun type de cryptage de transport authentifié depuis le plus longtemps. Les serveurs SMTP ont parfois utilisé TLS entre eux, mais n'ont pas vérifié que les noms dans les certificats correspondaient réellement, ils commencent maintenant à vérifier cela via DANE.

Différents types de procédures de validation des certificats

Avec les certificats réguliers signés par une autorité de certification, il existe plusieurs niveaux de validation de certificat:

• Validation de domaine (DV)
  Seule la propriété du nom de domaine est validée, seul le nom de domaine est affiché comme "Objet" dans le certificat
• Validation de l'organisation (OV) Le
  nom de domaine et le nom du propriétaire sont validés, le nom de domaine et le nom du propriétaire apparaissent comme "Objet" dans le certificat
• Validation étendue (EV)
  Une validation plus rigoureuse de l'entité propriétaire, le nom de domaine et le nom du propriétaire apparaissent comme "Sujet" dans le certificat, barre verte avec le nom du propriétaire

Le processus que vous décrivez et que vous proposez de remplacer ne s'applique qu'au niveau le plus bas, la validation de domaine (DV).

DV est le niveau où la validation est relativement simple à automatiser, comme ce que LetsEncrypt a fait, et fournit un niveau de confiance similaire à ce que DNS pourrait fournir s'il était utilisé comme source unique pour une ancre de confiance (implications pour l'interface utilisateur, certifications peuvent sont fiables mais contiennent des données supplémentaires qui ne sont en aucun cas validées).

Authentification basée sur DNS des entités nommées (DANE)

DANE s'appuie sur DNSSEC (car l'authenticité des données DNS est cruciale) pour publier des informations d'ancrage de confiance pour les clients TLS dans DNS.

Il utilise le TLSAtype RR et peut être utilisé pour identifier le certificat ou la clé publique ( sélecteur ) de l'entité finale ou de l'autorité de certification, avec ou sans nécessiter également la validation régulière de la chaîne de certificats pour réussir ( utilisation du certificat ) et comment le certificat / Les données clés sont représentées dans l'enregistrement ( type correspondant ).

Le TLSAnom du propriétaire de l'enregistrement a un préfixe qui indique le port et le protocole (par exemple _443._tcp) et le RData indique les modes cert usage, selectoret matching typeen plus des données de certificat / clé à faire correspondre. Voir la section 2.1 de RFC6698 pour les spécificités de ces paramètres.

Un TLSAenregistrement peut par exemple ressembler à ceci:

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

Avec les modes d'utilisation 2ou 3(indique l'utilisation de l'ancre de confiance TLSA seule), un client prenant en charge DANE accepterait un certificat qui n'est pas signé par une autorité de certification généralement approuvée mais qui correspond à l' TLSAenregistrement.
Ceci est conceptuellement le même que ce que vous proposez dans votre question.

Le hic? Les clients prenant en charge DANE sont actuellement plus ou moins inexistants, un problème étant que DNSSEC lui-même n'est pas aussi largement déployé (en particulier la validation sur la machine cliente) que ce qui serait probablement nécessaire pour que DANE décolle. Probablement un problème de poule et d'oeuf, étant donné que DANE est l'un des premiers nouveaux cas d'utilisation potentiellement importants qui s'appuient sur des données DNS authentifiées.

Il existe un plugin de navigateur qui ajoute la validation DNSSEC et DANE , à part le fait qu'il n'y a pas grand-chose là-bas qui soit loin d'être traditionnel à ce stade. Et, étant un plugin plutôt que supporté nativement, il sert plus de preuve de concept que toute autre chose lorsqu'il s'agit d'une utilisation générale.

Cela pourrait être fait. Cela a été considéré. Cela pourrait encore arriver, mais il n'y a pas eu beaucoup de mouvement.