Opération blindage pour l'adressage du Web
VeriSign et l’Icann ont posé les fondements pour une généralisation du protocole DNSSEC, permettant de sécuriser les noms de domaine sur le Web. Sur les serveurs racine de l'Internet, le déploiement débutera d’ici à la fin de l’année.
C'est parti ! L'Icann, l'organisme qui gère les noms de domaine, et l'opérateur VeriSign ont décidé de mettre les bouchées doubles dans l'implémentation du protocole DNSSEC (DNS Security Extensions) avec, à la clé, une feuille de route précise pour le déploiement sur les serveurs racine. Ensuite, Verisign implémentera ce protocole sur les domaines .com et .net, dont il est responsable.
DNSSEC est un protocole qui, grâce à un système de signature électronique, permet de vérifier l'authenticité de la réponse d'un serveur DNS. Son fonctionnement est hiérarchique. Chaque serveur d'une zone DNS (.fr, .com, inria.fr, etc.) disposera d'une paire de clés de signature à chiffrement asymétrique, appelée Zone Signing Keys (ZSK). L'une des clés est publique, l'autre privée. Cette dernière sert à signer les données DNS que délivre le serveur de zone. Un client DNS qui reçoit une réponse signée d'un de ces serveurs pourra déchiffrer la signature au moyen de la clé publique et vérifier, ainsi, la provenance et l'intégrité des données.
Pour autant, ce système de clés ne permet pas de savoir à 100 % si le serveur lui-même est réellement digne de confiance : un usurpateur pourrait se substituer à lui et diffuser ses propres ZSK. C'est pourquoi les serveurs de zone disposent d'une deuxième paire de clés asymétriques. Appelées Key Signing Keys (KSK), elles servent à signer les ZKS des zones inférieures (01net.com, afnic.fr, etc.), créant ainsi une chaîne de confiance sur l'ensemble des URL. Un navigateur n'obtiendra la confiance d'une zone de niveau n (01net.com), que s'il a obtenu la confiance des zones de niveau supérieur (.com).
Une paire de clés maître pour sécuriser tout l'Internet
La mise en œuvre de DNSSEC est discutée depuis longtemps, mais elle n'est envisagée sérieusement que depuis la découverte d'une grave faille dans le DNS en 2008 qui, justement, faisait apparaître la possibilité d'usurper un serveur DNS et de dévier un trafic Web vers des sites pirates. La grande difficulté dans l'implémentation de DNSSEC est la gestion hiérarchique des clés. Or, l'Icann et VeriSign sont maintenant tombés d'accord sur la manière d'introduire ce protocole au niveau des serveurs racine, afin de créer la base de cette chaîne de confiance.
Ainsi, les ZSK des serveurs racine seront générées et détenues par VeriSign, qui les renouvellera tous les trois mois. Ces ZSK seront signés par une paire de clés maître KSK, qui sera générée et détenue par l'Icann. Toute la sécurité de DNSSEC s'appuiera in fine sur cette fameuse paire de clés KSK, sur laquelle l'organisme veillera comme sur un véritable trésor. Sauvegardée et dupliquée sur deux sites physiques distincts, cette paire est renouvellée tous les deux à cinq ans. Sa gestion – création, activation, signature, renouvellement, sauvegarde, etc. – est répartie sur sept personnes de la communauté Internet qui devront se coordonner. Ainsi, une procédure de génération ou de signature nécessitera la présence physique d'au moins trois d'entre eux.
Les principes techniques sont décrits dans un document de travail, disponible sur le site du NTIA (National Telecommunications and Information Administration).
Les domaines .com et .et opérationnels d’ici à mars 2011
Côté déploiement, le planning est serré. La génération des premières clés maître KSK se fera en décembre prochain. Le déploiement des clés ZSK sur les 13 serveurs racine se fera dans la foulée, mais de manière progressive, jusqu'en mai ou juin 2010. VeriSign s'attaquera ensuite aux domaines .com et .net. Sur ces deux zones, DNSSEC devrait être opérationnel d'ici à la fin du premier trimestre 2011. L'opérateur va aider les bureaux d'enregistrement dans leur migration vers DNSSEC. Il a également mis en place un laboratoire d'interopérabilité pour tester la conformité des équipements et logiciels réseaux avec ce protocole.
Les .com et .net ne seront pas les premiers domaines à adopter DNSSEC, comme le montre la carte du fournisseur Xelerance. Les .org et .gov ont déjà passé le cap, ainsi que certains domaines de pays (Suède, République tchèque, Bulgarie, Brésil, Porto Rico, Namibie, Thaïlande, Turkmenistan). Pour le .fr, le déploiement de DNSSEC est géré au sein du projet IDSA.
Il faut préciser, toutefois, que ce protocole n'est pas une solution magique. « DNSSEC est une composante importante de la sécurité sur Internet, mais ne résout pas tous les problèmes, explique Ken Silva, directeur technique de VeriSign, dans un communiqué. C'est pourquoi il faut mettre en place d'autres couches de protection, comme l'Extended Validation SSL ou l'authentification à double facteur. »
couverture médiatique
de
jve$$
, posté le 24 novembre 2009 à 12h47
C'est bien pour Verisign, ça leur fait de la pub, mais en input direct, ça leur rapporte pas un rond. Ca doit être pour cela que DNSSEC n'a pas été implémenté avant :)
Concernant les certificats Extended Validation, la par contre c'est du pur produit Verisign, et cher en plus !
Concernant les certificats Extended Validation, la par contre c'est du pur produit Verisign, et cher en plus !
Update : DNSSEC, c'est parti !
de
Nacyl
, posté le 29 janvier 2010 à 12h30
Le coup d'envoi est lancé pour la migration de 13 serveurs racine.
Une question cependant ce pose et qui n'est pas mentionnée dans l'article.
Une "nouveauté" de DNSSEC est de pouvoir gérer des paquets dont la taille est supérieure aux 512 octets retenue dans la précédente documentation du protocole DNS (RFC 1305) comme prévu dans la RFC 2671.
Bonne idée pour chiffrer les transactions DNS de bout en bout pour autant que tous les équipements concernés soient mis à jour !
Car certains vieux matériels (routeurs, firewalls, etc...) risquent, en ne gérant pas convenablement (voir pas du tout) les paquets DNS > 512 octets de priver les réseaux qui se trouvent derrière d'accès à internet...
Une question cependant ce pose et qui n'est pas mentionnée dans l'article.
Une "nouveauté" de DNSSEC est de pouvoir gérer des paquets dont la taille est supérieure aux 512 octets retenue dans la précédente documentation du protocole DNS (RFC 1305) comme prévu dans la RFC 2671.
Bonne idée pour chiffrer les transactions DNS de bout en bout pour autant que tous les équipements concernés soient mis à jour !
Car certains vieux matériels (routeurs, firewalls, etc...) risquent, en ne gérant pas convenablement (voir pas du tout) les paquets DNS > 512 octets de priver les réseaux qui se trouvent derrière d'accès à internet...
à lire aussi
SUR LES MÊMES THÈMES 


nos newsletters
Abonnez-vous à Micro Hebdo : 4,90 €/mois
Abonnez-vous à l'Ordinateur Individuel : 3 €/mois
Abonnez-vous à la version digitale
Abonnez-vous à 01Business et Technologies : 19 €/mois












agrandir la photo





alerter le modérateur