bortzmeyer

Le 23 septembre, je reçois (sur une adresse personnelle) un spam venant d'une entreprise de spam (l'émetteur SMTP est publi-redactionnel.deltapresse.fr / 77.32.194.137) et me proposant EN CRIANT « PROPOSITION D'UN PUBLIREPORTAGE DIFFUSÉ SUR LE FIGARO ». Le texte prétend que « Le tournage se déroule dans le studio du Figaro au 14 Boulevard Haussmann à Paris 9ème » et que « Vous bénéficiez des audiences du Le Figaro , premier site d’information en France, disposant d'une cible qualifiée aux quatre coins de l'Hexagone. (Note de ma part : À mon avis, un hexagone a six coins, mais passons.) Cette émission est préparée en amont avec notre présentateur « Itinéraire Entreprise ». C'est donc vous qui choisissez les sujets que vous souhaitez aborder lors de l'entretien. L’objectif ? Promouvoir votre société, votre savoir-faire et vos compétences. Grâce à cette interview vidéo, vous pourrez communiquer en misant sur votre personnalité et être vu partout et tout le temps. » Il s'agit bien de publicité, pas d'un reportage : « Préparation : Notre présentateur “Itinéraire Entreprise” vous contacte une semaine avant pour préparer l'interview en amont. Cet exercice vous permet d'anticiper les questions pour vous sentir plus en confiance lors du tournage » et pour faire plus pro « Transport : Un chauffeur est à votre disposition pour vos trajets à Paris intramuros et vous emmène directement dans les locaux du Figaro Boulevard Haussmann. Maquillage : À votre arrivée, une hôtesse d'accueil vous reçoit et vous accompagne dans la loge pour une séance de maquillage en accord avec la lumière du plateau. » Le résultat : on sera connu « Photo : Des clichés professionnels sont capturés pour la création de visuels sur vos réseaux sociaux. Interview : Une prise de parole est opérée face caméra avec notre présentateur. Rédaction : Un article de 750 mots récapitulatif est rédigé par notre attachée de presse. Il comprendra vos coordonnées ainsi que trois liens vers votre site internet et vos réseaux sociaux. Relais digital : Notre partenaire Delta Presse diffuse votre article à un panel de plus de 95 000 journalistes pour un relais sur différents médias. (Note de ma part : J'en profite pour vous recommande les savoureux tweets d'un journaliste spécialisé en informatiuqe qui se moque des innombrables communiqués de presse débiles qu'il reçoit, mot-croisillon CommuniquéIdiotDuJour sur Twitter.) Publication : La vidéo et l'article sont diffusés sur la page économie du Le Figaro. Une page web sur le Le Figaro hxxps://www.lefigaro.fr/economie/dossier/itineraire-entreprise ) vous sera complètement dédiée. Tracking (Note de ma part : comme c'est mignon, comme terme : les spammeurs n'ont pas honte de dire qu'ils fliqueront les visiteurs, par exemple avec des web bugs.) : Un suivi de l'audience de votre interview est réalisé par nos soins. Vous bénéficierez d'un taux de rebond et d'un référencement efficace grâce à l'interview et de ces liens dont raffole Google. Une fois diffusée, vous recevrez une copie de cette interview pour votre site internet et vos propres réseaux sociaux. » À aucun moment, ils ne parlent du prix que cela me coûtera si j'étais assez bête et assez vaniteux pour accepter. J'ignore si le Figaro est vraiment impliqué, je vais leur demander.

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) : 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 : Ç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é.