Cette semaine on va parler de DNS, ou Domain Name System, qui est un système permettant de traduire des noms de domaine en adresses IP. Cet article sera assez court bien long (edit après la relecture finale) mais vous permettra de mieux comprendre ce qui se passe quand vous tapez un URL dans votre barre de navigation et également comment fonctionnent certaines attaques de man in the middle.

Le problème des adresses

L’internet – interconnected networks – consiste en l”interconnexion massive de clients (PC, smartphone, etc.) et serveurs entre eux afin de former ainsi un réseau mondial. Dans les faits il porte ce nom de “réseaux interconnectés” car il s’agit en fait de la mise en relation de réseaux, eux-mêmes constitués de sous-réseaux, etc. Une sorte de boîte gigogne de réseaux en somme.

Afin de s’y retrouver dans tout ce bazar, car il s’agit tout de même de pouvoir véhiculer des données entre deux points de ce réseau massif (sinon ça ne sert strictement à rien sinon à gaspiller des câbles et autres fibres optiques), il a fallu à un moment donné trouver un moyen d’identifier les différents points de ce foutoir et surtout de les localiser.

Imaginez un monde où le concept d’adresse (postale) n’a pas été inventé. Vous allez à la poste pour envoyer un courrier à Thomas Dupont. Quatre cas de figure sont possibles :

• le postier ne connaît pas de Thomas Dupont et vous demande poliment de vous casser pour libérer la file d’attente
• le postier connaît un Thomas Dupont et va lui remettre la lettre ; pas de bol, ce n’est pas le bon Thomas Dupont
• le postier connaît un Thomas Dupont et c’est bien le bon (hourra)
• le postier connaît plusieurs Thomas Dupont et c’est la catastrophe

Ce monde semble déjà très pénible (notamment parce que j’ai écrit Thomas Dupont sept fois en comptant celle-ci) vous en conviendrez. Maintenant on revient dans notre monde à nous avec nos belles adresses postales et miracle : vous donnez au postier de quoi cibler ses recherches : Pays, Ville, Rue, Numéro, Complément ; il devrait maintenant pouvoir amener la lettre à la bonne personne et ce même s’il ne la connaissait pas a priori. C’est pas beau ça ?

Pour nos machines connectées à internet (et à des réseaux en général), on a procédé à quelque chose de similaire pour être sûrs de pouvoir joindre le bon destinataire lors des échanges de données : chaque nœud d’un réseau est identifié avec une adresse – appelée adresse IP (Internet Protocol) – valable sur ce réseau.

IPv4 et limitations

Aujourd’hui, la plupart des machines communiquent entre elles en utilisant le protocole IPv4. Ce dernier utilise une adresse codée sur 32 bits qu’on représente souvent en 4 paquets de 8 bits sous forme décimale : X.Y.Z.T avec chaque variable entre 0 et 255, par exemple 192.168.1.1.

L’utilisation d’une IP à 32 bits pose un problème de taille (littéralement) : 32 bits ne permettent de représenter qu’un peu plus de 4 milliards de valeurs différentes (d’autant qu’on s’interdit de commencer une IP par “0.” ce qui limite encore le nombre). Le problème se pose si je vous dis pour vous donner une idée qu’on était à près de 12 milliards de systèmes interconnectés en 2021. Ça coince ! Comment on s’en sort ?!

La première solution, prometteuse pour l’avenir mais que tout le monde repousse d’année en année parce que pour paraphraser Amonbofis “oui, mais [l’IPv4] on a tout le temps fait comme ça” : l’IPv6. C’est le successeur désigné du protocole IPv4. L’IPv6 code les adresses sur 128 bits, ce qui permet de coder plus de 340 sextillions d’adresses (pour ceux qui ne savent pas ce qu’est un sextillion – ce qui est mon cas – voilà le nombre exact d’adresses IPv6 possibles : 340 282 366 920 938 463 463 374 607 431 768 211 456). Soyons clairs : on sera tous crevés depuis longtemps des retombées du réchauffement climatique avant de saturer ce protocole-là.

La seconde solution, qu’on utilise à outrance pour repousser l’inévitable passage à l’IPv6 est l’utilisation du NAT (Network address translation ; translation d’adresse réseau). L’idée est la suivante : pour la plupart des sous-réseaux locaux (typiquement votre réseau local à la maison ou un intranet d’entreprise) on utilisera une IP unique pour la navigation sur internet : c’est ce qu’on appelle leur IP publique. Toutes les machines du sous-réseau ont par contre une IP dite privée qui leur permet d’une part de communiquer entre elles et d’autre part de bien être identifiée de façon unique à un moment où à un autre lorsqu’il s’agit de communiquer avec l’extérieur. Vous pouvez en fait imaginer un immeuble en copropriété avec un concierge : tous les habitants de l’immeuble peuvent confier leur courrier au concierge qui se chargera de l’envoyer par le biais de la poste et ce même concierge se charge de recevoir tout le courrier de l’immeuble et de le remettre dans la boîte aux lettres individuelles des bonnes personnes.

Pour éviter toute collision entre les IP publiques et les IP privées, leurs plages sont réservées par convention. Les plages possibles pour une IP publique sont les suivantes :

• 1.0.0.0 – 9.255.255.255
• 11.0.0.0 – 126.255.255.255
• 129.0.0.0 – 169.253.255.255
• 169.255.0.0 – 172.15.255.255
• 172.32.0.0 – 191.0.1.255
• 192.0.3.0 – 192.88.98.255
• 192.88.100.0 – 192.167.255.255
• 192.169.0.0 – 198.17.255.255
• 198.20.0.0 – 223.255.255.255

En conséquence, les plages complémentaires sont privées. Vous remarquerez notamment que la plage 192.128.xxx.xxx est privée et c’est la plupart du temps la plage qui est utilisée par le service DHCP (Dynamic Host Configuration Protocol, protocole qui permet d’attribuer dynamiquement des IP aux clients d’un sous-réseau) fourni par votre box internet.

De l’IP au nom de domaine

Bon maintenant qu’on a défriché la théorie sur le pourquoi de l’IP, revenons à nos moutons. Parce que bon je comptais vous parler de DNS moi au départ.

Le problème qu’on a maintenant c’est que si vous voulez accéder à une ressource précise, par exemple le site français de Google, il va falloir retenir que l’IP du serveur est 172.217.21.3 et taper ça dans votre barre de navigation à chaque fois que vous voulez utiliser ce moteur de recherche. Pénible non ? Un peu comme si au lieu de mettre l’adresse postale lisible et hiérarchique de vos destinataires vous indiquiez sur vos lettres les coordonnées GPS de leurs boîtes aux lettres. C’est tout aussi précis mais beaucoup plus pénible à retenir. Autre soucis : si le site migre d’un serveur à un autre (par exemple dans le cadre d’un changement d’hébergeur ou, au hasard, quand OVH déploie en urgence une copie de votre serveur parce que son datacenter a brulé…), il va changer d’IP. L’utilisation du nom de domaine (et d’une configuration DNS à jour, on y arrive) permet de rendre ce changement transparent pour l’utilisateur.

La bonne idée est donc de mettre en place une adresse associée à la localisation sur le réseau pour “cacher” l’IP aux utilisateurs qui s’en tamponnent. Cette adresse, c’est ce qu’on appelle un nom de domaine. En fait pour reprendre Google, google.fr est un nom de domaine qui pointe vers le serveur dont l’IP est 172.217.21.3.

Cerises multiples sur le gâteau : cela permet de mettre en place tout un tas de mécaniques dont un reparlera sans doute dans des articles futurs, par exemple avoir plusieurs noms de domaines qui pointent vers la même machine physique et qui donnent accès à des ressources différentes. Cela ne serait pas possible avec une IP “nue” sans précision de port ou d’URI (Uniform Resource Identifier pour demander une ressource précise).

Fonctionnement du DNS

Bon ça y’est, on est en fin là ! On va parler de DNS à proprement parler. Le DNS en quelques mots ? C’est ce qui permet de retrouver l’IP d’une machine en parant de son nom de domaine (que je noterai DN pour Domain Name à partir de maintenant). Dans les faits ça permet de faire d’autres choses dont on parlera peut-être un jour mais son usage principal (qui lui a donné son nom) reste celui-ci.

Implémentation naïve

L’idée naïve serait d’avoir sur chaque machine une liste exhaustive d’association DN <> IP. Naïve en effet car cela pose deux soucis majeurs : la taille du fichier et sa mise à jour.

Pour la taille du fichier, sachez que chaque segment d’un URL peut faire jusqu’à 63 caractères. Donc avec X.Y, en comptant le point, on tombe sur 127 caractères possibles. Un caractère se code typiquement sur 8 bits. Ajoutons un séparateur, par exemple l’espace (8 bits encore), et une IP sur 32 bits. On en est à 1056 bits par ligne de correspondance DN <> IP. Et on rappelle qu’on a 2 puissance 32 IP possibles. On arrive à la modique somme de… 4,125 To d’espace de stockage nécessaire (recheckez le calcul je l’ai fait à l’arrache sur un coin de table). Je sais pas vous, mais moi j’ai pas envie de me coltiner 4 teras de données juste pour pouvoir naviguer sur internet. D’autant que là je suppose qu’un ne met qu’un DN par IP, ce qui n’est pas forcément le cas ça peut être autant qu’on veut.

Second problème comme je vous le disais : la mise à jour du fichier. Si demain je renomme mon domaine thepr1ms.fr en thepr1ms.org parce que c’est moins cher (en vrai clairement pas, le .org coûte souvent assez cher), qui se charge de mettre à jour l’entrée correspondante à mon IP dans tous les fichiers locaux de toutes les machines de la planète ? Moi ? Dans ce cas j’ai accès en écriture à ce fichier chez tout le monde ? Super, je vais changer l’IP de google.fr pour un site de phishing à moi et entuber la France entière !!!

Vous l’aurez compris, la mise à jour des infos va être un point crucial de la réflexion derrière le DNS.

Idée moins naïve

Nouvelle tentative alors : on n’a qu’à garder un fichier de correspondance unique pour tout l’internet. Comme ça les 4 To on ne se les tape pas chez nous et en plus on s’assure que tout le monde a la même information.

C’est mieux en effet mais ça ne solutionne pas notre problème de la mise à jour puisqu’il faudrait encore une fois que tout détenteur d’un nom de domaine ait accès en écriture sur cette base de connaissance.

De plus, on se créé un nouveau problème : si le monde entier vient lire ce fichier à chaque fois qu’on tape un URL dans notre barre de navigation, on va faire péter le serveur qui héberge cette ressource. Ce n’est tout simplement pas tenable.

DNS : la vraie bonne idée

Bon je vous donne le secret ? Allez ok !

Je vais commencer par vous décrire le cheminement d’une requête DNS complète et on parlera ensuite de cache.

Lorsque vous demandez le site google.fr par le biais de votre navigateur, un cheminement se met en place pour trouver l’IP qu’il y a derrière. On parle de résolution DNS. Déjà il faut savoir qu’en réalité vos URL se terminent par un point que par convention les navigateurs n’obligent pas à fournir mais en soit la résolution DNS ne se fait pas pour “google.fr” mais pour “google.fr.”.

La première étape va être d’interroger un serveur DNS du root domain. Le root domain, qui correspond à ce “.” final est la racine de l’internet mondial. Les serveurs DNS du root domain ont pour seule et unique fonction de rediriger votre requête vers le bon serveur Top Level Domain (les serveurs qui gèrent .fr, .com, .net, .org, etc. — TLD pour la suite). Ici on va donc vous rediriger vers le serveur qui gère “.fr”.

Une fois sur le bon TLD, ce dernier va chercher quel serveur fait autorité (authoritative server) pour votre nom de domaine. Bon pour Google il s’avère que ce mastodonte dispose de ses propres name servers, par exemple ns1.google.com. Les serveurs du TLD sont en charge de tenir à jour une liste de correspondance entre les DN et les authoritative servers correspondants.

Enfin, vous arrivez sur l’authoritative server, typiquement associé à l’hébergeur du site que vous cherchez. Ce dernier serveur sait enfin à quelle IP correspond le nom de domaine que vous recherchez et peut vous fournir l’information. Ça y’est, vous êtes arrivés !

Ici on a solutionné tous nos problèmes : la masse d’information est répartie entre plusieurs acteurs et la personne qui a le dernier mot est votre hébergeur (ou un service qui lui est associé), qui peut donc s’assurer que vous et vous seul pourrez faire une mise à jour des informations concernant votre DN.

Bon j’aimerais qu’on s’attarde deux secondes sur les serveurs DNS du root domain, parce que les gens n’ont la plupart du temps pas conscience de leur existence. Ils constituent la clé de voûte de l’internet. Si demain quelqu’un les fait tous péter en même temps (bonne change, il y en a plusieurs centaines répartis partout sur le globe), internet c’est ciao. Enfin, pas tout à fait immédiatement, mais on en parle juste après.

Ces serveurs, même s’il en existe plusieurs centaines, auraient selon ce que je vous ai décrit plus haut à se farcir des requêtes à chaque fois que quelqu’un dans le monde charge un site web. Autant vous dire que ça fait trop de boulot : on estimait en 2019 le nombre de requêtes HTTP dans le monde à plus de dix mille milliards par jour. Même si on les répartissait sur disons 1 000 serveurs cela voudrait dire dix milliards de requête par jour et par serveur… c’est très clairement le non !

Mises en cache

Pour soulager ces pauvres serveurs du root domain, on a deux niveaux de mise en cache. Je ne pense pas qu’on ait parlé de cache à ce stade sur ce blog donc je vais décrire très rapidement le concept : l’idée c’est de stocker une information qu’on connaît déjà dans le but de ne pas avoir à la chercher à nouveau si on en a de encore besoin.

Le cache est une très bonne idée dans le fond car cela vous fait gagner un temps monumental. Toutefois les mises en cache posent deux problèmes majeurs : on ne peut pas tout retenir, sinon on finit par accumuler beaucoup de données et ce n’est pas viable (on reparlera à l’occasion de la mise en cache par votre OS quand il lit des fichiers par exemple) mais aussi (et presque surtout) on se retrouve à nouveau avec notre problème de l’implémentation naïve du début. Bah oui, si je garde une copie locale de la résolution DNS des sites que j’ai déjà visités, comment je peux être mis au courant des mises à jour éventuelles ?

On touche ici à la limite des caches : il s’agit de retenir pour gagner du temps, mais de savoir remettre en cause ce que l’on croit savoir quand on se réfère à un cache trop vieux.

Je disais donc, deux niveaux de cache ! Le premier c’est votre machine qui le garde : votre système d’exploitation garde en cache les résolutions DNS qu’il connaît pendant un certain temps. Pour la culture, Windows utilise par exemple un cache de 24h par défaut pour les entrées DNS.

Le second niveau de cache est au niveau de votre serveur DNS récursif. Et là vous vous dites “qu’est-ce qu’il nous veut avec ce serveur dont il ne nous avait pas encore parlé ?!” Entre vous et l’internet se trouve un serveur DNS — bien souvent fourni par votre FAI mais vous pouvez en choisir un manuellement — qu’on appelle serveur DNS récursif. Son rôle est de recueillir vos requêtes DNS, de vérifier s’il dispose de la résolution dans son propre cache et en fonction de ça de vous donner l’IP que vous cherchez ou de vous rediriger vers un serveur DNS du root domain.

Résolution DNS complète

On récapitule ? Vous avez bien suivi ? Lorsque vous taper un URL dans votre barre d’adresse, les actions suivantes ont lieu :

1. Recherche de la résolution dans le cache local de votre machine : si cela s’y trouve, vous obtenez l’IP, sinon on passe à l’étape 2
2. Recherche de la résolution DNS dans le cache de votre serveur DNS récursif : si c’est là l’IP vous est retournée, sinon on part à l’aventure en étape 3
3. Requête auprès d’un serveur DNS du root domain pour qu’on vous redirige vers un serveur DNS du TLD associé à votre nom de domaine
4. Le DNS du TLD recherche qui est l’authoritative server pour le nom de domaine et vous redirige chez lui
5. L’authoritative server est celui qui a l’accès direct au lien DN <> IP et vous donne une information fiable et fraiche sur l’IP recherchée.

Man in the middle

Ça y’est, nos histoires de man in the middle dont on parlait à l’époque des articles sur les certificats vont pouvoir prendre tout leur sens.

Imaginez la chose suivante : vous utilisez régulièrement des PC publics par exemple dans les aéroports ou les cybercafés. Ce que vous ne savez pas, c’est que JoeL3H4ckerWeshweshDu95 (que l’on réduira à JoeWesh pour la suite de notre exemple) utilise ces mêmes PC publics à ses heures perdues.

JoeWesh a quelques connaissances en informatique (peut-être parce qu’il lit ce blog), et il comprend à la fois le fonctionnement de la résolution DNS et celle des certificats. Il a donc créé chez lui son propre serveur DNS récursif (c’est pas si compliqué que ça) et l’a mis en place sur les PC publics de ce cybercafé du coin de la rue de la soif que vous fréquentez à moitié beurré le jeudi soir avant d’aller en boîte. Maintenant, quand vous tapez un URL dans la barre de navigation, c’est JoeWesh qui choisit où vous arrivez.

“Pas de panique” se disent certains d’entre vous “si je tape https://ma-banque-securisee-et-moderne.fr dans ma barre d’adresse, le navigateur va vérifier que le certificat qui me parvient est bien associé à ce DN et qu’il a bien été signé par une autorité de certification de confiance reconnue !”. Alors déjà, bravo, je vois que vous êtes des fidèles lecteurs de ce blog et que vous suivez !

Mais vous vous souvenez aussi qu’on peut créer sa propre autorité de certification pour signer ses propres certificats. Et ça, JoeWesh le sait bien lui aussi. Il a d’ailleurs créé une fausse version du site de ma-banque-gnagnagna dont on parlait plus haut et lui a autosigné un beau certificat… auquel il a demandé aux navigateurs de votre petit cybercafé du coin de la rue blablaba de faire confiance !

Vous voyez où on en vient là ? Vous voulez innocemment vous connecter sur le site de votre banque mais que nenni, vous êtes chez JoeWesh et rien ne vous l’indiquera (si ce n’est la faute d’orthographe sur la bannière de la page d’accueil du faux site lors JoeWesh est un illettré qui porte peu d’attention au détails).

Bon dans les fait, si JoeWesh a un accès total et complet à cette machine il utilisera des moyens plus directs de vous nuire (keylogger, logiciels pirates…), mais bon, vous voyez l’idée ?

La morale : ne faites jamais transiter d’informations importantes (typiquement des informations bancaires) sur des machines publiques. Le PC de la bibliothèque c’est pour faire des recherches et éventuellement lire les news mais certainement pas pour faire vos emplettes en ligne ou encore aller consulter votre compte client de chez Tesla.

Je vous laisse sur cette anecdote il y a quelques années des hackers ont ouvert sans soucis une Tesla réputée incrackable. Comment ? Ils se sont mis devant un fast-food, ont simulé la présence d’un Wi-Fi public sur lequel tournait un serveur DNS récursif maison. Un conducteur de Tesla est arrivé, s’est connecté sur son compte Tesla depuis ce Wi-Fi tout claqué au sol… Game Over ! Les mecs ont récupéré ses identifiants et ont pu le suivre à la trace via coordonnées GPS, attendre que le véhicule soit garé, l’ouvrir et sont aller faire une petite balade avec.