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 TLSA
enregistrement 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.