Les 1 et 2 septembre 2020, plusieurs FAI (Fournisseurs d’Accès à l’Internet) français, dont SFR et Bouygues, ont été « en panne », problème qui a été largement commenté dans les médias. En fait, leurs résolveurs DNS étaient hors-service, et il semble bien que c’était suite à une attaque menée contre ces résolveurs. Quelles leçons en tirer ?
Le 11 mai 2017, c'était la première édition de mon cours DNS de trois heures au CNAM. Pour l'anecdote, c'était dans le bâtiment où il y avait eu la première connexion UUCP/Usenet, et le premier serveur HTTP public, en France. https://www.bortzmeyer.org/files/cours-dns-cnam-SHOW.pdf
Traditionnellement, les requêtes DNS voyageaient sur le réseau en clair, visibles par tous. Ce n'est évidemment plus acceptable, notamment depuis les révélations de Snowden, et ce RFC normalise donc un mécanisme qui permet de chiffrer les requêtes DNS pour en assurer la confidentialité vis-à-vis d'un éventuel surveillant.
Une tribune sensationnaliste dans le Monde le 6 mai prétendait que « Google [avait] changé l'Internet » et portait une accusation précise : le navigateur Google Chrome utiliserait une racine DNS spécifique à Google. Passons sur le fond politique de l'article, est-ce qu'au moins les faits allégués sont exacts ?
Normalement, l'Internet est ouvert. C'est même une de ses principales caractéristiques : un outil de communication ouvert, où tout le monde peut s'exprimer. C'est cette ouverture qui est à la base de son succès. Mais une de ses conséquences est que certaines communications vont être indésirables pour certains. Il y a donc une demande pour du « blocage » ou du « filtrage », afin d'empêcher ces communications. Ce nouveau RFC, dû à l'IAB, examine les techniques de blocage et de filtrage et cherchent lesquelles sont le plus compatible avec une architecture saine et robuste de l'Internet. Évidemment, les techniques qui menacent le moins la robustesse de l'Internet sont celles qui se déroulent entièrement aux extrêmités. Si je ne veux pas voir les publicités, j'installe un logiciel qui télécharge sur ma machine une liste noire de serveurs distribuant ces publicités, et je peux ainsi bloquer et filtrer sans risques pour l'utilisation de l'Internet par les autres. Mais, hélas, pas mal de gens puissants se moquent de fragiliser l'Internet (ou la démocratie) et bien d'autres méthodes de blocage ou de filtrage existent.
Today, 4 March, ARTICLE 19 and Coding Rights are launching Net of Rights, a short film which explores the link between internet protocols and human rights online. The film will screen at 6pm at the Internet Freedom Festival, or can be seen on the Net of Rights website. || Le film téléchargeable https://hrpc.io/net-of-rights/
Aujourd'hui a été publiée la faille de sécurité Drown, touchant notamment la bibliothèque cryptographique OpenSSL. C'est l'occasion de se livrer à quelques réflexions sur Drown, TLS et la sécurité. Le même jour, huit (!) failles de sécurité dans OpenSSL ont été publiées (Drown a été éclaté en deux failles, CVE-2016-0800 et CVE-2016-0703). Cela ne facilite pas le travail de ceux qui essaient de démêler tout cela mais Drown est très bien documenté sur son site officiel (très complet, avec logo et tout). Je recommande également le papier officiel, très clair. Il n'y a normalement donc pas besoin de ré-expliquer ce qu'est Drown. Pourtant, je suis étonné de constater que certaines choses n'ont pas été comprises. Par exemple bien des gens croient que, puisque leur serveur HTTPS n'accepte pas SSLv2, ils sont en sécurité. Rien n'est plus faux et c'est bien expliqué dans la FAQ de Drown : pour effectuer cette attaque, il suffit que le certificat du site visé (et donc la clé privée) soit disponible sur un autre site, qui, lui, accepte SSLv2. Et, c'est là un point qui m'a personnellement surpris, ce cas est assez fréquent. Comme le note l'article Drown, le modèle de financement des AC encourage à acheter le moins de certificats possibles, et donc à les utiliser sur plusieurs serveurs, ou bien sur le serveur de production et sur celui de développement. [...] Autre question posée par Drown, pourquoi est-ce qu'il y a autant de machines qui acceptent encore SSLv2 ? Il a été officiellement abandonné en 2011 par le RFC 6176. Et le RFC est sorti bien tard, tous les experts savaient depuis longtemps que SSLv2 était cassé sans espoir de réparation. Mais les mises à jour ne se font, sur l'Internet, qu'à un rythme glacial (voir nul). Le problème n'est pas technique, il vient du fait que les mises à jour ne rapportent rien, n'ont pas de retour sur investissement, et ne sont donc en général jamais faites. Tout le monde s'indigne lorsqu'une faille comme Drown est publiée mais, en temps normal, personne ne s'en préoccupe. La prévention est toujours le parent pauvre de la sécurité. L'opérationnel et la sécurité concrète n'intéressent personne
Carré, Petit, Utile : Le programme radio des gens du numérique, tous les Jeudi à 11h sur Radio <FMR>
Des petits paquets dans le désordre, des tuyaux, non, pas des tuyaux, des cables, les Vrais Maître d'internet, comment couper l'information sur le réseau.
Nous recevons Stéphane Bortzmeyer ingénieur R&D pour l'AFNIC.
IETF https://www.ietf.org/
La suite de protocoles TCP / IP (en français, clair) http://www.linux-france.org/prj/edu/archinet/systeme/ch01s03.html
L'entête IP, expliqué par Sébastien Fontaine http://www.frameip.com/entete-ip/
Format général du datagramme IP (en anglais) http://www.tcpipguide.com/free/t_IPDatagramGeneralFormat.htm
podcast : http://cpu.dascritch.net/public/Sonores/Emissions/podcast/0012-CPU%2810-12-15%29.mp3
The author hesitated for a long time before publishing this article, because there are strong ethical issues. Documenting the effects of censorship can be seen as helping censors. For instance, if measurements show that censorship is very limited in practice, it may motivate some authorities to increase the pressure and its negative consequences. But I believe that censors are already better informed than the average citizen and that it is necessary to have factual information in order to have an informed debate in democracies.
Another big ethics issue concerns the measurements themselves. Is there a risk of endangering people who host a probe by doing DNS lookups for illegal/forbidden/questionable things (for instance DNS lookup for a porn site from a probe in Iran)? Today, the DNS is typically "under the radar" for most surveillance activities. Doing an HTTP request for an illegal site attracts attention to you in some countries (and it is one of the reasons why RIPE Atlas probes do not perform HTTP queries for arbitrary URLs), but it does not seem to be the case (yet) for DNS requests. (See RFC 7626, "DNS Privacy Considerations".)
cas intéressant cité par Phil Mayers sur la liste des utilisateurs de BIND va me permettre, cher lecteur, de t'instruire sur la différence entre nom de domaine et nom de machine.
La question originale était de savoir pourquoi on pouvait faire une résolution DNS (par exemple avec dig) de nexistesurementpas.um.outlook.com alors que les commandes comme ping ne pouvaient pas utiliser ce nom :
% dig +short nexistesurementpas.um.outlook.com
*.um.outlook.com.glbdns2.microsoft.com.
wildcard-emeasouth.um.outlook.com.
157.55.9.252
On récupère bien une adresse IP (c'est pareil avec d'autres outils DNS comme host) mais :
% ping nexistesurementpas.um.outlook.com
ping: unknown host nexistesurementpas.um.outlook.com
Mais, alors, pourquoi est-ce que ping prétend que ce nom n'existe pas ? (Le problème n'est pas spécifique à ping, d'autres commandes comme telnet font le même diagnostic.)
L'explication est qu'il existe une différence entre les noms de domaine (domain names) et les noms de machines (host names). Les premiers permettent à peu près tous les caractères possibles (cf. RFC 2181, section 11, et regardez le nom &-funny-%-syntax-$.bortzmeyer.org pour s'en convaincre). Les seconds obéissent à une syntaxe bien plus restrictive, documentée dans le RFC 1123, section 2.1. En gros, un nom de machine est restreint à LDH (Letters, Digits and Hyphen). C'est pour cela que je peux résoudre le nom rigolo indiqué plus haut :
% dig +short +nodnssec '&-funny-%-syntax-$.bortzmeyer.org'
www.bortzmeyer.org.
204.62.14.153
Mais que je ne peux pas l'utiliser :
% ping '&-funny-%-syntax-$.bortzmeyer.org'
ping: unknown host &-funny-%-syntax-$.bortzmeyer.org
« Ce[tte] RFC est en fait à la croisée de deux activités. L'une d'elles consiste à documenter les problèmes de vie privée, souvent ignorés jusqu'à présent dans les RFC. Cette activité est symbolisée par le RFC 6973 (…). Et la seconde activité qui a donné naissance à ce RFC est le projet d'améliorer effectivement la protection de la vie privée des utilisateurs du DNS, en marchant sur deux jambes : minimiser les données envoyées (…) et les rendre plus résistantes à l'écoute, via le chiffrement. ».
La méthode que j'ai utilisé la plupart du temps est simplement d'éteindre le Pi, de prendre la carte SD et de la mettre dans un PC Linux où on pourra réparer tranquillement. Bien sûr, cela nécessite d'avoir un PC sous la main mais je suppose que peu de gens ont un Pi sans aucun autre ordinateur.
Une fois la carte SD montée sur la machine Linux, on a alors un environnement Unix complet pour investiguer, et réparer. Cela va bien plus vite.
Comment indiquer qu'un domaine ne reçoit jamais de courrier ? Jusqu'à présent, il n'existait pas de mécanisme standard, permettant d'indiquer aux clients de ne pas perdre de temps à essayer d'écrire. Ce nouveau RFC indique une méthode, le « MX nul » qui consiste à mettre un point en partie droite de l'enregistrement MX.
Le protocole TLS offre un grand nombre de choix : choix de la version, choix des algorithmes cryptographiques, plein d'options... Tous ces choix ne sont pas équivalents en terme de sécurité : les versions anciennes de TLS ont des vulnérabilités absentes des plus récentes, par exemple. Dès qu'un protocole cryptographique a des choix, il y a un risque de sécurité : que l'attaquant tente de perturber la négociation initiale entre les deux parties, pour les amener à choisir les variantes les moins sécurisées, en faisant croire à chacun que son partenaire ne peut pas gérer les meilleures variantes. C'est ce qu'on nomme une attaque par repli (downgrade attack) et c'est une plaie classique des protocoles cryptographiques (sauf de ceux qui n'offrent aucun choix, mais qui ont d'autres problèmes, notamment l'impossibilité d'évoluer). Ce RFC présente une nouvelle technique TLS pour empêcher certaines attaques par repli : annoncer un algorithme cryptographique qui n'est pas un vrai algorithme mais qui signale qu'on a effectué un repli, permettant au partenaire de détecter que quelqu'un a interféré avec la communication. Cette technique se nomme SCSV, pour Signaling Cipher Suite Value.
L'Afnic travaille, notamment au sein du CENTR et de l'IETF, à améliorer la protection de la vie privée pour les utiisateurs du DNS. Le protocole DNS est un élément peu connu mais crucial de l'infrastructure de l'Internet. Aujourd'hui où les préoccupations sur la vie privée ont pris beaucoup d'ampleur, il est donc normal de se pencher sur la question « DNS et vie privée ». Tout utilisateur de l'Internet se sert abondamment du DNS, même s'il ne s'en rend pas compte, et même s'il ignore tout du DNS et des noms de domaine. À chaque fois que cet utilisateur envoie un message, qu'il clique sur un lien hypertexte, que son ordinateur met à jour ses logiciels, il y a une (et souvent bien plus d'une) requête DNS. Mais, autant les questions de vie privée liées au protocole du Web, HTTP, ont été longuement discutées (qu'on songe aux débats comme « faut-il une autorisation explicite de l'utilisateur pour placer des cookies ? » ou bien « l'adresse IP est-elle une donnée nominative ? »), autant celles liées au DNS ont été d'abord négligées, puis ensuite étudiées uniquement dans un petit cercle, essentiellement à l'IETF. La sortie prochaine du RFC « DNS privacy considerations » sera la première manifestation officielle de cet intérêt.
Le DNS est un système décentralisé, mais arborescent : toute zone (à part la racine) dépend d'une zone parente, qui doit notamment indiquer les serveurs de noms de ses zones filles. En théorie, l'information dans la zone parente et celle dans la zone fille doivent parfaitement coïncider mais, en pratique, des différences apparaissent souvent, et elles ont parfois des conséquences ennuyeuses, pouvant aller jusqu'à mettre en danger le bon fonctionnement de la zone. La principale raison de cette « désynchronisation » est qu'il n'existait aucun mécanisme standard par lequel le gestionnaire d'une zone fille pouvait transmettre à la zone parente les données à distribuer. C'est ce manque que comble notre tout nouveau RFC, avec l'introduction des enregistrements DNS de type CSYNC (Child SYNChronization).
Tout l'Internet repose sur le protocole BGP, qui permet l'échange de routes entre opérateurs Internet. (BGP est normalisé dans le RFC 4271.) La sécurité de BGP est donc cruciale pour l'Internet, et elle a fait l'objet de nombreux travaux. Ce nouveau RFC résume l'état actuel des bonnes pratiques en matière de sécurité BGP. Du classique, aucune révélation, juste la compilation de l'état de l'art. Ce RFC porte aussi bien sur la protection du routeur, que sur le filtrage de l'information (les routes) reçues et transmises.
Ce genre de compilation aurait plutôt due être faite dans le cadre du project BCOP mais celui-ci semble mort.
La section 2 de ce RFC rappelle qu'il n'a pas de caractère obligatoire : il expose des pratiques de sécurité générales, et il est toujours permis de faire des exceptions, en fonction des caractéristiques spécifiques du réseau qu'on gère.
Donc, au début (sections 4 et 5 du RFC), la protection de la discussion entre deux routeurs, deux pairs BGP qui communiquent (sécurité du canal). Ensuite (sections 6 à 11), la protection des informations de routage échangées, le contrôle de ce qui est distribué (sécurité des données).
Suite aux révélations du héros Edward Snowden, bien des gens ont pris conscience de ce que tous les experts en sécurité annonçaient depuis longtemps : les services d'espionnage espionnent et ne respectent aucune limite. Notamment, tout le trafic envoyé sur l'Internet peut être écouté, si on ne prend pas de précautions particulières. La solution technique la plus souvent citée est l'usage systématique de la cryptographie. Ce choix est tout à fait justifié. Mais il ne faut pas s'imaginer qu'il va être gratuit : tout chiffrer va faire perdre certaines possibilités, notamment en matière de déboguage.