bortzmeyer

https://www.bortzmeyer.org/

Le 4 août 2020, le « Community Manager » de la Direction Générale des Finances Publiques à écrit sur Twitter « Un nom de domaine est imitable » en réponse à une question d'un utilisateur qui s'inquiétait d'un message de hameçonnage reçu, message qui prétendait venir de ne_pas_repondre@dgfip.finances.gouv.fr. Puis le même « Community Manager » a donné des détails dans un autre tweet.

Le problème de la sécurité du courrier électronique et de la sécurité sur l'Internet en général est compliqué. Il n'est pas facile d'expliquer dans les 280 caractères d'un tweet des questions subtiles d'authentification sur les réseaux informatiques. Néanmoins, comme il s'agit ici d'un service officiel et important, il me semble qu'une grande rigueur dans les faits est nécessaire. Voyons donc ce qui n'allait pas dans ces deux tweets.

D'abord, mon explication : l'expéditeur, dans le courrier électronique, n'est pas authentifié. Pas du tout. Je peux trivialement envoyer un message qui prétend venir de macron@elysée.fr ou de inspecteur@impots.gouv.fr et cela passera. Conséquence pratique de ce problème : il ne faut pas agir uniquement sur la base d'un message électronique. Surtout s'il s'agit d'argent. Ne visitez pas un site Web inconnu, et surtout ne laissez pas votre nom et votre mot de passe uniquement parce que l'adresse de ce site Web figurait dans un message prétendant venir de l'État.

Les experts en Internet me feront remarquer que c'est plus compliqué que cela : d'abord, il y a deux adresses d'expéditeur dans un message, celle de l'enveloppe et celle de l'en-tête. Et des techniques comme SPF ou DKIM permettent de l'authentification partielle de l'expéditeur. Certes, mais rappelez-vous du contexte : il s'agissait de répondre sur Twitter, donc rapidement, et à quelqu'un qui n'était pas expert et n'aurait peut-être pas eu la patience d'écouter de longues explications.

Mais cela n'empêche pas de faire attention à l'exactitude des informations données. Commençons avec « Les noms de domaine sont imitables ». La phrase est tellement vague qu'il est même difficile de la critiquer. Fait-elle allusion au cas particulier du courrier électronique, où on a vu que le mensonge est techniquement facile ? Ou bien à des risques spécifiques aux noms de domaine, comme le détournement d'un nom suite à un piratage d'un des acteurs de la chaine de gestion des noms ? Ou à des attaques techniques sophistiquées, nécessitant des techniques de défense comme DNSSEC ? Ou encore à la possibilité d'un escroc d'utiliser un nom qui ressemble assez au vrai pour tromper l'utilisateur distrait ? Difficile de le savoir.

Ensuite, le tweet original dit « dans ce cas précis notre adresse ne comporte pas de _ mais des - ». Cela ne change rien. Le hameçonneur aurait pu tout aussi bien, sans difficulté, prétendre envoyer depuis ne-pas-repondre@dgfip.finances.gouv.fr. S'il ne l'a pas fait, ce n'est pas parce qu'il y a une quelconque impossibilité technique, c'est juste qu'il était négligent ou, plus probablement, qu'il a pensé que personne ne ferait attention.

Ensuite, le deuxième tweet dit « Oui un nom de domaine est imitable mais pas l'adresse entière ». Là, la phrase est assez précise pour qu'on puisse dire qu'elle est fausse. Dans l'usurpation d'une adresse de courrier, il n'y a pas de différence entre le nom de l'utilisateur (à gauche du @) et le nom de domaine (à droite du @). S'il y en a une, elle va plutôt dans l'autre sens : des techniques existent pour limiter l'usurpation sur le nom de domaine, mais il y en a beaucoup moins pour le reste de l'adresse.

Pour résumer : vérifier l'adresse de l'expéditeur du message ne sert pas à grand-chose, surtout si on n'est pas expert du domaine, il faut plutôt vérifier l'adresse Web vers laquelle le message essaie de vous faire aller. Si c'est censé venir du gouvernement français, le nom de domaine dans cette adresse Web se terminera forcément par .gouv.fr.

Le projet NSA d'un serveur DNS a été décrit dans un article de CyberScoop et résumé par NextInpact (voir aussi cet article). L'article original n'est pas très détaillé techniquement donc il y a forcément pas mal de spéculation dans les commentaires. Il s'agirait apparemment de créer un résolveur DNS souverain, menteur et (partiellement) public. Souverain car géré par un pays (les États-Unis) pour lui-même. (Un exemple de résolveur DNS souverain est le Bouclier Canadien fait par le registre du .ca, un autre exemple est un projet indien  qui n'avance pas.) Menteur car il est prévu qu'il altère les réponses DNS, par exemple pour gêner l'accès aux serveurs utilisés par le logiciel malveillant. (Et peut-être pour bloquer le porno aussi.) Partiellement public car il semble qu'il sera réservé aux entreprises étatsuniennes travaillant pour l'armée. (Un autre exemple de résolveur DNS pour l'État existe en Grande-Bretagne, le 25.25.25.25, géré par le registre du .uk.) Faire gérer ce résolveur par la NSA est amusant. C'est l'occasion de rappeler que les protocoles sécurisés comme DoH (DNS sur HTTPS) ou DoT (DNS sur TLS) ne protègent que contre un tiers, pas contre le gérant du serveur. (On n'a pas encore d'information fiable sur les protocoles qui seront disponibles sur ce service.)

À propos d'un article sur DoH et la situation en Inde

Arun Mohan Sukumar a écrit un article https://thewire.in/tech/mozilla-dns-over-https-protocol-privacy-geopolitics au sujet du protocole DoH (DNS sur HTTPS). Rien de nouveau ou d'original, à part sous l'angle géopolitique puisqu'il mentionne des arguments liés à la situation en Inde. La plupart des arguments donnés dans l'article sont archi-classiques et je les ai déjà traités sur mon blog https://www.bortzmeyer.org/doh-et-ses-adversaires.html Je ne vais mentionner ici que ceux spécifiques à l'Inde et à l'Asie. D'abord, des services comme des résolveurs DoH de confiance sont particulièrement importants en Inde. Le pays est certes une démocratie (dirigée actuellement par un parti intégriste et autoritaire) mais c'est aussi un pays où la censure de l'Internet est très fréquente, justifiée par des arguments puritains ou politiques (la situation au Cachemire est un bon prétexte pour qualifier toute opposition de propagande terroriste, ou pour estimer qu'elle risque d'encourager des violences). Les Indiens cherchent donc à contourner cette censure et DoH est un outil parmi d'autres pour cela. Bref, quand l'article dit « enabling this protocol essentially undercuts national laws or ISP policies prohibiting certain content », je réponds « oui, et c'est bien le but ». L'argument de sécurité est assez ridicule quand la seule référence est un article vague sur le nombre d'attaques DNS, mêlant des attaques sans rapport entre elles. Ensuite, sur l'argument géopolitique, oui, la souveraineté locale est un problème réel, et faire passer ses requêtes DNS d'un FAI local qui ment et surveille à une boîte états-unienne qui surveille n'est pas forcément un progrès. La solution n'est pas d'interdire ou d'empêcher les utilisateurs de choisir un résolveur tiers, la solution est de leur fournir des résolveurs de confiance, qu'ils aient envie d'utiliser.
DoH lui-même n'est qu'une technique : on peut parfaitement faire du DoH avec un résolveur menteur, et l'article note d'ailleurs qu'il y a un tel projet en Inde. Mais, en Inde comme en France, les grands discours ministériels sur la souveraineté numérique ne sont pas toujours suivis d'effets concrets. Tiens, l'article oublie de dire, alors qu'il parle de DNS, que le domaine national .in est géré depuis des années par une entreprise états-unienne... PS : le document de l'IETF cité n'est pas un document de l'IETF mais un Internet-Draft. Tout le monde peut en écrire un, ils ne font l'objet d'aucune validation. Celui-ci a été écrit par un FAI étatsunien qui regrette la perte de contrôle sur les utilisateurs liée à DoH. PS : un interprète me dit que le dialogue « Tumhara khoon hai khoon?! Kya humara khoon pani hai? », non traduit dans l'article, est un affrontement verbal, genre « mon sang n'est pas de l'eau ».

Introduction

Le défi était « une explication pédagogique des informations que retourne dig nomdedomaine.tld NS et CNAME ». Voici une tentative de réponse.

Petit détour sur dig

dig est un programme informatique qui interroge des serveurs Internet pour trouver de l'information au sujet d'un nom de domaine. Après le nom de la commande (« dig »), on trouve le nom de domaine concerné, et un type.

NS

Le type NS signifie « serveurs de noms » (NS est le sigle « name server » en anglais). La commande « dig cam.ac.uk NS » va nous renvoyer les serveurs de noms de l'université de Cambridge. Ces serveurs de noms sont les machines qui répondent aux questions sur ce domaine. Elles voient donc passer les questions des internautes. Si elles sont toutes en panne, le domaine ne marche plus.

CNAME

Le type CNAME dit qu'on cherche le « vrai » nom d'un domaine qui est un alias, un surnom. Ce système d'alias permet d'avoir plusieurs noms « pointant » tous vers un vrai nom. Ainsi, la commande « dig f7ds.liberation.fr CNAME » nous permet de voir que le vrai nom du domaine f7ds.liberation.fr n'est pas sous liberation.fr. (Le vrai nom est liberation.eulerian.net, Eulerian étant une entreprise de surveillance des internautes, à des fins publicitaires.) Mais toutes les utilisations de CNAME n'ont pas pour but de tromper l'utilisateur.

Et pour en savoir plus

Alternatives à dig

Vous n'êtes pas obligé·e·s d'utiliser dig. Le système des noms de domaines (DNS, pour « domain name system » en anglais) peut être interrogé par bien d'autres programmes. Par exemple, sur le Web, l'adresse https://dns.bortzmeyer.org/gouv.td/NS vous permettra de voir les serveurs de noms du domaine du gouvernement tchadien. (C'est donc l'équivalent de « dig gouv.td NS ».) Si vous utilisez le réseau social « fédivers » (parfois appelé Mastodon), vous pouvez écrire à DNSresolver@botsin.space avec un nom de domaine et un type, et vous aurez la même information.

Tout savoir sur le DNS

Mon cours sur le DNS dans une école d'ingénieurs est en ligne.

Test de guillemets Comme le disait Ronsard  « c'est mieux avec des guillemets français ».

Test de Syncthing Syncthing https://syncthing.net/ est un outil de synchronisation de fichiers en pair-à-pair. J'ai testé avec deux machines, un PC Ubuntu et un ordiphone Android. Les machines se reconnaissent par leur “device ID”, un condensat d'une clé cryptographique. Sur Android, on peut l'afficher avec “Afficher l'ID de l'appareil”. Sur Ubuntu via l'interface Web “Show my ID”. Pour accepter l'Android, j'ai utilisé la fonction qui affiche les ID des machines du même réseau local. Pour accepter le PC, j'ai utilisé le QR-code affiché dans l'interface Web. Installation sur Ubuntu : dans le magasin standard, donc apt-get install syncthing (ou bien le cliquodrome d'installation de logiciels). Aucune idée de ce qu'on doit faire après, je ne trouve pas la doc. Ah, si, le lien était discret : https://docs.syncthing.net/intro/getting-started.html On lance syncthing et il crée les clés puis vous redirige vers une interface Web Installation sur Android : via le Google Play Store. Il faut ensuite explicitement indiquer quels dossiers on partage ET REDÉMARRER SYNCTHING (c'est documenté mais on oublie toujours). Ensuite, l'Android voit le dossier ~/Sync que le PC partage. En sens inverse, le dossier est automatiquement créé, avec un identificateur choisi par Syncthing (et pas moyen de le renommer). Globalement, le concept semble bon. Mais Syncthing est très difficile à utiliser : dès qu'on a fait des trucs un peu non standard (par exemple parce qu'on débute et qu'on n'a pas bien compris les concepts), on a des messages pas clairs genre “Out of sync” ou “missing folder”. En cas de problème, il faut bien tout supprimer, arrêter syncthing, redémarrer et recréer les partages.

J'ai lu rapidement le livre de Juan Branco, « Crépuscule » (Dans l'édition en ligne, il y a peut-être moins de coquilles dans l'édition papier. http://branco.blog.lemonde.fr/files/2019/01/Macron-et-son-Crepuscule.pdf) En gros, je n'ai pas aimé. Son style est effet ampoulé et on a envie de lui dire « calme-toi, Juan, tu n'es pas Victor Hugo sur les barricades de 1848 »). Un éditeur aurait dû lui dire de se relire sérieusement. Mais, surtout, Branco personnalise trop. On a l'impression à le lire que tous les problèmes de notre société viennent de ce que X couche avec Y, ou que W dîne avec Z. Franchement, que les riches vivent entre eux, et sont d'accord politiquement sur l'essentiel, on le savait et ce livre n'apporte rien à ce sujet. Sans compter que ça tourne souvent au (long) réglement de comptes personnel, avec des gens qu'il n'aime pas. Ce livre n'est pas une analyse de classe. Sur les riches, il vaut mieux relire les Pinçon-Charlot. Sur la politique française, plutôt voir Ruffin. Et, sur la complicité des médias avec l'État et les patrons, il faut plutôt se renseigner chez Acrimed. Sans compter que le livre n'est pas exempt d'erreurs comme de dire que Niel doit sa fortune à la licence de téléphonie mobile (il était déjà milliardaire avant). Et, par ses outrances, Branco offre une cible facile aux macroniens, ce qui leur évite de répondre sur le fond.

Vous avez certainement déjà vu des articles sur les mauvaises pratiques de Facebook en matière de gestion des données privées. Vous en avez peut-être même un peu assez, genre « oui, c'est bon, on a compris, ce sont des méchants, pas la peine de le répéter si souvent ». Et c'est vrai qu'on peut avoir l'impression qu'il ne peut plus y avoir de nouveau avec Facebook, que toutes les saloperies possibles, ils les font déjà. Pourtant, même si on est un anti-Facebook convaincu, on peut quand même être surpris (et, hélas, en mal) par le rapport de l'association Privacy International au sujet de Facebook et plus spécialement de la façon dont Facebook s'arrange pour que les apps (les programmes) tournant sur les ordiphones Android lui envoient des données personnelles, sans autorisation de l'utilisateur, sans que celui-ci ou celle-ci le sache, et sans même qu'il ou elle ait un compte Facebook. Le rapport est une étude concrète. Pas de grandes diatribes comme en font nos intellectuels français contre les affreux « géants de l'Internet », en restant dans le vague. Ici, au contraire, comme le fait Exodus Privacy (qui est cité dans le rapport), les auteurs ont regardé de près la question. Ils ont pris un certain nombre d'apps tournant sur Android (non pas qu'iOS, le système d'exploitation des iPhone, soit meilleur, mais simplement le temps manquait pour tout tester sérieusement), les ont fait tourner dans un environnement de test, avec interception et décryptage des communications entre l'app et Facebook. Et les résultats sont consternants : les deux tiers des apps envoient des données personnelles à Facebook, dès le démarrage, qu'on soit utilisateur de Facebook ou pas. Exodus Privacy avait déjà montré que la plupart des apps disponibles sur le magasin d'apps d'Android (Play Store, propriété de Google) incluent un grand nombre de pisteurs, de dispositifs techniques permettant de suivre à la trace les utilisateurs. Privacy International a une approche technique différente, en faisant une analyse dynamique, et non plus statique, de l'app. Leur interception des communications chiffrées avec Facebook permet de lire le contenu des messages. C'est ainsi qu'ils montrent que ces messages envoient l'identifiant publicitaire Google, un identificateur unique spécifique à chaque téléphone, que Google fournit gentiment pour faciliter le suivi des utilisateurs. Cela, c'est l'envoi de base. Voici cet identifiant publicitaire (vous pouvez trouver le vôtre sous Paramètre –> Google –> Annonces) : Copie d'écran d'un ordiphone, montrant l'identifiant publicitaire Mais certaines applications font bien pire, en envoyant d'autres données, parfois plus sensibles. Pourquoi tant de développeurs ont-ils choisi d'envoyer ces données à Facebook ? Parfois, c'est tout simplement qu'ils ne le savaient pas. Ils avaient inclus le SDK (Software Development Kit, la bibliothèque logicielle que Facebook fournit à ceux qui veulent inclure certains services Facebook dans leur app) et le SDK, dès le démarrage de l'application, envoie les données à Facebook, avant toute demande d'autorisation. (Notez qu'Exodus Privacy avait déjà noté un problème similaire : des développeurs informatiques négligents incluent une bibliothèque dans leur app, sans vérifier si elle ne comprend pas des pisteurs.) Je vous laisse lire le rapport complet, très bien fait, pour voir l'ampleur des dégueulasseries (le mot n'est pas trop fort) commises par Facebook et ses complices. Une partie très intéressante est celle qui contient les réponses des sociétés mises en cause, que Privacy International avait prévenues. Un festival de langue de bois corporate, plein de « your privacy is important to us », « we work very hard to improve the user experience », « we are committed to comply » et autres mensonges. Très peu d'entreprises répondaient concrètement, très peu annonçaient des mesures précises. La palme revient à Google qui prétend que l'identificateur publicitaire est changé lorsqu'on réinitialise l'ordiphone Android aux valeurs d'usine (cassant le suivi de l'utilisateur) alors que l'équipe de Privacy International a pu vérifier que c'était faux. On voit là le poids à accorder aux déclarations, aux privacy policies et autres promesses. Facebook annonce quand même que le SDK a été modifié (un mois après l'entrée en application du RGPD) pour ne plus envoyer d'informations sans demande explicite de l'app. Cela ne concerne que les apps qui seront créées, dans le futur, avec le nouveau SDK. Mais pour le reste, Facebook refuse toute responsabilité, puisque les conditions d'utilisation du SDK précisent que c'est au(x) développeur(s) de l'app d'obtenir un consentement de l'utilisateur... Bref, on voit qu'une entreprise comme Facebook est au-delà de toute possibilité de réforme, et qu'elle doit être détruite.

Suite des essais Write.as. Maintenant que je me suis abonné à bortzmeyer@write.as depuis mon compte Mastodon, je regarde si je reçois les notifications. Au passage, je me rends compte que je ne sais pas quelle variante de Markdown est utilisée par Write.as donc comment inclure des images de chats, pour mon SEO ? Apparemment, la solution documentée est d'utiliser la syntaxe Pandoc mais il faut héberger l'image à l'extérieur de Write.as. Exemple : Une image d'exemple Ça marche, la notification a bien été envoyée et reçue sur Mastodon. Par contre, en cas de mise à jour de l'article, rien n'est notifié.

Ce qu'il y a de bien, sur l'Internet, c'est que chacun·e peut s'exprimer. Avant l'Internet, la liberté d'expression était surtout théorique, Mme ou M. Michu n'avait pas de moyen concret de faire connaitre ses pensées au monde. Maintenant, c'est possible. Possible, mais pas forcément facile. Créer son blog, par exemple, est certainement faisable (je le fais) mais nécessite du temps, des compétences et des efforts (outre ceux, évidents, nécessaires à l'écriture elle-même). Même si on a les compétences, on n'a pas forcément le temps ou l'envie. Voilà pourquoi il est crucial qu'il existe des plates-formes simples d'usage, où on peut s'y mettre tout de suite. Le problème est qu'elles ont des inconvénients, notamment la captation de données personnelles. D'où l'intérêt du service Write.as, que j'ai découvert suite à un article d'Aris, et que je suis en train de tester. Il ne résout pas certains inconvénients des plate-forme. La dépendance, par exemple, reste ; si Write.as disparait, ce texte disparaitra aussi (je n'ai pas trouvé le moyen de sauvegarder ses textes sous leur forme éditable, il faut ratisser l'HTML produit, avec un logiciel comme httrack). Mais, au moins, il ne semble pas avoir de pisteurs Google ou Facebook (l'app sur ordiphone en a, et la création du compte fait passer par un CAPTCHA Google.) Write.as a ses propres pisteurs, dont mon bloqueur, uBlock Origin, a arrêté une partie. Pour avoir moins de dépendance vis-à-vis de la plate-forme, on peut utiliser son propre nom de domaine ce qui est évidemment très recommandé. Mais ce n'est accessible qu'avec l'offre payante, alors que j'utilise la gratuite. (Ce n'est pas forcément un problème : « si c'est gratuit, demande-toi si ce n'est pas toi le produit ».) Et même si Write.as n'est pas parfait, il est important qu'il existe une variété de plate-formes de publication. Il serait dramatique que tous les textes soient uniquement sur Medium, qui peut changer sa politique du jour au lendemain. Techniquement, c'est en effet très simple d'utilisation (et documenté). Pour mettre des liens ou des images, ou même simplement de l'italique, on utilise la syntaxe Markdown. (Je ne vois pas d'éditeur graphique, mais, bon, la syntaxe Markdown est simple.) Et le service est fédéré : vous pouvez suivre mes écrits depuis un logiciel du fedivers comme Pleroma ou Mastodon, en suivant bortzmeyer@write.as. (Vous pouvez aussi utiliser le classique flux de syndication, https://write.as/bortzmeyer/feed/.) Notez enfin que Write.as est fondé sur un logiciel libre, WriteFreely.