Quentin Duchemin : Bonjour à toutes et à tous. Bienvenue sur Graf’hit 94.9. Vous écoutez La Voix Est Libre, une émission créée par Picasoft [1], une association compiégnoise qui s’est donné pour mission de sensibiliser les citoyens et les citoyennes aux enjeux du numérique et qui héberge des services web libres et respectueux de la vie privée.
Pour l’émission d’aujourd’hui, je suis avec Talitha. Salut Talitha.

Talitha : Salut Quentin.

Quentin Duchemin : On va parler DNS. Alors, qu’est-ce que c’est le DNS ? Eh bien c’est tout l’objectif de cette émission de le découvrir en détail et, pour ce faire, on a le plaisir et l’honneur de recevoir Stéphane Bortzmeyer. Bonjour Stéphane.

Stéphane Bortzmeyer : Bonjour.

Quentin : Stéphane, tu es ingénieur à l’Afnic [Association française pour le nommage Internet en coopération] [2]. L’Afnic, encore un acronyme dont le grand public ne sait pas bien ce qu’il signifie. Tu es à l’origine d’un des premiers sites français qui a été mis en ligne, pionnier de la promotion du chiffrement en France ; tu es notamment spécialiste des questions de DNS et tu écris beaucoup à ce sujet et sur plein d’autres sujets sur ton blog, bortzmeyer.org [3].
Talitha, je te passe la main pour les questions.

Talitha : Bonjour Stéphane. Pour les questions, comme l’a soulevé Quentin, la première chose qu’on se dit : on n’ entend jamais parler de l’Afnic et pourtant, c’est une association dont le rôle est essentiel dans le fonctionnement du Web, notamment en France. Est-ce que tu peux nous expliquer un peu ce que c’est et surtout, quel est ton rôle dans cette association ?

Stéphane Bortzmeyer : C’est vrai qu’on n’entend jamais parler de l’infrastructure, ça n’est pas spécifique aux réseaux informatiques. L’infrastructure c’est tout ce qui est indispensable mais qu’on ne voit pas, sauf quand il y a une panne, et là on s’en rend compte. Une infrastructure effectivement essentielle pour l’Internet, c’est le système des noms de domaine, domain name system en anglais, DNS.

C’est tout ce qui permet à ces noms de domaine qu’on voit dans les publicités sur les côtés des bus, c’est tout ce qui leur permet de fonctionner. Vous voulez vous connecter sur Wikipédia, vous avez un nom de domaine fr.wikipedia.org. Le système des noms de domaine c’est tout ce qui va faire que, à partir de ce nom-là, vous allez pouvoir atterrir au bon endroit, visiter le bon serveur et avoir les bons articles sous licence libre que vous vouliez consulter.

Le rôle de l’Afnic dans ce système qui est complexe, où il y a plein d’acteurs, c’est d’être un registre de noms de domaine. Un registre, c’est un type avec une plume d’oie qui écrit sur un parchemin la liste des noms de domaine réservés. En fait, il n’y a pas vraiment de parchemin, c’est une base de données, mais le concept est le même. C’est l’organisation qui garde trace de la liste de tous les noms de domaine existants, des serveurs qui vont contenir les données sur ces domaines, des contacts qu’il faut contacter s’il y a un problème administratif ou technique, et qui s’assure, notamment, de l’unicité de ces noms.

Le rôle de l’Afnic va plus loin, puisqu’il faut aussi gérer les serveurs de noms, donc les machines qui distribueront ces informations. Puis il y a d’autres serveurs, vous avez parfois entendu parler de Whois, qui permet d’accéder aux informations sociales, donc les contacts, leur nom, leur adresse ; si ce sont des personnes physiques, leur nom n’est pas diffusé.
Donc c’est toute cette activité qui, effectivement, n’est pas visible en temps normal, mais est quand même cruciale et on s’en rend compte quand il y a un problème.

Moi, là-dedans, je n’ai pas de responsabilités opérationnelles. Je m’occupe de la formation, de la veille technologique, de la normalisation technique, puisque l’Internet fonctionne parce qu’il y a des normes techniques que tout le monde suit, qui permettent à un navigateur web libre, comme Firefox [4], de consulter un site web hébergé sur une plateforme prédatrice, ou le contraire, parce que tout le monde suit la même norme technique, donc c’est un gros travail d’élaboration. Et puis je m’occupe effectivement de questions pointues liées au DNS, quand il y a des problèmes particuliers liés au DNS.

Talitha : OK, très bien. Donc, en quoi le DNS est-il carrément un élément critique du fonctionnement d’Internet ?

Stéphane Bortzmeyer : Le DNS est un élément critique parce que, simplement, s’il est en panne, pour la grande majorité des usages, c’est comme s’il n’y avait pas d’Internet du tout. Ça s’est vu parfois dans certaines pannes où, pour l’utilisateur, pour M. ou Mme Tout-le-Monde, c’est vraiment comme s’il n’y avait pas d’Internet du tout. En effet, pratiquement toutes les transactions sur Internet commencent par un appel au DNS, puisqu’il faut commencer par obtenir des informations techniques à partir d’un nom de domaine.
Vous voulez aller sur Wikipédia, le nom de domaine va être fr.wikipedia.org. Votre navigateur web va avoir besoin de l’adresse IP du serveur web qui héberge Wikipédia.
Pour ça, il fait appel aux noms de domaine, plus précisément, à deux composants essentiels :

• les serveurs faisant autorité pour un nom de domaine, qui connaît ces informations et les diffuse — dans le cas du .fr ce sont ceux de l’Afnic ; dans le cas de wikipedia.org, ce sont ceux de la fondation qui est derrière Wikipédia ;
• l’autre composant essentiel ce sont les résolveurs, qui sont des serveurs qui sont hébergés, typiquement, chez votre fournisseur d’accès Internet ou par votre service informatique quand vous êtes dans les locaux de votre employeur ; ce sont eux qui vont interroger successivement plusieurs serveurs faisant autorité jusqu’à avoir la réponse qui va être envoyée à M. Tout-le-Monde ou, plus exactement, à son navigateur, et lui permettre à la fin de se connecter, et youpi, il va être content, il va pouvoir s’instruire, il va pouvoir regarder plein de choses.

Du fait que tout commence par une requête au DNS, s’il est en panne, c’est comme s’il n’y avait pas d’Internet, donc c’est vraiment une ressource critique. S’il ment ou s’il est détourné, s’il y a une faille de sécurité, on peut être amené à un tout autre endroit que celui qu’on voulait avoir. Donc c’est très important de soigner l’ensemble de l’écosystème DNS, qu’il soit bien géré et supervisé, qu’on fasse attention aux failles de sécurité et que l’on fasse attention aux autorisations diverses : il ne faut pas que je puisse, par exemple, modifier le nom de domaine de Picasoft ou de Wikipédia. Il faut qu’un nom de domaine ne puisse être modifié que par son titulaire ou les personnes qu’il a désignées.

Donc voilà en quoi c’est une infrastructure critique, même si elle est purement logicielle. Quand je dis infrastructure, les gens pensent parfois à du matériel, des trucs qu’on peut toucher, comme les câbles. Non, le DNS c’est purement logiciel, mais c’est quand même critique.

Talitha : D’accord. Du coup, par rapport aux failles de sécurité dont tu as parlé, notamment de mensonge, quelles sont les différentes actions qu’on peut faire dessus ? Comment travaille-t-on sur le DNS pour le maintenir et le sécuriser ?

Stéphane Bortzmeyer : Un exemple récent, qui a occupé une bonne partie de mon week-end, la faille Log4Shell [5] qui a fait pas mal de bruit récemment. Il s’agit d’un composant logiciel libre utilisé dans un très grand nombre de programmes, un composant un peu planqué, un peu caché, que les utilisateurs ne voient pas, une bibliothèque utilisée par les programmeurs qui est vraiment dans plein de programmes, probablement dans plein de machines sur Internet, qui avait une faille de sécurité sérieuse. Pas mal d’acteurs de l’Internet ont passé le week-end d’abord à vérifier si leurs applications utilisaient Log4j, la bibliothèque en question, et, si oui, si elle était vulnérable. Et si elle l’était, à déployer les mises à jour ou les mesures de contournement visant à limiter les dégâts. C’est le lot habituel de tous les gens qui sont dans l’opérationnel, qui font fonctionner l’Internet au quotidien. Ça affecte aussi le DNS : il se trouve que la plupart des registres de noms de domaine utilisent des programmes écrits en Java, le langage dans lequel la bibliothèque Log4j est utilisée. Donc, ça faisait potentiellement pas mal de problèmes qui auraient pu arriver, ou pas, mais, de toutes façons, il fallait vérifier.

Sinon les deux grands problèmes typiques, d’abord le risque de panne, c’est LE principal risque, ça ne s’est jamais produit depuis la création de l’Afnic. Si ça se produisait, par exemple suite à une panne matérielle, suite à une attaque par déni de service, suite à des problèmes comme ça, si on se retrouvait avec une partie des noms de domaine qui ne fonctionne plus, ce serait évidemment catastrophique. Il y a eu un cas réel il y a quelques années, par exemple quand le domaine national turc, .tr, avait fait l’objet d’une attaque par déni de service qui était apparemment politiquement motivée, une attaque qui visait à empêcher le domaine de fonctionner, et ça avait malheureusement marché. Plus aucun nom de domaine se terminant en .tr ne fonctionnait, donc plus personne ne pouvait visiter par exemple les sites web dont le nom se terminait en .tr, écrire à des gens dont l’adresse de courrier électronique se terminait en .tr, vraiment la grosse catastrophe.
Il y a donc tout un travail qui est fait pour éviter ça, à la fois préventif — avoir beaucoup de machines, bien connectées — et de supervision pour s’assurer que tout ça fonctionne en permanence. On passe beaucoup de temps à regarder des écrans avec du vert et puis, quand il y a du rouge, c’est qu’il y a un problème, il faut faire quelque chose. C’est donc un travail opérationnel permanent, puisque le DNS doit fonctionner 24 heures sur 24, 7 jours sur 7, pas une milliseconde d’interruption puisque certains services qui tournent sur Internet sont cruciaux. L’Internet ne sert pas qu’à regarder des vidéos de chat, il y a aussi des applications vraiment critiques qui doivent marcher tout le temps.

L’autre gros problème est le risque de détournement d’un nom de domaine. C’est compliqué, la sécurité des noms de domaine, il y a beaucoup d’aspects, donc, en gros, il s’agit de vérifier que le système respecte bien les autorisations, que l’on ne puisse pas modifier le nom de domaine de quelqu’un d’autre, surveiller qu’il n’y a pas de failles qui vont apparaître. C’est tout un travail, il faudrait des heures et des heures pour détailler tout l’aspect sécurité des noms de domaine ; il y a beaucoup de choses derrière pour que ça fonctionne bien. Là aussi, on en entend parler quand il y a un problème. Par exemple, il y a deux/trois ans, le nom de domaine de WikiLeaks avait été détourné comme ça. Quelqu’un avait réussi — je ne sais pas comment, je n’ai pas les détails —, mais on avait constaté que le nom de domaine avait été détourné, que l’adresse IP donnée en échange de ce nom de domaine pointait vers un serveur web qui n’était pas celui de WikiLeaks. Les médias, en général, avaient mal rendu compte de l’affaire, comme c’est souvent le cas en sécurité, en prétendant que le serveur web de WikiLeaks avait été piraté ; ça n’est pas du tout vrai. C’était une attaque indirecte : le nom de domaine avait été détourné, donc emmenait vers un autre serveur web qui contenait un message insultant pour WikiLeaks.

Voilà le genre de choses qui occupent les gens qui gèrent les noms de domaine et qui font que le point vraiment important c’est ce côté opérationnel, c’est-à-dire quelque chose qui, comme l’eau, comme l’électricité, doit fonctionner en permanence, malgré les pannes, les attaques, les problèmes comme le Log4shell récemment.

Talitha : Merci Stéphane pour ces réponses qui sont claires et complètes. Nous te remercions également d’avoir été avec nous ce matin. Bonne journée à toi.

Stéphane Bortzmeyer : Merci. Au revoir.

Quentin Duchemin : Merci beaucoup, Stéphane, au revoir.

Bon !, on a bien dégrossi le sujet, c’est chouette. On va pouvoir enchaîner en essayant de détailler un petit peu les sujets que Stéphane a abordé. Comme il le dit, c’est vrai que le DNS est un sujet qui, en plus d’être très peu souvent traité, est extrêmement complexe, notamment du point de vue de sa sécurité.

On va recommencer par la base pour bien ancrer dans les esprits. Talitha, est-ce que ça te dit de nous faire un petit rappel sur la base du DNS ? Et pourquoi est-ce qu’on s’en sert, on va dire le plus traditionnellement ?

Talitha : Bien entendu Quentin. Ce que je vais dire maintenant va peut-être recouper légèrement ce qu’a dit notre invité. On va replacer les termes pour partir sur des bases claires.
D’abord DNS, c’est Domain Name System, un système de noms de domaine. Ce système va définir les règles sur lesquelles on s’accorde pour gérer un problème informatique donné et se comprendre sur le sujet.
Quelle est la problématique dans le cadre du DNS ? En fait, c’est simple. Pour parler entre eux, les ordinateurs ont des adresses, comme nous, il faut bien avoir une adresse pour savoir vers qui aller. Sauf que, pour les ordinateurs, c’est un ensemble de chiffres qui peut être assez long et pas très manipulable au quotidien ; cette adresse s’appelle une adresse IP. Pour ne pas avoir besoin de manipuler au quotidien ces nombres, on va associer à chaque adresse IP un nom, un nom de notre langage à nous, beaucoup plus facile à exploiter que ce soit pour les administrateurs réseau ou pour les utilisateurs.

Par exemple, si vous voulez aller sur le site de Picasoft, vous allez vous rendre sur le site https://picasoft.net, sauf que, en réalité, picasoft.net ne mène nulle part en soi. Le DNS va gérer le passage du terme picasoft.net à l’adresse réelle du serveur Picasoft, qui va vous permettre d’accéder à la page web. C’est pour cela qu’il existe ce qu’on appelle des serveurs DNS.

Il faut bien faire attention avec les serveurs DNS, puisqu’il en existe deux types.
On va avoir les serveurs de noms, qu’on appelle parfois serveur faisant autorité, comme l’avait souligné Stéphane. Ces serveurs sont chargés de stocker les données de correspondance entre les adresses IP et les noms de domaine. Ce sont donc eux qui ont les tables de correspondance et qui ont la donnée principale.
À côté de ça, on a également les résolveurs. Les résolveurs vont faire le lien entre les machines qui ont recours au DNS pour accéder à une adresse et l’adresse en question.

Quentin Duchemin : C’est l’intermédiaire entre les serveurs de noms qui ont la table dont tu parlais, et le client qui, lui, veut savoir, par exemple, à quelle IP correspond picasoft.net.

Talitha : Exactement. Pour illustrer ça avec un exemple, on va garder l’exemple de picasoft net. Si je veux accéder au site picasoft net, mon ordinateur va demander au résolveur : où se trouve picasoft.net ? Le résolveur, à son tour, va demander au serveur de noms à quelle adresse IP correspond picasoft.net. Le serveur de noms lui donne l’adresse IP, le résolveur peut alors me renvoyer l’adresse réelle de la machine de Picasoft et, ainsi, je peux me connecter au site.

Ce rappel c’était principalement pour faire attention aux confusions sur le vocabulaire. Dans le langage courant, on utilise pas mal les termes « DNS », « serveurs DNS », mais les termes sont plus précis que ça.

Quentin Duchemin : Merci Talitha pour avoir reposé les bases.
Bien sûr, quand on dit que, une fois que vous avez interrogé le résolveur, vous pouvez utiliser l’adresse pour contacter le site, ce n’est pas vous directement, c’est votre navigateur, votre ordinateur qui fait tout ça en arrière-plan.
Comme l’a dit Stéphane, le DNS est un système qui est absolument crucial pour le fonctionnement d’Internet, puisque toute requête, toute action qui implique un nom de domaine doit nécessairement passer par le DNS afin d’obtenir une adresse IP qu’un ordinateur sait contacter. Donc « pas de serveur DNS » ça veut dire, notamment sur le Web, pas d’accès au service, quand bien même celui-là serait en pleine forme et fonctionnel. Stéphane nous a donné un exemple. On a un autre exemple récent avec Facebook qui, suite à une erreur de configuration réseau, avait rendu ses serveurs de noms inaccessibles donc, à chaque fois que quelqu’un essayait d’aller sur Facebook, eh bien simplement le serveur de noms ne répondait pas, donc on n’avait pas d’adresse IP, c’est donc comme si Facebook n’existait pas.

C’est d’autant plus crucial aujourd’hui qu’un des premiers problèmes qu’on va traiter tout de suite, qui est lié au DNS, c’est le fait que les serveurs de noms, donc les serveurs faisant autorité, soient très centralisés. On ne va parler que de problèmes aujourd’hui, puisque c’est vraiment notre moto ici !

Une étude récente essaie de regarder qui sont les principaux fournisseurs de serveurs de noms, puisque la plupart des sites web des entreprises n’hébergent pas leurs propres serveurs de noms, ce qui est un problème. Sur les 100 000 sites les plus visités, selon le classement Alexa, 24 % de ces sites utilisent CloudFlare [6], une grande entreprise qui fournit notamment des serveurs de noms ; AWS, Amazon Web Services pour 12 % et GoDaddy [7] pour 4 %. C’est-à-dire que pour 38 % des 100 000 premiers sites du classement Alexa, on a seulement trois fournisseurs de serveurs de noms. Si jamais il y avait une panne sur un de ces fournisseurs, eh bien un quart du Web serait inaccessible.

Notamment en 2016, Dyn, qui est aussi un fournisseur de serveurs de noms qu’il propose aux entreprises, a été victime d’une grande attaque par déni de service qui a paralysé les opérations de l’entreprise et, par là-même, qui a interrompu toutes les opérations de résolution de noms de domaine pour plus de 175 000 sites web.

Là on commence à s’apercevoir qu’il y a quand même beaucoup de problèmes qui se jouent de manière un petit peu invisible.
Avant d’attaquer à nouveau le vif du sujet, on peut peut-être se demander comment est arrivé le DNS ? Comment on faisait au tout début d’Internet, voire avant Internet ? Talitha ?

Talitha : Au tout début d’Internet, même avant le Web, en 1969, toutes les correspondances entre les noms de domaine et les adresses IP tenaient en un seul fichier. C’était un fichier qui était commun à tous les utilisateurs d’Internet, puisque, à cette époque c’était gérable ; ce fichier s’appelait host.txt et il était centralisé. En quelques années c’est devenu assez ingérable étant donné la grande augmentation du nombre d’utilisateurs, donc ça n’a plus été possible de fonctionner avec juste un fichier. Plusieurs solutions ont été proposées et, en 1983, la solution retenue a été le DNS, donc un système qui permet la résolution de noms, pas avec un seul fichier centralisé comme ça l’était initialement, mais en redistribuant la tâche de résolution de nom à plusieurs serveurs qui sont organisés hiérarchiquement.
Quentin, quelle est donc cette hiérarchie dans le DNS ?

Quentin Duchemin : Quel ping-pong endiablé !
Il n’est effectivement pas possible, quand on voit la quantité de noms de domaine qui existent aujourd’hui, de travailler avec une espèce d’annuaire global et centralisé. Déjà, ça ne serait pas possible et sans doute pas souhaitable. Le DNS est donc un système qui a été pensé dès le début pour être hiérarchique et distribué. Il n’y a pas de pouvoir central ni d’annuaire global, comme je l’ai dit.

Comment voit-on cette hiérarchie ? Eh bien on la voit quand on regarde un nom de domaine : on voit bien qu’un nom de domaine est souvent composé de plusieurs parties. Par exemple, picasoft.net, on a « picasoft » et « net ». Le système des noms de domaine est donc une hiérarchie : on peut voir ça comme un arbre dont le sommet unique est appelé la racine. On représente la racine par un point. C’est, en fait, virtuellement comme si on rajoutait un point à la fin de tous les noms de domaine, picasoft.net. ; on ne le met pas par commodité.
À partir d’un domaine, on peut créer un ou plusieurs sous-domaines et chaque partie d’un domaine va correspondre à ce qu’on appelle une zone DNS. Je m’explique : « fr » est une zone DNS et tout ce qu’il y a en-dessous de « fr », par exemple « gouv.fr », eh bien « gouv » va être une autre zone DNS. Dans ce cas-là, la zone fr a délégué la gestion de la zone gouv aux personnes qui gèrent la zone gouv. On peut avoir ce système hiérarchique au sens où chaque zone délègue à des sous-zones qui correspondent aux sous-domaines.

Je vais donner un autre exemple. La racine, pour picasoft.net, c’est le point qu’il y aurait à la fin. Le « .net » est une autre zone gérée sans doute par une organisation comme l’Afnic, qui gère les points fr. Picasoft.net est une zone que nous gérons. Et tout ce qui est en-dessous de picasoft.net, par exemple, tout ce qui est en test.picasoft.net, c’est aussi nous qui le gérons. On a donc une zone qui descend jusqu’à l’infini en dessous de picasoft.net.
On les appelle les domaines qui se trouvent immédiatement sous la racine les domaines de premier niveau, ou TLD pour Top Level Domain, ce sont tous les .fr, .net, .org, etc. Ceux qui ne correspondent pas à une extension de pays sont des domaines génériques, GTLD, Generic TLD, par exemple les .org ou les .com.

Pour la résolution, c’est exactement pareil. Quand un résolveur essaye de nous dire ce qu’est pad.picasoft.net, il va commencer par interroger la racine pour avoir tous les serveurs qui sont capables de lui dire où aller demander les informations pour .net. Ensuite il va demander aux serveurs qui ont les informations pour .net où je peux trouver pad.picasoft.net. Ces serveurs-là vont dire « non, ce n’est pas nous qui nous en occupons, ce sont les serveurs de nom picasoft.net, qu’on peut trouver à cette adresse-là ». Donc, mon résolveur va ensuite aller interroger les serveurs de picasoft.net qui vont dire « j’ai l’information et l’adresse de pad.picasoft.net, c’est cette adresse IP. »

Peut-être pour terminer, on note qu’en pratique il y a tout un système — et c’est important pour la suite — de cache. Ça veut dire que les résolveurs, très souvent, vont retenir des informations qu’on leur a données, de manière à ne pas aller réinterroger, à chaque requête, les serveurs racines, voire les serveurs de point .net. Sinon, vu les millions, dizaines de millions de requêtes, sans doute plus, qui ont lieu chaque seconde, eh bien les serveurs racines devraient répondre la même information : où trouver les infos pour .net, pour .fr, .org, en permanence.

Maintenant qu’on a laborieusement esquissé une idée de comment fonctionne le système hiérarchique des noms de domaine, on va voir que ça pose pas mal de problèmes, dont Stéphane a déjà un petit peu parlé. Le premier problème est un problème de vie privée. Talitha, si tu veux prendre la main ?

Talitha : Bien évidemment.
Comme on l’a précisé au début, ce sont des grosses structures qui détiennent la majorité des DNS qu’on utilise au quotidien, ça va être Google, Cloudflare ou encore nos fournisseurs d’accès à Internet. Comme ce sont eux qui effectuent la résolution de noms, ils récupèrent tous les noms de domaine, toutes les adresses des sites auxquels on veut accéder. Nous fournissons donc à d’autres institutions notre historique de navigation. Comme on peut l’imaginer, ça pose un problème de vie privée en fonction de la structure en question.

Une solution qui existe par rapport à ça, c’est d’avoir recours à un résolveur libre, mais c’est parfois compliqué à mettre en place au quotidien. C’est une solution qui existe, mais pas forcément commune ou viable.

Quentin Duchemin : D’autant que, sur la plupart de nos appareils, on n’est même pas au courant que les résolveurs préconfigurés sont ceux de Google. Comme tu dis, ça n’est pas forcément évident d’aller changer sur le téléphone ou autre.

Talitha : C’est le genre de problème où la solution est simple, mais, le plus gros pas, c’est de savoir qu’il y a un problème.

Quentin Duchemin : Exactement !
Un deuxième souci, assez généralisé, c’est le problème de la censure et ce qu’on appelle les DNS menteurs, des résolveurs qui vont nous renvoyer une fausse réponse. Je reprends la définition récupérée dans un rapport de l’Afnic sur le filtrage : « Le filtrage consiste à modifier le processus normal de résolution du nom d’un serveur vers une adresse IP soit en bloquant la réponse, soit en répondant un message d’erreur, soit en retournant l’adresse d’un autre serveur indiquant généralement que l’accès à ce site est interdit. »

On a plein d’exemples en France : Sci-Hub [8], dont on a parlé dans les émissions sur l’open science, contient une version piratée de beaucoup de papiers, d’articles scientifiques, en accès libre ou de The Pirate Bay, un site de torrent. Dans ces cas-là, le gouvernement français demande à la plupart des fournisseurs d’accès à Internet français de mentir au niveau de leur résolveur quand on leur demande à quelle adresse IP appartient ce service ; dans ce cas-là, ils répondent simplement « je ne connais pas ce service », alors qu’ils savent très bien quelle est l’adresse IP ; ça fait comme s’il n’existait pas, alors qu’en réalité il est bien accessible.

On a un autre exemple. En 2016, une erreur de redirection de certains sites internet pour les clients d’Orange faisait que les sites comme Google ou Wikipédia étaient redirigés vers la page de blocage des sites incitant au terrorisme ou en faisant l’apologie, qui est hébergée par le ministère de l’Intérieur. On se réveille un matin, on veut aller sur Wikipédia, et hop !, on a une page qui nous dit qu’on a essayé d’aller sur un site terroriste. C’est un exemple un peu visible de DNS menteur que le grand public a pu voir, mais, en général, on ne s’en rend pas bien compte.

C’est plus ou moins la même solution que Talitha avait proposée. Pour les problèmes de vie privée, on essaie d’utiliser un résolveur de quelqu’un en qui on a confiance et qui est respectueux de la vie privée, proposé, par exemple, par un chaton [9] ou un FAI associatif comme la FDN [French Data Network] [10], parce que, en général, ces résolveurs sont aussi libres, c’est-à-dire qu’ils ne vont pas mentir donc c’est la même réponse. En général les résolveurs de Google ne mentent pas, mais il faut accepter les conditions d’utilisation de Google qui, comme chacun sait, sont très respectueuses de notre vie privée !

Talitha : Quand tu dis que les résolveurs libres ne vont pas mentir, quel est le lien un peu plus explicite entre un service libre et le fait qu’il ne mente pas à ses utilisateurs ?

Quentin Duchemin : Il n’y a pas de lien direct. C’est plus une sorte d’heuristique, c’est au doigt mouillé : les chatons ou autres associations qui proposent des services qu’on dit libres, basés sur des logiciels libres, etc., font en général attention à la vie privée, mais je pense qu’ici c’est plus la terminologie libre. Il y a les résolveurs qui ne mentent pas, dont font partie ceux de Google, ceux de la FDN [10], etc., et ceux qui sont respectueux de la vie privée, comme ceux de 42l [11] et de la FDN.

Talitha : Dans le domaine du Libre, il y a une plus grosse confiance.

Quentin Duchemin : Oui, en général. Après, bien sûr, ce n’est pas une règle absolue.

Même si on utilise un résolveur libre et respectueux de la vie privée, en fait ça ne résout pas tous les problèmes.
La première chose qui reste à résoudre, c’est la gestion de la vie privée au niveau des intermédiaires. Déjà, les requêtes DNS sont faites entièrement en clair, c’est-à-dire que n’importe qui, qui est entre vous et le résolveur DNS, peut espionner la requête dans les tuyaux, donc voir quels sites vous avez essayé de consulter. C’est bien d’avoir un résolveur en bout de chaîne qui respecte la vie privée, mais ça ne résout pas ce problème d’espionnage au milieu.

Et, même avec ça, il reste un souci central : si quelqu’un arrive à se faire passer pour un résolveur DNS, c’est-à-dire se met, par exemple, entre vous et le vrai résolveur DNS, c’est comme s’il contrôlait entièrement le résolveur et même comme s’il contrôlait entièrement le serveur de noms, puisqu’il va pouvoir vous répondre n’importe quoi. Imaginez, par exemple, si la zone fr se fait avoir, tout ce qui est en-dessous de .fr pourra potentiellement renvoyer des fausses informations et même si la zone .fr ne se fait pas avoir, si quelqu’un situé entre vous et les résolveurs dit n’importe quoi pour la zone fr.

Pour illustrer, on a un exemple plus concret : en Turquie, en 2014, dans un contexte politique très tendu, le gouvernement turc a essayé de bloquer notamment Twitter et YouTube. Pour ce faire, il a commencé, comme on fait en France, par du mensonge DNS classique : demander aux FAI de dire à leurs résolveurs qu’ils ne connaissaient pas Twitter. Mais, comme les Turcs étaient malins et qu’ils utilisaient justement des résolveurs DNS qui ne mentent pas — d’ailleurs ceux de Google à l’époque —, le gouvernement turc s’est décidé à usurper carrément les résolveurs de Google en interceptant les requêtes qui lui étaient destinées directement sur le matériel réseau de son fournisseur d’accès à Internet, Turkish Telecom, en se faisant donc passer pour les résolveurs DNS de Google et le tout sans que ce soit détectable par le client.

Comment est-ce possible ? Tout simplement parce que le DNS a été créé à l’époque où Internet n’était pas un réseau public, en tout cas il fallait une carte pour entrer, donc il n’a pas de mécanisme de sécurité pensé et intégré pour garantir l’authenticité des réponses et leur intégrité. Au-delà de pouvoir faire une censure à si large échelle — ce qui est déjà très grave —, le DNS, en plus, n’est pas seulement utilisé pour pouvoir consulter un site web, récupérer l’adresse IP d’un site web, il est utilisé aujourd’hui pour plein d’autres choses que cette translation-là et utilisé, de plus en plus, pour sécuriser Internet. Donc typiquement, dans le DNS, on va trouver plein d’autres informations que la correspondance nom de domaine/adresse IP. Pour un nom de domaine précis, on va, par exemple, trouver des indications qui disent quelle IP a le droit d’envoyer des mails pour un nom de domaine.
Typiquement, quand je reçois un mail qui vient de — je ne sais pas — mattermost chez picasoft.net, je peux aller vérifier dans la zone DNS de Picasoft si l’adresse IP du serveur de mail qui me l’a envoyée est bien celle qui a le droit, afin que quelqu’un ne puisse pas usurper les mails en picasoft.net ; le mail, comme DNS, est très peu sécurisé de base.

Il y a d’autres informations dans les zones DNS — on ne va pas en parler ici, ça fera l’objet d’une autre émission sur le mail —, mais tout un tas de choses qui permettent de s’assurer que les mails qu’on reçoit sont bien authentiques et aussi qu’ils n’ont pas été modifiés sur le trajet.

Avec ce qu’on vient de voir, quelqu’un qui peut se faire passer pour le serveur d’un noms de domaine peut absolument tout usurper et se donner tous les droits, comme faire semblant d’envoyer des mails valides, rediriger sur un autre site. On voit que si jamais ça fonctionnait comme ça en pratique ce serait dramatique, comme ce qui a pu se passer en Turquie.

Comment résoudre ce problème ? C’est une question compliquée, comme l’a expliqué Stéphane dans l’interview.

Avant d’y répondre, on va faire une pause et écouter une petite musique. Cette semaine, on va écouter Disrupt de Louis Lingg and the Bombs sur l’album >_…checking system…disruption detected…, qui vient d’être publié. C’est sous licence Creative Commons BY NC SA. Bonne écoute.

Pause musicale : Disrupt de Louis Lingg and the Bombs.

Quentin Duchemin : De retour dans La Voie Est Libre.
Un résumé très bref de ce qu’on a dit dans la première partie de l’émission.
DNS, c’est le système de noms de domaine qui permet notamment de faire l’association entre un nom de domaine, quelque chose de facile à retenir comme picasoft.net, et une adresse IP, comme une adresse physique, une adresse postale pour les humains, que l’ordinateur utilise pour contacter réellement les services à qui on essaie de parler.

On a vu que c’est un point crucial de l’Internet, puisque, à chaque fois qu’on utilise un nom de domaine, il faut faire une requête à un résolveur DNS qui va aller interroger les serveurs de noms qui contiennent l’information — à quelle IP, par exemple, correspond quel nom de domaine —, et que s’il y avait des problèmes de sécurité au niveau du DNS, eh bien c’est tout l’Internet qui s’en trouverait impacté.

Les problèmes de sécurité sont de deux types.
Le premier ce sont les problèmes de confidentialité, puisque les requêtes DNS transitent sur le réseau entièrement en clair. N’importe quel indiscret qui écouterait le réseau pourrait intercepter toutes les requêtes DNS que fait votre ordinateur, donc savoir, globalement, tout votre historique, etc.
Le deuxième problème est un problème d’authenticité : puisque le DNS a été créé à une époque où Internet n’était pas public, donc pas sécurisé, n’importe qui pourrait se faire passer pour un serveur de noms ou intercepter les requêtes à un résolveur et vous répondre n’importe quoi. Les conséquences seraient dramatiques vu que le DNS est tout le temps utilisé pour savoir quelle est la bonne machine sur laquelle on veut aller, si ce mail est bien authentique, etc.

Pour résoudre ces problèmes, on va utiliser deux techniques qui sont basées sur les maths et la cryptographie : le chiffrement et la signature. On va essayer d’introduire ça calmement, avec des métaphores, pour bien vous convaincre que ce sont des méthodes efficaces et on verra ensuite comment elles sont mises en œuvre.

Talitha, c’est parti pour une merveilleuse introduction au chiffrement.

Talitha : Chiffrement, cryptographie sont un peu des grands mots.
Le principe du chiffrement, c’est vraiment le principe d’un message codé. Si je veux envoyer un message à Quentin pour que seuls Quentin et moi le comprenions, on va se mettre d’accord sur un code, une règle que j’applique sur mon message ; Quentin connaît également la règle et, du coup, toutes les personnes entre les deux, qui vont entendre le message, vont trouver qu’il n’a aucun sens. Mais Quentin, à la réception, pourra appliquer la règle en inverse et comprendre ce qui se passe.
Pour donner une métaphore simple pour comprendre le principe, on va parler du chiffre de César. C’est un système de chiffrement où, pour chaque lettre du message initial, on va décaler de trois lettres vers la droite : si la lettre est un A, on va écrire un C à la place ; si c’est un B, on va écrire à la place D , etc.
Donc j’écris mon message initial, ce que j’appelle le message en clair, en fait avant chiffrement, je lui applique le chiffre de César et je l’envoie à Quentin. Quentin connaît la règle du chiffre de César, il peut re-décaler de trois lettres vers la gauche et comprendre ce qui se passe. Mais, au milieu, toute personne qui a lu le message ne comprend rien, puisque ce ne sont plus les mêmes mots. C’est ce qu’on appelle le chiffrement symétrique : la même méthode est utilisée pour chiffrer et pour déchiffrer. On appelle cette méthode une clé. Donc on a une clé unique.

Le problème du chiffrement symétrique. Imaginons que Quentin et moi n’ayons pas pu nous mettre d’accord sur le code de manière sécurisée, imaginons qu’il y ait toujours des gens autour ou qu’on soit à distance. Comment fait-on pour se mettre d’accord sur une règle ? Comme on n’a pas eu de chiffrement avant de faire ce chiffrement, notre règle va forcément être visible par tout le monde, donc elle ne sert plus à rien. Pour résoudre ce problème, on a inventé ce qui s’appelle le chiffrement asymétrique. Au lieu d’avoir une clé unique qui va permettre de déchiffrer le message, on va en utiliser deux.

On va expliquer ça avec une autre petite métaphore. C’est comme si, au lieu de juste envoyer le message à Quentin, je prenais une boîte en bois. Il y a un cadenas dessus et une fente. Moi je ferme le cadenas avec une clé. Cette clé, on va l’appeler la clé privée. Je la garde avec moi, du coup je possède une clé physique. Ensuite, j’envoie la boîte verrouillée à Quentin, donc tout le monde peut voir la boîte, pas de problème. Quand Quentin reçoit la boîte, il écrit son message en clair, il écrit juste ce qu’il a à me dire et il le met dans la boîte ; il n’a pas accès à l’intérieur de la boîte, il n’y a que moi qui puisse ouvrir la boîte, puisque qu’il n’y a que moi qui ai la clé, et il le renvoie. À ce moment-là, il n’y a pas de problème à faire circuler le message : le message est dans la boite, tout le monde voit la boîte, tout le monde voit le bout de bois, mais personne ne peut lire ce qui est à l’intérieur. Et quand je le reçois, vu que j’ai la clé, je peux ouvrir la boîte et lire le message. Ça, c’est le chiffrement asymétrique. La boîte c’est ce qu’on va appeler une clé publique — tout le monde peut la voir, il n’y a pas de problème — et le cadenas c’est ce qu’on appelle la clé privée. Si quelqu’un a la clé privée et la clé publique, alors il peut lire les messages.

Voilà pour un bref rappel du principe du chiffrement sur lequel reposent les principes de signature que va vous expliquer Quentin.

Quentin Duchemin : Notons que ce chiffrement est celui qui est vraiment utilisé partout sur Internet. Quand vous avez le cadenas quand vous consultez un site web en https, c’est le chiffrement asymétrique qui est utilisé, pour les cartes bancaires, etc. Ça repose sur ce même principe.

La métaphore de la boîte est très bien pour comprendre le chiffrement : c’est comme si j’envoyais plein de boîtes à tout le monde, que les gens mettent plein de messages dedans et que je sois le seul propriétaire de la clé pour les déchiffrer. Mais elle ne marche que dans un sens, alors qu’en fait le vrai chiffrement asymétrique marche dans les deux sens. Ça veut dire que tout ce qui a été chiffré avec ma clé privée va pouvoir être déchiffré par ma clé publique. En réalité, la clé privée peut aussi permettre de faire un chiffrement.

À ce stade, on pourrait se demander quel est l’intérêt de chiffrer un truc avec la clé dont je suis le seul propriétaire et tout le monde pourrait le déchiffrer, vu que ma clé publique est publique, genre, c’est un peu nul ton truc. Eh bien ça permet de faire des signatures. Une signature, c’est ce qui va permettre de certifier l’authenticité, comme une signature réelle sur un chèque ou autre chose — c’est bien moi qui ai fait cette signature —, mais, en plus, ça permet aussi de certifier l’intégrité d’un document ou de n’importe quoi, ce qui est un peu différent de la signature du monde réel.

Qu’est-ce que ça veut dire et comment fait-on ?
En résumé, on va commencer par calculer une sorte d’empreinte du message ou du document qu’on peut envoyer et on va dire que c’est comme une empreinte digitale qui serait unique pour chaque document.
Ce sont des maths, on ne rentre pas dans le détail, mais imaginons que tous les messages du monde, tous les documents, aient une empreinte digitale unique. On va prendre cette empreinte digitale et on va la chiffrer avec la clé privée que je suis le seul à avoir. Je chiffre l’empreinte et je l’envoie à côté du message que j’envoie en clair, ou chiffré, pourquoi pas ? Tout le monde peut déchiffrer cette empreinte que j’ai chiffrée, vu que tout le monde a ma clé publique, et va pouvoir, à son tour, calculer l’empreinte du message qui a été effectivement reçu et comparer cette empreinte avec l’empreinte que j’avais chiffrée. Que se passe-t-il si c’est la même empreinte ? Ça veut dire que le message est intègre, qu’il n’a pas été modifié sur le trajet. Si quelqu’un avait modifié le message sur le trajet, pour que ça ne se voit pas, il aurait aussi fallu qu’il modifie l’empreinte chiffrée qui était adjointe au message. Or, pour pouvoir la modifier, il aurait eu besoin de ma clé privée, sinon les gens ne pourraient pas déchiffrer l’empreinte avec ma clé publique et se rendraient compte qu’il y a un problème.
Ce mécanisme de signature est extrêmement malin : si jamais je peux déchiffrer la signature d’un message avec la clé publique de quelqu’un et, qu’en plus, le contenu, l’empreinte qui est à l’intérieur, est la même que l’empreinte du message effectivement reçu, j’ai la certitude que c’est bien la personne que j’ai en face qui m’a envoyé ce message, et qu’en plus ce message n’a pas été modifié. Ou alors l’alternative, c’est que sa clé privée a été compromise, mais, dans ce cas-là, c’est la merde ! C’est comme quand les mots de passe sont compromis, ça ne fonctionne pas très bien.

Pour revenir à nos problèmes de confidentialité au niveau du DNS, que tout le monde peut voir les requêtes qui sont effectuées entre moi et le résolveur, donc potentiellement voir mon historique, et à nos problèmes d’authenticité, à savoir est-ce que le résolveur qui me répond me fournit vraiment les informations qui sont contenues dans la zone, dans le serveur de noms ?, eh bien on utilise le chiffrement et la signature. Le chiffrement va être utilisé pour la confidentialité sur toute la chaîne entre moi et le résolveur DNS.
Plein de solutions ont été proposées pour implémenter ce chiffrement. Une des plus populaires aujourd’hui, qui est implémentée dans les navigateurs web, c’est DOH pour DNS over https. Elle consiste à utiliser le protocole sécurisé du Web, https, et à encapsuler, à l’intérieur de ce protocole. les requêtes DNS. Ça se configure très facilement dans un navigateur.

42l [11], une association qui fait partie du même collectif que Picasoft, propose un tel service. Vous allez sur 42l.fr et, dans la rubrique Services, vous trouverez un lien DOH qui vous explique comment utiliser leur résolveur DNS accessible via DOH, dans votre navigateur [12]. Ainsi, toutes les requêtes DNS que fait votre navigateur seront sécurisées, personne ne pourra écouter entre les deux, puisque, par défaut, vu que ce sont des résolveurs par défaut qui sont utilisés quand vous vous connectez à votre box, les fournisseurs d’accès à Internet ont tout votre historique.

C’est la première solution pour la confidentialité au niveau des tuyaux.

Pour l’absence d’usurpation, on pourrait faire une émission entière là-dessus, je vais essayer de résumer. On utilise ce qui s’appelle DNSSEC [13]. DNSSEC est une extension de DNS, DNS Security Extensions, qui a été standardisée en 2005. L’idée est d’utiliser la signature cryptographique pour garantir l’intégrité et l’authenticité des données renvoyées par les résolveurs.
L’idée est simple. Chaque zone a une paire de clés, publique et privée, et va signer cryptographiquement l’ensemble de ces enregistrements. À picasoft.net, on n’utilise pas encore DNSSEC, nous sommes de mauvais élèves. Mais si picasoft.net voulait sécuriser ce qu’on appelle ses enregistrements, donc les correspondances par exemple entre adresses IP et noms de domaine, on dirait : « OK, très bien, pad.picasoft.net, c’est 91.158.machin, et on adjoindrait un autre enregistrement qui calculerait l’empreinte du message « pad.picasoft.net, c’est 91.158.machin » et qui le chiffrerait avec la clé privée de picasoft.net.

À ce stade, on pourrait se dire très bien, mais comment est-ce qu’on est sûr de où est stockée, finalement, la clé publique qui va permettre aux gens de vérifier que l’empreinte est bien la bonne,etc. ? Eh bien, on la stocke directement dans notre zone, mais, à ce moment-là, quelqu’un pourrait très bien se mettre au milieu, entre le résolveur et moi, inventer une fausse paire de clés, publique et privée, puis faire semblant d’avoir des enregistrements qui sont bien signés, etc. C’est pour ça que, par-dessus, on va aussi demander au propriétaire de la zone .net de stocker et de signer notre clé publique. Ça devient peut-être un peu compliqué comme gymnastique mentale, mais ça permet d’avoir une espèce de chaîne de confiance où on va pouvoir vérifier en remontant, au fur et à mesure, que la clé publique associée à une zone a bien été signée par la zone du dessus et, elle-même, que sa clé publique a bien été signée par la clé privée de la zone du dessus, etc.
Tout ça pour dire que si, dans ce mécanisme-là, on voulait pouvoir usurper la clé publique de picasoft.net, il faudrait réussir à récupérer la clé privée de la zone .net pour signer la fausse clé publique de picasoft.net.

C’est un peu laborieux, je pense que ce n’est déjà pas mal pour une introduction.

Pour résumer, ces deux solutions ne fonctionnent pas totalement de concert. C’est-à-dire pour le problème de la confidentialité pour les intermédiaires et le problème de l’intégrité, ces deux solutions qui sont apportées sont très différentes : celle de l’utilisation du chiffrement pour chiffrer de bout en bout, entre moi et le résolveur, et celle de l’intégrité pour garantir que la zone n’a pas été modifiée et que ce sont bien les propriétaires de la zone qui ont donné les bonnes correspondances entre nom de domaine et adresse IP.

Notamment, ce n’est pas parce que vous utilisez DOH, DNS over https, que DNSSEC est utilisé. D’ailleurs DNSSEC n’est pas très utilisé aujourd’hui, quand bien même il a été standardisé en 2005 ; la preuve, chez Picasoft, encore une fois, nous ne sommes pas de bons élèves puisque nous gérons nous-mêmes notre serveur de noms. Assez peu de clients — les clients, c’est votre navigateur ou toute autre chose qui fait appel à un résolveur — vérifient que les enregistrements DNSSEC sont valides, ils font notamment ce travail de déchiffrer la signature, de vérifier qu’elle correspond bien à l’enregistrement, etc. Je crois que l’Apnic, l’équivalent de l’Afnic pour l’Asie Pacifique, estime que seulement 29 % en moyenne d’enregistrements DNSSEC sont validés. Si j’interprète bien, je suis pas totalement sûr, ça veut dire soit que 70 % des requêtes n’utilisent pas DNSSEC, soit 70 % des requêtes ont une signature qui n’est pas vérifiée. Bref !, dans tous les cas, c’est trop peu.

Voilà tout ce que j’avais à raconter. Je pense qu’on peut s’arrêter là, c’est déjà pas mal.

Talitha : Je pense qu’on a déjà un beau panel de problèmes et de solutions pour aujourd’hui.

Quentin Duchemin : C’est vendu, on s’arrête là.
Vous pouvez, comme d’habitude, retrouver le podcast de cette émission sur radio.picasoft.net. On y mettra les liens de tous les services dont on a parlé, puis nos sources, et n’hésitez surtout pas à aller lire le blog de Stéphane, bortzmeyer.org [3], blog dont on s’est pas mal inspiré pour trouver des exemples et monter nos explications.
D’ici la prochaine émission, on vous souhaite une excellente journée. Salut Talitha et à la prochaine.

Talitha : Salut Quentin.