Les DNS

Titre : Les DNS

Intervenants : Stéphane Bortzmeyer

Lieu : Emission " La voix est libre" de Picasoft, le chaton de l'UTC de Compiègne

Date : 15 décembre 2021

Durée : 57 min 13

Vidéo

Licence de la transcription : Verbatim

Illustration : Logo de Picasoft ? = https://podcast.picasoft.net/media/podcasts/la_voix_est_libre/cover_medium.webp

NB : transcription réalisée par nos soins, fidèle aux propos des intervenant·e·s mais rendant le discours fluide.
Les positions exprimées sont celles des personnes qui interviennent et ne rejoignent pas nécessairement celles de l'April, qui ne sera en aucun cas tenue responsable de leurs propos.

Compléments d'informations sous la vidéo

Thèmes de l'interview, thèmes des échanges, musiques, liens complémentaires :

https://podcast.picasoft.net/@la_voix_est_libre/episodes/les-dns

Présentation

L’AFNIC, c’est un nom qu’on n'entend jamais dans le grand public et pourtant c’est une association essentielle dans le fonctionnement du web français.

Qu’est ce que ça veut dire et quel est ton rôle dans cette association ?

En quoi DNS est un des éléments critiques du fonctionnement d’Internet ?

Par rapport aux différents problèmes de sécurité que tu as mentionné, comment on peut agir dessus pour le maintenir et le sécuriser ?

Transcription

Mots-clés = DNS ; sécurité ; vie privée ; censure ; chiffrement ; signature ; TLD ; cryptographie

Quentin : Bonjour à toutes et à tous. Bienvenue sur Graf’Hit 94.9. Vous écoutez La Voix Est Libre, une émission créée par Picasoft , une association compiégnolaise qui s’est donnée 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.

Alors, pour l’émission d’aujourd’hui, je suis avec Talita. Salut Talita.

Talita : Salut Quentin.

Quentin : Et puis on va parler DNS. Alors, qu’est-ce que c’est le DNS ? Et 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 : Alors, Stéphane, tu es ingénieur à l’Afnic . L’Afnic : encore un acronyme dont le grand public ne sait pas bien ce que c’est. 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.

Talita, je te passe la main pour les questions.

Talita : Bonjour Stéphane. Pour les questions, comme l’a soulevé Quentin, la première chose qu’on se demande, c’est vraiment : l’Afnic, on n’en entend jamais parler 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 : Alors, c’est vrai que l’infrastructure, on n’en entend jamais parler. Ç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. Et effectivement, une infrastructure 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. Donc, vous voulez vous connecter sur Wikipedia : 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 moment-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 aussi 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. Leur nom sauf si ce sont des personnes physiques, auquel cas le nom n’est pas diffusé. Donc, c’est toute cette activité qui, effectivement, n’est pas visible en temps normal, mais est cruciale quand même 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 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 ou quand il y a des problèmes particuliers liés au DNS.

Talita : OK, très bien. Et donc, en quoi est-ce que le DNS est carrément un élément critique du fonctionnement d’internet ?

Stéphane Bortzmeyer : Alors 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, ou 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. Donc, vous voulez aller sur Wikipedia : 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 c’est ceux de l’Afnic ; dans le cas de wikipedia.org, c’est ceux de la fondation qui est derrière Wikipedia. Et 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 houpi, il va être content, il va pouvoir s’instruire et 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é ou 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é. 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, par exemple. Non, c’est purement logiciel, le DNS, mais c’est quand même critique.

Talita : D’accord, et donc, 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 ? Et comment est-ce qu’on travaille sur le DNS pour le maintenir et le sécuriser ?

Stéphane Bortzmeyer : Alors un exemple récent, par exemple, parce que ça a occupé une bonne partie de mon week-end : la faille « Log4Shell » 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, dans vraiment plein de machines sur l’Internet, qui avait une faille de sécurité sérieuse. Donc, 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 il fallait vérifier de toutes façons.

Sinon les deux grands problèmes typiques : d’abord le risque de panne. Ça c’est LE principal risque : ça ne s’est jamais produit depuis la création de l’Afnic. Mais 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 domaines 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. Donc une attaque qui vise à empêcher le domaine de fonctionner, et ça avait malheureusement marché. Plus aucun 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 terminer en .tr, enfin vraiment la grosse catastrophe. Donc, il y a 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. Donc, c’est 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, et 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 aussi, il faudrait des heures et des heures pour détailler tout l’aspect sécurité des noms de domaine, et 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 avait 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é et 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 domaines et qui font que c’est vraiment le point important, c’est ce côté opérationnel : c’est-à-dire que c’est 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.

Talita : Merci, Stéphane, pour ces réponses qui sont claires et complètes. On te remercie également d’avoir été avec nous ce matin. Et bonne journée à toi.

Stéphane Bortzmeyer : Merci et au revoir.

Quentin : 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 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é.

Donc, on va recommencer par la base pour bien ancrer dans les esprits. Est-ce que Talita, ç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 ?

Talita : Mais bien entendu Quentin. Donc, 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. Donc d’abord DNS, c’est domain name system, un système de noms de domaine. Et 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. Donc, c’est quoi 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 les manipuler au quotidien, on va associer à chaque adresse IP un nom, donc un nom de notre langage à nous, beaucoup plus facile à exploiter pour nous, 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. Ce qui va se passer, c’est que 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 de 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. Donc, c’est eux qui ont les tables de correspondance et qui ont la donnée principale.

Et, à côté de ça, on a également les résolveurs. Les résolveurs vont faire le lien, en fait, entre les machines qui ont recours au DNS pour accéder à une adresse et l’adresse en question.

Quentin : 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.

Talita : 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 nom : OK, donc picasoft.net, ça correspond à quelle adresse IP ? Le serveur de noms lui donne l’adresse IP, le résolveur peut me renvoyer l’adresse réelle de la machine de Picasoft, et ainsi je peux me connecter au site.

Donc voilà : ce rappel était principalement pour faire attention aux confusions sur le vocabulaire. Parce que dans le langage courant, on utilise pas mal les termes de serveurs DNS, mais les termes sont plus précis que ça.

Quentin : Merci Talita pour avoir reposé les bases. Donc, 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 bien 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 et donc, à chaque fois que quelqu’un essayait d’aller sur Facebook, et bien simplement le serveur de noms ne répondait pas, donc on n’avait pas d’adresse IP, donc c’est 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. Et sur les 100 000 sites les plus visités, selon le classement Alexa, et bien 24 % de ces sites utilisent CloudFlare , une grande entreprise qui a notamment fourni des serveurs de noms, AWS, donc Amazon web services pour 12 %, et GoDaddy 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. Donc, si jamais il y avait une panne sur un de ces fournisseurs, et bien ça ferait un quart du web qui serait inaccessible.

Notamment en 2016, Dyn, qui est aussi un fournisseur de serveurs de noms qui 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 a interrompu toutes les opérations de résolution de noms de domaine pour plus de 175 000 sites web.

On commence à apercevoir qu’il y a quand même beaucoup de problèmes qui se jouent de manière un petit peu invisible. Mais avant de réattaquer sur 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 même avant Internet ? Talita ?

Talita : 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 puisqu’à cette époque c’était gérable. Et 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. Il y a eu plusieurs solutions proposées, mais en 1983, la solution proposée qui a été retenue, ça a été le DNS, donc un système qui permet la résolution de noms, mais 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 : Quel ping-pong endiablé ! [Rires] Effectivement, il n’est 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é. Ça ne serait déjà pas possible et sans doute pas souhaitable. Donc, le DNS est 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.

Alors, comment voit-on cette hiérarchie ? Et bien on la voit quand on regarde un nom de domaine : on voit bien qu’il est composé souvent de plusieurs parties. Par exemple, pour notre picasoft.net, on a le picasoft et le net. Et donc le système des noms de domaine est 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. Ou picasoft.net. : on ne le met pas par commodité. À partir d’un domaine, on peut créer un ou plusieurs sous-domaines : ce qui se passe, c’est que chaque partie d’un domaine va correspondre à ce qu’on appelle une zone DNS. Je m’explique : par exemple, FR est une zone DNS et tout ce qu’il y a en-dessous de FR, par exemple gouv.fr : gouv va être une autre zone DNS. En fait, ce qui se passe, c’est que, 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, et donc, 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. Picasoft.net : la racine, 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. Les domaines qui se trouvent immédiatement sous la racine, on les appelle les domaines de premier niveau, ou TLD pour Top Level Domain. C’est tous les .fr, .net, .org, etc. Et ceux qui ne correspondent pas à une extension de pays sont des domaines génériques, donc 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, et bien, en fait, 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. Les serveurs vont dire : ah ben non, c’est pas nous qui nous en occupons, c’est 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 : ah ben moi, j’ai l’information et l’adresse de pad.picasoft.net, c’est cette adresse IP.

On note peut-être pour terminer qu’en pratique, il y a tout un système - et c’est important pour la suite aussi - 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, voir 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.

Alors, 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. Talita, si tu peux prendre la main ?

Talita : Bien évidemment. Le problème de vie privée, en fait, c’est que, 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. Et 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 : on fournit à 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 existante, mais pas forcément commune ou viable.

Quentin : 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. Et comme tu dis, ça n’est pas forcément évident d’aller changer sur le téléphone ou autre.

Talita : Oui, voilà, 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 : 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. Ce sont 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 d’un 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 : avec Sci-Hub , dont on a parlé dans les émissions sur l’Open Science, qui contient une version piratée de beaucoup de papiers, d’articles scientifiques, en accès libre. Ou de ThePirateBay, un site de torrent. Ce qui se passe dans ces cas-là, c’est que 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 en disant : 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 Wikipedia é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 Wikipedia, 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.

Donc c’est plus ou moins la même solution que Talita 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, par exemple, proposé par un chaton ou un FAI associatif comme la FDN , parce qu’en général ces résolveurs sont aussi libres, c’est-à-dire qu’ils ne vont pas mentir. C’est la même réponse. Sachant qu’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.

Talita : 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 : Il n’y a pas de lien direct. C’est plus une sorte d’heuristique, c’est au doigt mouillé : en général, les chatons ou autres associations qui proposent des services basés sur des logiciels libres, etc., font 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 fait partie Google, celui de la FDN, etc. Et ceux qui sont respectueux de la vie privée, comme ceux de 42L et de la FDN.

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

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

30.15

Le problème, même si on utilise un résolveur libre et respectueux de la vie privée, c’est que ça ne résout pas en fait tous les problèmes. La première chose qui reste à résoudre, c’est la gestion de la vie privée, mais au niveau des intermédiaires. Comment dire ? 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 et donc voir quels sites vous avez essayé de consulter. Donc, 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, c’est que si quelqu’un arrive à se faire passer pour un résolveur DNS, c’est-à-dire se mettre par exemple entre vous et le vrai résolveur DNS, et bien 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 nom, puisqu’il va pouvoir vous répondre n’importe quoi. Donc, imaginez si, par exemple, la zone FR se faisait avoir, tout ce qui est en-dessous de .FR potentiellement pourrait 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. Donc pour illustrer, on a un exemple plus concret : par exemple, 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, ils ont 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 utilisaient justement des résolveurs DNS qui ne mentent pas - 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 c’est possible ? Tout simplement parce que le DNS a été créé à l’époque où Internet n’était pas un réseau public, en tout cas où 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, en plus le DNS n’est pas seulement utilisé pour pouvoir consulter un site web, récupérer l’adresse IP d’un site web. Aujourd’hui, il est utilisé pour plein d’autres choses que cette transaction-là, et 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. Donc quand moi, je reçois un mail qui vient de - je ne sais pas -, mattermost@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 est très peu sécurisé de base, comme DNS.

Il y a d’autres informations dans les zones DNS, comme par exemple - 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.

Donc là, avec ce qu’on vient de voir, quelqu’un qui peut se faire passer pour le serveur d’un nom 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. Si jamais ça fonctionnait comme ça, en pratique, ce serait dramatique comme ce qui a pu se passer en Turquie.

Donc, 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 s’é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.

39.35

De retour dans La Voie est Libre. Alors 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’était un point crucial de l’Internet, puisqu’à 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 donc que s’il y avait des problèmes de sécurité au niveau du DNS, et bien c’est tout l’Internet qui s’en trouverait impacté.

Les problèmes de sécurité sont de deux types. Le premier : les problèmes de confidentialité, puisque les requêtes DNS transitent sur le réseau entièrement en clair, et donc 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. Et le deuxième problème, c’est un problème d’authenticité : n’importe qui pourrait dans ce monde - puisque le DNS a été créé à une époque où Internet n’était pas public et 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, et donc 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, est-ce que ce mail est bien authentique ? Etc.

Donc, 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. Alors, Talita, c’est parti pour une merveilleuse introduction au chiffrement.

Talita : Chiffrement, cryptographie, ce 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 qui fait que j’applique une règle sur mon message, Quentin connaît la règle également. Et donc, 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 réappliquer la règle inverse et comprendre ce qui se passe. Donnons 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. Donc, si la lettre est un A, on va écrire un C à la place ; si c’est un B, on va écrire D à la place, etc. Donc j’écris mon message initial, ce que j’appelle le message en clair : on appelle un message en clair, en fait, avant chiffrement. J’ai créé mon message initial, 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 : c’est la même méthode qui 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, c’est que... 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 des gens toujours autour, ou qu’on soit à distance. Comment fait-on pour se mettre d’accord sur une règle ? Puisque, comme on n’a pas 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, 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, une clé physique. Ensuite, j’envoie la boîte verrouillée à Quentin : tout le monde peut voir la boîte, pas de problème. Quand Quentin reçoit la boîte, il va écrire son message en clair, il va juste écrire ce qu’il a à me dire. Il le met dans la boîte - il n’a toujours pas accès à l’intérieur de la boîte, il n’y a que moi qui peux ouvrir la boîte, puisque que c’est moi qui ais la clé -, il le renvoie. À ce moment-là, il n’y a pas de problème à faire circuler le message : il 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 moi 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 la clé, c’est ce qu’on appelle une 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 : Et notons que ce chiffrement-là, c’est celui qui est vraiment utilisé partout sur Internet. Quand vous avez le cadenas pour consulter 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.

Alors 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 pouvaient mettre plein de messages dedans et moi, j’étais 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 - en réalité, la clé privée peut aussi permettre de faire un chiffrement - va pouvoir être déchiffré par ma clé publique.

À 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. Et bien, en fait, ç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. Donc 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 on fait ? Pour résumer le processus de signature : on va commencer par calculer une sorte d’empreinte du message ou du document qu’on peut envoyer et c’est comme une empreinte digitale qui serait unique pour chaque document. C’est 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 ? Ce qui va se passer, c’est que tout le monde peut déchiffrer cette empreinte que j’ai chiffré - puisque 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é. Que se passe-t-il si c’est la même empreinte ? Ça veut dire que le message est intègre, il n’a pas été modifié sur le trajet. Parce que 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’autre 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.

Revenons à 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, et 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 ? - Et 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 à encapsulter les requêtes DNS à l’intérieur de ce protocole. Ça se configure très facilement dans un navigateur.

42L, 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. Ainsi, toutes les requêtes que fait votre navigateur seront sécurisées. Personne ne pourra écouter entre les deux, puisque, par défaut, vu que c’est le résolveur par défaut qui est utilisé quand vous vous connectez à votre box, votre fournisseur d’accès à Internet a tout votre historique.

Ça, c’est la première solution pour la confidentialité au niveau des tuyaux. Et pour l’absence d’usurpation, alors là, on pourrait faire une émission entière là-dessus. Donc, je vais essayer de résumer. On utilise ce qui s’appelle DNSSEC. DNSSEC est une extension, de DNS, DNS Security Extensions, qui a été standardisé 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. Par exemple, à Picasoft.net, on n’utilise pas encore DNSSEC, on est des 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, ce qu’on ferait, c’est qu’on dirait : OK, très bien, pad.picasoft.net, c’est 91.158.machin, et on adjoindrait un autre enregistrement qui calculera 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é finalement la clé publique qui va permettre aux gens de vérifier que l’empreinte est bien la bonne ? Et bien, on la stocke directement dans notre zone. Mais à ce moment-là, quelqu’un pourrait très bien se mettre entre le résolveur et moi, et 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. Alors ç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 que, elle-même, 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 c’est déjà pas mal pour une introduction. Donc pour résumer : ces deux solutions ne fonctionnent pas totalement de concert. C’est-à-dire que 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 c’est bien les propriétaires de la zone qui ont donné les bonnes correspondances entre noms de domaine et adresse IP.

Notamment, ce n’est pas parce que vous utilisez DOH, DNS over https, que DNSSEC est utilisé. Et 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 on n’est pas de bons élèves puisqu’on gère nous-mêmes notre serveur de noms. Notamment il y a assez peu de clients - les clients, c’est votre navigateur ou toute autre chose qui fait appel à un résolveur -, qui vérifient que les enregistrements DNSSEC sont valides, qui font ce travail de déchiffrer la signature, de vérifier qu’elle correspond bien à l’enregistrement, etc. Je crois que c’est l’Apnic - pour l’Asie Pacifique, l’équivalent de l’Afnic [pour la France] -, qui estime que seulement 29 % en moyenne des enregistrements DNSSEC sont validés. Ça veut dire que 70 %, si j’interprète bien - je suis pas totalement sûr - des requêtes, soit des requêtes générales dans le monde qui sont pas validées, soit 70 % des requêtes qui n’utilisent pas DNSSEC, soit 70 % des requêtes qui ont une signature qui ne sont pas vérifiées. Bref, dans tous les cas, c’est trop peu.

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

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

Quentin : C’est vendu, on s’arrête là. Vous pouvez, comme d’habitude, retrouver 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, 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 Talita et à la prochaine.

Talita : Salut Quentin.