Pourquoi ne pas valider les certificats auto-signés via un enregistrement DNS au lieu de letsencrypt


16

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



Merci Håkan! Grâce à une mise à jour, j'ai trouvé le terme DANE pour ce RFC. Dernière version du RFC: tools.ietf.org/html/rfc7671 Voir aussi: en.wikipedia.org/wiki/… (je le lirai plus tard).
Jelmer Jellema

2
Le «pourquoi pas» est également couvert dans le RFC Håkan lié: sans DNSSEC, la fiabilité de l'ensemble du modèle est compromise en raison des vulnérabilités inhérentes au DNS. Il convient également de noter que DNSSEC ne fait rien pour sécuriser le trafic entre les clients et les systèmes récursifs, qui reste sensible à l'homme au milieu usurpation d'identité.
Andrew B

Andrew, je vois le problème avec DNSSEC et MIDM, lorsque DNSSEC n'est pas forcé pour un domaine, et le forçage ne peut être effectué que si chaque recherche est effectuée en vérifiant le serveur de domaine racine pour le tld. Le problème est donc le suivant: nous voulons autoriser l'utilisation d'un certificat DV en demandant au propriétaire d'indiquer sa validité, mais nous ne pouvons pas faire confiance au DNS en raison de sa nature hiérarchique. Le fait que le DNS soit vulnérable à l'usurpation d'identité et aux attaques MIDM fait des certificats DV une sorte de validation externe d'une entrée de domaine. Hmm, je vais continuer à penser ...
Jelmer Jellema

Réponses:


18

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 :

Déploiement TLSA mondial entre le 17 juin

À 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.


6
Je pense que votre dernière phrase a été interrompue.
8bittree

Merci Sebastian, ta réaction est très utile. Veuillez consulter mes commentaires et ceux d'Andrew dans le cadre du PO.
Jelmer Jellema

3
Pourquoi est-il nécessaire que les serveurs Web implémentent cela? Je pourrais ajouter un certificat auto-signé à la configuration d'apache et mettre moi-même l'empreinte digitale dans le DNS, non?
Jelmer Jellema

1
Il existe également des problèmes de performances et d'évolutivité avec DNSSEC par rapport à DNS: le DNS ordinaire peut utiliser des réponses "prédéfinies" mais DNSSEC doit faire de la cryptodance pour chaque demande, et il y a BEAUCOUP de demandes DNS qui circulent. Comme, BEAUCOUP de requêtes DNS.
Joker_vD

4
@Joker_vD DNSSEC signe les données, pas le trafic. C'est-à-dire, du côté autoritaire, vous pouvez signer votre zone et ne pas avoir plus de «cryptodance» pendant la durée de vie des signatures (ou jusqu'à ce que vous changiez les données de la zone); c'est du côté du validateur (côté client) que la «cryptodance» par requête non mise en cache doit se produire. Les données supplémentaires et l'état DNSSEC correspondent au modèle de mise en cache général pour DNS.
Håkan Lindqvist

5

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.


Merci Håkan. Comme Andrew le fait remarquer dans mon OP, il y a un problème avec DNS et DNSSEC, car DNSSEC n'est pas forcé (pas même lorsque les clés sont en place au niveau du DNS TLD, je suppose). Les serveurs DNS en cours de route pourraient usurper les informations DANE , droite? Donc, DNSSEC devrait être obligé pour que les enregistrements DANE soient valides, ce qui signifie que chaque vérification doit également vérifier les clés sur le serveur TLD.
Jelmer Jellema

5
@JelmerJellema Comme je l'ai noté dans ma réponse, DNSSEC doit être validé sur le client (ce n'est pas le problème signalé par Andrew) et seuls les enregistrements TLSA signés validés avec succès peuvent être utilisés. Ce problème dont vous parlez n'est pas un problème en termes de conception, c'est un problème en termes de support dans les logiciels traditionnels.
Håkan Lindqvist

2
Bien qu'ils ne soient pas parfaits, de plus en plus de serveurs de noms récursifs chez les FAI ou ouverts, comme 8.8.8.8 ou 9.9.9.9, font la validation DNSSEC. dnssec-trigger construit sur des éléments non liés et / ou stubby permettrait d'avoir une validation DNSSEC complète sur les clients sans nécessairement un résolveur DNS complet de validation sur le client. Mais on est bien loin de ça ...
Patrick Mevzek
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.