13 février 2015

Introduction à DNSSEC

dnssec

DNSSEC est une suite d’extensions visant à sécuriser le protocole DNS dont les premiers travaux datent de 1997 et qui a été mise en œuvre le 15 juillet 2010, date de la signature de la zone racine.

Des statistiques sur son déploiement sont difficiles à obtenir mais d’après quelques sources qui s’y risquent (http://www.internetsociety.org/deploy360/dnssec/statistics/), DNSSEC n’est encore que très faiblement déployé.

Les fonctionnalités de DNSSEC

DNSSEC permet l’authentification des réponses DNS en signant les enregistrements par cryptographie à clé publique. Chaque zone possède un ensemble d’enregistrements contenus dans des RRset (Resource Record Set) pouvant par exemple pointer vers une adresse IP comme dans le protocole original (A record). De nouveaux types d’enregistrements font leur apparition :

  • DNSKEY : une clé publique signant des enregistrements RRset.
  • DS (Delegation Signer) : le hash de la clé publique de la zone parente.
  • RRSIG (Resource Record Signature) : la signature d’un RRset par une DNSKEY.

Les DNSKEY peuvent être de deux types :

  • KSK (Key Signing Key) : la clé publique à long terme utilisée pour vérifier la signature du RRset des DNSKEY.
  • ZSK (Zone Signing Key) : la clé publique à court terme utilisée pour vérifier la signature des autres RRset.

La KSK signe la ZSK qui elle-même signe les enregistrements, permettant à cette dernière d’être changée fréquemment pour la rendre difficile à casser pour un attaquant. La KSK devra faire au moins 2048 bits et sera changée tous les 1 à 2 ans et la ZSK devra faire au moins 1024 bits et être changée tous les 1 à 3 mois.

Les enregistrements DS permettent de créer une chaîne de confiance (http://en.wikipedia.org/wiki/Chain_of_trust) que ce schéma venant d’un excellent article de CloudFlare (https://blog.cloudflare.com/dnssec-an-introduction/) explique très bien :

La zone racine signe donc la zone top-level .com signée par Verisign, qui, elle-même, signe les noms de domaines directement sous elle comme google.com.

DNSSEC prévoit également un autre type d’enregistrement NSEC, permettant d’affirmer qu’un nom demandé n’existe pas.

Les bienfaits de DNSSEC

En 2008, Dan Kiminksy (http://en.wikipedia.org/wiki/Dan_Kaminsky) avait trouvé un défaut fondamental dans le protocole DNS permettant le “cache poisoning” de nombreux serveurs DNS. Un attaquant pouvait corrompre le cache d’un résolveur récursif, en répondant avant un serveur faisant autorité à une requête DNS émise par ce résolveur. Des contre-mesures ont permis de rendre cette attaque plus difficile, mais la nature non-authentifiée de DNS fait qu’elle ne peut pas être éradiquée.

DNSSEC ajoutant de l’authentification par de la cryptographie à clé publique préserve l’intégrité des données retournées par les serveur faisant autorité, tout en maintenant une compatibilité arrière avec le protocol d’origine.

Les défauts de DNSSEC

Alors si DNSSEC présente cet avantage certain, comment peut-on expliquer son retard d’adoption ? Tout d’abord parce que l’utilisateur final ne se rend pas compte de ce qu’il apporte, et ensuite parce qu’il n’est pas exempt de certains défauts :

  • DNSSEC est un protocole lourd au coût élevé. La signature de la zone top-level .org a coûté plusieurs millions d’euros et a mobilisé jusqu’à 30 à 40 personnes pendant plus de deux ans d’après Ram Moham, directeur technique d’Afilias (http://en.wikipedia.org/wiki/Afilias).
  • DNSSEC ne préserve pas la confidentialité des données, les requêtes et les réponses n’étant pas chiffrées.

Dan Bernstein (http://en.wikipedia.org/wiki/Daniel_J._Bernstein), virulent critique de DNSSEC en expose d’autres dans une présentation datant de 2011 (http://vimeo.com/18279777) :

  • DNSSEC via son système de NSEC expose le contenu des zones.
  • DNSSEC présente un facteur d’amplification de bande passante bien supérieur à celui déjà pourtant élevé de DNS, les réponses DNS étant plus longues que les requêtes. Mais dans DNSSEC, les réponses contiennent en plus des clés et des signatures. Cela permettrait à un attaquant de mener des attaques par réflexion (http://en.wikipedia.org/wiki/Reflection_attack) bien plus efficaces. Ce type d’attaque est possible car DNS utilise principalement UDP.

Dan Bernstein a créé DNSCurve, une alternative à DNSSEC, utilisant de la cryptographie par courbe elliptique (http://en.wikipedia.org/wiki/Elliptic_curve_cryptography), dont les clés sont plus courtes, réglant ce dernier problème. DNSCurve est entièrement chiffré. OpenDNS s’est déclaré en 2010 très favorable à ce protocole et très critique envers DNSSEC (http://blog.opendns.com/2010/02/23/opendns-dnscurve/). DNSCurve n’a pourtant pas gagné en popularité depuis.

Plus de détails dans cet article de CloudFlare (http://blog.cloudflare.com/dnssec-complexities-and-considerations/). Les réponses de Dan Kaminsky aux critiques de Dan Bernstein peuvent être trouvées sur son blog : http://dankaminsky.com/2011/01/05/djb-ccc/.

DNSSEC un protocole d’avenir ?

Malgré tout, un gros effort a été fait pour déployer DNSSEC. Aujourd’hui la plupart des zones top-level ont été signées. DNSSEC, bien que n’étant pas parfait, est tout de même une évolution souhaitable de DNS. DNSSEC protège-t-il de la surveillance d’état ? En partie.

La “master key” de la zone racine est partagée entre 7 individus (https://www.schneier.com/blog/archives/2010/07/dnssec_root_key.html) dont Dan Kiminksy. Il est donc impossible pour un état de signer des données avec. En revanche la clé privée de .com appartient à Verisign et est donc accessible à NSA. Alors préférez un autre top-level ! Pour plus d’information sur le sujet, un bon article de Stéphane Bortzmeyer : http://www.bortzmeyer.org/dnssec-racine-nsa.html.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *