Loading...
An error has occurred

An error has occurred in Orbeon Forms. You may want to try one of the following:

  • Close this dialog and continue to use this page.
  • Reload this page. Note that you will lose any unsaved changes.
  • If the above does not work, try reloading the page yourself. Note that you will lose any unsaved changes:

    • With Firefox and Safari: hold down the shift key and click the Reload button in your browser toolbar.
    • With Internet Explorer: hold down the control key and click the Reload button in your browser toolbar.
  • Return home.
Help

PLANÈTE XMLFR

Agrégation de carnets web.

2020-01-20

Google inverse les noms de domaines

Le 16 janvier au matin, il y avait une bogue amusante (qui a duré quelques jours) dans le moteur de recherche Google. Les noms de domaine étaient dans certains cas inversés, plus exactement mélangés dans l'affichage.

Quand on cherche quelque chose dans ce moteur de recherche (sur une machine de bureau, car c'est différent sur les mobiles), Google affiche pour chaque résultat :

  • L'endroit où a été trouvé le résultat, sous une forme vaguement inspirée des breadcrumbs (Google affichait autrefois un URL, ce qui était plus intelligent mais a sans doute été changé sur demande du marketing car « M. Michu ne comprend rien aux URL » et Google n'aime pas éduquer les utilisateurs),
  • Le titre de la page, qui est un lien hypertexte (en promenant son pointeur dessus, on voit l'URL s'afficher en bas à gauche, ce qui est utile pour savoir où on va avant d'y foncer),
  • La date et un résumé.
On voit ici un exemple :

L'endroit de la page est fabriqué à partir de l'URL mais n'est pas un URL. Il commence par un nom de domaine et se continue par un chemin dans le site. Mais ce qui est amusant est que cet affichage est bogué. Dans certains cas, le nom de domaine est mélangé. L'exemple précédent est correct mais, si je cherche le département de physique de l'Université de Cambridge :

Le vrai nom de domaine est www.phy.cam.ac.uk mais Google affiche phy.www.cam.ac.uk. Autre exemple, avec le gouverneur de Californie :

Ici, le vrai nom était www.gov.ca.gov mais Google affiche gov.www.ca.gov. L'URL vers lequel pointe le résultat est néanmoins correct, comme on le voit avec cet autre exemple (Firefox affiche l'URL de destination en bas à gauche) :

Pourquoi cette bogue ? La raison fondamentale est sans doute une incompréhension des noms de domaine, notamment du fait que le nombre de composants d'un nom soit quelconque (contrairement à une légende répandue.) Vous noterez que les seuls noms ainsi massacrés sont des noms ayant plus de trois composants. Mais c'est curieux de la part de Google, dont les services ont d'habitude très peu de bogues.

Mais on peut aussi voir dans cette bogue le résultat d'une mentalité très fréquente dans le Web, et particulièrement chez Google, comme quoi les noms de domaine ne sont pas une information pertinente et peuvent être cachés, ou massacrés, sans problème.

Merci à Jean-Philippe Pick pour avoir noté le phénomène. Le problème a été réparé le 19 janvier, sans nouvelles de Google ou sans information publiée.

2020-01-14

Unix: A history and a Memoir

Ce livre est une histoire du système d'exploitation Unix, par une des personnes qui ont suivi l'aventure d'Unix depuis le début, Brian Kernighan.

D'abord, Kernighan écrit très bien, il a un vrai talent pour tout expliquer, y compris les questions informatiques complexes (comme le fameux tube, une des inventions les plus marquantes dans Unix). Ensuite, il a lui-même travaillé au développement d'Unix (il a notamment participé à la création du langage C, dans lequel Unix a été rapidement réécrit, après ses débuts en langage d'assemblage.) Cela lui permet de faire revivre une époque aujourd'hui bien distante.

Il y a fort longtemps, dans un pays lointain, pas du tout dans la Silicon Valley mais à Murray Hill, un gentil roi, la compagnie AT&T avait installé son service de recherche et développement, les Bell Labs. Les Bell Labs (qui existent encore aujourd'hui sous ce nom mais ne sont plus que l'ombre de ce qu'ils étaient) sont devenus une légende de la physique, de la mathématique et de l'informatique, avec pas moins de neuf prix Nobel obtenus (non, l'invention d'Unix n'a pas été récompensée par un prix Nobel.)

C'est dans ce pays merveilleux que deux informaticiens, Ken Thompson et Dennis Ritchie, après le semi-échec du projet Multics, et le retrait des Bell Labs de ce travail, se sont attaqués à une de ces tâches où tous les gens raisonnables vous disent « c'est complèment irréaliste, jeune homme, vous n'êtes pas sérieux ». Ils ont écrit un système d'exploitation et Unix était né, prêt à conquérir le monde. Ce livre est l'histoire d'Unix. Elle est pleine de rebondissements, de crises, de discussions.

Pour rappeler l'importance d'Unix, il faut se souvenir que beaucoup de choses qui nous semblent aujourd'hui évidentes en informatique ne l'étaient pas à l'époque. Par exemple, la grande majorité des systèmes d'exploitation imposaient de fixer une taille maximale à un fichier avant sa création. Si elle était trop faible, on devait re-créer un autre fichier et copier les données. Si cette taille était trop élevée, on gaspillait de l'espace disque. Unix a mis fin à cela et, aujourd'hui, cela va de soi. De même Unix a unifié les différents types de fichiers. Avant Unix, plusieurs systèmes d'exploitation avaient des commandes différentes pour copier un fichier contenant un programme Cobol et un fichier de données !

L'atmosphère très spéciale des Bell Labs, informelle, avec peu de bureaucratie, un accent mis sur les compétences et pas sur les titres (une méritocratie, une vraie) a beaucoup aidé à développer un système d'exploitation à succès. Kernighan raconte beaucoup d'histoires amusantes, mais consacre également du temps à l'analyse des facteurs importants dans le succès des Bell Labs. Il insiste sur les facteurs physiques (« geography is destiny ») : tout le monde sur le même site, et un mélange de bureaux fermés (même les stagiaires avaient leur propre bureau fermé, loin de l'open space bruyant empêchant la concentration) et de pièces communes où on pouvait aller quand on voulait, discuter et interagir avec les autres. Les Bell Labs ont été un cas peut-être unique, où toutes les conditions étaient réunies au même endroit, pour produire une étonnante quantité d'inventions géniales. Le tout était aidé par un financement stable et un management qui laissait les chercheurs tranquilles. Il est curieux (et triste) de noter qu'une entreprise 100 % capitaliste comme AT&T donnait plus de liberté et de stabilité financière à ses chercheurs qu'une université publique d'aujourd'hui, où les chercheurs doivent passer tout leur temps en travail administratif, en évaluation, et en recherche d'argent.

Aux Bell Labs, il était fréquent pour un chercheur de travailler sur plusieurs sujets de front et le livre de Kernighan donne une petite idée de la variété des sujets. Anecdote personnelle : j'ai utilisé (très peu !) le système Ratfor que l'auteur avait écrit, quand je faisais du calcul numérique.

Une particularité d'Unix est en effet la profusion d'outils pour informaticiens qui ont été développés sur ce système. L'auteur consacre de nombreuses pages à ces outils en insistant sur le fait que le goupe Unix des Bell Labs maîtrisait toujours la théorie et la pratique. Chaque membre du groupe pouvait écrire une thèse en informatique théorique, et inventer puis programmer des outils utiles. Mais on oublie souvent que les premiers utilisateurs d'Unix n'étaient pas que des informaticiens. Le premier argument « de vente » d'Unix auprès de la direction des Bell Labs était ses capacités de… traitement de texte. Le service des brevets de Bell Labs déposait beaucoup de brevets, et leur préparation prenait un temps fou. En bons informaticiens, les auteurs d'Unix ont automatisé une grande partie des tâches, et les juristes se sont mis à préparer les demandes de brevets sur Unix…

De nos jours, on associe souvent Unix au logiciel libre, puisque Linux, FreeBSD et bien d'autres héritiers de l'Unix original sont libres. Mais à la grande époque des Bell Labs, ces considérations politiques étaient absentes. Kernighan n'en parle jamais et, au contraire, insiste sur le verrouillage de bien des innovations par des brevets. C'est en raison de la licence restrictive de l'Unix d'AT&T que des systèmes comme Linux ou FreeBSD n'ont plus une seule ligne du code original d'AT&T : il a fallu tout réécrire pour échapper aux avocats.

Kernighan ne fait pas que raconter des anecdotes édifiantes. Il corrige également quelques légendes. Par exemple, le fameux commentaire dans le code source d'Unix « You are not expected to understand this » ne veut pas du tout dire « lecteur, tu es stupide, laisse ce code aux pros » mais « il n'est pas nécessaire de comprendre ce bout de code pour comprendre le reste ».

Vous ne serez pas surpris d'apprendre que le livre a été composé sur Unix, avec groff et Ghostscript.

2020-01-12

Rapport de la députée Forteza sur les technologies quantiques

Le 9 janvier 2020, la députée Paula Forteza a rendu le rapport « Quantique : le virage technologique que la France ne ratera pas ». Quelques points sur ce rapport.

Le terme de « quantique » a un fort potentiel de hype pour les années à venir (surtout depuis l'annonce par Google de l'obtention de la suprématie quantique). Dans le contexte de la physique, il désigne quelque chose de clair (mais pas forcément de simple à comprendre !) Appliqué aux technologies, c'est plus compliqué. Et ce rapport couvre toutes les utilisations futures de la quantique, ce qui fait beaucoup. Globalement, le rapport est rigoureux sur la partie scientifique (il y a eu de bons conseillers, et ils ont été bien écoutés, donc des point délicats comme la différence entre qubits physiques et logiques, toujours oubliée par les marketeux, est bien décrite) mais plus contestable sur la partie politique. Je ne vais pas reprendre tous les points (lisez le rapport, vous ne vous ennuierez pas, et vous apprendrez des choses) mais seulement ceux qui me semblent particulièrement discutables.

Le point le plus curieux concerne la distribution quantique de clés (parfois appelée par abus de langage « cryptographique quantique »). La partie technique du rapport note à juste titre les nombreuses limitations (le rapport parle de « verrous ») de cette technique, que ses promoteurs présentent comme la solution magique à tous les problèmes de sécurité de l'Internet (ce qu'elle n'est pas). Mais la partie « propositions » du rapport oublie complètement ces limitations et assène qu'il faut mettre le paquet pour le développement de la QKD. On dirait vraiment que l'analyse de la technologie et les recommandations ont été écrites par des personnes différentes.

Le rapport est plus cohérent sur la question de la cryptographie post-quantique (cf. aussi mon exposé à pas Sage En Seine et le point de vue très différent de Renaud Lifchitz.) Encore que la partie résumée à l'attention des décideurs, comme souvent, présente le problème comme sans doute plus proche qu'il ne l'est (et propose de commencer à déployer les solutions en 2022 !) Le rapport semble pousser au déploiement immédiat d'algorithmes post-quantiques, alors qu'aucun n'est normalisé. (Et, puisqu'il s'agit d'un rapport officiel, on peut noter que le RGS, et notamment son annexe cryptographique, ne sont pas mentionnés.) Si vous voulez en savoir plus sur la cryptographie post-quantique, je vous recommande l'exposé de Magali Bardet lors de la JCSA de juillet 2019.

Ensuite, ce rapport reprend malheureusement le style de tant de rapports officiels précédents : pas d'autre proposition que de donner beaucoup d'argent à Atos ou Thales dans l'espoir que cela fera avancer les choses, meccano institutionnel (créer un comité machin), discours sur la grandeur de la France et sa maitrise de toutes les technologies et toutes les sciences, référence à la startup magique, croyance que la recherche fondamentale se pilote d'en haut (on annonce bien haut que la quantique est une priorité et paf, cela suffit à ce que les résultats arrivent), et surtout, aucune remise en cause des obstacles que rencontre actuellement la recherche. Par exemple, le rapport propose d'« encourager » (ça ne coûte rien…) les chercheurs à candidater à des programmes de financement européens mais sans se demander pourquoi il n'y a pas davantage de telles candidatures. (C'est en partie parce que les chercheurs passent déjà plus de temps dans la paperasserie et dans la chasse aux subventions que dans la recherche. Mais on ne pouvait pas attendre d'une députée du parti du gouvernement qu'elle critique l'organisation actuelle de la recherche.)

Le rapport propose de fournir un calculateur quantique accessible en ligne (pardon, le rapport dit « cloud », c'est plus poétique) pour faire du QCaaS (Quantum Computing as a Service). C'est déjà proposé par IBM et AliBaba. Cela ne veut pas dire qu'il soit inutile d'en créer d'autres, meilleurs et/ou différents mais cela ne montre pas une énorme ambition.

D'autre part, certaines propositions auraient mérité d'être développées, notamment sur les moyens à mettre en œuvre. Ainsi, la proposition de créer des enseignements d'algorithmique quantique dans vingt cycles d'enseignement supérieur est une très bonne idée mais pas un mot n'est dit sur le recrutement d'enseignants, alors que justement les compétences en ce domaine ne sont pas largement répandues.

Le rapport, je l'ai dit, est globalement rigoureux, mais dérape quand même parfois par exemple quand, à propos de programmation, il pointe l'importance de développer des langages de programmation adaptés, de haut niveau (ce qui est une très bonne idée) mais cite ensuite comme exemple Q#, qui est justement un langage de très bas niveau, où on manipule les portes logiques directement. Vous imaginez programmer un ordinateur classique ainsi ? Seule la syntaxe de Q# est « de haut niveau », les concepts manipulés ne le sont pas. Au passage, si vous êtes prorgrammeur ou programmeuse, le site de questions/réponses StackExchange a une déclinaison sur le calcul quantique.

Un point que j'ai apprécié, par contre, est l'insistance sur les « technologies habilitantes ». Il s'agit de toutes les techniques qui permettent de réaliser des dispositifs quantiques, notamment la cryogénie. C'est à juste titre que le rapport rappelle qu'un ordinateur quantique n'est pas seulement composé de qubits, c'est d'abord un gros réfrigérateur.

Sur la forme, je note l'abus de termes en anglais, qui n'aide pas à la compréhension.

Notez que l'IETF a un travail en cours sur la cryptographie post-quantique et un groupe de recherche sur les réseaux quantiques, qui a produit plusieurs documents intéressants (je vous recommande draft-irtf-qirg-principles, qui explique bien la quantique, avant d'expliquer ce que pourrait être un réseau quantique. Le RIPE-NCC a déjà organisé un hackathon sur ce sujet.)

2020-01-10

Un système anti-censure qui évolue en autonomie : Geneva

La lutte technique de la liberté d'expression contre la censure sur l'Internet n'est pas près de s'arrêter. Chaque fois que les censeurs conçoivent de nouvelles techniques, les défenseurs de la liberté mettent au point de meilleurs méthodes pour leur échapper, les censeurs améliorent alors leurs techniques, et ainsi de suite. La partie est donc difficile pour ceux et celles qui réalisent des dispositifs anti-censure, car il faut en permanence suivre et s'adapter. D'où l'idée d'un système qui évolue « tout seul ». Le génial Geneva utilise le concept des algorithmes génétiques, pour s'adapter à la censure et évoluer automatiquement en même temps qu'elle.

Geneva traite le cas des systèmes de censure Internet de type Homme du Côté. Dans ces systèmes (il en existe beaucoup d'autres ; les censeurs ont de l'imagination, et beaucoup plus d'argent et d'hommes que les défenseurs de la liberté), le censeur peut observer les paquets IP qui passent, et générer ses propres paquets, mais il ne peut pas modifier les paquets envoyés. (Dans les systèmes d'Homme du Milieu, par exemple le pare-feu d'une entreprise, l'attaquant peut modifier ou jeter les paquets, ces systèmes sont donc plus efficaces mais aussi plus coûteux, et parfois plus difficiles à intégrer dans l'infrastructure. Ils sont donc moins employés à l'échelle d'un pays, où le trafic est important. Mais rappelez-vous toujours que les censeurs utilisent plusieurs techniques, et souvent une combinaison de techniques, ajoutant par exemple les résolveurs DNS menteurs.) Un exemple d'attaque de l'Homme du Côté est un système qui observe le SNI dans les requêtes TLS (par exemple HTTPS) et, s'il voit un nom de domaine interdit (ou même simplement un mot censuré, par exemple Falun Gong en Chine), il génère un paquet TCP RST (ReSeT, RFC 793, section 3.1) vers l'émetteur ou le destinataire, coupant ainsi la connexion. TLS ne protège pas contre ces attaques, puisque, contrairement à QUIC, TLS ne chiffre pas la couche Transport. (Rappelez-vous également que l'Homme du Côté voit tous les paquets, il a donc la partie bien plus facile que l'attaquant aveugle des RFC 5927 ou RFC 5961.)

Contre de telles techniques de censure, la solution habituelle (et de nombreuses ont été développées) est de semer la confusion chez l'Homme du Côté, en envoyant des paquets qui seront interprétés différemment par le censeur et par le vrai destinataire. Par exemple, on envoie un paquet TCP RST avec un TTL qui lui permet d'atteindre la machine du censeur mais pas celle du destinataire. Le censeur croira alors que la connexion est finie, alors qu'en fait elle continuera. (Le censeur, dans le cas d'un État, a des moyens importants mais pas illimités. Il a donc intérêt à libérer de la mémoire en « oubliant » les connexions terminées, ce qui fait que le reste de la communication est ignoré.) L'inconvénient de ces stratégies est qu'il faut recommencer souvent, puisque les techniques de censure évoluent. Chaque fois que la censure se perfectionne, des contournements existants deviennent inefficaces et on est à nouveau censuré jusqu'au développement (lent et laborieux) d'un nouveau contournement. La lutte contre la censure est donc un combat éternel entre l'épée et la cuirasse.

Que peuvent apporter les algorithmes génétiques ici ? Un algorithme génétique est un algorithme qui reprend les grands concepts de la sélection naturelle. On choisit un ensemble de fonctions, on leur donne des règles de mutation, une fonction d'évaluation du résultat (qui joue le rôle de la survie du plus apte) et on laisse ensuite le système évoluer. On peut ainsi explorer un espace de solutions très large en bien moins de temps.

Portrait de Charles Darwin par George Richmond. ( Source: Wikimedia Commons.)

Tout l'art du concepteur d'algorithmes génétiques est dans la liberté plus ou moins grande qu'il ou elle laisse aux mutations. Si on laisse les mutations se faire au hasard, l'écrasante majorité des stratégies produites seront non viables, et l'exploration de l'espace des solutions prendra des siècles. Mais si on contraint fortement les mutations possibles, l'algorithme n'ira jamais bien loin, il restera sur les sentiers battus et ne fera pas de découverte disruptive.

Geneva tourne sur la machine du client, celui ou celle qui veut accéder à des contenus censurés. Geneva définit les solutions contre les attaques de l'Homme du Côté en trois parties : un déclencheur (trigger) qui dit quand lancer la solution, des actions qui disent ce qu'on va faire (par exemple créer un nouveau paquet) et des arbres (action trees) qui coordonnent la succession des actions. Par exemple, la stratégie mentionnée plus haut (un paquet TCP RST avec un TTL conçu pour atteindre le censeur mais pas le destinataire) s'exprimerait, dans le DSL de Geneva :

[TCP:flags:A]-

duplicate(send,
          tamper(TCP:flags:R)(
              tamper(IP:TTL:replace:10)
                  (send)))

-| \/
  
Le terme [TCP:flags:A] est le déclencheur : quand on envoie le TCP ACK (accusé de réception), on duplique ce paquet et on envoie à la fois le vrai et une copie ayant le bit R (RST) et un TTL diminué, pour n'atteindre que le censeur et lui faire croire que la connexion est finie. Un autre exemple corrompt délibérément la somme de contrôle TCP : certains censeurs ignorent cette somme de contrôle, ce qui permet d'envoyer un paquet (par exemple RST) qui ne sera lu que par l'Homme du Côté.

Geneva commence avec un ensemble de solutions faites à la main, les individus sur lesquels va s'exercer l'évolution. Ensuite, les mutations se produisent, portant sur les déclencheurs, sur les actions, et sur les arbres (la succession des actions). Geneva teste ensuite les résultats des mutations en cherchant à se connecter à un site Web censuré. Le critère de sélection est donc la réussite dans le contournement de la censure. (Les règles exactes sont plus complexes, car il faut éviter de se laisser pièger dans des minima locaux ; ce n'est pas parce qu'une solution marche qu'elle est la meilleure. Et puis certains systèmes de censure ne sont pas déterministes ; soit suite à une bogue, soit délibérement pour compliquer l'analyse, ils ne bloquent pas toujours.)

Geneva a été mis en œuvre en Python, utilisant évidemment Scapy, et le NFqueue de Netfilter sur Linux pour accéder au réseau. Notons que certaines opérations nécessitent d'être root (modifier les en-têtes IP) mais pas toutes (changer le découpage des données en segments TCP), ce qui permet dans certains cas de faire tourner Geneva, ou du moins le script (la stratégie) sélectionné, sans être root. Le code pour exécuter les scripts (mais pas encore celui avec l'algorithme génétique) est disponible en ligne.

Quels sont les résultats ? Eh bien, Geneva fonctionne, et même très bien d'après ses auteurs. En seulement quelques heures, il trouve une stratégie de contournement de la censure. Geneva a été testé dans le laboratoire, face à des solutions de censure connues, mais aussi en vrai sur le terrain, en Chine face au GFW, en Inde et au Kazakhstan. Disons-le tout de suite, en matière de censure, le GFW est le seul système intéressant, les autres sont vraiment primitifs. Geneva n'a eu aucun problème à trouver une stratégie pour échapper aux censures indienne et kazakhstanaise (simplement mettre le SNI dans deux segments TCP différents suffit, au Kazakhstan) mais le GFW lui a donné plus de fil à retordre. Le script :

[TCP:flags:PA]-fragment{tcp:8:True}(send,send)-|
[TCP:flags:A]-tamper{TCP:seq:corrupt}(send)-| \/
  
a réussi à passer. J'ai également bien aimé la stratégie FRAPUN (ainsi nommée en raison des bits de l'en-tête TCP qu'elle met à 1.)

Un des avantages des algorithmes génétiques est qu'ils peuvent trouver des solutions auxquelles leurs auteurs n'ont pas pensé (mais qu'ils peuvent expliquer a posteriori). Plus drôle, Geneva a aussi trouvé une solution que les auteurs du programme n'ont pas pu expliquer, mais qui marche face au GFW :

[TCP:flags:PA]-
fragment{tcp:8:True}(send,
fragment{tcp:4:True}(send, send))-| \/

Ce très bon article se termine par une discussion sur l'avenir de la lutte anti-censure. Geneva ne va évidemment pas mettre un point final à la question, il est certain que les censeurs s'y adapteront (c'est un problème classique en sécurité informatique : les logiciels distribués publiquement peuvent être utilisés par les bons comme par les méchants.)

J'ai aussi apprécié que l'article n'utilise pas de buzzwords comme IA ou machine learning. Aujourd'hui, où les chercheurs doivent passer davantage de temps à chercher des subventions et de l'impact médiatique (l'un n'allant pas sans l'autre) plutôt qu'à chercher, c'est appréciable. Mais, hélas, le dépôt git du projet, lui, le fait.

Notez que l'article mentionne des considérations éthiques. Lancer Geneva sur une machine en Chine peut vous attirer des ennuis. (L'Inde est moins dangereuse, de ce point de vue.) Certes, Geneva n'est pas trop bavard en octets mais son comportement si particulier pourrait être remarqué par les systèmes de surveillance que déploient la plupart des pays. C'est un problème fréquent quand on étudie la censure. Il faut donc bien prévenir les utilisateurs (ce que rappelle bien la section Disclaimer dans la documentation d'installation du logiciel.)

2020-01-09

Historique dans RDAP

Le protocole RDAP permet d'obtenir des informations sur une ressource enregistrée dans un registre, par exemple un RIR. Une extension permet d'avoir accès à l'histoire d'une ressource.

RDAP est normalisé dans les RFC 7480, RFC 7481 et RFC 7482. L'extension n'a jamais été normalisée, mais elle est déployée à l'APNIC. Voici un exemple d'utilisation, pour avoir l'histoire de l'adresse IP 2001:dc0:2001:11::194 :

% curl -s http://rdap.apnic.net/history/ip/2001:dc0:2001:11::194
...
  
Bon, d'accord, le résultat est confus. C'est du JSON donc on utilise jq pour le formatter plus joliment :
% curl -s http://rdap.apnic.net/history/ip/2001:dc0:2001:11::194 | jq .
...
      "applicableFrom": "2019-02-14T05:37:22Z",
      "applicableUntil": "2019-07-29T03:31:05Z",
      "content": {
        "country": "AU",
        "name": "APNIC-AP-V6-BNE",
        "type": "ASSIGNED PORTABLE",
        "startAddress": "2001:dc0:2000::",
        "ipVersion": "v6",
        "endAddress": "2001:dc0:3fff:ffff:ffff:ffff:ffff:ffff",
        "objectClassName": "ip network",
        "handle": "2001:0DC0:2000::/35",
...
  
On récupère un tableau d'enregistrements, chaque enregistrement étant valable de applicableFrom à applicableUntil. Pour voir combien de changements a vu ce préfixe IP, on va utiliser les fonctions de sélection de jq :
% curl -s http://rdap.apnic.net/history/ip/2001:dc0:2001:11::194 | \
    jq ".records|.[].applicableFrom"
...
  
Ça fait 48 changements, comme on pourrait le compter avec jq :
% curl -s http://rdap.apnic.net/history/ip/2001:dc0:2001:11::194 | \
    jq "[ .records|.[].applicableFrom ] | length"
49
  

Il avait été prévu à un moment de normaliser cette extension RDAP à l'IETF (Internet-Draft draft-ellacott-historical-rdap). Mais ça n'a pas suscité suffisamment d'intérêt. D'ailleurs, l'extension n'est même pas dans le registre des extensions RDAP. Une telle extension serait pratique pour l'investigation, mais pose aussi des problèmes de vie privée (plus de droit à l'oubli).

2020-01-06

Analyse technique du résolveur DNS public chinois 114dns

Aujourd'hui, nous allons regarder de près un résolveur DNS public, le 114.114.114.114, qui présente la particularité d'être géré en Chine. Il y a de nombreuses choses étranges sur ce service, qui distrairont les techniciens Internet.

Des résolveurs DNS publics, il y en a plein : Google Public DNS, Quad9, et plusieurs autres. Je ne discuterai pas ici des inconvénients qu'ils présentent, je veux juste faire quelques expériences avec un de ces résolveurs, et montrer par la même occasion quelques outils utiles pour explorer les entrailles de l'infrastructure de l'Internet.

Donc, depuis pas mal d'années, il existe un résolveur public chinois. Il a l'adresse IPv4 114.114.114.114 et il a un site Web (uniquement en chinois, il semble). Je l'ai dit, il n'est pas nouveau, mais il a fait l'objet d'un renouveau d'intérêt fin 2019 car il serait le résolveur DNS par défaut dans certains objets connectés fabriqués en Chine. Testons d'abord s'il existe et répond. Nous allons utiliser divers outils en ligne de commande qu'on trouve sur Unix. Commençons par le client DNS dig :

     
% dig +dnssec @114.114.114.114 cyberstructure.fr AAAA

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @114.114.114.114 cyberstructure.fr AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33037
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cyberstructure.fr.	IN AAAA

;; ANSWER SECTION:
cyberstructure.fr.	86399 IN AAAA 2001:4b98:dc0:41:216:3eff:fe27:3d3f

;; Query time: 3113 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Sun Dec 29 16:31:54 CET 2019
;; MSG SIZE  rcvd: 63

   
On note d'abord qu'il est lent (depuis la France) et qu'on a souvent des délais de garde dépassés. Mais il marche. Notez que l'utilisation de ping montre que c'est bien le résolveur qui est lent, pas le réseau : les paquets envoyés par ping ont une réponse bien plus rapide :
% ping -c 10 114.114.114.114
...
10 packets transmitted, 10 received, 0% packet loss, time 24ms
rtt min/avg/max/mdev = 95.508/96.107/98.871/1.031 ms
   
Le RTT est bien inférieur à ce qu'on obtient quand on va en Chine, indiquant que ce résolveur a des instances en d'autres endroits, probablemement grâce à l'anycast. C'est confirmé par un ping depuis une machine aux États-Unis, qui montre des RTT qui sont encore moins compatibles avec la durée d'un aller-retour en Chine :
% ping -c 10 114.114.114.114
...
--- 114.114.114.114 ping statistics ---
10 packets transmitted, 10 received, +1 duplicates, 0% packet loss, time 20ms
rtt min/avg/max/mdev = 19.926/20.054/20.594/0.226 ms
   

Qui gère ce résolveur ? whois nous dit que c'est bien en Chine :

% whois 114.114.114.114
% [whois.apnic.net]
...
inetnum:        114.114.0.0 - 114.114.255.255
netname:        XFInfo
descr:          NanJing XinFeng Information Technologies, Inc.
descr:          Room 207, Building 53, XiongMao Group, No.168 LongPanZhong Road
descr:          Xuanwu District, Nanjing, Jiangsu, China
country:        CN
...
source:         APNIC
   

Ce service n'est apparemment pas un résolveur menteur. Les noms censurés en Chine, comme facebook.com fonctionnent. Si on le souhaite, la documentation semble indiquer (je n'ai pas testé) que d'autres adresses abritent des résolveurs menteurs, par exemple 114.114.114.119 filtre le logiciel malveillant et 114.114.114.110 filtre le porno.

Quelles sont les caractéristiques techniques du service ? D'abord, notons qu'il ne valide pas avec DNSSEC, ce qui est dommage. On le voit car il n'y a pas le flag AD (Authentic Data) dans la réponse au dig plus haut (alors que le domaine visé est signé avec DNSSEC). Une autre façon de voir qu'il n'a pas DNSSEC est de demander des noms délibérement invalides comme servfail.nl. 114.114.114.114 donne une réponse alors qu'il ne devrait pas.

Pendant qu'on est sur DNSSEC, notons une bizarrerie du résolveur : il renvoie parfois une section EDNS (RFC 6891) et parfois pas. Dans l'exemple dig ci-dessus, il n'y en avait pas, mais parfois si :

     
% dig +dnssec @114.114.114.114 afnic.fr

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> +dnssec @114.114.114.114 afnic.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59581
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: c46f830f4a12bfab (echoed)
;; QUESTION SECTION:
;afnic.fr.		IN A

;; ANSWER SECTION:
afnic.fr.		579 IN A 192.134.5.25

;; Query time: 20 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Sun Dec 29 17:00:19 CET 2019
;; MSG SIZE  rcvd: 65

   
Ce comportement est tout à fait anormal, et il se peut qu'il y ait plusieurs machines derrière un répartiteur de charge, avec des configurations différentes.

Autre chose qui manque : il n'a pas de NSID (Name Server IDentifier, RFC 5001), cette indication du nom du serveur, très pratique lorsqu'on analyse un service anycasté, c'est-à-dire composé de plusieurs instances. (NSID peut également indiquer si une machine qui répond est la vraie, au cas, fréquent, où un détourneur n'ait pas eu l'idée de faire un faux NSID.)


% dig +dnssec +nsid @114.114.114.114 framagit.org

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> +dnssec +nsid @114.114.114.114 framagit.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 745
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; NSID
; COOKIE: 7f99ae3cb5e63ad1 (echoed)
;; QUESTION SECTION:
;framagit.org.		IN A

;; ANSWER SECTION:
framagit.org.		10779 IN A 144.76.206.42

;; Query time: 20 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Sun Dec 29 17:05:40 CET 2019
;; MSG SIZE  rcvd: 73

   
Le NSID est vide, ce qui est bizarre. Normalement, quand un serveur DNS ne veut pas répondre à la question NSID, il ne renvoie pas l'option EDNS dans la OPT pseudo-section. Ici, ce zèbre étrange renvoie l'option, mais vide.

Le service n'a apparemment pas d'adresse IPv6, ce qui est étonnant en 2019. En tout cas, il n'y a pas d'enregistrement de type AAAA pour le nom :


% dig +dnssec public1.114dns.com. AAAA

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> public1.114dns.com. AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4421
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 0d4b4b8dd9fc8613c831aa085e08cf5e9b2e8073e1d6741d (good)
;; QUESTION SECTION:
;public1.114dns.com.	IN AAAA

;; AUTHORITY SECTION:
114dns.com.		600 IN SOA ns1000.114dns.com. dnsadmin.114dns.com. (
				20120510   ; serial
				3600       ; refresh (1 hour)
				300        ; retry (5 minutes)
				604800     ; expire (1 week)
				300        ; minimum (5 minutes)
				)

;; Query time: 114 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 29 17:07:58 CET 2019
;; MSG SIZE  rcvd: 127

   
(Au fait, j'ai trouvé ce nom public1.114dns.com en faisant une résolution « inverse », avec dig -x 114.114.114.114.)

Enfin, ce résolveur n'a que le DNS traditionnel, sur UDP. Pas de TCP, pourtant normalisé dès les débuts du DNS, au même titre que UDP, et surtout pas de chiffrement pour sécuriser la communication, ce résolveur n'a pas DoT (DNS sur TLS, RFC 7858) ou DoH (DNS sur HTTPS, RFC 8484). On peut tester ces deux protocoles avec Homer :

% homer https://114.114.114.114/ cyberstructure.fr
...
pycurl.error: (7, 'Failed to connect to 114.114.114.114 port 443: Connection timed out')

% homer --dot 114.114.114.114 cyberstructure.fr
timeout
   

Tester depuis un seul point de mesure, ou même deux, est évidemment insuffisant pour un résolveur anycasté, donc nous allons utiliser les sondes RIPE Atlas via l'outil Blaeu. Ici, on demande à mille sondes RIPE Atlas, réparties sur toute la planète, d'interroger le résolveur public :

   
% blaeu-resolve -r 1000 --nameserver 114.114.114.114  --displayrtt --dnssec --nsid --displayvalidation write.as
Nameserver 114.114.114.114
[2001:4800:7812:514:500b:b07c:ff05:694d NSID: b''] : 909 occurrences Average RTT 129 ms
[2001:4800:7812:514:500b:b07c:ff05:694d] : 31 occurrences Average RTT 430 ms
[TIMEOUT] : 42 occurrences Average RTT 0 ms
Test #23727649 done at 2019-12-29T15:54:15Z
On voit le nombre relativement élevé de timeout (comme je l'ai noté plus haut, ce service est lent), et le fait que parfois, on n'a pas de réponse EDNS (et donc pas de NSID, même vide). Plus drôle, en répétant le test, les sondes Atlas trouvent plusieurs détournements de ce résolveur public. Une des grosses faiblesses d'un résolveur public sans authentification (ce qui est le cas de tous ceux qui n'offrent ni DoT, ni DoH) est qu'on ne peut pas les authentifier. Il est donc trivial de faire un faux serveur, en jouant avec le routage, comme le font souvent les censeurs. J'ai ainsi vu une sonde Atlas détecter un NSID « CleanBrowsing v1.6a - dns-edge-usa-east-dc-c », manifestement un outil de filtrage qui se faisait passer pour 114.114.114.114 et qui l'assumait, en affichant un NSID à lui.

Puisqu'on a parlé de routage, c'est l'occasion de tester traceroute. Un traceroute ordinaire ne donne rien, ses paquets étant manifestement jetés dans le réseau du résolveur. On va donc utiliser traceroute avec TCP vers le port 53, celui du DNS, depuis la machine états-unienne de tout à l'heure :


% tcptraceroute 114.114.114.114 53 
traceroute to 114.114.114.114 (114.114.114.114), 30 hops max, 60 byte packets
 1  88.214.240.4 (88.214.240.4)  2.518 ms  2.613 ms  2.699 ms
 2  be5893.rcr51.ewr04.atlas.cogentco.com (38.122.116.9)  0.485 ms  1.009 ms  1.014 ms
 3  be3657.rcr21.ewr03.atlas.cogentco.com (154.24.33.169)  1.021 ms  0.986 ms  1.091 ms
 4  be2495.rcr24.jfk01.atlas.cogentco.com (154.54.80.193)  1.350 ms be2390.rcr23.jfk01.atlas.cogentco.com (154.54.80.189)  2.468 ms  1.268 ms
 5  be2897.ccr42.jfk02.atlas.cogentco.com (154.54.84.213)  1.631 ms  1.669 ms be2896.ccr41.jfk02.atlas.cogentco.com (154.54.84.201)  1.749 ms
 6  be2890.ccr22.cle04.atlas.cogentco.com (154.54.82.245)  13.427 ms  13.581 ms be2889.ccr21.cle04.atlas.cogentco.com (154.54.47.49)  13.587 ms
 7  be2718.ccr42.ord01.atlas.cogentco.com (154.54.7.129)  20.108 ms  21.048 ms  20.062 ms
 8  be3802.rcr21.ord07.atlas.cogentco.com (154.54.47.38)  20.992 ms 154.54.89.2 (154.54.89.2)  20.794 ms be3802.rcr21.ord07.atlas.cogentco.com (154.54.47.38)  20.925 ms
 9  * * *
10  23.237.126.230 (23.237.126.230)  22.188 ms  22.502 ms  22.331 ms
11  23.237.136.242 (23.237.136.242)  24.471 ms  23.732 ms  24.089 ms
12  * * *
13  public1.114dns.com (114.114.114.114) <syn,ack>  19.963 ms  20.631 ms  20.658 ms

 
On y voit que la machine répond bien en TCP (bien qu'elle refuse d'assurer un service DNS en TCP, encore une bizarrerie). On note aussi que le RTT confirme celui de ping. (Ce qui ne va pas de soi : le réseau peut traiter différemment différents protocoles.)

Il y a une dernière chose très étrange avec ce service. Son adresse fait partie d'un préfixe IP annoncé en BGP, 114.114.112.0/21. Vous pouvez le trouver auprès d'un service comme RIPE Stat, ou bien en utilisant curl pour interroger une API publique :

%  curl https://bgp.bortzmeyer.org/114.114.114.114
114.114.112.0/21 174
Après le préfixe (114.114.112.0/21), on voit le numéro d'AS, 174. Or, cet AS est l'opérateur étatsunien Cogent :
% whois AS174
...
# Copyright 1997-2019, American Registry for Internet Numbers, Ltd.

ASNumber:       174
ASName:         COGENT-174
ASHandle:       AS174
Ref:            https://rdap.arin.net/registry/autnum/174

OrgName:        Cogent Communications
OrgId:          COGC
Address:        2450 N Street NW
City:           Washington
StateProv:      DC
PostalCode:     20037
Country:        US
Ref:            https://rdap.arin.net/registry/entity/COGC
A priori, pourquoi pas, une organisation chinoise a bien le droit de faire appel à un opérateur étatsunien pour annoncer son préfixe. Mais il y a des choses étranges. D'abord, la route enregistrée dans l'IRR d'APNIC ne mentionne pas Cogent, mais l'AS 4837, China Unicom :
%  whois 114.114.114.114 
...
route:          114.114.112.0/21
descr:          China Unicom Shandong Province network
descr:          Addresses from CNNIC
country:        CN
origin:         AS4837
mnt-by:         MAINT-CNCGROUP-RR
last-modified:  2011-04-12T07:52:02Z
source:         APNIC
   
Il n'y a pas de ROA (Route Origin Authorizations, RFC 6482) pour ce préfixe :
% whois -h whois.bgpmon.net 114.114.114.114 
% This is the BGPmon.net whois Service
...
RPKI status:         No ROA found
...
   
(On pourrait avoir le même résultat en consultant RIPE stat.) La seule information quant à la validité de l'annonce BGP est donc l'objet route, qui exclut Cogent. Notez qu'en fouillant un peu plus, on trouve des annonces du préfixe 114.114.112.0/21 par d'autres AS, 4837 (ce qui est conforme à l'objet route ci-dessous), et 4134 (ChinaNet). Mais la plupart des routeurs BGP de la planète ne voient que l'annonce de Cogent.

Que faut-il déduire de ce dernier cafouillage ? La situation est certes anormale (l'IRR n'annonce qu'un seul AS d'origine possible, mais c'est un autre qu'on voit presque partout), mais est-ce le résultat d'une attaque délibérée, comme les détournements BGP dont on parle souvent (RFC 7464), en général en les attribuant aux… Chinois ? Probablement pas : la situation générale de la sécurité du routage est médiocre, les IRR ne sont pas maintenus à jour, l'opérateur Cogent n'est pas connu pour sa rigueur (il ne devrait pas annoncer des préfixes sans qu'ils soient marqués comme tel dans un IRR) et il s'agit sans doute plus de négligence que de malveillance.

Et pour finir la partie sur le routage, une copie d'écran de RIPE stat montrant l'incohérence des annonces :

Revenons un peu à ping. Manuel Ponce a fort justement observé qu'il y avait un problème intéressant dans les réponses à ping :

% ping -c 10 114.114.114.114

PING 114.114.114.114 (114.114.114.114) 56(84) bytes of data.
64 bytes from 114.114.114.114: icmp_seq=1 ttl=63 time=94.0 ms
64 bytes from 114.114.114.114: icmp_seq=2 ttl=56 time=93.8 ms
64 bytes from 114.114.114.114: icmp_seq=3 ttl=81 time=93.9 ms
64 bytes from 114.114.114.114: icmp_seq=4 ttl=84 time=94.1 ms
64 bytes from 114.114.114.114: icmp_seq=5 ttl=62 time=94.2 ms
64 bytes from 114.114.114.114: icmp_seq=6 ttl=66 time=94.0 ms
64 bytes from 114.114.114.114: icmp_seq=7 ttl=80 time=93.9 ms
64 bytes from 114.114.114.114: icmp_seq=8 ttl=69 time=93.9 ms
64 bytes from 114.114.114.114: icmp_seq=9 ttl=72 time=94.2 ms
64 bytes from 114.114.114.114: icmp_seq=10 ttl=59 time=94.1 ms

--- 114.114.114.114 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 93.801/94.045/94.285/0.342 ms
   
Prenez cinq minutes pour regarder et voyez si vous trouvez le problème…

C'est bon, vous avez trouvé ? Moi, je n'avais pas vu : le TTL change à chaque paquet. Normalement, il devrait être à peu près constant, sauf si le routage se modifie subitement pendant le test (ce qui est rare). Ici, c'est un mystère de plus de ce curieux service. Personne n'a trouvé d'explication certaine de ce phénomène mais Baptiste Jonglez suggère cette commande Netfilter si vous voulez faire pareil sur vos serveurs (Non testé ! Ne l'essayez pas en production comme ça !) :

for ttl in {0..31}
    do
      iptables -t mangle -A OUTPUT -p icmp --icmp-type echo-reply -m statistic --mode nth --every 32 --packet $ttl -j TTL --ttl-set $((ttl+72))
    done
   
Cela donne des TTL dans l'ordre. Pour les avoir aléatoires, Paul Rolland suggère de remplacer --mode nth --every 32 --packet $ttl par --mode random --probability 0.03125.

2020-01-01

50 ans

Non, ce n'est pas mon âge. Mais, aujourd'hui, l'« epoch » d'Unix et de l'Internet a cinquante ans.

J'ai toujours été fasciné par les calendriers. C'est un intérêt courant chez les informaticiens, d'autant plus que la quasi-totalité des logiciels qui manipulent des dates sont bogués, en partie en raison de la complexité du problème.

Tous les calendriers commencent par une date spéciale. Cela peut-être la naissance d'un prophète, le début de sa prédication, une insurrection, une proclamation, un serment, une grande bataille, ou un autre événement important, réel ou imaginé. Il y a avant et puis après. Ainsi, le calendrier légal en France, comme dans la plupart des pays du monde, est fondé sur la date de naissance (supposée…) de Jésus-Christ. Pour le laïciser un peu, on parle désormais d'« ère commune » et nous sommes donc le 1 janvier 2020 de l'ère commune (en anglais, CE, pour « common era ».)

Cette date spéciale se nomme en anglais « epoch » et nous allons parler ici d'une « epoch » intéressante, le premier janvier 1970.

Car le choix de la date spéciale est crucial. Elle sépare l'histoire en deux, avant, âge de ténèbres, d'ignorance et d'oppression, et après, âge du bonheur et de la lumière. D'où le choix d'événements grandioses pour distinguer l'avant et l'après.

Mais les ordinateurs ne sont pas romantiques. Ils se moquent des grands sentiments et des passions humaines, ils sont gérés par la pure rationalité. Quand on a besoin de définir une « epoch », pour les ordinateurs, il n'est pas nécessaire d'utiliser une date émouvante. Et, comme on a rarement besoin, sauf si l'ordinateur est utilisé par un historien, de manipuler dans un programme informatique des dates très anciennes, autant prendre une « epoch » récente. Le premier janvier 1970, certains lecteurs et lectrices de ce texte étaient déjà nés, ainsi que l'auteur de ces lignes (mais je n'avais pas encore mon bac).

C'est ainsi que le système d'exploitation (logiciel de base de la machine) le plus utilisé dans le monde, Unix, utilise comme « epoch », comme date spéciale, le 1 janvier 1970, il y a juste cinquante ans. Cette date a été choisie simplement parce qu'elle était, au moment du choix, située dans un passé récent et qu'elle était facile à mémoriser.

Unix compte tous les temps en secondes écoulées depuis le 1 janvier 1970 à 0h0mn, temps universel. Évidemment, ce n'est que la représentation interne, dans la mémoire du système. Les applications destinées aux utilisateurs affichent la date d'une manière plus habituelle. La très forte prévalence d'Unix dans l'Internet (la quasi-totalité des serveurs, et la grande majorité des clients) fait que cette epoch est également, de facto, celle de l'Internet, qui a commencé à peu près au même moment. (Jérôme Mainaud, merci à lui, me fait remarquer que le protocole de synchronisation d'horloges NTP, très répandu sur l'Internet, a une autre epoch, le 1 janvier 1900.)

Si vous êtes en ce moment sur une machine Unix dotée d'un « shell », d'un interpréteur de commandes, et que vous avez le programme « GNU date » (sur des systèmes comme Ubuntu ou Mint, c'est le programme date par défaut), vous pouvez afficher le nombre de secondes écoulées depuis l'« epoch » en tapant :

date +%s
Le premier janvier 2020, à 0h0mn en temps universel, il affiche 1 577 836 800.

Une lecture recommandée : « Calendrical calculations », d'Edward Reingold et Nachum Dershowitz (Cambridge University Press).

Merci à Hervé Le Crosnier (C&F Éditions) pour l'inspiration pour cet article.

2019-12-29

Migration de tous mes dépôts de développement vers un Gitlab

Je viens de terminer la migration de tous mes dépôts de développement logiciel actifs (et quelques inactifs) vers un GitLab, suite au rachat de GitHub par Microsoft, en 2018.

Quand j'avais commencé à mettre des dépôts sur une forge publique, c'était sur SourceForge, en 2000. Après que SourceForge ait sombré, techniquement et politiquement, je suis passé à GitHub, à l'époque une petite entreprise sympa et techniquement pointue. Puis GitHub a grandi, devenant le « Facebook des geeks ». Et, en juin 2018, Microsoft annonce le rachat de GitHub, le sort fréquent des petites entreprises cools. Il n'était évidemment pas question pour moi de rester chez Microsoft, l'entreprise symbole du logiciel privateur. Même si de nombreux Microsoft fanboys s'étaient à l'époque succédé sur les réseaux sociaux pour répéter les éléments de langage « Microsoft a changé », « Maintenant, c'est une entreprise sympa », « Il y a eu quelques erreurs mais maintenant, Microsoft ne traite plus le logiciel libre de cancer communiste », je n'ai jamais avalé ces arguments. D'ailleurs, Microsoft lui-même ne s'est jamais réclamé du logiciel libre, juste d'un vague « open source », qui veut tout et rien dire, et qu'on utilise quand le mot « liberté » fait peur.

Bon, c'est bien joli, cela, mais cela fait bien plus d'un an que le rachat a eu lieu, c'était pas rapide comme fuite hors de l'étreinte de Microsoft ? C'est vrai, il m'a fallu du temps, la paresse a longtemps été la plus forte, mais j'ai fini par le faire.

Et la destination ? La solution techniquement la plus proche de GitHub est un GitLab. Attention, beaucoup de gens confondent un GitLab (une instance spécifique d'un service utilisant le logiciel) et le GitLab.com géré par la société du même nom. Migrer vers GitLab.com n'aurait qu'un intérêt limité : ce serait abandonner une entreprise pour une autre, qui connaitra peut-être le même sort si elle a du succès. Au contraire, le logiciel GitLab est libre et peut donc être installé par de nombreux acteurs. Je ne sais pas s'il existe quelque part une liste d'instances GitLab ouvertes, mais je connais Framasoft et j'ai donc choisi la leur, FramaGit. Je sais que Framasoft est lancé dans une entreprise de « déframasofisation » et qu'il faudra peut-être une autre migration dans un an ou deux mais le sort de FramaGit ne semble pas clairement fixé. Si vous connnaissez un GitLab (ou équivalent) chez un CHATON sympa…

Passons maintenant à la pratique. Il faut récupérer les données. L'utilisation d'un VCS décentralisé comme git résout automatiquement une grande partie du problème. Chaque copie locale contient non seulement tout le code mais également tout l'historique. Il ne reste plus qu'à récupérer les tickets et les pull requests. Personne ne migrerait depuis GitHub si cela signifiait de perdre ces importantes informations. Pour tout récupérer, GitLab a fait une excellente documentation. J'en résume les principaux points :

  • La mise en correspondance des auteurs des commits entre GitHub et la nouvelle forge se fait sur la base d'une connexion utilisant GitHub ou bien sur celle de l'adresse de courrier. Sans correspondance, commits et tickets seront attribués à la personne faisant l'importation.
  • L'administrateur de la forge GitLab utilisée doit avoir activé l'intégration GitHub. (C'est le cas de FramaGit.)
  • Ensuite, il n'y a plus qu'à faire (vous noterez que la traduction en français de GitLab est incomplète) Nouveau projet → Import project → [depuis] Github → [Accepter l'autorisation OAuth] Authenticate with GitHub → [Sélectionner le projet à importer]. Le plus long est évidemment de tout vérifier, mettre à jour ses dépôts locaux, documenter sur l'ancien dépôt (je n'ai pas détruit les anciens dépôts, juste mis à jour la documentation) et sur le nouveau.

Comme mon adresse de courrier n'était pas la même sur GitHub et sur FramaGit, je ne pouvais pas compter sur une bonne correspondance. Je me suis donc une fois connecté à FramaGit en utilisant mon compte GitHub, créant ainsi un compte « fantôme » qui allait recevoir les anciens commits. (J'aurais pu m'en passer, ce qui aurait réaffecté ces commits au compte FramaGit habituel.) Ensuite, tout s'est bien passé, commits, pull requests et tickets sont bien importés. (Attention à ne pas trop en mettre, FramaGit semble avoir une limite à 50 projets.)

Notez que, politiquement, c'est évidemment une excellente idée que de migrer depuis un service centralisé comme GitHub vers plein de petits GitLab partout. Mais, techniquement, cela peut rendre la coopération difficile, puisqu'il faut un compte sur chaque instance pour participer. C'est d'autant plus absurde que git est lui-même décentralisé (et a des mécanismes pour contribuer sans compte.) Il faudrait donc qu'on puisse avoir un dépôt complètement décentralisé, par exemple en mettant les tickets dans git lui-même. (On me dit que ce serait possible avec le logiciel SourceHut, qui a déjà un service d'hébergement, mais je n'ai pas testé. Ou bien avec Fossil ou encore git-bug. Et il y a une liste de projets similaires.) Une autre approche (qui ne me convainc pas, mais qui peut être utile pour certains services) serait de fédérer les GitLab, par exemple avec ActivityPub. Voir par exemple le ticket #4013 de GitLab.

2019-12-24

RFC 8700: Fifty Years of RFCs

Ce nouveau RFC marque le cinquantième anniversaire des RFC. Le RFC 1 avait en effet été publié le 7 avril 1969. Ce RFC 8700, publié avec un certain retard, revient sur l'histoire de cette exceptionnelle série de documents.

Il y avait déjà eu des RFC faisant le bilan de la série, à l'occasion d'anniversaires, comme le RFC 2555 pour le trentième RFC, et le RFC 5540 pour le quarantième. La série a évidemment commencé avec le RFC 1, cinquante ans auparavant, et donc dans un monde très différent. À l'époque, les RFC méritaient leur nom, ils étaient été en effet des « appels à commentaires », prévus non pas comme des références stables, mais comme des étapes dans la discussion. En cinquante ans, les choses ont évidemment bien changé, et les RFC sont devenus des documents stables, intangibles, et archivés soigneusement. Logiquement, le processus de création des RFC a également évolué, notamment vers un plus grand formalisme (on peut même dire « bureaucratie »).

Plus de 8 500 RFC ont été publiés (il existe quelques trous dans la numérotation ; ainsi, le RFC 26 n'a jamais existé…) Les plus connus sont les normes techniques de l'Internet. La description précise de HTTP, BGP ou IP est dans un RFC. Mais d'autres RFC ne normalisent rien (c'est le cas du RFC 8700, sujet de cet article), ils documentent, expliquent, suggèrent… Tous les RFC ont en commun d'être publiés puis soigneusement gardés par le RFC Editor, une fonction assurée par plusieurs personnes, et aujourd'hui animée par Heather Flanagan, auteure de ce RFC 8700, mais qui a annoncé son départ.

Cette fonction a elle aussi une histoire : le premier RFC Editor était Jon Postel. À l'époque c'était une fonction informelle, tellement informelle que plus personne ne sait à partir de quand on a commencé à parler du (ou de la) RFC Editor (mais la première mention explicite est dans le RFC 902). Postel assurait cette fonction en plus de ses nombreuses autres tâches, sans que cela n'apparaisse sur aucune fiche de poste. Petit à petit, cette fonction s'est formalisée.

Les changements ont affecté bien des aspects de la série des RFC, pendant ces cinquante ans. Les premiers RFC étaient distribués par la poste ! Au fur et à mesure que le réseau (qui ne s'appelait pas encore Internet) se développait, ce mécanisme de distribution a été remplacé par le courrier électronique et le FTP anonyme. Autre changement, les instructions aux auteurs, données de manière purement orales, ont fini par être rédigées. Et l'équipe s'est étoffée : d'une personne au début, Postel seul, le RFC Editor a fini par être une tâche assurée par cinq à sept personnes. Autrefois, la fonction de RFC Editor était liée à celle de registre des noms et numéros, puis elle a été séparée (le registre étant désormais PTI). Puis la fonction de RFC Editor a été structurée, dans le RFC 4844, puis RFC 5620, enfin dans le RFC 6635. Et l'évolution continue, par exemple en ce moment avec le changement vers le nouveau format des documents (voir RFC 7990). Dans le futur, il y aura certainement d'autres changements, mais le RFC Editor affirme son engagement à toujours prioriser la stabilité de la formidable archive que représentent les RFC, et sa disponibilité sur le long terme (RFC 8153).

La section 2 du RFC rappelle les grands moments de l'histoire des RFC (je n'ai pas conservé toutes ces étapes dans la liste) :

  • Avril 1969, premier RFC, le RFC 1,
  • 1971, premier RFC distribué via le réseau, le RFC 114,
  • 1977, premier RFC publié le premier avril, le RFC 748,
  • 1986, création de l'IETF,
  • 1998, début du projet de récupération et de restauration des vieux RFC perdus,
  • 1998, mort de Jon Postel, le « père de la série des RFC » (cf. RFC 2441),
  • 2009, publication du RFC 5620, qui décrit à peu près le modèle d'aujourd'hui,
  • 2010, les RFC ne sont plus gérés à l'ISI, mais chez une organisation spécialisée,
  • 2011, une des nombreuses réformes des RFC, l'abandon des trois niveaux de normalisation, documenté dans le RFC 6410,
  • 2013, début du projet de changement du format (RFC 6949) et d'abandon du texte brut,
  • 2017, passage au zéro papier (RFC 8153).

Dans la section 3 de ce RFC, plusieurs personnes ayant vécu de l'intérieur l'aventure des RFC écrivent. Steve Crocker, dans la section 3.1, rappelle les origines des RFC (qu'il avait déjà décrites dans le RFC 1000). Il insiste sur le fait que les débuts étaient… peu organisés, et que la création de la série des RFC n'était certainement pas prévue dés le départ. Elle doit beaucoup aux circonstances. Le réseau qui, après bien des évolutions, donnera naissance à l'Internet a été conçu vers 1968 et a commencé à fonctionner en 1969. Quatre machines, en tout et pour tout, le constituaient, un Sigma 7, un SDS 940, un IBM 360/75 et un PDP-10. Le point important est qu'il s'agissait de machines radicalement différentes, un des points distinctifs de l'Internet, qui a toujours dû gérer l'hétérogénéité. Un byte n'avait pas la même taille sur toutes ces machines. (Le terme français octet est apparu bien plus tard, lorsque la taille de huit bits était devenue standard.)

Crocker décrit la première réunion de ce qui allait devenir le Network Working Group puis, très longtemps après l'IETF. Rien n'était précisement défini à part « il faut qu'on fasse un réseau d'ordinateurs » et persone ne savait trop comment le faire. La principale conclusion de la réunion avait été « il faudrait faire une autre réunion ». Dès le début, le réseau qui allait permettre de travailler à distance était donc un prétexte à des réunions AFK. (L'ironie continue aujourd'hui, où l'IETF réfléchit à avoir des réunions entièrement en ligne.)

L'espoir des étudiants comme Crocker était qu'un monsieur sérieux et expérimenté vienne expliquer ce qu'on allait devoir faire. Mais cet espoir ne s'est pas matérialisé et le futur Network Working Group a donc dû se débrouiller.

Parmi les idées les plus amusantes, le groupe avait réfléchi à la création d'un langage portable permettant d'envoyer du code sur une autre machine qui l'exécuterait. Ce lointain prédécesseur de JavaScript se nommait DEL (pour Decode-Encode Language) puis NIL (Network Interchange Language). Mais en attendant le travail matériel avançait, la société BBN ayant obtenu le contrat de construction des IMP (à peu près ce qu'on appelerait plus tard routeurs). La répartition des tâches entre le NWG et BBN n'était pas claire et le groupe a commencé de son côté à documenter ses réflexions, créant ainsi les RFC. Le nom de ces documents avait fait l'objet de longs débats. Le Network Working Group n'avait aucune autorité officielle, aucun droit, semblait-il, à édicter des « normes » ou des « références ». D'où ce titre modeste de Request for Comments ou « Appel à commentaires ». Cette modestie a beaucoup aidé au développement du futur Internet : personne ne se sentait intimidé par l'idée d'écrire des documents finaux puisque, après tout, ce n'était que des appels à commentaires. C'était d'autant plus important que certains des organismes de rattachement des participants avaient des règles bureaucratiques strictes sur les publications. Décréter les RFC comme de simples appels à commentaires permettait de contourner ces règles.

Le premier « méta-RFC » (RFC parlant des RFC) fut le RFC 3, qui formalisait cette absence de formalisme. De la même façon, il n'existait pas encore vraiment de RFC Editor, même si Crocker attribuait les numéros, et que le SRI gardait une archive non officielle. Mais deux principes cardinaux dominaient, et sont toujours vrais aujourd'hui : tout le monde peut écrire un RFC, nul besoin de travailler pour une grosse entreprise, ou d'avoir un diplôme ou un titre particulier, et tout le monde peut lire les RFC (ce qui n'a rien d'évident : en 2019, l'AFNOR ne distribue toujours pas librement ses normes.)

Dans la section 3.2, Vint Cerf décrit les changements ultérieurs. En 1971, Jon Postel est devenu RFC Editor (titre complètement informel à cette époque). Cette tâche était à l'époque mélée à celle d'attribution des numéros pour les protocoles, désormais séparée. Postel s'occupait à la fois du côté administratif du travail (donner un numéro aux RFC…) et de l'aspect technique (relecture et révision), tâche aujourd'hui répartie entre diverses organisations comme l'IESG pour les RFC qui sont des normes. C'est pendant cette « période Postel » que d'autres personnes sont venues rejoindre le RFC Editor comme Joyce Reynolds ou Bob Braden. Jon Postel est décédé en 1998 (cf. RFC 2468).

Leslie Daigle, dans la section 3.3 de notre RFC, rappelle la longue marche qu'a été la formalisation du rôle de RFC Editor, le passage de « bon, qui s'en occupe ? » à un travail spécifié par écrit, avec plein de règles et de processus. (Daigle était présidente de l'IAB au moment de la transition.) Le travail était devenu trop important en quantité, et trop critique, pour pouvoir être assuré par deux ou trois volontaires opérant « en douce » par rapport à leurs institutions. Une des questions importantes était évidemment la relation avec l'IETF. Aujourd'hui, beaucoup de gens croient que « les RFC, c'est l'IETF », mais c'est faux. Les RFC existaient bien avant l'IETF, et, aujourd'hui, tous les RFC ne sont pas issus de l'IETF.

Parmi les propositions qui circulaient à l'époque (début des années 2000) était celle d'une publication complètement automatique. Une fois le RFC approuvé par l'IESG, quelqu'un aurait cliqué sur Publish, et le RFC se serait retrouvé en ligne, avec un numéro attribué automatiquement. Cela aurait certainement fait des économies, mais cela ne réglait pas le cas des RFC non-IETF, et surtout cela niait le rôle actif du RFC Editor en matière de contenu du RFC. (Témoignage personnel : le RFC Editor a joué un rôle important et utile dans l'amélioration de mes RFC. C'est vrai même pour les RFC écrits par des anglophones : tous les ingénieurs ne sont pas des bons rédacteurs.) D'un autre côté, cela résolvait le problème des modifications faites de bonne foi par le RFC Editor mais qui changeaient le sens technique du texte.

La solution adoptée est décrite dans le RFC 4844, le premier à formaliser en détail le rôle du RFC Editor, et ses relations complexes avec les autres acteurs.

Nevil Brownlee, lui, était ISE, c'est-à-dire Independent Submissions Editor, la personne chargée de traiter les RFC de la voie indépendante (ceux qui ne viennent ni de l'IETF, ni de l'IAB, ni de l'IRTF.) Dans la section 3.4, il revient sur cette voie indépendante (d'abord décrite dans le RFC 4846). En huit ans, il a été responsable de la publication de 159 RFC… Avant, c'était le RFC Editor qui décidait quoi faire des soumissions indépendantes. Comme le rappelle Brownlee, le logiciel de gestion de cette voie indépendante était un simple fichier texte, tenu par Bob Braden.

Le principal travail de l'ISE est de coordonner les différents acteurs qui jouent un rôle dans ces RFC « indépendants ». Il faut trouver des relecteurs, voir avec l'IANA pour l'allocation éventuelle de numéros de protocoles, avec l'IESG pour s'assurer que ce futur RFC ne rentre pas en conflit avec un travail de l'IETF (cf. RFC 5742), etc. Ah, et c'est aussi l'ISE qui gère les RFC du premier avril.

Puis c'est la RFC Editor actuelle, Heather Flanagan qui, dans la section 3.5, parle de son expérience, d'abord comme simple employée. La charge de travail atteignait de tels pics à certains moments qu'il a fallu recruter des personnes temporaires (au nom de l'idée que la publication des RFC devait être un processus léger, ne nécessitant pas de ressources permanentes), ce qui a entrainé plusieurs accidents quand des textes ont été modifiés par des employés qui ne comprenaient pas le texte et introduisaient des erreurs. L'embauche d'employés permanents a résolu le problème.

Mais il a fallu aussi professionnaliser l'informatique. Le RFC Editor qui travaillait surtout avec du papier (et un classeur, le fameux « classeur noir ») et quelques outils bricolés (la file d'attente des RFC était un fichier HTML édité à la main), a fini par disposer de logiciels adaptés à la tâche. Finies, les machines de Rube Goldberg !

Dans le futur, bien sûr, les RFC vont continuer à changer ; le gros projet du moment est le changement de format canonique, du texte brut à XML. Si l'ancien format avait de gros avantages, notamment en terme de disponibilité sur le long terme (on peut toujours lire les anciens RFC, alors que les outils et formats à la mode au moment de leur écriture sont depuis longtemps oubliés), il avait aussi des inconvénients, comme l'impossibilité d'utiliser d'autres caractères que l'ASCII. Le RFC 7990 décrit le nouveau format, actuellement en cours de déploiement.

Autres lectures :

2019-12-16

The box

C'est une banalité que de choisir le conteneur comme symbole de la mondialisation. Mais comment en est-on arrivé là ? Qui a inventé le conteneur et pourquoi ? Comment s'est-il imposé ? Je trouve que Marc Levinson a fait un excellent travail d'histoire de la conteneurisation dans ce gros livre.

Donc, le conteneur, c'est la grosse boîte en acier qu'on voit déborder sur le pont des navires. Permettant d'abaisser le coût de transport international jusqu'au point qu'il devient souvent négligeable, le conteneur a permis aux baskets fabriquées au Viêt Nam, aux T-shirts du Bangladesh et aux téléphones montés en Chine d'arriver partout dans le monde. Plus besoin de mettre les usines près des futurs clients, on peut les installer là où les travaileurs ne sont pas syndiqués et donc pas chers. Mais malgré son rôle économique crucial, le conteneur ne fait pas rêver. On écrit plein de livres sur les avions, sur les bateaux, sur de nombreuses machines, mais pas sur cette grosse boîte disgracieuse, peinte de couleurs vulgaires, qu'est le conteneur. C'est là que Marc Levinson est intervenu pour écrire ce livre touffu et très détaillé. (L'original est en anglais mais j'ai lu la traduction en français.)

Levinson retrace l'histoire du conteneur, en insistant sur le rôle de Malcom McLean, qui n'est pas « l'inventeur » du conteneur (comme beaucoup d'inventions, le conteneur a de nombreux pères), mais celui qui l'a promu et développé depuis le début. L'histoire de l'homme seul luttant contre les conservatismes pour révolutionner le transport de marchandises aurait pu être fait en style « légende étatsunienne » classique, avec le courageux entrepreneur qui, parti de rien, devient riche par son travail personnel, mais, heureusement, Levinson ne donne pas dans ce travers. Il explique bien le rôle de McLean, mais aussi ses erreurs et ses défauts, et le rôle de nombreuses autres personnes.

C'est que le conteneur a eu une histoire difficile. Il n'y a que dans les légendes que l'inventeur conçoit un objet et qu'après de courtes difficultés initiales, l'objet conquiert le monde par la seule force de ses qualités intrinsèques. En fait, le conteneur ne s'est pas imposé tout de suite. Il a rencontré de nombreuses difficultés, du conservatisme des acteurs déjà installés aux problèmes politiques et légaux, en passant par la difficulté d'adapter toute la chaîne du transport. Sans oublier des problèmes techniques bien concrets, pour faire une boîte solide, mais pas chère et facile à manipuler.

Levinson ne cache pas que l'effondrement des coûts du transport international n'est pas uniquement dû au conteneur, objet magique. Il a fallu refaire toute la logistique, et cela a pris de nombreuses années. En cela, ce livre est un excellent modèle d'analyse d'un système socio-technique. Contrairement à beaucoup d'études sur un objet technique, celle-ci ne considère pas le conteneur comme isolé, mais bien comme un des maillons d'un système complexe. Avec le recul, on dit que c'est le conteneur, par la baisse des coûts qu'il a engendrée, qui a permis l'actuelle mondialisation. Mais pendant de nombreuses années, il fallait vraiment avoir la foi, le conteneur coûtait aussi cher, voire plus cher que les systèmes qu'il voulait remplacer. Et il fallait remplir cette grosse boîte, pour qu'elle ne voyage pas à moitié vide et cela au retour comme à l'aller. C'est seulement quand tout le système socio-technique du transport s'est adapté à ces exigences que les coûts ont réellement baissé. En attendant, il a fallu financer l'adaptation des bateaux et des ports à ce nouvel objet et, contrairement à la légende des entrepreneurs privés qui risquent leur argent et, si ça marche, en retirent des bénéfices bien mérités, ici, une bonne partie des ports et même des navires ont été financés pendant des années par l'argent public, McLean ayant réussi à convaincre beaucoup de monde que l'avenir était au conteneur. C'est d'ailleurs la guerre du Viêt Nam qui a marqué le vrai décollage du conteneur, vu les énormes besoins en matériel de l'armée étatsunienne et l'argent dont elle disposait.

Comme tous les changements socio-techniques, le conteneur a fait des gagnants et des perdants. Levinson ne joue pas la partition de la « mondialisation heureuse » et analyse qui a gagné et qui a perdu. Parmi les perdants, les marins : la rapidité de chargement et de déchargement, un des buts de la conteneurisation, a réduit à quelques heures la durée des escales. On ne voit plus du pays quand on est marin, seulement les gigantesques terminaux à conteneurs, toujours situés, vu leur taille, très loin de la ville, contrairement au port traditionnel. Toujours parmi les perdants, les dockers, le but du conteneur étant entre autres de nécessiter moins de personnel pour charger et décharger les bateaux. Les pages consacrées aux questions sociales sont très intéressantes, mais le livre est évidemment très centré sur les États-Unis et ce pays présente quelques particularités, comme les liens de certains syndicats avec le crime organisé (même si l'auteur note que le film Sur les quais n'est pas toujours réaliste), ou comme la concurrence entre syndicats (celui des dockers et celui des camionnneurs qui s'allient chacun avec son patronat, contre l'autre syndicat…)

Mais les principaux perdants n'ont pas forcément été du côté des professionnels du transport maritime : ce sont tous les travailleurs qui se trouvent désormais en compétition avec des pays sans lois sociales, sans syndicats, sans droit du travail.

La normalisation est un sujet peu abordé dans les analyses des systèmes socio-techniques mais, ici, elle a la place qu'elle mérite. Le conteneur n'est en effet intéressant que si n'importe quel navire, train ou camion peut l'embarquer. Cela nécessite une normalisation de la taille, des caractéristiques physiques (résistance à l'écrasement) et du système de verrouillage des conteneurs. C'est un des meilleurs chapitres du livre, introduisant le lecteur à ce monde feutré des négociations autour de la normalisation, sachant que des détails apparemment sans importance, comme la largeur exacte du conteneur, peuvent faire perdre beaucoup d'argent aux premiers investisseurs, qui risquent de devoir refaire leurs ports et leurs navires, si la taille initialement retenue n'est pas celle choisie par ces premiers arrivés. Et les décisions de normalisation ne sont pas purement arbitraires, la technique a son mot à dire, par exemple sur le système de verrouillage (sinon, on perd des conteneurs en mer.)

Pour résumer, c'est un très bon exemple d'analyse socio-technique, à lire même si vous ne travaillez pas dans le domaine du transport de marchandises. On voudrait que tous les systèmes socio-techniques complexes fassent l'objet d'aussi bonnes synthèses.

Et de jolies photos de conteneurs, prises à l'exposition Playmobil à Calais : (Version en taille originale.) (Version en taille originale.)

2019-12-15

Vérifier le nom dans un certificat : pas trivial

J'ai récemment eu à écrire un programme qui se connecte en TLS à un serveur et devait donc vérifier le certificat. La bibliothèque TLS utilisée ne vérifie pas que le nom dans le certificat correspond au nom demandé, c'est au programmeur de le faire, et ce n'est pas trivial, avec de nombreux pièges.

Un peu de contexte pour comprendre : le programme était un client DoT (DNS sur TLS, normalisé dans le RFC 7858). Il ne s'agit pas d'un client HTTP (qui ont tous des mécanismes de vérification du certificat). Au début, je me suis dit « pas de problème, je ne vais pas programmer TLS moi-même, de toute façon, cela serait très imprudent, vu mes compétences, je vais utiliser une bibliothèque toute faite, et, avantage en prime, j'aurais moins de travail ». Le client étant écrit en Python, j'utilise la bibliothèque pyOpenSSL, qui repose sur la bien connue OpenSSL.

Je prends bien soin d'activer la vérification du certificat et, en effet, les certificats signés par une AC inconnue, ou bien les certificats expirés, sont rejetés. Mais, surprise (pour moi), si le nom dans le certificat ne correspond pas au nom demandé, le certificat est quand même accepté. Voici un exemple avec le client OpenSSL en ligne de commande, où j'ai mis badname.example dans mon /etc/hosts pour tester (une autre solution aurait été d'utiliser l'adresse IP et pas le nom, pour se connecter, ou bien un alias du nom) :

% openssl s_client -connect badname.example:853  -x509_strict
...
Certificate chain
 0 s:CN = dot.bortzmeyer.fr
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
...
    
Et aucun message d'erreur, tout se passe bien, alors que le certificat ne contenait pas du tout badname.example.

Notez que c'est précisé. La documentation d'OpenSSL nous dit « You must confirm a match between the hostname you contacted and the hostnames listed in the certificate. OpenSSL prior to 1.1.0 does not perform hostname verification, so you will have to perform the checking yourself. ». Pourquoi cette absence de vérification ? Et comment faire la vérification ?

En fait, le problème n'est pas spécifique à OpenSSL. Le système de sécurité autour des certificats est un empilement complexe de normes. À la base, se trouve une norme UIT nommée X.509. Elle était disponible en ligne (depuis, l'UIT l'a fait disparaitre, où irions-nous si tout le monde pouvait lire les normes) et fait, aujourd'hui, 236 pages. Elle décrit le format des certificats, le rôle des AC, et plein d'autres choses, mais ne parle pas de la vérification des noms (on dit « sujets » et pas « noms », dans la terminologie X.509), et pour cause : X.509 permet de très nombreuses façons d'indiquer le sujet, ce n'est pas forcément un nom de domaine. Comme le dit sa section 9.3.1, « public-key certificates need to be usable by applications that employ a variety of name forms ». Une convention aussi banale que d'utiliser une astérisque comme joker n'est même pas mentionnée. Bref, X.509 ne va pas répondre à nos questions. Mais l'Internet n'utilise pas X.509. Il utilise la plupart du temps le protocole TLS, normalisé dans le RFC 8446. TLS utilise comme méthode d'authentification principale un certificat, décrit par un profil, une variation de X.509, ne gardant pas toutes les posssibilités de X.509, et en ajoutant d'autres. Ce profil est souvent nommé PKIX, pour Public-Key Infrastructure X.509 et est normalisé dans le RFC 5280. PKIX est plus précis que X.509 mais reste encore loin de tout spécifier, renvoyant souvent aux applications telle ou telle question. Par exemple, les jokers, déjà mentionnés, sont laissés à l'appréciation des applications. On comprend donc que les développeurs de OpenSSL n'aient pas inclus une vérification par défaut.

Pour compléter cette revue des normes, il faut citer surtout le RFC 6125, qui, lui, décrit précisément la vérification des sujets, quand ce sont des noms de domaine. C'est la principale source d'information quand on veut programmer une vérification du nom.

Ah, et, quand on teste, bien penser à séparer bibliothèque et programme utilisant cette bibliothèque. Ce n'est pas parce que la commande openssl peut tester le nom que la bibliothèque le fait par défaut. L'option pertinente se nomme -verify_hostname :

% openssl s_client -connect badname.example:853  -x509_strict -verify_hostname badname.example 
...
verify error:num=62:Hostname mismatch
...    
Si on avait utilisé le bon nom (celui présent dans le certificat,ici dot.bortzmeyer.fr), on aurait eu :
Verification: OK
Verified peername: dot.bortzmeyer.fr
     
Notez bien que c'est une option. Si elle est mise sur la ligne de commande, openssl demandera à la bibliothèque OpenSSL de faire la vérification, mais cela ne sera pas fait autrement. OpenSSL dispose d'un sous-programme X509_check_host qui fait la vérification, mais il n'est pas appelé par défaut, et il n'est pas présent dans pyOpenSSL, la bibliothèque Python.

Par contre, avec la bibliothèque GnuTLS, le programme en ligne de commande fait cette vérification, par défaut :

% gnutls-cli --port 853 badname.example
...
Connecting to '2001:41d0:302:2200::180:853'...
...
- Certificate[0] info:
 - subject `CN=dot.bortzmeyer.fr', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x042ab817dad761f36920a3f2b3e7b780986f, RSA key 2048 bits, signed using RSA-SHA256, activated `2019-11-26 08:34:11 UTC', expires `2020-02-24 08:34:11 UTC', pin-sha256="eHAFsxc9HJW8QlJB6kDlR0tkTwD97X/TXYc1AzFkTFY="
...
- Status: The certificate is NOT trusted. The name in the certificate does not match the expected. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
    
Le sous-programme dans GnuTLS qui fait la vérification se nomme gnutls_x509_crt_check_hostname.

Et si vous voulez faire cette vérification vous-même (ce qui n'est pas prudent mais on va dire qu'on veut vivre dangereusement) ? Il faut penser à plein de choses. Prenons l'exemple d'un programme en Python. Le test de base, où on compare le nom de serveur donné au « common name » (CN) dans le certificat :

if hostname == cert.get_subject().commonName:
    
est non seulement insuffisant (il ne tient pas compte des jokers, ou des « subject alternative name », ou SAN) mais il est en outre incorrect, le RFC 6125 disant bien, dans sa section 6.4.4, qu'il ne faut tester le « common name » que si tous les autres tests ont échoué. Il faut en fait tenir compte des SAN (Subject Alternative Names) contenus dans le certificat. Il faut examiner tous ces SAN :
for alt_name in get_certificate_san(cert).split(", "):
    if alt_name.startswith("DNS:"):
        (start, base) = alt_name.split("DNS:")
        if hostname == base:
	   ...
    

Rappelez-vous qu'un sujet, en X.509, n'est pas forcément un nom de domaine. Cela peut être une adresse IP, un URL, ou même du texte libre. Traitons le cas des adresses IP. Le certificat de Quad9 utilise de telles adresses :

% openssl s_client -connect 9.9.9.9:853 -showcerts | openssl x509 -text
...
    X509v3 Subject Alternative Name: 
       DNS:*.quad9.net, DNS:quad9.net, IP Address:9.9.9.9, IP Address:9.9.9.10, IP Address:9.9.9.11, IP Address:9.9.9.12, IP Address:9.9.9.13, IP Address:9.9.9.14, IP Address:9.9.9.15, IP Address:149.112.112.9, IP Address:149.112.112.10, IP Address:149.112.112.11, IP Address:149.112.112.12, IP Address:149.112.112.13, IP Address:149.112.112.14, IP Address:149.112.112.15, IP Address:149.112.112.112, IP Address:2620:FE:0:0:0:0:0:9, IP Address:2620:FE:0:0:0:0:0:10, IP Address:2620:FE:0:0:0:0:0:11, IP Address:2620:FE:0:0:0:0:0:12, IP Address:2620:FE:0:0:0:0:0:13, IP Address:2620:FE:0:0:0:0:0:14, IP Address:2620:FE:0:0:0:0:0:15, IP Address:2620:FE:0:0:0:0:0:FE, IP Address:2620:FE:0:0:0:0:FE:9, IP Address:2620:FE:0:0:0:0:FE:10, IP Address:2620:FE:0:0:0:0:FE:11, IP Address:2620:FE:0:0:0:0:FE:12, IP Address:2620:FE:0:0:0:0:FE:13, IP Address:2620:FE:0:0:0:0:FE:14, IP Address:2620:FE:0:0:0:0:FE:15
    
Voici une première tentative pour les tester :
    elif alt_name.startswith("IP Address:"):
          (start, base) = alt_name.split("IP Address:")
          if hostname == base:
	     ...
    
Mais ce code n'est pas correct, car il compare les adresses IP comme si c'était du texte. Or, les adresses peuvent apparaitre sous différentes formes. Par exemple, pour IPv6, le RFC 5952 spécifie un format canonique mais les certificats dans le monde réel ne le suivent pas forcément. Le certificat de Quad9 ci-dessus utilise par exemple 2620:FE:0:0:0:0:FE:10 alors que cela devrait être 2620:fe::fe:10 pour satisfaire aux exigences du RFC 5952. Il faut donc convertir les adresses IP en binaire et comparer ces binaires, ce que je fais ici en Python avec la bibliothèque netaddr :
    elif alt_name.startswith("IP Address:"):
         (start, base) = alt_name.split("IP Address:")
         host_i = netaddr.IPAddress(hostname)
         base_i = netaddr.IPAddress(base)
         if host_i == base_i:
	    ...
    

Ce problème du format des adresses IP illustre un piège général lorsqu'on fait des comparaisons avec les certificats, celui de la canonicalisation. Les noms (les sujets) peuvent être écrits de plusieurs façons différentes, et doivent donc être canonicalisés avant comparaison. Pour les noms de domaine, cela implique par exemple de les convertir dans une casse uniforme. Plus subtil, il faut également tenir compte des IDN (RFC 5891). Le RFC 6125, section 6.4.2, dit qu'il faut comparer les « A-labels » (la forme en Punycode), on passe donc tout en Punycode (RFC 3492) :

def canonicalize(hostname):
    result = hostname.lower()
    result = result.encode('idna').decode()
    return result      
    
Vous pouvez tester avec www.potamochère.fr, qui a un certificat pour le nom de domaine en Unicode.

Ensuite, il faut tenir compte du fait que le certificat peut contenir des jokers, indiqués par l'astérisque. Ainsi, rdap.nic.bzh présente un certificat avec un joker :

% gnutls-cli  rdap.nic.bzh 
...
- Certificate[0] info:
 - subject `CN=*.nic.bzh', issuer `CN=RapidSSL TLS RSA CA G1,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x0a38b84f1a0b01c9a8fbc42854cbe6f6, RSA key 4096 bits, signed using RSA-SHA256, activated `2018-09-03 00:00:00 UTC', expires `2020-07-30 12:00:00 UTC', pin-sha256="2N9W5qz35u4EgCWxbdPwmWvf/Usz2gk5UkUYbAqabcA="
...
Il faut donc traiter ces jokers. Attention, comme le précise le RFC 6125 (rappelez-vous que la norme X.509 ne parle pas des jokers), il ne faut accepter les jokers que sur le premier composant du nom de domaine (*.nic.bzh marche mais rdap.*.bzh non), et le joker ne peut correspondre qu'à un seul composant (*.nic.bzh accepte rdap.nic.bzh mais pas foo.bar.kenavo.nic.bzh.) Cela se traduit par :
    if possibleMatch.startswith("*."): # Wildcard
        base = possibleMatch[1:] # Skip the star
        (first, rest) = hostname.split(".", maxsplit=1)
        if rest == base[1:]:
            return True
        if hostname == base[1:]:
            return True
        return False
    else:
        return hostname == possibleMatch      
    
Un point amusant : le RFC 6125 accepte explicitement des astérisques au milieu d'un composant, par exemple un certificat pour r*p.nic.bzh accepterait rdap.nic.bzh. Mon code ne gère pas ce cas vraiment tordu, mais les développeurs d'OpenSSL l'ont prévu (si l'option X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS n'est pas activée) :

/* Only full-label '*.example.com' wildcards? */
     if ((flags & X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS)
                && (!atstart || !atend))
                return NULL;
            /* No 'foo*bar' wildcards */
      
    
Autre cas amusant, le code de curl, quand il vérifie que le nom du serveur correspond au contenu du certificat, refuse les jokers si le nom dans le certificat n'a que deux composants. Le but est sans doute d'éviter qu'un certificat pour *.com ne permette de se faire passer pour n'importe quel nom en .com mais cette règle, qui ne semble pas être dans le RFC 6125, n'est sans doute pas adaptée aux récents TLD .BRAND, limités à une entreprise.

Au passage, j'avais dit au début que mon but initial était de tester un serveur DoT (DNS-over-TLS, RFC 7858). Le RFC original sur DoT ne proposait pas de tester le nom, estimant qu'un résolveur DoT serait en général configuré via son adresse IP, pour éviter un problème d'œuf et de poule (on a besoin du résolveur pour trouver l'adresse IP du résolveur…) La solution était d'authentifier via la clé publique du résolveur (l'idée a été développée dans le RFC 8310.)

Voilà, vous avez un exemple de programme Python qui met en œuvre les techniques données ici (il est plus complexe, car il y a des pièges que je n'ai pas mentionnés), en tls-check-host.py. Une autre solution, n'utilisant que la bibliothèque standard de Python, est tls-check-host-std-lib.py, mais, attention, ladite bibliothèque standard ne gère pas les IDN, donc ça ne marchera pas avec des noms non-ASCII. (Mais son utilisation évite de recoder la vérification.)

En conclusion, j'invite les programmeurs qui utilisent TLS à bien s'assurer que la bibliothèque TLS qu'ils ou elles utilisent vérifie bien que le nom de serveur donné corresponde au contenu du certificat. Et, si ce n'est pas le cas et que vous le faites vous-même, attention : beaucoup d'exemples de code source de validation d'un nom qu'on trouve au hasard de recherches sur le Web sont faux, par exemple parce qu'ils oublient les jokers, ou bien les traitent mal. Lisez bien le RFC 6125, notamment sa section 6, ainsi que cette page OpenSSL.

Merci à Patrick Mevzek et KMK pour une intéressante discussion sur cette question. Merci à Pierre Beyssac pour le rappel de ce que peut faire la bibliothèque standard de Python.

2019-12-12

Why I don’t use Semantic Web technologies anymore, even if they still influence me ?

2019-12-12 Gautier Poupeau - Les petites cases - Management de l&#039;information, RDF, Web sémantique, Système d&#039;information, Sparql, Web, Causeries, Digital humanities, RDFa, Linked Data

Avant-propos : ce texte en anglais est celui de la keynote que j’ai eu le grand plaisir d’assurer le 12 décembre 2019 à l’invitation de Vincent Razanajao et Alberto Dalla Rosa lors de la conférence « Linked Pasts V » qui a eu lieu à Bordeaux (11-13 décembre 2019). Il a été traduit par Emmanuelle Bermès que je remercie encore énormément pour ce travail. Il reprend en grande partie des billets déjà publiés sur ce blog. Vous trouverez avant le texte en lui-même les slides qui accompagnaient mon intervention.

Introduction

I started to be interested in Semantic Web technologies in 2005. My first talk on this topic was in 2006 at the Digital Humanities conference in Paris. Then, I had the opportunity to test them life-size in 2007 for a project conducted by the CCH of King's College. But, it was during the SPAR project of the National Library of France, started in 2008, that I really started to touch the tremendous promise of these technologies and their limits, already. Between 2008 and 2014, I had the opportunity to deploy them in different contexts, in order to address different use cases: data publication, harvesting of data embedded within web pages, bridging internal silos and data consistency, data enrichment and mashups... I would like to share this experience with you today, with two objectives:

  • show in what contexts and how we can use Semantic Web technologies;
  • take a comprehensive look at these technologies and explain how they have impacted my thinking in the field of data management, even if I don’t use them anymore.

But first, I'd like to go back to the history of these technologies: after all history is a great way to put things into perspective ....

<!--break-->

A quick history of the Semantic Web

The initial purpose of the Web was to enable CERN researchers in Geneva and affiliated laboratories to grant quick and easy access to the elements contained in their computers, in order to exchange them with their peers. What did the researchers' machines contain?

  • First, documents: experiences protocols and reports, scientific papers, monographs... that is, a set of finite, organized and coherent information intended for humans
  • But also, data: tables and databases containing research results, that is, information in a standardized form aimed at being used by machines.
  • Therefore, the Web has been designed, from its origin, to allow the linking and exchange of documents and data in a global interoperability space.

The pioneers of the Web, led by Tim Berners-Lee, focused first on developing building blocks for the exchange and linking of documents. To do so, they relied on a mature set of technologies and principles:

  • A communication protocol, HTTP, based on the TCP / IP protocol, also known as the Internet;
  • An identification mechanism, the URLs, which makes it possible to access a document on a distributed network of machines;
  • A principle for linking documents, the hypertext, created at the end of the Second World War by Vanevar Bush and adapted to computer science by Ted Nelson in the mid-1960s;
  • A document encoding language, HTML, based on SGML, a standard for hierarchical description of information.

The success of the Web of documents is due to several factors:

  • Web standards are open and free: anybody can implement them without having to pay;
  • Web standards are robust: they do not contain any SPOF, Single Point Of Failure. The Web can be extended without limits, you just need a web server connected to the Internet. There is no centralized directory. Furthermore, linking to another page is not subject to any authorization or verification
  • Web standards are easy to implement: you can learn HTML in one or two hours. The hypertext is natural because it is based on the principle of the association of ideas, just like human thinking.

So, the development of standards for the web of documents and their appropriation by a large community were quite simple. However, the situation when it comes to data was much more complex. In the 90s, there wasn’t any technological consensus to implement in this field. In September 1994, at the 1st WWW conference, Tim Berners-Lee draws the future directions of the W3C and demonstrates the "need for semantics for the Web". Today, we no longer speak about semantic web but about knowledge graphs. In between, these technologies have been redefined several times while keeping their technological base.

We can identify 3 periods:

Semantic Web era : from 1994 to 2004, a first period was dedicated to the development of major Semantic Web standards like RDF and OWL.

Linked Data era : Then from 2006 to 2014, the effort focused on adoption, with a new initiative called Linking Open Data. SPARQL was developed and major industry players like Google, Bing and Yahoo entered the game by releasing the Schema.org vocabulary. Finally, Wikidata was opened to contributors and new versions of RDF, JSON and SPARQL were released.

Knowledge graph era: Today, we can consider that we are in a third period, the knowledge graph era. It started when Google announced the knowledge vault and is characterized by the emergence of new de facto standards for graphs, more fit to be used by the industry.

Three periods, three redefenitions of what the semantic web technologies are but same technologies, Isn’t it the indication of a problem with them?

Feedback

To illustrate my point, I would like to provide some feedback on some projects I’ve been involved in. I will focus on the reasons that led us to choose semantic Web technologies, the limits we faced and the lessons learnt.
The SPAR project / Flexibility and linking of heterogeneous data

The National Library of France’s project for a “Scalable Preservation and Archiving Repository” (SPAR) aims to ensure the long-term continuity of access to its digital collections. The system strictly follows the principles of the OAIS model (Open Archival Information System), including in its architecture. Indeed, each functional entity of the OAIS model is implemented as an application module: Ingest, Data Management, Storage, Access and Administration.

  • The Ingest module enables the control and enrichment of information packages and the transformation of submission information packages into archival information packages
  • The Data Management module provides storage, indexing and querying of all metadata: reference data and information packages
  • The storage module provides secure storage of all packages
  • The Access module retrieves information packages
  • Finally the Administration module is used to manage the system.

The "Data Management" module, in charge of storing and querying metadata, had to answer various problems:

  • all metadata needed to be searchable without any preconceived idea of how to query them;
  • the data was heterogeneous and included semi-structured data;
  • the metadata from the information packages was to be queried along with the reference data;
  • we needed a powerful query language, preferably a standard, accessible to non-IT staff like preservation experts;
  • the system had to be flexible and standard, independent of any software implementation in order to ensure evolutivity and reversibility in the long term.

At the time (that is, in 2008), it turned out that the RDF model and the SPARQL query language were the most appropriate answer to all these issues:

  • Relational databases seemed too rigid and software-dependent;
  • Search engines did not allow indexing in real time and were also problematic because they limited the query to a single entity and made fine querying of structured data difficult;
  • As for document databases, they were still in their infancy and even today, they do not offer the same query flexibility as SPARQL.

So we decided to implement the whole "Data Management" module with the RDF model and to expose a sparql endpoint as an API. To do this, we deployed the Virtuoso software, already in use since two years within Dbpedia.

As a result, this is how metadata is handled within SPAR. The submission information package is a zip archive that contains:

  • all files to be preserved;
  • an XML file using METS and Dublin Core to describe the list of files, their structure and the descriptive metadata.

The ingest module checks the package against reference data (agents, formats, etc.). At the end of the ingest process, the files are stored in the Storage module while the metadata is transformed into RDF to be indexed within the Data Management module.

The ontology used for this RDF transformation was created ad hoc based on existing models: Dublin Core, OAI-ORE and home-made ontologies.

The first problems appeared when we ran performance tests. The model proved to be as flexible as expected and the query language was expressive enough. But the system was lacking performance and scalability.

We had to adapt the architecture. So, we created multiple instances of Virtuoso, containing different metadata sets based on usage, including an instance with all the metadata. The result was much more complex than initially planned. We also worked on the volume of indexed metadata by excluding redundant information. Last but not least, it is worth noting that the instance containing all the metadata has a very limited number of users (roughly counted on the fingers of both hands).

Ten years later, the system is still in place. The BnF has gone from the open (and free) version of Virtuoso to the paid version to ensure scalability. As far as I know, they remains convinced of this choice. As for myself, I’ll remember this experience as a crazy bet (a few of us have spent restless nights asking ourselves if it was the right solution...). Fortunately, speed of response and number of users were not an issue on this project. I remain convinced that it would be difficult to build a production service with a large number of users and / or data, directly on a searchable RDF database with SPARQL.

The Isidore project / Data retrieval and exposure

Isidore is a project led by the research infrastructure Huma-Num, started in 2008. Since 2010, it provides an online platform for searching open access resources in humanities and social sciences. Today, almost 6 million resources from more than 6,400 data sources are aggregated.

The architecture of Isidore is composed of three parts:

  • Back office applications for managing data sources and repositories;
  • A data pipeline system responsible for retrieving data sources, controlling them, enriching them and indexing them in a search engine;
  • Two storage systems to request and publish the data: a search engine that publishes the data through a specific API and a triple store providing a SPARQL endpoint.

Semantic Web technologies are involved in several ways in this project:

Isidore harvests metadata and content in three different ways, one of which is RDFa. RDF statements are embedded in Web pages using RDFa, thus allowing to retrieve metadata from those web pages listed via the Sitemap protocol. At that time, we were convinced that the OAI-PMH protocol, often used to expose the data, presented major drawbacks:

  • it was impossible to express different granularity levels, because disparate entities were described at the same level;
  • the description was limited to simple Dublin Core;
  • the HTTP protocol was used correctly (the error mechanism does not use the appropriate error codes, mechanism of the hypermedia is unused...).

In our view, RDFa was a simple way to lead producers towards Semantic Web technologies and to go beyond the limits of OAI-PMH. With a supposedly limited investment, it provided a greater capacity for description using OAI-ORE, an RDF vocabulary created in 2008 to address the limitations of OAI-PMH, and Dublin Core terms.

In Isidore, the reference data used to carry out the enrichments is expressed in RDF, connected with links;

All metadata retrieved from data sources or obtained from Isidore's enrichment mechanisms are converted to RDF and stored in an RDF database. They are published according to Linked Data principles.

Inspired by the emerging initiatives around Open Data, we felt it was essential to make the data available in return. Several objectives were targeted:

  • as a public initiative, be transparent about the data used to build the search engine;
  • make available to producers (and, by extension, to everyone) the enrichments produced from their data (generation of a unique Handle identifier, classification of resources, automatic annotation with reference systems...) in a logic of counter-gift;
  • help SHS academics get acquainted with semantic Web technologies.

I am not in the best place to draw conclusions from these different initiatives. With the perspective of time but also of my current position, I have the impression that the challenge was half met. The choices were certainly good at the time. They served as an example to help us progress when it came to the reuse of exposed data, the use of semantic Web technologies and, more generally, the interoperability of research data.

However, actual reuse of these data remain scarce. Maybe this kind of data is not necessarily amenable to reuse, but furthermore, their exploitation requires a challenging learning curve. Researchers want simple, accessible things. During a study day organized in 2017 around the relationship between research and heritage institutions, Raphaëlle Lapotre, product manager of data.bnf.fr, confirmed:

"We mostly get in touch with the researchers when things go wrong with the data. And it often goes wrong for several reasons. But, indeed, there was the question of these standards giving the researchers a hard time [...] they tell us: but why don’t you just use csv rather than bother with your semantic web business? "

This is a general finding in the world of Open Data: the more complex the data, the less reused they are.

As for RDFa, this formalism proved to be much more complex than expected to handle. There was no initiative or vocabulary at the time to structure this data in a consistent manner. We advocated the Dublin Core terms because it seemed most appropriate for this type of data. Since then, Schema.org has come forth and gradually, RDFa has given way to Json-LD. Obviously, I would focus towards this couple today. Finally, it should be noted that, despite its shortcomings, the OAI-PMH protocol remains the main channel for Isidore to retrieve data... victory of simplicity over expressivity? Whatever, this is a lesson to remember while OAI-ORE celebrates its 10 years.

From mashups to Linked enterprise Data: breaking silos / linking and bringing consistency to heterogeneous data

In their founding paper published in 2001 in the journal Scientifc American, Tim Berners-Lee, Ora Lassila and James Hendler illustrate their proposal with a concrete example. A software agent searches various sources of available data on the web and combines them in real time to arrange a medical appointment. This use case is supposed to demonstrate the possibilities of data publication and how Semantic Web technologies can connect heterogeneous data to deduce information. Decentralization, interoperability and inference are ultimately the three main objectives of the Semantic Web.

Following the same principles, we could mix several sources of heterogeneous data exposed in RDF (or another way) to create new applications with real time updated data from different sources. That's the whole principle of data mashups.

However, from theory to practice, there is a gap.

In the different mashups that we have developed, like this one on historical monuments, the general principle and the place of Semantic Web technologies are the same. We used them in two different ways:

  • to recover the published data sources according to the principles of Linked Data or through a sparql endpoint;
  • to make the "glue" between heterogeneous data sources by building a graph itself stored in an RDF database and from which we built the XML files to index in the search engine.

The first obvious difference with the use case outlined in the 2001 paper is data retrieval. With the current state of the art and taking into account the problems of network resilience, building a fast and scalable application requires to recover the data asynchronously, process it and then store it in a local database. This requires putting in place heavy mechanisms to update the data that can not be done in real time, thus questioning the idea of decentralization.

In this kind of exercise, preparing a consistent dataset is complex in itself, regardless of whether or not Semantic Web technologies are at play. In addition, two other challenges have to be faced:

  • the mapping of all data sources to RDF and the development of a data model that can describe all the harvested data;
  • the conversion of the stored data back into a search engine-readable formalism (Json or XML), the capabilities of the RDF database being limited from this point of view.

Is the conversion and storage in RDF step really useful? We could go directly from the retrieval phase to the storage in the search engine via data processing. The main interest of this choice is to separate the data and its logic from the way of exploiting it. In this way, it is possible, simple and fast to create different views focused on the different entities of the model. We could invent new ways to navigate the data depending on how to browse the graph. Obviously, this supposes that the reusers know perfectly the structure of the graph and master Semantic Web technologies...

Yes, flexible it is. But in the end, when you compare the time spent developing and automating the mapping and RDF storage and the time gained in the exploitation of data, there is almost no immediate advantage in using these technologies; it may even be the contrary. Such an effort will be justified (perhaps) only with time (without guarantee ...) and the actual creation of different uses or views on the data.

The Linked Enterprise Data, a concept that we tried to push at Antidot, could be compared to a data mashup of the legacy information systems of organizations. The idea is to free data from existing silos, separate data from usage, link and create consistency between all data sources, in order to propose new uses and a new way of exploiting / exploring the data assets of the organization.

In the case of Electre, a company specializing in the supply of bibliographic data, the implementation of Linked Enterprise Data made it possible to recentralize all the data dispersed in different silos, to make them consistent and link them via a common model, and to enrich them. The goal was to simplify the reuse of data.

As in the case of mashups, the goal is achieved. But at what cost ? It was necessary to convert all data sources into RDF and ensure consistency within a triple store in near real-time with every change in the system. This proved to be very complex to supervise and maintain over time. In this case, the actual benefit of the RDF mapping isn’t obvious. The construction of a new data silo in RDF may be actually revealing a wider architecture problem in the information system, and even worse, a way to avoid seeing it completely.

We only had a few opportunities to develop this vision for organizations. Indeed, we ran into different problems. Beyond technical issues like scalability, performance, data retrieval from silos, RDF mapping and issues with contextualization of RDF triples, there are organizational issues. Organizations lack interest in managing their own data, especially when the return on investment is not obvious. Sometimes the IT isn’t legitimate to take a transversal vision inside the organization.

  • issue of scalability and performance;
  • complexity in moving data out of silos and mapping it to RDF;
  • disinterest of organizations for the data itself and its logic;
  • real or supposed illegitimacy of IT units to take a transversal vision in the organization;
  • limit of the RDF model to express the source of the information and, more generally, difficulty to contextualize the triple;
  • inability to guarantee a return on investment;
  • lack of skills of developers in the field.

Finally, lack of skills of developers in the field is an important flaw, because it conditions the realization, the supervision and the maintainability of such systems. The IT staff will never move towards a solution that they are not sure to be able to sustain over time.

Conclusions and perspectives

These different experiences demonstrate the benefits offered by semantic Web technologies regarding two elements:

  • The flexibility of the graph at the core of the RDF model;
  • The possibilities offered by these technologies in terms of data publication, interoperability and decentralization.

For each of these topics, I will now show the contribution of Semantic Web technologies, but also their limits and the means to overcome them.

The flexibility of the graph model
Benefits of Semantic Web technologies

Compared with the rigidity of relational databases - be it a reality or just an impression - the RDF graph appears like absolute freedom:

  • the data structure is no longer separated but part of the data itself.
  • where relationship tables sometimes had an approximate typology, the graph model makes things explicit and the logic model has never been closer to the conceptual model and real-world logic.
  • No more local entity identifiers, URIs make universal resource identification.
  • the data is structured according to the logic of the data and not the use that is made of it.

It makes possible what the tabular model has never been able to solve: the linking of heterogeneous entities easily, either directly by typed links or via reference data, also including the structure of the data as part of the data itself.

The graph can evolve over time and its growth is potentially infinite without needing to edit the entire logic model.

Yes, all these promises are held by the Semantic Web technologies, RDF and SPARQL in particular.

However, the very structure of the RDF model has revealed limitations on the management of the provenance of the various pieces of information and the contextualization of the triple. And this point, already present in Tim Berners-Lee's Semantic Web, is still not really resolved. Solutions have appeared but they are not entirely satisfactory. From this point of view, RDF 1.1 is a missed appointment.

Meanwhile, another model called "property graph" has emerged. It proposes a response to this limit. This model is today at the heart of all graph database technologies proposed by the major players in the sector: IBM, Microsoft, Amazon (based in principle on the Blazegraph product whose company seems to have been bought by Amazon), Google, not to mention the new ones: Huawei, Datastax, Neo4j or OrientDB.

Thus, the graph model is doing well and for a good reason. It offers unparalleled flexibility in the manipulation of structured data and in the cross-query of heterogeneous data. But, most industry players made the choice to implement the property graph model and they all adopted the Apache Tinkerpop framework and the Gremlin query language to interact with the storage system, making it a de facto standard.

Maintainability and management of data in a graph system

Beyond the limits

Acknowledging the limits of RDF doesn’t mean to renounce everything that Semantic Web technologies have brought over these years. In particular, a reconciliation remains possible between property graph and RDF with RDF * / SPARQL *. If there is no need to publish the data on the Web, the use of property graphs seems to me a good idea.

Working with these technologies also led us to think about data governance. Creating a global map of all your data seems a good starting point. You should also focus on conceptual modeling as the first stage of your project and all along the development.

Finally, when getting started, ask yourself: do you really need the graph model? We shouldn’t just use Semantic Web technologies just because they are fashionable. As Dan Brickley says: you do what you want inside your own system. RDF is to be seen as a tool to exchange data, not as a mandatory standard to be used at the core of your architecture.

Data publication / Interoperability / Decentralisation
Contributions of semantic Web technologies

Indeed, the main strength and interest of Semantic Web technologies (maybe the only one?) is to ensure the interoperability of structured data by offering a common model (the triple). From this point of view, the promise is perfectly kept. If we design data-level interoperability, Semantic Web technologies are at the moment the best solution, and they have deeply influenced our thinking on this matter.

Although it was not enough for these technologies to be widely adopted, they accelerated the reflexion on interoperability by opening up unexplored technical possibilities. They allowed us to better understand the conditions required for linking heterogeneous data and to create bridges between worlds that seemed remote or even impossible to reconcile (see also the presentation). Semantic Web technologies have made it possible to consider new ways of conceiving interoperability.

Moreover, as it is the case with Wikidata, SPARQL is a powerful tool for querying data, regardless of RDF being used as a model.

Limitations of Semantic Web Technologies

However, there are major shortcomings in this area as well:

  • Network performance and resiliency issue still require asynchronous data retrieval.
  • Maintainability over time of the infrastructure implies important costs and technological complexity, without providing any solution to deal with the problem of error 404, just like for the web pages.
  • The level of knowledge required for the exploitation is also important, and today, another issue has arisen: to interrogate Wikidata is not to interrogate any sparql endpoint, the appropriation of the model finally takes as much time as to appropriate a new proprietary API.
  • All queries are not possible, the full text search is very limited or impossible because the technologies are not designed in this perspective.
  • Structural interoperability doesn't actually work, because not everyone uses the same ontology and even when they do, these ontologies are not necessarily used homogeneously.
Overcoming the limits

The data actually needs to be published according to its own nature, the possible uses and the intended users:

  • Simple CSV or Json / XML dumps
  • A simple API
  • A sparql end-point for the most advanced uses if resources are available to maintain it.

We should focus on simple and easy-to-use ontologies: in short schema.org to expose the data. Who has never wasted time trying to get their heads around the data.bnf.fr model, or getting lost in the maze of the british museum sparql endpoint with its data model strictly following the CIDOC-CRM?

Do we need this level of interoperability? We must face the facts: faced with an increasing mass of data, we must give up the idea of syntactical or structural interoperability through the use of a single model, be it for production, storage or exploitation within an Information System. However, it is still possible to provide some linking of the different bits of information, for example through the use of independent identifiers that are common to the whole information system. It does not mean that interoperability between organizations is a utopia, but it relies rather on interoperability of systems end-to-end via data processing, than on global interoperability in the storage of data.

Data management at the National Audiovisual Institute

It is still possible to envisage a global consistency of the different data of an organization without using semantic Web technologies, by deploying transverse data governance and designing the data models based on the logic of the data itself rather than on their use. In short, it is a matter of properly managing the data. The answer to this question is not only technical... This observation, along with this year-long experience with Semantic Web technologies, led us to the way we finally designed the new information system of the french national institute of audiovisual.

The main directions of our project are as follows:

  • Technically separate data from their usage by setting up a technical data storage and processing infrastructure independent of the business applications that use them;
  • Functionally separate data from their usage by managing all types of data handled by the institution, rethinking data models in relation to their logic and not their use and acknowledging that some data models are dedicated to production and storage while several other models are designed specifically for data publication.
  • Five types of databases are used in order to meet the storage needs of all types of data (structured, semi-structured and unstructured) and their exploitation:
    • A relational database
    • A document database
    • A graph database
    • A search engine.
    • A column store
  • A single, centralized infrastructure includes the five storage systems, the layer for processing and synchronizing data (the real core of the system and what actually ensures interoperability), and a dissemination layer in order to abstract the architecture from the business applications that use the data.

So currently, Semantic Web technologies are only used to retrieve and process the data from Wikidata so as to enrich our reference vocabularies for people and places. If the need arises and / or if there is a political intent, we can still consider exposing all or part of our data as Linked Data and through a sparql endpoint, but otherwise, we will prefer dumps in simple formats, to ensure greater data reuse. Thus, while being impregnated with all the reflection and the contributions resulting from the Semantic Web technologies, our project does not use them any more.

Les fantastiques futurs de l’intelligence artificielle

2019-12-12 Emmanuelle Bermès - Figoblog - Bibliothéconomie, Internet, événements, intelligence artificielle

La semaine dernière, j’ai eu la chance d’être invitée à me rendre à Stanford pour participer à la conférence Fantastic Futures, 2e du nom, un événement dont l’objectif était de faire émerger une communauté autour de l’intelligence artificielle pour les archives, les bibliothèques et les musées.

Spoiler : la communauté s’appelle AI4LAM, elle a un site web, des chaînes Slack et un groupe sur Google. Sinon, pour revoir la conférence, c’est par ici.

Cela ne vous aura pas échappé : l’intelligence artificielle est à la mode. On en parle à la radio, dans les journaux, des députés au style vestimentaire peu commun rédigent des rapports pour le Président de la République… et dans la communauté professionnelle, nous suivons le mouvement : voir par exemple la journée d’études du congrès de l’ADBU 2019 ou encore celle organisée hier à la BnF par l’ADEMEC (vidéos bientôt en ligne). Pourtant, si l’IA était une boîte de gâteaux, on pourrait écrire dessus « L’intelligence artificielle, innovante depuis 1956″…

Pour ma part, le sujet m’est pour ainsi dire tombé dessus, pour la 1e fois, quand on m’a invitée à participer aux Assises numériques du SNE en novembre 2017. Alors que nous préparions notre table-ronde, j’étais un peu dubitative sur ma participation, et j’ai été jusqu’à dire que de mon point de vue, la BnF n’utilisait pas encore en production de technologies d’intelligence artificielle. L’un des autres participants m’a alors dit « mais si ! l’OCR c’est déjà de l’intelligence artificielle ! » Et finalement, même si tout dépend de la définition (plus ou moins précise) que l’on en donne, ce n’est pas faux. Comme le disait Joanna Bryson à Stanford mercredi dernier, l’intelligence c’est la capacité à transformer une perception en action…

Que de chemin parcouru, pour moi, depuis 2017 !

En 2018, les explications de Yann Le Cun ont éclairé ma lanterne sur cette notion d’intelligence, de perception et ce qu’on appelle l’apprentissage (profond ou non, par machine ou pas !) L’exemple du Perceptron, sorte d’ancêtre de l’OCR, m’a permis de comprendre que mon manque supposé de familiarité avec l’intelligence artificielle relevait en fait d’un malentendu. Comme pour beaucoup de gens, l’intelligence artificielle évoquait pour moi une machine s’efforçant d’adopter des comportements plus ou moins proches de l’humain, l’un de ces comportements étant la capacité à « apprendre » comme le suggère le terme de « machine learning ».

???

Je me suis donc référée à Jean-Gabriel Ganascia pour tenter de désamorcer ces idées reçues et j’ai appris dans son opus daté de 2007 que la discipline informatique connue sous le nom d’ « intelligence artificielle » vise non pas à créer une machine dotée de toutes les facultés intellectuelles de l’humain, mais à reproduire de façon logique et mathématique certaines de ces facultés, de manière ciblée. Il y a autant de différence entre l’intelligence artificielle et l’humain qu’entre passer un OCR sur un texte et le lire…

Pendant que je plongeais dans ces découvertes, l’IA entrait bel et bien à la BnF, par la petite porte, celle de Gallica studio. Un peu plus tard, à la conférence Europeana Tech je (re)découvrais les rouages du prototype GallicaPix et obtenais encore d’autres exemples et explications avant d’en remettre une couche à LIBER 2018 (la répétition est l’essence de la pédagogie, n’est-ce pas…). Enfin, la première conférence Fantastic Futures était organisée en décembre 2018 à Oslo et inscrivait pour de bon l’IA sur notre agenda stratégique, à travers deux projets, l’un portant sur la fouille d’images dans Gallica dans la continuité de GallicaPix et l’autre sur la mise à disposition de collections-données pour les chercheurs dans le cadre du projet Corpus. J’ai même fini par intervenir sur le sujet dans un colloque organisé en octobre par les archives diplomatiques.

Me revoici donc en décembre 2019 à Stanford, prête à plonger dans le grand bain… Qu’ai-je retenu de ces 3 jours de conférence ?

D’une façon générale, cet événement fait apparaître l’idée que le sujet est encore assez jeune dans la communauté des bibliothèques, archives et musées. Alors qu’il existe une conviction solide et partagée que l’IA va transformer en profondeur la société, les méthodes de travail, et avoir un impact significatif sur nos institutions, la mise en pratique reste encore largement expérimentale.

Trois types d’acteurs ont néanmoins proposé une vision concrète, voire des réalisations effectives :

  • les acteurs de l’industrie, qui font état d’un déploiement déjà très avancé dans différents secteurs,
  • les acteurs de la recherche, qui multiplient les projets autour de données diverses, notamment celles des collections spécialisées qui se prêtent tout particulièrement à de telles expérimentations
  • enfin dans le domaine de la création artistique, à travers un artiste qui utilise l’IA dans le cadre d’une démarche d’interrogation sur la société et les rapports humains.

En termes de projets, deux types d’initiatives sont observables dans le domaine de l’IA pour les LAM.

En premier lieu, celles qui visent à mettre des données et collections numériques à disposition des chercheurs à des fins de fouille de texte et de données, en utilisant le machine learning. On peut citer par exemple le Lab de la Bibliothèque du Congrès qui a récemment obtenu un financement de la Mellon pour une expérimentation à grande échelle dans ce domaine. Certains de ces projets conduisent à développer des outils permettant aux chercheurs de s’approprier les modèles d’apprentissage ou des interfaces innovantes comme PixPlot, développé par le laboratoire d’humanités numériques de Yale, qui permet de manipuler des corpus de plusieurs milliers d’images que l’IA regroupe par similarité.

À l’exemple du prototype « Nancy » de la Bibliothèque Nationale de Norvège, d’autres projets visent en revanche l’automatisation de tâches actuellement réalisées manuellement par les bibliothécaires. Toutefois, Nancy reste une initiative expérimentale qui, si elle démontre efficacement les apports potentiels de l’IA pour le traitement des collections, serait très difficile voire impossible à industrialiser telle quelle sur la production courante. De même, les projets de traitement des collections du IA studio de la bibliothèque de Stanford, l’un d’eux portant sur une collection de romans du 19e s. numérisés mais non catalogués, s’attachent au traitement d’un corpus clos et bien défini et sont en réalité hybrides avec la catégorie précédente, car ils mobilisent également des chercheurs au travers de projets ciblés.

Pour finir, je retiendrai un certain nombre de thématiques phares qui sont revenues à plusieurs reprises, aussi bien dans la conférence elle-même que dans les workshops ou la « unconference » :

  • Les questions éthiques, bien connues en dehors de notre communauté mais abordées ici avec l’idée que des institutions publiques comme les bibliothèques pourraient devenir un acteur important pour porter cet enjeu au regard de l’industrie. L’idée de doter les projets d’un “plan de gestion éthique” comme on a des “plans de gestion des données” a émergé pendant le workshop que je co-animais.
  • Les enjeux de qualité des données, avec là aussi l’idée que les bibliothèques ont un savoir-faire qu’elles pourraient mobiliser pour apporter à l’industrie des jeux de données de qualité pour l’entraînement du machine learning.
  • Le développement d’interfaces graphiques, nécessaires pour comprendre les IA, les manipuler et interpréter les résultats (cf. PixPlot ci-dessus)
  • La formation, avec notamment l’exemple finlandais : l’IA est un enjeu global de société et chacun devrait pouvoir se former pour comprendre ce dont il s’agit. A cette fin, un cours en ligne a été mis en place, visant 1% de la population du pays. Une extension internationale du projet est en cours, avec sa traduction dans les différentes langues de l’Union Européenne.
  • Enfin les outils, données et modèles, avec un enjeu d’échanges et de mutualisation au sein de la communauté et un focus sur les documents spécialisés (manuscrits, images et cartes notamment, mais aussi son et vidéo). Le lien de ces problématiques avec IIIF a été constamment mis en avant.

Nous nous sommes quittés après 3 jours riches et intenses sur l’annonce de la création de la communauté AI4LAM que j’ai mentionnée plus haut. Et mon petit doigt me dit que mes futurs n’ont pas fini d’être fantastiques… Prochaine étape le 3 février dans le cadre du séminaire DHAI de l’ENS, où Jean-Philippe et moi présenterons les deux initiatives phares de la BnF dans ce domaine.

2019-12-09

ceci est un essai

un nouvel essai, juste pour voir. Et pas de petits carrés indésirables...... Lire ceci est un essai

2019-12-05

RFC 8674: The "safe" HTTP Preference

Ce nouveau RFC définit une nouvelle préférence qu'un client HTTP peut envoyer au serveur. « safe » (sûr) indique que le client ne souhaite pas recevoir du contenu qu'il trouve contestable.

Je vous arrête tout de suite : vous allez me demander « mais qui définit du contenu contestable ? Ça dépend des gens » et, je vous rassure, l'auteur du RFC a bien vu le problème. La préférence safe est juste une possibilité technique, le RFC ne définit pas ce qui est sûr et ce qui ne l'est pas, cela devra se faire dans un autre cadre, une discussion à ce sujet serait bien trop casse-gueule pour l'IETF. En pratique, le résultat de l'utilisation de cette préférence dépendra de bien des choses, comme la politique du serveur (le RFC dit « the cultural context of the site »), et une éventuelle relation pré-existante entre le serveur et un utilisateur particulier. Le RFC donne quand même une indication : safe peut vouloir dire « adapté aux mineurs ».

Il y a manifestement une demande, puisque bien des sites Web ont un mode « sûr », où on peut sélectionner « je ne veux pas voir des choses que je n'aime pas ». Notez que, dans ces cas, la définition de ce qui est sûr ou pas dépend du site Web. S'ils est géré aux États-Unis, « sûr » sera sans doute « aucune nudité humaine », en Arabie saoudite, « aucune femme visible », etc. Ce mode « sûr » des sites Web n'est pas pratique pour l'utilisateurice, car il nécessite de sélectionner l'option pour chaque site, et de se créer un compte, soit explicite, soit implicite via les cookies (RFC 6265). À moins que le mode « sûr » soit le mode par défaut et, dans ce cas, ce sont les gens qui n'en voudront pas qui auront du travail. D'où l'idée, très controversée à l'IETF, de configurer cela dans le navigateur Web (ou bien dans le système d'exploitation, pour que tous les clients HTTP le fassent), qui va indiquer au serveur les préférences (un peu comme le Do Not Track, dont on sait qu'il est largement ignoré par les sites Web). La technique utilisée est celle des préférences HTTP, normalisées dans le RFC 7240, préférences dont je rappelle que leur respect par le serveur est optionnel. La préférence safe envoyée par le client est donc à prendre comme un appel à « faire au mieux » et « je te fais confiance pour la définition de "sûr" », pas plus.

La section 2 de notre RFC est plus concrète, présentant la syntaxe exacte de safe. Voici un exemple de requête HTTP exprimant cette préférence :

GET /foo.html HTTP/1.1
Host: www.example.org
User-Agent: ExampleBrowser/1.0
Prefer: safe
  
La préférence est enregistrée à l'IANA. Le RFC impose que les requêtes « sûres » soient faites en HTTPS, pour éviter la surveillance spécifique des gens qui demandent du safe (et qui peuvent être des enfants), et pour éviter qu'un intermédiaire ne bricole la requête, ajoutant ou enlevant cette préférence. Une réponse possible à la requête ci-dessus serait :
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/html
Preference-Applied: safe
Server: ExampleServer/2.0
Vary: Prefer  
  
Le Vary: (RFC 7231, section 7.1.4) indique aux relais/caches intermédiaires qu'ils doivent tenir compte de la valeur de Prefer: avant de renvoyer la page mémorisée à un autre client.

Si vous voulez tester en vrai, la page https://www.bortzmeyer.org/apps/porn vous renverra un contenu différent selon que vous envoyez l'en-tête Prefer: safe ou pas. Voici un exemple avec curl :

%  curl --header "Prefer: safe" https://www.bortzmeyer.org/apps/porn
  
Le code est du Python/WSGI et se résume à :
    
def porn(start_response, environ):
    # Apache/WSGI always give us one Prefer: header even if the client sent several.
    preferences = re.split("\s*,\s*", environ['HTTP_PREFER'])
    safe = False
    for pref in preferences:
        if pref.lower() == 'safe':
            safe = True
            break
    begin = """<html><head>..."""
    end = """</body></html>"""
    safe_content = """<p>Safe ..."""
    unsafe_content = """<p>Unsafe ..."""
    if safe:
        output = begin + safe_content + end
    else:
        output = begin + unsafe_content + end
    status = '200 OK'
    response_headers = [('Content-type', 'text/html'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
    return [output]

  

Cette préférence semble répondre à une forte demande, puisqu'elle est déjà reconnue :

La section 3 du RFC rassemble quelques informations de sécurité :

  • HTTPS est indispensable, sinon un intermédiaire pourra ajouter (ou retirer) la préférence safe,
  • Paradoxalement, safe peut être dangereux puisqu'il transmet une information supplémentaire au serveur, aidant au fingerprinting,
  • On n'a évidemment aucune garantie que le serveur a bien adapté le niveau du contenu à ce qu'on voulait. Le RFC fait même remarquer qu'un serveur sadique pourrait envoyer du contenu « pire » lorsque la préférence safe est présente.

Enfin, l'annexe A donne quelques conseils aux auteurs de navigateurs quant à la mise en œuvre de cette préférence. L'UI n'est pas évidente. Il est crucial de ne pas donner à l'utilisateur ou l'utilisatrice l'impression que cette préférence fournirait des garanties. Le RFC suggère un texte plus prudent pour une case à cocher « Demander du contenu "sûr" aux sites Web ». Et l'annexe B a des conseils pour les gérants de sites Web comme, par exemple, ne pas permettre aux utilisateurs de demander (via leur profil, par exemple) d'ignorer la préférence safe puisqu'elle a pu être placée par un logiciel de contrôle parental.

Ce RFC a le statut « pour information » et a été publié sur la voie indépendante (cf. RFC 5742) puisqu'il n'a pas fait l'objet d'un consensus à l'IETF (euphémisme…) Les principales objections étaient :

  • « Sûr » n'a pas de définition précise et universelle, le terme est vraiment trop vague,
  • Les navigateurs Web envoient déjà beaucoup trop d'informations aux serveurs, en ajouter une, qui pourrait, par exemple, permettre de cibler les mineurs, n'est pas forcément une bonne idée.

2019-11-28

RFC 8689: SMTP Require TLS Option

Ah, la sécurité, c'est toujours compliqué. Pour le courrier électronique, par exemple, SMTP peut être fait sur TLS, pour garantir la confidentialité et l'intégrité du message. Mais TLS est optionnel. Cela entraine deux problèmes : si la politique du MTA est laxiste, le message risque de passer en clair à certains moments, et si elle est stricte, le message risque d'être rejeté alors que l'expéditeur aurait peut-être préféré qu'il passe en clair. Ce nouveau RFC fournit deux mécanismes, un pour exiger du TLS à toutes les étapes, un au contraire pour demander de la bienveillance et de la tolérance et d'accepter de prendre des risques.

SMTP (RFC 5321) a une option nommée STARTTLS (normalisée dans le RFC 3207), qui permet, si le pair en face l'accepte, de passer la session SMTP sur TLS, assurant ainsi sa sécurité. STARTTLS a plusieurs problèmes, notamment son caractère optionnel. Même avec des sessions SMTP entièrement TLS (sans STARTTLS, cf. RFC 8314), le problème demeure. Que doit faire un MTA s'il ne peut pas lancer TLS, parce que le MTA en face ne l'accepte pas, ou parce que son certificat est invalide (RFC 6125) ou encore car DANE (RFC 7672) est utilisé et que le certificat ne correspond pas ? Jusqu'à présent, la décision était prise par chaque MTA et, comme SMTP repose sur le principe du relayage, l'émetteur original ne pouvait pas exprimer ses préférences, entre « je suis parano, j'ai lu le bouquin de Snowden, j'exige du TLS tout le temps » et « je m'en fous, je suis inconscient, je crois que je n'ai rien à cacher, je veux que le message soit envoyé, même en clair ». La politique des serveurs SMTP était typiquement de privilégier la distribution du message plutôt que sa sécurité. Désormais, il possible pour l'émetteur de donner ses préférences : l'option SMTP REQUIRETLS permet d'exiger du TLS tout le temps, et l'en-tête TLS-Required: (bien mal nommé) permet d'indiquer qu'on préfère au contraire la délivrance du message à sa sécurité.

En général, aujourd'hui, les MTA acceptent d'établir la session TLS, même si le certificat est invalide. En effet, dans le cas contraire, peu de messages seraient livrés, les certificats dans le monde du courrier étant fréquemment invalides, à l'opposé de ce qui se passe dans le monde du Web, où les navigateurs sont bien plus stricts. Pour durcir cette politique par défaut, et aussi parce qu'un attaquant actif peut retirer l'option STARTTLS et donc forcer un passage en clair, il existe plusieurs mécanismes permettant de publier une politique, comme DANE (RFC 7672) et MTA-STS (RFC 8461). Mais elles sont contrôlées par le récepteur, et on voudrait permettre à l'émetteur de donner son avis.

Commençons par REQUIRETLS, l'extension SMTP. (Désormais dans le registre IANA des extensions SMTP.) Il s'agit pour l'émetteur d'indiquer qu'il ne veut pas de laxisme : il faut du TLS du début à la fin, et, évidemment, avec uniquement des certificats valides. En utilisant cette extension, l'émetteur indique qu'il préfère que le message ne soit pas distribué, plutôt que de l'être dans de mauvaises conditions de sécurité. Cette extension peut être utilisée entre deux MTA, mais aussi quand un MUA se connecte au premier MTA, pour une soumission de message (RFC 6409). Voici un exemple (« C: » = envoyé par le client, « S: » = envoyé par le serveur) :


S: 220 mail.example.net ESMTP
C: EHLO mail.example.org
S: 250-mail.example.net Hello example.org [192.0.2.1]
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-REQUIRETLS
C: MAIL FROM:<roger@example.org> REQUIRETLS
S: 250 OK
C: RCPT TO:<editor@example.net>
S: 250 Accepted
C: DATA
S: 354 Enter message, ending with "." on a line by itself

(Le message)
C: .
S: 250 OK
C: QUIT    

  
(Le lecteur ou la lectrice astucieux aura remarqué qu'il y a un piège, le risque qu'un attaquant actif ne retire le REQUIRETLS du client ou bien du serveur. Ce cas est traité plus loin.)

Dans l'exemple ci-dessus, le serveur a annoncé qu'il savait faire du REQUIRETLS, et le client a demandé à ce que l'envoi depuis roger@example.org soit protégé systématiquement par TLS. Cela implique que pour toutes les sessions SMTP suivantes :

  • L'enregistrement MX soit résolu en utilisant DNSSEC (ou alors on utilise MTA-STS, RFC 8461),
  • Le certificat soit valide et soit authentifié par une AC ou par DANE,
  • Le serveur suivant doit accepter la consigne REQUIRETLS (on veut une chaîne complète, de l'émetteur au récepteur).
Puisque l'idée est d'avoir du TLS partout, cela veut dire qu'un MTA qui reçoit un message marqué REQUIRETLS doit noter cette caractéristique dans sa base et s'en souvenir, puisqu'il devra passer cette exigence au serveur suivant.

Si le serveur en face ne sait pas faire de REQUIRETLS (ou, pire, pas de TLS), l'émetteur va créer une erreur commençant par 5.7 (les erreurs SMTP étendues sont décrites dans le RFC 5248) :

REQUIRETLS not supported by server: 5.7.30 REQUIRETLS needed    
  

Et l'en-tête TLS-Required: ? (Ajouté dans le registre IANA des en-têtes.) Il fait l'inverse, il permet à l'émetteur de spécifier qu'il préfère la distribution du message à la sécurité, et qu'il faut donc débrayer les tests qu'on pourrait faire. Ce nom de TLS-Required: est mal choisi, car cet en-tête ne peut prendre qu'une seule valeur, no (non), comme dans cet exemple amusant du RFC :


From: Roger Reporter <roger@example.org>
To: Andy Admin <admin@example.com>
Subject: Certificate problem?
TLS-Required: No
Date: Fri, 18 Jan 2019 10:26:55 -0800

Andy, there seems to be a problem with the TLS certificate
on your mail server. Are you aware of this?

    Roger

  

Si l'en-tête est présent, le serveur doit être plus laxiste que d'habitude et accepter d'envoyer le message même s'il y a des problèmes TLS, même si la politique normale du serveur serait de refuser. Bien sûr, TLS-Required: no n'interdit pas d'utiliser TLS, si possible, et l'émetteur doit quand même essayer. Notez aussi que les MTA sont libres de leur politique et qu'on peut parfaitement tomber sur un serveur SMTP qui refuse de tenir compte de cette option, et qui impose TLS avec un certificat correct, même en présence de TLS-Required: no.

(Le lecteur ou la lectrice astucieux aura remarqué qu'il y a un piège, le risque qu'un attaquant actif n'ajoute TLS-Required: no. Ce cas est traité plus loin.)

Ah, et si on a les deux, REQUIRETLS et TLS-Required: no ? La section 4.1 du RFC couvre ce cas, en disant que la priorité est à la sécurité (donc, REQUIRETLS).

La section 5 de notre RFC couvre le cas des messages d'erreur générés par un MTA lorsqu'il ne peut pas ou ne veut pas envoyer le message au MTA suivant (ou au MDA). Il fabrique alors un message envoyé à l'expéditeur (bounce, en anglais, ou message de non-distribution). Ce message contient en général une bonne partie, voire la totalité du message original. Sa confidentialité est donc aussi importante que celle du message original. Si celui-ci était protégé par REQUIRETLS, le courrier d'erreur doit l'être aussi. Le MTA qui génère ce courrier d'erreur doit donc lui-même activer l'extension REQUIRETLS. (Notez que, comme le chemin que suivra cet avis de non-remise ne sera pas forcément le même que celui suivi par le message originel, s'il y a un serveur non-REQUIRETLS sur le trajet, le courrier d'erreur ne sera pas reçu.)

Si un logiciel ré-émet un message (par exemple un gestionnaire de liste de diffusion transmettant aux membres de la liste, cf. RFC 5598), il devrait, idéalement, appliquer également le REQUIRETLS sur le message redistribué. Le RFC ne l'impose pas car, en pratique, cela risquerait d'empêcher la réception du message par beaucoup.

Notre RFC se termine par une longue section 8 sur la sécurité, car les problèmes qu'essaie de résoudre ces solutions sont complexes. Le cas des attaques passives est facile : TLS protège presque parfaitement contre elles. Mais les attaques actives soulèvent d'autres questions. REQUIRETLS mènera à un refus des connexions SMTP sans TLS, protégeant ainsi contre certaines attaques actives comme le SSL stripping ou comme une attaque de l'Homme du Milieu avec un mauvais certificat. (Cette dernière attaque est facile aujourd'hui dans le monde du courrier, où bien des serveurs SMTP croient aveuglément tout certificat présenté.) REQUIRETLS protège également contre beaucoup d'attaques via le DNS, en exigeant DNSSEC (ou, sinon, MTA-STS).

Par contre, REQUIRETLS ne protège pas contre un méchant MTA qui prétendrait gérer REQUIRETLS mais en fait l'ignorerait. De toute façon, SMTP sur TLS n'a jamais protégé des MTA intermédiaires, qui ont le texte du message en clair. Si on veut se protéger contre un tel MTA, il faut utiliser PGP (RFC 4880) ou équivalent. (Par contre, le risque de l'ajout d'un TLS-Required: no par un MTA malveillant ne semble pas traité dans le RFC ; PGP ne protège pas contre cela.)

Il peut y avoir un conflit entre TLS-Required: no et la politique du MTA, qui tient absolument à vérifier les certificats des serveurs auxquels il se connecte, via PKIX ou via DANE. Le RFC laisse entendre que le dernier mot devrait revenir à l'expéditeur, au moins si le message a été envoyé via TLS et donc pas modifié en route. (Le cas d'un message reçu en clair - donc pas sécurisé - et demandant de ne pas exiger TLS reste ouvert…)

Et pour finir, l'exemple de session SMTP où le serveur annonçait qu'il gérait REQUIRETLS (en disant 250-REQUIRETLS) était simplifié. Si la session commençait en clair, puis passait à TLS après, avec la commande STARTTLS, le client doit recommencer la session une fois TLS activé, pour être sûr que ce qu'annonce le serveur est réel.

Bien qu'il y ait déjà des programmeurs ayant travaillé sur ce RFC, je ne trouve encore rien du tout dans le source de Postfix, le MTA que j'utilise, même dans la version expérimentale.

2019-11-22

Pourquoi ne pas mélanger résolveur DNS et serveur DNS faisant autorité ?

Je donne souvent le conseil de ne pas configurer un serveur DNS à la fois en résolveur et en serveur faisant autorité. Mais pourquoi, au juste ?

D'abord, fixons la terminologie. Parler de « serveur DNS » tout court (ou, encore pire de « DNS » pour désigner un serveur, du genre « pour être sûr que la NSA ait mes données, j'utilise 8.8.8.8 comme DNS ») est générateur de confusion. En effet, les deux types de serveurs DNS, résolveurs et serveurs faisant autorité sont très différents, posent des questions bien diverses, et il est rare qu'on ait besoin de parler des deux ensemble. Quand quelqu'un écrit ou dit « serveur DNS », il s'agit en général de l'un ou de l'autre type, et cela vaudrait donc la peine de le préciser. Les termes de résolveur et de serveur faisant autorité sont bien définis dans le RFC 8499 mais il est sans doute utile de rappeler ces définitions et quelques explications ici :

  • Un résolveur (en anglais resolver) est un serveur DNS qui ne connait presque rien au démarrage, mais qui va interroger, pour le compte du client final, d'autres serveurs jusqu'à avoir une réponse qu'il transmettra au client final. Dans une configuration typique, le résolveur que vous utilisez est géré par votre FAI ou bien par le service informatique de l'organisation où vous travaillez. (Il existe aussi des résolveurs publics, comme ceux de Cloudflare ou de Quad9.)
  • Un serveur faisant autorité (en anglais authoritative server, parfois bêtement traduit par « serveur autoritaire ») connait (« fait autorité pour ») une ou plusieurs zones DNS et il sert l'information sur ces zones aux résolveurs qui l'interrogeront. Il est typiquement géré par un hébergeur DNS ou par le bureau d'enregistrement ou directement par le titulaire du nom de domaine.
Par exemple, au moment de la rédaction de cet article, je suis dans un train, avec le Wi-Fi, et le résolveur annoncé est 10.26.0.4, une machine gérée par la SNCF. Si je veux me connecter à celsa.fr, ma machine demandera au résolveur 10.26.0.4, qui relaiera aux deux serveurs faisant autorité, ns0.idianet.net et ns1.idianet.net (Idianet étant l'hébergeur DNS choisi par le CELSA), puis me retransmettra leur réponse.

La plupart des logiciels permettant de faire un serveur DNS ne permettent de faire qu'un résolveur, ou bien qu'un serveur faisant autorité. Comme je l'ai dit, c'est logique puisque ce sont deux fonctions très différentes, avec des problèmes bien distincts :

  • Le serveur faisant autorité est public (s'il est interne à une organisation, la question de la séparation entre résolveur et serveur faisant autorité est différente), donc il doit faire face à un Internet pas toujours sympathique,
  • Le résolveur, lui, est privé (il est déconseillé d'avoir des résolveurs ouverts, sauf si on est Google et qu'on sait ce qu'on fait, cf. RFC 5358),
  • Le serveur faisant autorité a des temps de réponse connus, et une consommation de mémoire stable,
  • Le résolveur, lui, ne sait pas à l'avance combien de temps prendront les requêtes, et il peut avoir à allouer des ressources variables,
  • Et, bien sûr, le serveur faisant autorité connait exactement les données, alors que le résolveur les obtient de l'extérieur, ce qui diminue la confiance qu'on peut leur accorder.
Mais certains logiciels (comme BIND) permettent d'assurer les deux fonctions, et en même temps. Certains administrateurs système ont donc configuré une machine où le même démon est résolveur et serveur faisant autorité. C'est une mauvaise idée, et ces administrateurs système ont tort. Pourquoi ?

Le principal problème pratique est de débogage. En effet, si le même serveur DNS est à la fois résolveur et serveur faisant autorité, les réponses reçues par un client DNS peuvent être issues du résolveur ou directement des zones DNS gérées. Normalement, avec un logiciel bien fait, les données faisant autorité auront toujours priorité (c'est bien ce que veut dire « faire autorité ») et les données issues de la résolution ne les remplaceront jamais. C'est ainsi que se comporte BIND aujourd'hui, mais cela n'a pas toujours été le cas, et ce n'est toujours pas le cas pour d'autres logiciels. On voit ainsi parfois des données récupérées lors du processus de résolution (et donc moins fiables, surtout lors d'attaques type empoisonnement de cache) masquer les données faisant autorité.

La seconde raison pour laquelle le mélange est une mauvaise idée est plus abstraite : les deux fonctions, résolveur et autorité, sont très différentes conceptuellement, et beaucoup de problèmes pratiques avec le DNS viennent d'une ignorance des acteurs (pas seulement les utilisateurs, même les administrateurs systèmes et réseaux) de ces deux fonctions, de leur rôle respectif, et des problèmes pratiques auxquelles elles font face.

Enfin, pour les programmeurs, on notera que, si ces deux fonctions ont du code en commun (encodage et décodage des requêtes et réponses, par exemple, et qui peut donc avoir intérêt à être dans une bibliothèque commune), l'essentiel du programme est différent. Ainsi, un serveur faisant autorité est sans état : il peut répondre aux questions immédiatement, il ne dépend de personne d'autre, et peut donc travailler de manière synchrone. Le résolveur, lui, est forcément avec état car il doit mémoriser les requêtes en cours de résolution, résolution dont la durée dépend des serveurs faisant autorité extérieurs. Si vous voulez essayer, notez qu'écrire un serveur faisant autorité est un projet relativement simple, alors qu'un résolveur est beaucoup plus compliqué (notamment du point de vue de la sécurité). Contrairement au serveur faisant autorité, il dépend fortement de serveurs extérieurs. (Comme une partie du code est quand même commune, une bonne architecture est celle de Knot : le serveur faisant autorité et le résolveur partagent la même bibliothèque libknot pour certaines fonctions de base mais, autrement, ce sont deux logiciels très différents.)

Pour finir, voici un exemple de la différence entre les réponses fournies par un résolveur (127.0.0.1, ma machine locale, je ne suis plus dans le train), et celles fournies par un serveur faisant autorité pour la zone en question (ns0.idianet.net). D'abord, le résolveur :

    
% dig A celsa.fr                      

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> A celsa.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53605
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;celsa.fr.		IN A

;; ANSWER SECTION:
celsa.fr.		83049 IN A 195.154.244.151

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Nov 19 20:09:28 CET 2019
;; MSG SIZE  rcvd: 53

  
La réponse ne fait pas autorité (il n'y a pas de flag AA - Authoritative Answer), et le TTL a été décrémenté depuis sa valeur originale (l'information a été tirée de la mémoire du résolveur). Maintenant, la réponse d'un serveur faisant autorité :
    
% dig @ns0.idianet.net A celsa.fr     

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @ns0.idianet.net A celsa.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3519
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;celsa.fr.		IN A

;; ANSWER SECTION:
celsa.fr.		86400 IN A 195.154.244.151

;; AUTHORITY SECTION:
celsa.fr.		86400 IN NS ns0.idianet.net.
celsa.fr.		86400 IN NS ns1.idianet.net.

;; ADDITIONAL SECTION:
ns0.idianet.net.	86400 IN A 195.154.201.10
ns1.idianet.net.	86400 IN A 195.154.244.138

;; Query time: 4 msec
;; SERVER: 195.154.201.10#53(195.154.201.10)
;; WHEN: Tue Nov 19 20:09:34 CET 2019
;; MSG SIZE  rcvd: 132

  
Cette fois, la réponse fait autorité (flag AA) et le TTL est la valeur originale (ici, une journée). On notera également le temps de réponse plus court du résolveur, puisqu'ici, l'information était déjà dans sa mémoire. Si le résolveur avait été « froid » (pas d'information en mémoire), le temps de réponse aurait été plus long, et le TTL aurait eu sa valeur originale (car l'information venait juste d'être récupérée).

En conclusion, il est recommandé de séparer les deux fonctions, de résolveur et de serveur faisant autorité. Même si ça semble marcher lors de la mise en service, mélanger les deux fonctions vous vaudra des maux de tête plus tard, lorsqu'un problème surviendra.

RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record

Ce RFC décrit un mécanisme pour renforcer un peu la sécurité des certificats. Il normalise les enregistrements CAA (Certification Authority Authorization), qui sont publiés dans le DNS, et indiquent quelles AC sont autorisées à émettre des certificats pour ce domaine. Le but est de corriger très partiellement une des plus grosses faiblesses de X.509, le fait que n'importe quelle AC peut émettre des certificats pour n'importe quel domaine, même si ce n'est pas un de ses clients. Ce RFC remplace l'ancienne définition de CAA, qui était dans le RFC 6844.

CAA est donc une technique très différente de DANE (RFC 6698), les seuls points communs étant l'utilisation du DNS pour sécuriser les certificats. DANE est déployé chez le client TLS, pour qu'il vérifie le certificat utilisé, CAA est surtout dans l'AC, pour limiter le risque d'émission d'un certificat malveillant (par exemple, CAA aurait peut-être empêché le faux certificat Gmail du ministère des finances.) Disons que CAA est un contrôle supplémentaire, parmi ceux que l'AC doit (devrait) faire. Les clients TLS ne sont pas censés le tester (ne serait-ce que parce que l'enregistrement CAA a pu changer depuis l'émission du certificat, la durée de vie de ceux-ci étant en général de plusieurs mois). CAA peut aussi servir à des auditeurs qui veulent vérifier les pratiques d'une AC (même avertissement : le certificat a pu être émis alors que l'enregistrement CAA était différent.)

La section 4 de notre RFC présente l'enregistrement CAA. Il a été ajouté au registre des types d'enregistrements sous le numéro 257. Il comprend une série d'options (flags) et une propriété qui est sous la forme {clé, valeur}. Un nom peut avoir plusieurs propriétés. Pour l'instant, une seule option est définie (un registre existe pour les options futures), « issuer critical » qui indique que cette propriété est cruciale : si on ne la comprend pas, le test doit être considéré comme ayant échoué et l'AC ne doit pas produire de certificat.

Les principales propriétés possibles sont (la liste complète est dans le registre IANA) :

  • issue, la principale, qui indique une AC autorisée à émettre des certificats pour ce domaine (l'AC est indiquée par son nom de domaine),
  • issuewild, idem, mais avec en plus la possibilité pour l'AC d'émettre des certificats incluants des jokers,
  • iodef, qui indique où l'AC doit envoyer d'éventuels rapports d'échec, pour que le titulaire du nom de domaine puisse les corriger. Un URL est indiqué pour cela, et le rapport doit être au format IODEF (RFC 7970).
Voici par exemple quel était l'enregistrement CAA de mon domaine personnel :

% dig CAA bortzmeyer.org
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61450
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 7, ADDITIONAL: 7
...
;; ANSWER SECTION:
bortzmeyer.org.		26786 IN CAA 0 issue "cacert.org"
bortzmeyer.org.		26786 IN CAA 0 issuewild "\;"
...

  
Il indique que seule l'AC CAcert peut créer un certificat pour ce domaine (et sans les jokers). Bon, c'est un peu inutile car CAcert ne teste pas les enregistrements CAA, mais c'était juste pour jouer. Je n'ai pas mis d'iodef mais il aurait pu être :
bortzmeyer.org. CAA 0 iodef "mailto:security@bortzmeyer.org"
  
Et, dans ce cas, l'AC peut écrire à security@bortzmeyer.org, avec le rapport IODEF en pièce jointe.

Attention, l'enregistrement CAA est valable pour tous les sous-domaines (et ce n'est pas une option,contrairement à, par exemple, HSTS du RFC 6797, avec son includeSubDomains). C'est pour cela que j'avais dû retirer l'enregistrement ci-dessus, pour avoir des certificats pour les sous-domaines, certificats faits par une autre AC. (Depuis, j'ai mis deux enregistrements CAA, pour les deux AC utilisées, les autorisations étant additives, cf. section 4.2 du RFC.)

Des paramètres peuvent être ajoutés, le RFC cite l'exemple d'un numéro de client :

example.com.   CAA 0 issue "ca.example.net; account=230123" 
  

Une fois les enregistrements CAA publiés, comment sont-ils utilisés (section 3) ? L'AC est censée interroger le DNS pour voir s'il y a un CAA (on note que DNSSEC est très recommandé, mais n'est pas obligatoire, ce qui réduit le service déjà faible qu'offre CAA). S'il n'y en a pas, l'AC continue avec ses procédures habituelles. S'il y a un CAA, deux cas : il indique que cette AC peut émettre un certificat pour le domaine, et dans ce cas-là, c'est bon, on continue avec les procédures habituelles. Second cas, le CAA ne nomme pas cette AC et elle doit donc renoncer à faire un certificat sauf s'il y a une exception configurée pour ce domaine (c'est la deuxième faille de CAA : une AC peut facilement passer outre et donc continuer émettre de « vrais/faux certificats »).

Notez que le RFC ne semble pas évoquer la possibilité d'imposer la présence d'un enregistrement CAA. C'est logique, vu le peu de déploiement de cette technique mais cela veut dire que « qui ne dit mot consent ». Pour la plupart des domaines, la vérification du CAA par l'AC ne changera rien.

Notez que, si aucun enregistrement CAA n'est trouvé, l'AC est censé remonter l'arbre du DNS. (C'est pour cela que SSL [sic] Labs trouvait un enregistrement CAA pour mercredifiction.bortzmeyer.org : il avait utilisé le CAA du domaine parent, bortzmeyer.org.) Si example.com n'a pas de CAA, l'AC va tester .com, demandant ainsi à Verisign si son client peut avoir un certificat et de qui. Cette erreur consistant à grimper sur l'arbre avait déjà été dénoncée dans le RFC 1535, mais apparemment la leçon n'a pas été retenue. Au moins, ce RFC corrige une grosse erreur du RFC 6844, en limitant cette montée de l'arbre au nom initialement cherché, et pas aux alias (enregistrements DNS CNAME) éventuels.

Enfin, la section 5 du RFC analyse les différents problèmes de sécurité que peut poser CAA :

  • Le respect de l'enregistrement CAA dépend de la bonne volonté de l'AC (et CAA ne remplace donc pas DANE),
  • Sans DNSSEC, le test CAA est vulnérable à des attaques par exemple par empoisonnement (le RFC conseille de ne pas passer par un résolveur normal mais d'aller demander directement aux serveurs faisant autorité, ce qui ne résout pas le problème : le programme de test peut se faire empoisonner, lui aussi, d'autant plus qu'il prend sans doute moins de précautions qu'un résolveur sérieux),
  • Et quelques autres risques plus exotiques.

Le CA/Browser Forum avait décidé que le test des CAA serait obligatoire à partir du 8 septembre 2017. (Cf. la décision.) Comme exemple, parmi les enregistrements CAA dans la nature, on trouve celui de Google, qui autorise deux AC :


% dig CAA google.com
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55244
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
google.com.		86400 IN CAA 0 issue "pki.goog"
google.com.		86400 IN CAA 0 issue "symantec.com"
...

  
(Le TLD .goog est apparemment utilisé par Google pour son infrastructure, .google étant plutôt pour les choses publiques.) Notez que gmail.com, souvent détourné par des gouvernements et des entreprises qui veulent surveiller le trafic, a également un enregistrement CAA. Le célèbre SSL [sic] Labs teste la présence d'un enregistrement CAA. S'il affiche « DNS Certification Authority Authorization (CAA) Policy found for this domain », c'est bon. Regardez le cas de Google.

Quelques lectures et ressources pour finir :

La section 7 de ce RFC décrit les changements depuis le RFC 6844. Sur la forme, le RFC a été profondément réorganisé. Sur le fond, le principal changement est que la procédure de montée dans l'arbre du DNS, très dangereuse, a été légèrement sécurisée en la limitant au nom lui-même, et pas aux alias. En effet, le RFC 6844 prévoyait que, si on cherchait le CAA de something.example.com, qu'on ne le trouvait pas, et que something.example.com était en fait un alias vers other.example.net, on remonte également l'arbre en partant de example.net. Cette idée a été heureusement abandonnée (mais, pour something.example.com, on testera quand même example.com et .com, donc le registre de .com garde la possibilité de mettre un CAA qui s'appliquera à tous les sous-domaines…)

Autre changement, la section 6, sur les questions de déploiement, qui intègre l'expérience pratique obtenue depuis le RFC 6844. Notamment :

  • Certaines middleboxes boguées (pléonasme) bloquent les requêtes des types DNS inconnus et, apparemment, ne sont mises à jour que tous les vingt ans donc CAA est encore considéré comme inconnu,
  • Certains serveurs faisant autorité sont programmés avec les pieds et répondent mal pour les types de données DNS qu'ils ne connaissent pas (ce n'est évidemment pas le cas des logiciels libres sérieux comme BIND, NSD, Knot, PowerDNS, etc.)

Le reste des changements depuis le RFC 6844 porte sur des points de détails comme une clarification de la grammaire, ou bien des précisions sur la sémantique des enregistrements CAA lorsque des propriétés comme issue sont absentes.

2019-11-21

Flattr sur mon blog

Si vous regardiez attentivement en bas des pages de ce blog, il y avait un bouton Flattr. Pourquoi ? À quoi servait-il ?

Un des problèmes les plus difficiles du Web est la rémunération des créateurs. Cette rémunération est importante, non pas que je craigne que le Web diminue dramatiquement de taille si on ne payait pas les créateurs (la plupart ne sont pas payés aujourd'hui et le Web est quand même très gros) mais parce que je trouve que c'est une question de justice : créer du contenu intéressant prend du temps, de la compétence et des efforts, et il est normal d'avoir une rémunération pour cela. Aujourd'hui, quelles sont les possibilités de rémunération pour un blogueur ? Il y en a plusieurs, que certains blogueurs combinent. (Je parle du point de vue du blogueur car c'est celui que je connais bien mais la presse en ligne, par exemple, a un problème très proche, regardez ce que propose reflets.info.)

  • Il peut faire cela le soir en dehors du temps de travail. Cela limite évidemment la quantité et la qualité de la production : le soir, les prolétaires sont fatigués.
  • Il peut avoir un patron compréhensif, voire encourageant, qui le laisse bloguer pendant le travail, ou même le paie pour cela. C'est évidemment fragile car l'employeur peut changer d'avis.
  • Il peut trouver un mécène, un riche qui va donner de l'argent à une association ou une personne pour leur permettre de bloguer. Cela ne va pas forcément dans le sens de l'indépendance du blogueur...
  • Il peut être un riche oisif, à qui un héritage non mérité permet de bloguer sans travailler. Le principal problème est qu'il faut une vieille tante riche sans enfants.
  • Il peut mettre de la publicité sur son blog. Cela ne rapporte pas tant que cela, cela insupporte les visiteurs (la publicité est l'une des plaies de la société) et, au lieu d'être dépendant d'un mécène, on l'est d'une régie publicitaire.
  • Il peut faire payer l'accès à son blog, via un abonnement. Je n'ai pas de problème moral contre cela mais un gros problème pratique : cela rend difficile ou impossible le partage de contenu, qui est quand même à la base du Web. Envoyer un simple lien à des amis devient impossible, si on est abonné à ce site et qu'ils ne le sont pas. Et puis, c'est lourd de s'abonner pour un blog qu'on ne visitera que de temps en temps.
  • Il peut enfin demander des contributions volontaires, comme les chanteurs dans le métro. Mais on se heurte alors au problème du manque de moyens techniques pour permettre des petits paiements simples, rapides et où on ne laisse pas sa chemise en frais de transaction. C'est cette dernière voie que j'ai choisi d'explorer, d'abord avec Flattr.

Le principe de Flattr est le suivant : on s'inscrit sur leur site, on peut alors recevoir des « flattrs » (des flatteries ?) et, si on a déposé des fonds, en envoyer. Pour déposer des fonds, on a droit aux classiques cartes de crédit, à PayPal et même aux bitcoins. Lorsqu'on se promène sur un site Web et qu'on voit le bouton Flattr, on clique dessus, et le titulaire du bouton est « flattrisé » et verra son compteur augmenter. Au-delà d'une certaine valeur, il pourra même retirer des fonds. Cela marche aussi, sans avoir à ajouter de boutons, pour des services comme GitHub (quand un utilisateur de Flattr « starre » un dépôt, son titulaire est « flattrisé »). Ainsi, en novembre 2013, j'ai gagné pas moins de 0,19 € uniquement avec Twitter (chaque mise en favori « flattre »).

J'ai donc décidé de sauter un pas et de tenter Flattr sur mon blog. (Cela a posé des problèmes techniques avec le format XHTML de mon blog, le code du bouton proposé par Flattr n'étant pas compatible.) Ouvrez des comptes Flattr, déposez-y un peu d'argent et, si un article vous plait, cliquez sur le bouton Flattr en bas, je vous remercie d'avance.

Je n'utilise plus le bouton par défaut de Flattr : il fait systématiquement une requête vers les serveurs de Flattr pour chaque visite. Cela peut poser des problèmes à certains de mes visiteurs, de se voir ainsi suivis par Flattr. Je l'ai donc remplacé par un bouton statique qui ne charge rien si on ne clique pas.

Je ne suis pas du tout juriste, mais, a priori, je suppose que je vais devoir déclarer mon compte Flattr comme compte à l'étranger (pour ne pas faire comme Cahuzac) et qu'il faudra que j'intègre mes gains Flattr (dont je ne pense pas qu'ils seront colossaux...) dans ma déclaration de revenus. Sur la fiscalité des dons en France, Éric D. suggère ses articles « Un don, ça se déclare comment ? » et « Et si… oui mais en fait non. » dont les conclusions sont assez pessimistes (la fiscalité ne permet pas de faire des microdons simplement). La documentation officielle est en ligne et est manifestement conçue uniquement pour un petit nombre de dons importants (et uniquement entre gens qui se connaissent, oubliant les dons par des inconnus), pas par beaucoup de microdons, sans pour autant exclure explicitement les dons en dessous d'un certain montant. Enfin, les dons ne sont pas imposés comme des revenus (taxation progressive, avec un taux qui augmente avec le revenu) mais d'un taux fixe, et colossal (60 %). En pratique, il n'y a pas de problèmes aujourd'hui parce que tout cela se passe « sous le radar » (les gens qui touchent 10 € par mois avec Flattr ne le déclarent pas et le fisc a autre chose à faire que de les poursuivre) mais si ce mécanisme de financement de la création se répandait, il y aurait de vrais problèmes fiscaux. Autre possibilité, les déclarer comme revenus non commerciaux, comme c'est apparemment possible pour les bitcoins. Sinon, les gens de Tipeee (un autre système de rémunération, basé en France) ont fait une page très détaillée sur le sujet.

Et est-ce que Flattr n'a pas des défauts ? Si, certainement, commission trop élevée, système centralisé... Il y a eu une bonne discussion sur SeenThis sur ces sujets.

Autres articles sur Flattr et les microdons :

En pratique, Flattr a été un échec, je n'ai presque rien reçu par ce biais et j'ai donc finalement supprimé le bouton.

2019-11-20

PROPOSITION : mettre *vraiment* à jour le flux

J’avais oublié de préciser que vous n’allez plus être informé·e des mises à jour si vous ne changez pas d’adresse de flux. Pour rappel, c’est dorénavant celle-ci qui est valide :

https://larlet.fr/david/log/

Bonne journée :-)

PS : c’est probablement la dernière invitation à changer, c’est un peu pénible à faire un flux à la main…

2019-11-19

RFC 7469: Public Key Pinning Extension for HTTP

Depuis que les piratages de Comodo et DigiNotar ont fait prendre conscience du peu de sécurité qu'apportent les certificats X.509, plusieurs solutions ont été proposées pour combler les failles des autorités de certification. La proposition de ce RFC, HPKP (HTTP Public Key Pinning), consistait à permettre à un client d'épingler (to pin) les clés cryptographiques d'un serveur HTTP utilisant TLS, c'est-à-dire à s'en souvenir pendant une durée spécifiée par le serveur. Ainsi, même si un faux certificat est émis par une AC, il ne serait pas accepté. En pratique, HPKP a été peu adopté et semble aujourd'hui en voie d'abandon.

Un exemple plus récent d'un « vrai / faux certificat » (certificat vrai car émis par une AC reconnue, mais faux car émis sans l'autorisation du titulaire du nom de domaine, et dans l'intention de tromper les utilisateurs) est celui du ministère des finances français. Comme souvent avec les certificats mensongers, celui-ci visait Google (je soupçonne fort que le but était de lire le courrier Gmail des employés, mais, à Bercy, on dément, et on affirme que les buts étaient de pouvoir effectuer un filtrage du contenu sur le Web externe, et de passer les flux à l'antivirus) et c'est ce qui explique que cette compagnie soit très présente dans les forums comme l'IETF où on cherche des solutions aux sérieuses faiblesses de X.509. Parmi les solutions élaborées, il y a DANE, qui s'appuie sur le DNS (RFC 6698), mais Google préfère les certificats à la lumière du jour du RFC 6962 et l'épinglage (pinning) des clés, dans ce tout nouveau RFC 7469.

À noter qu'il existe déjà des en-têtes HTTP permettant au serveur de spécifier au client son comportement, comme le HSTS du RFC 6797. Mais l'épinglage de clés est indépendant de HSTS.

L'épinglage fait partie des techniques TOFU (Trust On First Use) : la première fois qu'un client se connecte au serveur, il ne peut pas savoir si la clé est bonne (il doit se fier à la validation X.509, avec ses limites). À la première connexion, le client HTTP (par exemple un navigateur Web) doit espérer qu'il n'y a pas d'homme du milieu ayant réussi à obtenir un faux certificat (pour cette raison, une attaque persistente, comme celle du ministère des finances, citée plus haut, ne serait pas empêchée par l'épinglage). Aux connexions suivantes, le client HTTP pourra par contre vérifier l'identité du serveur, grâce à la clé épinglée, c'est-à-dire gardée en mémoire. Ce n'est pas idéal (imaginez un homme du milieu ayant un faux certificat pour la première connexion et épinglant ses propres clés, empêchant ainsi toute correction ultérieure !) mais c'est un progrès sur la situation actuelle (valider les clés est un problème difficile en cryptographie). À part des clés partagées à l'avance directement entre les correspondants (ce qui ne passerait évidemment pas à l'échelle pour le Web entier), il n'y a pas de solution parfaitement sûre pour la validation des clés.

La section 2 décrit les détails pratiques. Elle définit un nouvel en-tête HTTP, Public-Key-Pins:. Présent dans une réponse HTTPS, cet en-tête indique au client HTTP que ce serait souhaitable qu'il épingle, qu'il mémorise, la clé publique. Le contenu de l'en-tête Public-Key-Pins: est le condensat de la clé publique utilisée pour TLS, condensat encodé en Base64 (RFC 4648). L'algorithme de condensation est indiqué dans la valeur de l'en-tête. Aujourd'hui, c'est forcément SHA-256 (RFC 6234). La clé est l'encodage DER du champ subjectPublicKeyInfo du certificat X.509 (à noter que les cas des clés brutes du RFC 7250 ou des clés PGP du RFC 6091 ne semblent pas traités, car elles n'ont pas les problèmes des certificats X.509). Une directive max-age est obligatoire dans l'en-tête HTTP, pour indiquer le nombre de secondes que doit durer l'épinglage (après quoi le client HTTP « oublie » la clé). Voici un exemple :

Public-Key-Pins: max-age=604800;
       pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="

Il existe aussi deux directives facultatives. includeSubDomains indique que l'épinglage s'applique aussi aux serveurs dont le nom est un sous-domaine de celui-ci. Si le client se connecte en HTTPS à bar.example.com et reçoit un Public-Key-Pins: avec includeSubDomains, et qu'il se connecte plus tard à foo.bar.example.com, il exigera de trouver la clé épinglée (voir la section 4.2 pour quelques pièges de cette directive). Autre directive facultative, report-uri indique à quel URI le client doit signaler les erreurs résultant de l'épinglage. En effet, on peut prévoir que, comme avec toute technique de sécurité, il y aura des problèmes. Par exemple, des webmestres changeront de clé et oublieront de modifier le Public-Key-Pins:. Il est donc important que ces problèmes soient détectés rapidement. Ce signalement se fera selon la technique décrite plus loin en section 3. Attention aux conséquences pour la vie privée ! La très détaillée section 5 couvre ce risque d'intrusivité. Voici un exemple avec ces deux directives, et l'utilisation de plusieurs clés (par exemple parce qu'un remplacement est en cours) :

Public-Key-Pins: max-age=2592000;
       pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
       pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";
       includeSubDomains;
       report-uri="https://other.example.net/pkp-report"

À noter qu'un deuxième en-tête est défini, Public-Key-Pins-Report-Only:, qui a exactement la même syntaxe, mais une sémantique différente : le client HTTP teste la clé épinglée et, si elle est fausse, le signale à l'URI indiqué par report-uri (qui devient donc obligatoire), mais n'empêche pas l'accès au serveur. C'est utile pour tester avant le vrai déploiement. Les deux en-têtes sont désormais dans le registre des en-têtes.

Comme indiqué plus haut, la section 3 décrit la façon dont un client HTTP peut signaler une erreur de validation. Pour cela, le client HTTP doit fabriquer un message en JSON (RFC 8259) et l'envoyer avec la méthode POST de HTTP à l'URI indiqué dans la directive report-uri. Voici un exemple d'un tel message (la date est au format du RFC 3339) :

 {
    "date-time": "2014-04-06T13:00:50Z",
    "hostname": "www.example.com",
    "port": 443,
    "effective-expiration-date": "2014-05-01T12:40:50Z"
    "served-certificate-chain": [
      "-----BEGIN CERTIFICATE-----\n
      MIIEBDCCAuygAwIBAgIDAjppMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT\n
      ...
    ],
    "validated-certificate-chain": [
      "-----BEGIN CERTIFICATE-----\n
      MIIEBDCCAuygAwIBAgIDAjppMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT\n
      ...
    ],
    "known-pins": [
      'pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="',
      "pin-sha256=\"E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=\""
    ]
  }

Comme souvent en sécurité, le diable est dans les détails, et c'est ce qui explique que la section 4, l'obligatoire « Security Considerations » soit particulièrement longue. Par exemple, l'épinglage peut avoir des conséquences néfastes si on s'est fait voler sa clé privée : normalement, on génère une nouvelle clé, un nouveau certificat et on demande à l'AC de re-signer. Mais on ne pourra pas l'utiliser car la clé publique correspondant à la clé volée est toujours épinglée dans des tas de navigateurs. On peut réduire ce problème en diminuant la durée d'épinglage. Mais, alors, on réduit aussi la durée de la protection dans le cas où une AC génère un certificat mensonger. Un compromis est donc nécessaire. Une approche possible est d'épingler, non pas la clé du serveur mais une clé intermédiaire dans la chaîne des certificats. Supposons que la société Example, qui gère example.com soit cliente de l'AC SmallAC qui a elle-même son certificat signé par une AC très largement reconnue, BigAC. En épinglant la clé de SmallAC, on se protège contre un vol de la clé privée d'example.com, et contre un faux certificat, même émis par BigAC. La société Example reste vulnérable à un faux certificat produit par SmallAC mais cela diminue sérieusement le nombre d'acteurs qui peuvent attaquer Example. (Notez que DANE a les mêmes possibilités : on peut publier dans le DNS sa propre clé, ou bien celle d'une AC.)

On a vu plus haut qu'on pouvait avoir plusieurs clés dans l'en-tête Public-Key-Pins:. Une des utilisations de cette possibilité est le cas où on a une clé de réserve (backup pin), non utilisée mais gardée en un endroit différent de la clé du certificat actuel. Ainsi, si, pour une raison ou pour une autre, la clé est inutilisable, la clé de réserve peut prendre le relais immédiatement puisqu'elle est déjà épinglée.

Autre cas où l'épinglage peut avoir un effet néfaste, celui de l'épinglage hostile. Imaginons un méchant qui obtienne un faux certificat. Il détourne le trafic (par exemple par un empoisonnement DNS) et envoie les gens vers son serveur HTTPS, qui semblera légitime, en raison du faux certificat. Avec l'épinglage, il peut même prolonger son attaque en épinglant sa clé. Si le site légitime n'avait pas été visité avant, ou s'il ne faisait pas d'épinglage, l'attaque peut réussir, bloquant le client HTTPS sur la clé de l'agresseur pour la durée max-age spécifiée par ledit agresseur. Il n'y a pas de solution miracle pour ce problème. Une possibilité est de précharger les clés de sites connus dans le navigateur. Une autre est d'utiliser les certificats au grand jour du RFC 6962. (Et, bien sûr, il y a DANE, RFC 6698, que Google prend toujours soin de ne pas mentionner.)

Autres risques, ceux pour la vie privée (section 5). Un serveur peu sympathique peut utiliser l'épinglage comme une sorte de cookie discret. Par exemple, il peut mettre une petite image dans un sous-domaine, épingler des fausses clés pour ce sous-domaine (une différente par visiteur) et attendre les signalements à report-uri pour identifier un client HTTPS unique. Des sites différents peuvent même coopérer pour avoir le même report-uri, pour suivre un client à travers plusieurs sites.

À noter aussi que les signalements d'un problème de validation contiennent la chaîne de certificats utilisée. Cela peut permettre d'identifier l'utilisation de faux certificats par telle ou telle organisation. C'est plutôt une bonne chose pour détecter des attaques comme celle effectuée au ministère des finances mais cela ne sera évidemment pas apprécié de ceux qui veulent faire du détournement de trafic.

Comme toujours en sécurité, l'utilisabilité est cruciale (section 7). Lorsqu'un épinglage a eu lieu, et que le trafic est ensuite détourné vers un faux serveur, le client HTTPS (par exemple le navigateur Web) va refuser l'accès à ce faux serveur ce qui, du point de vue de M. Toutlemonde devant son navigateur, est un déni de service. Il va donc falloir bien expliquer à M. Toutlemonde ce qui se passe, pour éviter qu'il n'accuse le site légitime.

Le RFC recommande aussi que l'utilisateur puisse accéder facilement à la liste des clés épinglées et aussi, ce qui me semble plus contestable, qu'il puisse la modifier, par exemple en désépinglant les clés. Cela me semble dangereux car cela peut ouvrir une voie à l'ingénierie sociale (« il y a un petit problème technique, si l'accès vous est refusé, cliquez sur Clear all pinned keys »).

L'annexe A contient un exemple, utilisant OpenSSL en ligne de commande, pour générer le Public-Key-Pins:. J'en ai fait un petit script qui s'utilise ainsi :

% make-pin.sh www.ietf.org
...
DHKscLdFrBmZiBGxMdZiyaxp29vnyyPltRS1ZmTF09Y=
Et hop, on n'a plus qu'à mettre Public-Key-Pins: max-age=604800; pin-sha256="DHKscLdFrBmZiBGxMdZiyaxp29vnyyPltRS1ZmTF09Y=" dans la réponse du serveur HTTP. (Tom me fait remarquer à juste titre qu'une clé de secours est obligatoire - section 4.3 - et que donc il faut toujours au moins deux pin-sha256. J'ai simplifié.) Les premières versions de l'Internet-Draft qui a mené à ce RFC utilisaient un programme en Go, make-pin.go :
% openssl s_client -servername www.ietf.org -connect www.ietf.org:443 > ietf.pem
...
% ./make-pin ietf.pem 
Hex: 0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6
Base64: DHKscLdFrBmZiBGxMdZiyaxp29vnyyPltRS1ZmTF09Y=

À noter que l'annexe B contient quelques conseils pratiques à l'usage des gérants de serveurs HTTPS, sur le bon déploiement de l'épinglage. Par exemple, il est recommandé de commencer doucement, en mode report-only avant de se jeter dans le grand bain et de risquer de bloquer ses clients. Comme avec n'importe quelle technique de sécurité, on risque de se planter soi-même si on ne fait pas attention : n'épinglez pas bêtement !

Question mises en œuvre, Chrome et Firefox avaient déjà de l'épinglage, avec une série de clés mise en dur dans le logiciel (voir la description de Mozilla et leur annonce). Vous pouvez tester ici si votre navigateur gère l'épinglage. Une description de l'épinglage des clés dans Chrome avait été faite par Adam Langley et sa lecture est recommandée (par exemple pour comprendre pourquoi on épingle juste des clés et pas des certificats entiers). Pour le monde Microsoft, voir leur article. Il y aussi un article détaillé sur le concept, chez OWASP, et l'article de Robert Love avec des détails pratiques. Le peu de succès de HPKP fait que Firefox, par exemple, a annoncé son intention de l'abandonner (cf. ticket #1412438.)

Merci à Florian Maury et Kim Minh Kaplan pour leur relecture.

2019-11-18

Capitole du Libre 2019

Le 16 et le 17 novembre 2019, c'était Capitole du Libre à Toulouse, un rassemblement libriste à ne pas manquer. Plein de rencontres, d'ateliers et de conférences intéressantes.

C'était aussi le premier anniversaire du mouvement des Gilets jaunes, marqué par de nombreuses manifestations.

J'y ai fait une séance dédicace de mon livre « Cyberstructure », qui avait été annoncé pour la première fois publiquement au Capitole du Libre de l'année dernière. La séance était organisée par la librairie « Les petits ruisseaux ». J'étais à côté de David Revoy, l'auteur de Pepper et Carrot, qui faisait de superbes dessins.

J'ai fait un exposé sur le protocole QUIC, actuellement en cours de normalisation à l'IETF. Voici la version en PDF pour présentation, la version en PDF pour impression et le source en LaTeX/Beamer. La vidéo est disponible (et également sur GoogleTube). Il y a aussi d'excellentes sketchnotes (par Kevin Ottens, merci à lui.) Version complète

Le programme de Capitole du Libre était très riche. J'ai beaucoup aimé la présentation de Marina Fernández de Retana (alias Kaoseto), l'auteure du « Cycle de Shaedra ». Ses romans ne sont pas écrits avec un gros logiciel WYSIWYG comme LibreOffice (a fortiori pas en Word), mais dans un langage de balisage, du WYSIWYM. Un des gros avantages des outils WYSIWYM est l'intégration aux outils externes comme grep ou git (là où l'obésiciel doit réinventer en moins bien tous ces outils externes.) Après avoir essayé LaTeX (messages d'erreur insupportables) et Markdown (pas de balisage sémantique, on ne peut pas créer ses propres balises, encore qu'il existe des extensions utiles pour l'écrivain comme Manuskript ou Crowbook), l'auteure a finalement choisi Frundis. Frundis permet notamment de créer ses propres balises sémantiques, même pour la poésie, et de produire ensuite facilement du bon PDF (pour l'impression) et du du bon EPUB (pour lire sur écran). (Au passage, j'ai suivi une démarche du même genre pour mon livre, mais c'est plus rare chez un·e romanci·er·ère.) À noter qu'elle tape le Frundis avec vim sur un clavier Bépo.

Question Frundis, si vous voulez un exemple ultra-court (Frundis peut faire bien mieux), voici :

.X set lang fr
.X set document-title "Quel beau titre"
.Ch Test
Comment ça va ?
.P
Début, puis un lien :
.Lk https://cyberstructure.fr/ "Mon livre"
.P
Suite, lorem, ipsum, dolor, et tout ça.    
  
J'ai installé le logiciel en suivant les instructions dans le README et ça marche :
% frundis -T latex -s -o test1.tex test1.frundis     
  
produit un fichier LaTeX à partir duquel on peut faire un PDF.
% frundis -T xhtml -s -o test1.html test1.frundis    
  
produit de l'HTML. Notez que Frundis corrige certaines erreurs, comme de mettre un espace ordinaire (au lieu de l'espace insécable) avant un point d'interrogation :
frundis: test1.frundis:3:Ch: incorrect regular space before '?'
  
Je n'ai pas aussi bien réussi avec EPUB, il faudra que je regarde ça.

Dans la conférence « Rien à cacher ? Vous devriez. », Julien Osman a expliqué très clairement les enjeux actuels de la protection des données personnelles, face aux capacités modernes du machine learning. « Le machine learning est à la data ce que sont les raffineries au pétrole. [Ça transforme un truc qui, brut, n'a aucun intérêt, en un truc qui rapporte.] » Ainsi, cette technique permet d'identifier les points sensibles d'un individu, ceux où une publicité ciblée sera efficace (comme dans le cas de Cambridge Analytica.) « Aujourd'hui, notre gouvernement est plutôt bienveillant. Il installe des caméras de vidéo-surveillance partout, pour que la Mère Michel arrête de perdre son chat. Mais, demain, avec la reconnaissance faciale et un gouvernement moins bienveillant, cela donnera quoi ? »

Taziden est revenu sur « Censure de sites imposée aux FAI : où en est on ? ». Il a notamment noté qu'on n'avait pas de liste consolidée de tous les noms de domaine censurés par l'autorité judiciaire. Certes, les décisions de justice sont publiques, mais il n'existe pas de liste de synthèse, rendant difficile l'évaluation de l'ampleur de la censure. Pour mesurer le degré d'application de cette censure, Taziden suggérait OONI mais aussi les sondes RIPE Atlas (le programme Blaeu permet de voir la censure de Sci-Hub aujourd'hui en France). La censure administrative (par la police) est évidemment encore plus opaque, on a seulement un rapport annuel agrégé. En 2018, il y a eu 879 demandes de blocage. Notez que des sites Web ont retiré des contenus, par peur de se retrouver dans la liste de blocage (cf. lettre de menace affichée pendant l'exposé). Les blocages effectivement faits ne montrent donc qu'une partie de la censure administrative. L'orateur a rappelé que la CNIL est censée garder un œil sur cette censure administrative. Suite à la demande de retrait et de blocage d'Indymedia Grenoble & Nantes, l'orateur a fait une demande afin d'obtenir des documents et il les a eu. Ils montraient que la police et la CNIL n'étaient pas d'accord. Le tribunal administratif de Cergy a d'ailleurs annulé les décisions de blocage des sites Indymedia le 1 septembre 2019. Pour contourner cette censure, Taziden a cité les résolveurs DNS publics. Attention : si on y accède en UDP (le cas le plus courant), on n'a aucune authentification, aucune intégrité, et aucune confidentialité. Utilisez plutôt DoT (DNS sur TLS) ou DoH (DNS sur HTTPS). Ainsi, le résolveur DNS public de LDN, 80.67.188.188 a DoT (voir ce test avec le client DoT Homer).

Un mot aussi sur deux activités d'aide au développement avec du logiciel libre, « Le logiciel libre au service de l'éducation en Guinée » par Kovann Ly (association EDA - Enfants De l'Aïr) et « Afrikalan : rendre les logiciels libres éducatifs accessibles hors des pays du nord » par l'association Bilou Toguna. EDA a de nombreuses activités (santé, éducation, agriculture) mais la partie qui intéresse plus directement le Capitole du Libre, c'est l'accès au numérique dans l'éducation. Un des problèmes dans la zone des mines d'or est que certains parents mettent leurs enfants à la mine plutôt qu'à l'école. Pour encourager la scolarisation, l'école doit être « sexy » et c'est là que l'informatique joue un rôle. Mais installer vingt PC normaux dans une salle dépasse les capacités du groupe électrogène (il n'y a pas de réseau électrique), d'où le choix des Raspberry Pi. Les Raspberry Pi sont connectés entre eux en WiFi mais les établissements scolaires n'ont pas d'accès Internet (notez que l'administration scolaire n'est pas chaude, par peur de l'Internet). Une copie de Wikipédia est donc disponible sur le serveur (qui est dans un très beau boitier en bois fait par le menuisier local.) Pas mal de logiciels libres sont installés sur les postes des élèves, dont Scratch. L'expérience avec les Raspberry Pi est positive : matériel très robuste, malgré l'électricité déconnante, et faible consommation électrique (ce sont les écrans qui consomment l'essentiel). Par contre, il faut fréquemment dépoussiérer, pour enlever la latérite. L'autre conférence, « Afrikalan : rendre les logiciels libres éducatifs accessibles hors des pays du nord » ou « Pourquoi les pingouins devraient plus souvent aller dans les écoles d'Afrique » portait, en dépit de son titre, plutôt sur le périscolaire. En effet, une des difficultés dans l'enseignement au Mali, où intervient l'association, est que les enseignants sont peu autonomes. Ils ne créent pas leur propre contenu pédagogique, ils appliquent. Cela rend difficile de créer des variantes (logiciel libre au lieu de privateur). D'où le choix d'Afrikalan de travailler plutôt dans un cadre périscolaire. Entre autres, Afrikalan utilise les nombreuses activités conçues par des enseignants pour des enfants d'âge très divers par Pepit. Souvent, les adultes dans l'école s'approprient les ordinateurs qui avaient été installés pour les enfants, l'ordinateur étant un objet de prestige, et les adultes n'en ayant pas pour leur travail. Il faut donc des objets qui ne soient pas considérés comme des ordinateurs. Et, comme EDA, Afrikalan utilise le Raspberry Pi, qui n'est pas moins cher (compte-tenu du prix de son écran), mais qui fait l'objet de moins de convoitises.

Et sur les réseaux sociaux décentralisés ? J'ai été moins convaincu par « Zot : aux frontières des réseaux fédérés avec Hubzilla et Zap » d'Ale Abdo mais il est vrai qu'il a manqué de temps pour présenter ces systèmes pas évidents. Hubzilla (qui a changé de nom plusieurs fois) utilise le protocole Zot pour fournir un réseau social décentralisé. (Il y a une passerelle vers ActivityPub, pour parler aux fédiversiens.) Une des originalités est que l'identité (et les contacts) peuvent se promener d'une instance (« hub ») à l'autre, en copiant sa clé privée et son profil. Quant à Zap, c'est une scission de Hubzilla, qui se concentre sur l'aspect réseau social (Hubzilla peut faire plein d'autres choses).

Mille mercis à Toulibre et à tous les organisateurs (vous pouvez suivre un interview de ceux-ci.) Photo de Matthieu Herrb :

Autre(s) lecture(s) sur cette édition de Capitole du Libre :

2019-11-11

ACTION : mettre à jour le flux

Bonjour fidèle lecteur ou lectrice,

Version courte

Si tu vois ce message, il faut mettre à jour l’URL dans ton outil de veille favori pour renseigner :

https://larlet.fr/david/log/

Ça devrait être simple, indolore et te permettre de continuer à être informé·e des publications récentes.

J’aimerais que ces outils soient suffisamment intelligents pour comprendre qu’une redirection permanente qui a plus de six ans est définitive et qu’ils se mettent à jour tout seuls mais ça n’est manifestement pas le cas.

Version longue

Tout d’abord merci, ça veut dire que tu me donnes de l’attention depuis au moins six ans ! Biologeek, Django, Ubuntu, peut-être même depuis que je parle de bio-informatique :D

Il y a six ans, j’ai décidé de centraliser tout ce que je publiais sur un même nom de domaine et j’ai fait notamment une redirection depuis biologeek.com vers larlet.fr pour les flux RSS/Atom. Je pensais naïvement que les agrégateurs finiraient par se mettre à jour d’eux-mêmes à force de suivre des redirections permanentes. Je viens de vérifier dans mes logs serveurs et ce n’est malheureusement pas le cas.

Pourquoi est-ce que j’aimerais que tu mettes cette adresse à jour ?

  1. Je ne sais pas à combien de redirections on est depuis 6 ans mais ça doit se compter en millions selon la fréquence de rafraichissement ce qui doit être non négligeable en terme de consommation de bout en bout.
  2. Je ne sais pas combien de temps je vais encore garder biologeek.com et je ne voudrais pas que tu sois perdu·e s’il venait à être récupéré par quelqu’un d’autre.
  3. Je me suis rendu compte que pas mal d’agrégateur étaient mauvais en sécurité en ce qui concerne l’échappement de contenu HTML, ce qui veut dire que combiné au point 2 ça peut être pas terrible et je ne voudrais pas prendre cette responsabilité.
  4. Ça me simplifierait la tâche de commencer à réduire le nombre de redirections ici et là. Je suis dans une période de ménage un peu forcé mais ça pourrait déboucher sur du code public.

Si tu as besoin d’aide pour effectuer cette manipulation, je peux t’aider par courriel : david@larlet.fr (indique-moi quel outil tu utilises).

Si tu te rends compte que c’est un bon moyen de réduire le nombre de tes souscriptions et que tu n’es plus vraiment intéressé·e par les mêmes sujets, c’est cool aussi. C’est la beauté d’une technologie qui ne te trace pas, je n’en aurai même pas conscience :-).

Bonne semaine,
David

PS : si vous voyez ce message alors que vous avez déjà la « bonne » URL, c’est que j’ai foiré une redirection. Mea culpa.

2019-11-05

Grandir connectés

Les discours sur les pratiques numériques des « jeunes » ne manquent pas, allant de « ielles sont digital natives, ielles sont complètement à l'aise dans l'environnement numérique, les adultes n'ont rien à leur apprendre » à « ielles sont bêtes, ielles ont la capacité d'attention d'un poisson rouge, ielles gobent toutes les fake news, ielles ne lisent plus rien, c'était mieux avant [surtout qu'il n'y avait pas d'écriture inclusive] ». Les deux positions ont en commun d'être énoncées sans avoir sérieusement étudié les pratiques effectives de jeunes réels… Au contraire, dans ce livre, Anne Cordier regarde des vrais jeunes et, sans juger a priori, analyse ce qu'ielles font sur l'Internet.

Le livre date de 2015 (et le travail de recherche semble avoir été fait un certain temps avant), mais les choses n'ont pas forcément énormément changé depuis. Il y a sans doute moins de Facebook et davantage d'Instagram chez les jeunes, et MSN, cité dans le livre, a probablement disparu. Mais les fondamentaux demeurent, à savoir une grande… déconnexion entre l'existence connectée quasiment en permanence, et la difficulté à comprendre ce qui se passe derrière l'écran. (Et comme le note l'auteure, cette déconnexion n'est pas spécifique aux jeunes. Bien des adultes, même en milieu professionnel, ne comprennent pas non plus les dessous du numérique.)

La méthodologie suivie par l'auteure était d'observer, dans un CDI, collègiens et lycéens dans leurs aventures connectées, et de les interroger, de façon aussi neutre que possible, sur ce qu'ielles en pensaient, sur leurs analyses de l'Internet. Il est important de ne pas juger. Par exemple, ceux et celles qui ont des difficultés avec les outils de l'Internet ont souvent du mal à en parler aux enseignant·e·s ou aux parents. Et d'autant plus que le discours sur les mythiques digital natives, ces jeunes qui sauraient absolument tout sur le numérique et n'auraient rien à apprendre à ce sujet, est très présent, y compris dans leurs têtes. Si une personne de 70 ans peut avouer « moi, ces machines modernes, je n'y comprends rien », un tel aveu est bien plus difficile à 11 ans, quand on est censé tout maitriser de l'Internet. Les expressions du genre « si j'avouais que je ne sais pas faire une recherche Google, ce serait la honte » reviennent souvent.

Alors, que font et disent ces jeunes ? D'abord, ielles sont divers, et il faut se méfier des généralisations. D'autant plus que l'auteure a travaillé avec des classes différentes, dans des établissements scolaires différents. La première chose qui m'a frappé a été le manque de littératie numérique (et je ne pense pas que ce se soit beaucoup amélioré depuis 2015). Oui, ils et elles savent se servir avec rapidité des équipements électroniques, et de certains logiciels (comme, aujourd'hui, WhatsApp). Mais cela n'implique pas de compréhension de ce qui se passe derrière, et cela conduit à des comportements stéréotypés, par exemple d'utiliser toujours le même moteur de recherche. Le livre contient beaucoup de déclarations des jeunes participant à l'étude, et, p. 215, l'auteure leur demande pourquoi avoir choisi le moteur de recherche de Google : « on n'a que ça à la maison ». Sans compter celles et ceux qui affirment bien fort que « Google, c'est le meilleur », avant d'admettre qu'ielles n'en connaissent pas d'autres. Là encore, ne rions pas d'eux et elles : bien des adultes ne sont pas plus avancés, même s'ielles sont à des postes importants dans le monde professionnel.

En parlant de Google, il est frappant, en lisant le livre, à quel point Google occupe une « part d'esprit », en sus de sa part de marché. Et, là, ça n'a certainement pas changé depuis la sortie du livre. Les services de Google/Alphabet sont la référence pour tout, et plus d'un collègien ou lycéen lui attribue des pouvoirs quasi-magiques. À l'inverse, les échecs ne sont que rarement correctement analysés (p. 115). Cela va de l'auto-culpabilisation « j'ai fait une erreur, je suis nulle », au déni « je suis super-fort en Internet, ce n'est pas moi qui ai fait une erreur, je suis un boss » en passant par la personnalisation « il n'a pas compris ce que je lui demandais ». Notez quand même qu'à part quelques vantards, beaucoup des jeunes interrogés sont assez lucides sur leur manque de littératie numérique « on ne nous a jamais appris, les profs disent qu'on est censés tout savoir, mais en fait, on ne sait pas ».

Le plus grave, je trouve, c'est l'absence de compréhension de ce qu'ielles font (p. 244), qui se manifeste notamment par l'absence de terminologie. Beaucoup des jeunes interrogés ne savent pas raconter ce qu'ielles font sur l'Internet, à part en décrivant des gestes (« je clique sur le E bleu »). Une telle absence de modélisation, de conceptualisation, ne permet certainement pas de comprendre ce qui se passe, et d'avoir une attitude active et critique.

Les jeunes sont souvent en compétition les uns avec les autres, et cela se manifeste aussi dans les usages numériques. Lors d'un travail scolaire impliquant le montage d'un film, les utilisateurices de Movie Maker se sont ainsi fait vertement reprendre, comme quoi il ne s'agissait que d'un outil pour bricoleurs, pas pour vrais pros.

Par contre, ielles parlent beaucoup d'entraide, surtout de la part des grandes sœurs (les grands frères sont plus rarement mentionnés) et même des parents (les mères, surtout, les pères semblent moins souvent cités par les jeunes.)

Bref, un livre que je recommande beaucoup, pour avoir une bonne idée de l'état de la « culture numérique » chez les jeunes. Normalement, vous en sortez avec moins de certitudes et de généralisations qu'au départ.

Comme l'auteure a été professeur documentaliste, j'en profite pour signaler l'existence des APDEN, les associations de professeurs documentalistes, qui font d'excellentes réunions. Et puisqu'on a parlé d'éducation au numérique, je vous suggère la lecture du programme de SNT, qui commence en 2019. Mon avis est que ce programme est ambitieux, peut-être trop, vu les moyens concrets alloués, mais qu'il va dans la bonne direction : c'est justement ce niveau d'exigence qu'il faudrait pour le numérique.

Je vous recommande également cet excellent interview de l'auteure à l'émission 56Kast.

2019-11-03

RFC 8642: Policy Behavior for Well-Known BGP Communities

Le protocole d'annonces de routes BGP permet d'attacher aux annonces des étiquettes, les communautés, qui sont des métadonnées pour les routes. Certaines valeurs sont réservées pour des communautés « bien connues » qui sont censées donner le même résultat partout. Mais ce n'est pas vraiment le cas, comme l'explique ce RFC, qui demande qu'on améliore la situation.

Les communautés sont normalisées dans le RFC 1997, qui décrit par la même occasion le concept de communauté bien connue. Celles-ci sont enregistrées à l'IANA. Voici un exemple d'annonce BGP avec des communautés :

TIME: 11/03/19 09:14:47
TYPE: BGP4MP/MESSAGE/Update
FROM: 89.149.178.10 AS3257
TO: 128.223.51.102 AS6447
ASPATH: 3257 8966 17557 136030 138368
NEXT_HOP: 89.149.178.10
COMMUNITY: 3257:4000 3257:8102 3257:50001 3257:50110 3257:54900 3257:54901 65535:65284
ANNOUNCE
  103.131.214.0/24    
  
Cette annonce du préfixe 103.131.214.0/24 contient sept communautés, dont une bien connue, 65535:65284 (0xFFFFFF04 en hexadécimal), NOPEER, normalisée dans le RFC 3765.

Le RFC estime que le RFC 1997 était un peu trop flou, et que cela explique partiellement les différences que nous observons aujourd'hui.

Ainsi, le changement d'une communauté par la politique locale d'un AS. Un routeur BGP qui reçoit une annonce avec des communautés peut évidemment modifier ces communautés (typiquement en ajouter, mais parfois aussi en enlever). Tous les modèles de routeurs permettent donc de modifier les communautés, entre autres en fournissant une commande, appelée set ou un nom de ce genre, qui remplace les communautés par un autre ensemble de communautés. Toutes les communautés ? Non, justement, c'est là qu'est le problème : sur certains routeurs, les communautés bien connues sont épargnées par cette opération, mais pas sur d'autres routeurs.

(Personnellement, cela me semble un problème d'interface utilisateur, qui ne concerne pas vraiment le protocole. Mais je cite l'opinion du RFC, qui trouve cette différence de comportement ennuyeuse, par exemple parce qu'elle peut créer des problèmes si un technicien, passant sur un nouveau type de routeur, suppose qu'une commande ayant le même nom va avoir la même sémantique.)

La section 4 du RFC liste les comportements constatés sur les routeurs :

  • Sur Junos OS, community set remplace toutes les communautés, bien connues ou pas,
  • Sur les Brocade NetIron, set community a le même effet,
  • Même chose sur VRP de Huawei, avec community set,
  • Idem sur SR OS, avec replace,
  • Sur IOS XR, set community remplace toutes les communautés sauf certaines communautés bien connues, comme NO_EXPORT, ces communautés doivent être retirées explicitement si on veut un grand remplacement ; la liste des communautés ainsi préservées n'est même pas la liste enregistrée à l'IANA,
  • Sur OpenBGPD, set community ne supprime aucune des communautés existantes, qu'elles soient bien connues ou pas.

La section 5 de notre RFC souhaite donc que, pour les futures communautés spécifiées dans de futurs RFC, le comportement (remplaçable ou pas) soit précisé par l'IETF.

À destination, cette fois, des gens qui font le logiciel des routeurs, la section 6 suggère :

  • De ne pas changer le comportement actuel, même pour améliorer la cohérence, même si une communauté change de statut (devenant bien connue) car ce changement serait trop perturbant,
  • Mais de documenter soigneusement (apparemment, ce n'est pas fait) le comportement des commandes de type set ; que font-elles aux communautés bien connues ?
Quant aux opérateurs réseau, le RFC leur rappelle qu'on ne peut jamais être sûr de ce que vont faire les AS avec qui on s'appaire, et qu'il vaut mieux vérifier avec eux ce qu'ils font des NO_EXPORT ou autres communautés bien connues qu'on met dans les annonces qu'on leur envoie.

2019-11-02

A Fediverse/Mastodon bot for BGP queries

I created a bot to answer BGP queries over the fediverse (decentralized social network, best known implementation being Mastodon). What for? Well, mostly for the fun, but also because I need from time to time to find out the origin AS for an IP address or prefix, and I don't have a direct access to a DFZ router. This article is to document this project.

The idea was originally suggested during my lightning talk at RIPE 76 meeting in Marseille.

First, how to use it. Once you have a Fediverse account (for Mastodon, see https://joinmastodon.org/), you write to @bgp@botsin.space. You just tell it the IP address (or IP prefix) you want to know about and it replies with the actually announced prefix and the origin AS. There are also links to the RIPE Stat service, for more details. Here is an example, with the answer:

The bot replies with the same level of confidentiality as the query. So, if you want the request to be private, use the "direct" mode. Note that the bot itself is very indiscreet: it logs everything, and I read it. So, your direct messages will be private only from third parties, not from the bot administrator.

If you are a command-line fan, you can use the madonctl tool to send the query to the bot:

% madonctl toot "@bgp@botsin.space 2a01:e34:ec2a:94a0::4"
You can even make a shell function:
# Definition (in a startup file)
whichasn() {
    madonctl toot --visibility direct "@bgp@botsin.space $1"
}

# Usage
% whichasn   
You can also, instead of an IP address, just send "info" and the bot will reply with details about the number of prefixes and AS it knows.

There is also a more classical (non-fediverse) Web interface, at https://bgp.bortzmeyer.org/IPADDRESS. For instance, with curl :

% curl  https://bgp.bortzmeyer.org/159.89.230.222
159.89.224.0/20 1406
      
Note that, unlike the fediverse interface, the Web interface is not really necessary, you could use other online services such as RIPE Stat. Here is an example with RIPE Stat (we use jq to parse the resulting JSON):
% curl -s https://stat.ripe.net/data/routing-status/data.json\?resource=185.49.140.0 | jq .data.resource            
"185.49.140.0/22"

Now, the implementation of the bot. (You can get all the files at https://framagit.org/bortzmeyer/fediverse-bgp-bot/.) The code is derived from my DNS bot so I won't repeat here most of the stuff, only the BGP-specific things.

The bot backend could call directly the RIPE stat API mentioned above. But there is a limit in the number of requests and, if the bot is popular, it could be blacklisted. Same thing for other online services. Hence my choice of getting the raw RIS dumps. Parsing them and serving them to the bot is done by the WhichASN daemon.

Other useful services and readings for the BGP fans:

  • We rely on the excellent RIS (Routing Information Service), which collects and stores BGP information, before making them available to the public.
  • There are other ways to access RIS data, such as RIPE Stat or RIS Live.
  • The RouteViews project has several useful tools, such as a DNS interface. It would solve the rate-limiting issue but, unfortunately, it works only with IPv4.
  • I also like the Qrator API (but you need to register).
  • I could also have used BGPstream.
  • There are also several whois servers distributing BGP information such as whois.cymru.com or whois.bgpmon.net.

2019-10-31

N° 92 – Science ouverte en réflexions tropicalisées

2019-10-31 Antonin Benoit Diouf - SENBIBDOC - conférences, Congrès, colloques, conférences, séminaires,..., Africa, données, OpenAccess, OpenData, OpenScience, science_ouverte
La capitale sénégalaise (Dakar) vient d’abriter le « Colloque international sur la science ouverte au Sud : enjeux et perspectives d’une nouvelle dynamique ». Il a été organisé dans le cadre du 75ème anniversaire de l’IRD en collaboration avec le CIRAD et l’Université Cheikh Anta Diop de Dakar. Du 23 au 25 octobre 2019, une cinquantaine de participants ont échangé sur l’état des lieux, les enjeux et les perspectives de la science ouverte dans les pays du sud, plus particulièrement ceux de l’Afrique subsaharienne francophone. Un programme très riche qui a permis aux participants de connaître ce La suite…

2019-10-27

(Cyber) harcèlement

Le sujet du harcèlement dans l'enseignement est douloureux mais il est quand même nécessaire de l'étudier. Il ne se réduit pas au cyberharcèlement, et il n'est même pas sûr que le cyberharcèlement soit si différent que cela du harcèlement classique, comme l'indique le titre de ce livre, qui met « cyber » entre parenthèses. En outre, ce sujet se prête au sensationnalisme, et les articles sur quelques cas spectaculaires masquent souvent la réalité du phénomène. On peut donc féliciter l'auteure d'avoir abordé le sujet sous un angle plus scientifique, en s'appuyant sur des faits, et en étudiant le phénomène sous tous ses aspects, afin de mieux pouvoir le combattre.

C'est d'autant plus important que les exagérations et les approximations qui sont fréquentes lorsqu'on parle du cyberharcèlement ont souvent des but cachés. Par exemple, les politiciens français dénoncent souvent l'anonymat sur l'Internet comme étant lié au harcèlement, et réclament son abolition, alors que Bérengère Stassin fait remarquer que, dans la plupart des affaires de harcèlement scolaire, la victime sait parfaitement qui sont ses harceleurs. Mais la vérité ne compte pas quand on veut faire passer une nouvelle loi.

Et, si les médias et les autorités parlent si souvent du cyberharcèlement (et très peu du harcèlement tout court), c'est que cela sert aussi à diaboliser les outils de communication modernes, qui les concurrencent. On voit ainsi des campagnes de sensibilisation anxiogènes, qui ne présentent l'Internet que comme un outil de harcèlement.

Revenons au livre. L'auteure commence par recadrer le problème dans l'ensemble des phénomènes de harcèlement à l'école, malheureusement fréquents. (Elle fait aussi remarquer que les cas les plus dramatiques, se terminant parfois par un suicide de la victime, font parfois oublier qu'il existe un harcèlement de masse, pas aussi grave mais beaucoup plus fréquent.) Le harcèlement scolaire a été étudié depuis longtemps par les spécialistes, même s'il n'existe évidemment pas de solution miracle. Le harcèlement massif est difficile à mesurer car il consiste en beaucoup de micro-agressions. Chaque agresseur a l'impression de ne pas avoir fait grand'chose, alors que c'est leur nombre qui fait la gravité du phénomène. Et le harcèlement est inégalement réparti entre les genres, les filles en étant plus souvent victimes.

Comme toutes les activités humaines, le harcèlement s'est ensuite adapté à l'Internet et diverses formes de cyberharcèlement sont apparues, que l'auteure passe en revue en détail avec, pour chacune, ce que dit la loi. Mais la presse et les politiciens, toujours prêts à diaboliser le nouveau système de communication, ont rapidement entonné le discours « c'est la faute d'Internet et des écrans, les jeunes étaient mieux avant », quitte à inventer les faits, comme dans l'affaire du soi-disant Momo challenge. La réalité est pourtant bien assez grave comme cela, et plusieurs personnalités ont dénoncé publiquement le cyberharcèlement dirigé contre elles, par exemple Marion Seclin ou Nadia Daam. Ces trois premiers chapitres du livre sont difficiles à lire, car parlant de choses extrêmement douloureuses (même si les agresseurs les considèrent toujours avec légèreté) mais indispensables, pour avoir une idée claire du phénomène. Le livre détaille notamment les nombreuses études qui ont été faites, analysant les motivations des harceleurs (inutile de rappeler que comprendre, ce n'est pas excuser, n'est-ce pas ?)

Une fois qu'on a étudié le harcèlement, reste à lutter contre lui. C'est l'objet du dernier chapitre. Au moins, maintenant, le problème est nommé et reconnu (ce n'était pas le cas il y a cent ans.) L'État s'en empare, le ministère fait des campagnes, et sensibilise, plusieurs associations sont actives (comme l'APHEE, Marion, la main tendue ou e-Enfance, cette dernière étant spécialisée dans la lutte contre le cyberharcèlement et, au passage, le livre contient énormément d'URL de ressources utiles pour lutter contre le harcèlement).

Le livre ne fournit bien sûr pas de solution simple et magiquement efficace. Il liste de nombreuses initiatives, de nombreux endroit où trouver des informations et des idées. Les personnes impliquées dans la lutte contre le harcèlement, les enseignant·e·s par exemple, y trouveront des armes contre ces affreuses pratiques. Ne manquez pas également de visiter le blog de l'auteure.

Autre compte-rendu de ce livre : celui de Didier Epsztajn.

RFC 8633: Network Time Protocol Best Current Practices

Le protocole NTP, qui sert à synchroniser les horloges sur l'Internet, est probablement un des plus vieux protocoles encore en service. Il est normalisé dans le RFC 5905. Ce nouveau RFC ne change pas la norme, il rassemble simplement un ensemble de bonnes pratiques pour l'utilisation de NTP. Sa lecture est donc très recommandée à toutes les personnes qui gèrent la synchronisation d'horloges dans leur organisation.

Bien sûr, tout dépend des niveaux d'exigence de cette organisation. Quel écart entre les horloges acceptez-vous ? Quel est le risque d'une attaque délibérée contre les serveurs de temps que vous utilisez ? À vous de lire ces bonnes pratiques et de les adapter à votre cas.

Le RFC commence par un conseil de sécurité réseau général (section 2). NTP est fondé sur UDP, ce qui signifie que le protocole de transport ne protège pas contre les usurpations d'adresses. Et comme les réponses NTP sont souvent bien plus grosses (en octets) que les questions, des attaques par réflexion et amplification sont possibles, et effectivement observées dans la nature. (Le RFC recommande également la lecture de « Technical Details Behind a 400Gbps NTP Amplification DDoS Attack », de « Taming the 800 Pound Gorilla: The Rise and Decline of NTP DDoS Attacks » et de « Attacking the Network Time Protocol ».) Il est donc nécessaire que les opérateurs réseau déploient les mesures « BCP 38 » contre les usurpations d'adresses IP.

Après ce conseil général, qui concerne également d'autres protocoles, comme DNS ou SNMP, la section 3 du RFC se penche sur les bonnes pratiques de configuration de NTP. Évidemment, il faut maintenir les logiciels à jour (ce qu'on oublie plus facilement lorsqu'il s'agit d'un protocole d'infrastructure, comme NTP).

Moins évidente, la nécessité d'avoir plusieurs sources de temps. Une source donnée peut être malveillante, ou tout simplement incorrecte. Or, NTP peut utiliser plusieurs sources, et trouver le temps correct à partir de ces sources (les détails sont dans le RFC 5905, et dans le livre de D. Mills, « Computer network time synchronization: the Network Time Protocol ».) Trois sources sont le minimum, quatre sont recommandées, si, bien sûr, elles sont suffisamment diverses, et dignes de confiance. (Au passage, Renater gère une liste de serveurs NTP en France mais elle ne semble pas à jour, chronos.cru.fr n'existe plus, il y manque le serveur de l'AFNIC, ntp.nic.fr, etc.)

Ce conseil de chercher plusieurs serveurs suppose évidemment que ces serveurs sont indépendants : s'ils prennent tous le temps depuis une même source et que celle-ci est déréglée ou malveillante, avoir plusieurs serveurs ne suffira pas. Il est donc également nécessaire de veiller à la diversité des horloges sous-jacentes. Avoir plusieurs serveurs mais connectés à des horloges du même vendeur fait courir le risque d'un problème commun à toutes. La diversité doit aussi s'appliquer au choix du type d'horloge : si on utilise plusieurs horloges, mais toutes fondées sur des constellations de satellites, une tache solaire va les perturber tous en même temps. Autre risque : un problème DNS supprimant le nom de domaine, comme c'était arrivé à usno.navy.mil (l'USNO), en décembre 2018 et surtout à ntp.org en janvier 2017 (cf. cette discussion ou bien celle-ci).

Autre question, les messages de contrôle de NTP. Introduits dans l'annexe B du RFC 1305, qui normalisait la version 3 de NTP, ils n'ont pas été conservés pour la version 4 (RFC 5905). (Un projet existe à l'IETF pour les remettre, cf. draft-ietf-ntp-mode-6-cmds.) Utiles à l'administrateur système pour la gestion de ses serveurs, ces messages peuvent être dangereux, notamment en permettant des attaques par réflexion, avec amplification. La bonne pratique est donc de ne pas les ouvrir au monde extérieur, seulement à son réseau. Des exemples de configurations restrictives figurent à la fin de cet article.

Il est évidemment nécessaire de superviser ses serveurs NTP, afin de s'assurer qu'ils sont en marche, et, surtout, du fait qu'ils soient bien synchronisés. Des exemples, utilisant Icinga, figurent à la fin de cet article.

Un serveur NTP qui sert des dizaines de milliers de clients peut nécessiter beaucoup de ressources réseau. Il est donc important de n'utiliser comme serveur que des serveurs qu'on est autorisé à questionner (ce qui est le cas des serveurs publics comme ntp.nic.fr). Il existe hélas de nombreux exemples d'abus de serveurs NTP, le plus célèbre étant sans doute celui du serveur de Poul-Henning Kamp par D-Link.

Pour permettre à tous et toutes de synchroniser leurs horloges, le projet « NTP Pool » a été créé. De nombreux volontaires mettent à la disposition de tous leurs serveurs NTP. L'heure ainsi distribuée est en général de bonne qualité mais, évidemment, le projet ne peut fournir aucune garantie. Il convient bien pour les configurations par défaut distribuées avec les logiciels, ou pour des machines non critiques. Autrement, il faut utiliser des serveurs « de confiance ».

Pour l'utiliser, il faut regarder les instructions (elles existent aussi en français). En gros, on doit indiquer comme serveurs NTP des noms pris sous pool.ntp.org et ces noms pointeront, au hasard, vers des machines différentes, de manière à répartir la charge. Voici un exemple (avec un serveur français) :

% dig +short A 0.fr.pool.ntp.org
5.196.192.58
51.15.191.239
92.222.82.98
162.159.200.123
Mais quelque temps après, les adresses IP auront changé.
%  dig +short A 0.fr.pool.ntp.org
80.74.64.2
212.83.154.33
94.23.99.153
37.187.5.167
   
Voici un exemple de configuration avec le serveur NTP habituel, dans son ntp.conf :
pool 0.fr.pool.ntp.org iburst
pool 1.fr.pool.ntp.org iburst
pool 2.fr.pool.ntp.org iburst
pool 3.fr.pool.ntp.org iburst
    
Ainsi, on aura quatre serveurs, pointant vers des adresses réparties dans le lot. Avec OpenNTPd, ce serait :
servers fr.pool.ntp.org
    
L'administrateur système ne pense pas toujours à ajuster la configuration, donc beaucoup de fournisseurs de logiciels ont un sous-domaine de pool.ntp.org, utilisé dans les configurations livrées avec leurs serveurs NTP. Par exemple, pour OpenWrt, le fichier de configuration par défaut contiendra :
server 0.openwrt.pool.ntp.org iburst
server 1.openwrt.pool.ntp.org iburst
server 2.openwrt.pool.ntp.org iburst
server 3.openwrt.pool.ntp.org iburst
    

Un problème récurrent des horloges sur l'Internet est celui des secondes intercalaires. La Terre étant imparfaite, il faut de temps en temps corriger le temps universel avec ces secondes intercalaires. Jusqu'à présent, on a toujours ajouté des secondes, puisque la Terre ralentit, mais, en théorie, on pourrait avoir à en retirer. Il existe un temps qui n'a pas ce problème, TAI, mais, outre qu'il s'éloigne petit à petit du temps astronomique, il n'a pas été retenu dans les normes comme POSIX (ou NTP, qui ne connait qu'UTC…) Il faut donc gérer les soubresauts d'UTC, et c'est une source de bogues sans fin. Les secondes intercalaires ne sont pas prévisibles longtemps à l'avance (je vous avait dit que la Terre est imparfaite) et il faut donc lire les bulletins de l'IERS (en l'occurrence le bulletin C) pour se tenir au courant. Notez que ce bulletin n'est pas écrit sous une forme structurée, lisible par un programme, donc on pourra préférer le leap-seconds.list, disponible en plusieurs endroits. Pour un serveur NTP, une autre solution est d'utiliser des horloges qui distribuent de l'information sur les secondes intercalaires prévues. C'est le cas du GPS ou de DCF77. Dans ce cas, le serveur NTP peut se préparer un peu à l'avance (ce qui n'évite pas les bogues…)

Autre problème amusant, noté par le RFC, le leap smearing, qui consiste à lisser l'arrivée d'une seconde intercalaire au lieu de brutalement décaler l'horloge d'une seconde. Lors de la seconde intercalaire de juin 2015, certains serveurs NTP faisaient du leap smearing et pas d'autres, ce qui semait la confusion chez les clients qui avaient un mélange de ces deux types de serveurs. Le leap smearing n'est pas conforme à la norme NTP et ne doit donc pas être utilisé sur des serveurs NTP publics, d'autant plus que le protocole ne permet pas de savoir si le serveur utilise ce smearing ou pas. Dans un environnement fermé, par contre, on fait évidemment ce qu'on veut.

Concernant ce leap smearing, le RFC note qu'il peut poser des problèmes juridiques : l'horloge de la machine ne sera pas en accord avec l'heure légale, ce qui peut créer des histoires en cas, par exemple, d'accès des autorités aux journaux.

Passons maintenant aux mécanismes de sécurité de NTP (section 4 du RFC). L'analyse des risques a été faite dans le RFC 7384, notre RFC rappelle les moyens de faire face à ces risques. Il y a bien sûr les clés partagées (la directive keys /etc/ntp/ntp.keys dans le serveur NTP classique). NTP n'a pas de mécanisme de distribution de ces clés, il faut le faire en dehors de NTP (copier /etc/ntp/ntp.keys…), ce qui ne marche donc pas pour des serveurs publics. (Comme il y a toujours des lecteurs qui me disent « mais c'est pas pratique de recopier les clés à la main sur toutes les machines », je rappelle l'existence d'Ansible, et autres outils analogues.) À noter que le seul algorithme de condensation normalisé pour l'utilisation de ces clés est MD5, clairement dangereux (RFC 6151). Ceci dit, d'autres algorithmes sont parfois acceptés par les mises en œuvre de NTP, cf. RFC 8573. (Opinion personnelle : MD5 vaut mieux que pas de sécurité du tout.)

Et… c'est tout. Il n'existe pas actuellement d'autre mécanisme de sécurité pour NTP. Le système Autokey, normalisé dans le RFC 5906 a été abandonné, en raison de ses vulnérabilités. Un travail est en cours pour lui concevoir un successeur.

La section 5 de notre RFC résume les bonnes pratiques en matière de sécurité NTP :

  • Éviter les fuites d'information que permettent les requêtes de contrôle. Les articles de Malhotra, A., Cohen, I., Brakke, E., et S. Goldberg, « Attacking the Network Time Protocol », de Van Gundy, M. et J. Gardner, « Network Time Protocol Origin Timestamp Check Impersonation Vulnerability » (CVE-2015-8138) et de Gardner, J. et M. Lichvar, « Xleave Pivot: NTP Basic Mode to Interleaved » (CVE-2016-1548) documentent des attaques rendues possibles par ce côté trop bavard de NTP. C'est ainsi par exemple que Shodan se permettait de repérer des adresses IPv6 à analyser, pour compenser le fait que l'espace d'adressage IPv6 est trop gros pour le balayer systématiquement (RFC 7707).
  • Surveiller les attaques connues, par exemple avec Suricata.
  • NTP a un mécanisme de répression des requêtes, le KoD (Kiss-o'-Death, RFC 5905, section 7.4), qui permet de calmer les clients qui suivent la norme (un attaquant l'ignorera, bien sûr).
  • La diffusion des informations NTP à tout le réseau local, pratique pour diminuer l'activité NTP (directives broadcast et broadcastclient dans le serveur NTP), ne devrait se faire que si ledit réseau est de confiance et que les informations sont authentifiées.
  • Même chose pour le mode symétrique (entre pairs qui s'échangent les informations NTP, directive peer).

Enfin, la section 6 du RFC couvre le cas particulier des systèmes embarqués. Par exemple, les objets connectés ont une fâcheuse tendance à rester en service des années sans mise à jour. S'ils ont été configurés en usine avec une liste de serveurs NTP, et que certains de ces serveurs disparaissent ensuite, l'objet risque de ne plus pouvoir se synchroniser ou, pire, il va matraquer une machine innocente qui a récupéré l'adresse d'un serveur NTP (cf. RFC 4085). Il est donc important que les clients NTP puissent mettre à jour la liste de leurs serveurs. D'autre part, la liste doit évidemment être correcte dès le début, et ne pas inclure des serveurs NTP, même publics, sans leur autorisation. Une solution simple est de passe par le le projet « NTP Pool ».

L'annexe A de notre RFC rassemble des conseils qui sont spécifiques à une mise en œuvre de NTP, celle de la Network Time Foundation, le « code NTP original » (paquetage ntp sur Debian ou ArchLinux).

Pour obtenir une variété de sources, le démon « ntpd » fourni a la directive pool, qui permet de désigner un ensemble de serveurs :

pool 0.debian.pool.ntp.org iburst
pool 1.debian.pool.ntp.org iburst
pool 2.debian.pool.ntp.org iburst
pool 3.debian.pool.ntp.org iburst
    

NTP a la possibilité de recevoir des messages de contrôle (annexe B du RFC 1305). Cela peut être dangereux, et il est recommandé d'en restreindre l'accès. Avec le serveur habituel ntpd, c'est bien documenté (mais cela reste complexe et pas intuitif du tout). Voici un exemple :

restrict default noquery nopeer nomodify notrap
restrict ::1
restrict 2001:db8:b19:3bb0:: mask ffff:ffff:ffff:ffff:: notrust
restrict 2001:db8:2fab:e9d0:d40b:5ff:fee8:a36b nomodify
    
Dans cet exemple, la politique par défaut (première ligne) est de ne rien autoriser. Toute machine qui tenterait de parler au serveur NTP serait ignorée. Ensuite, la machine locale (::1, deuxième ligne) a tous les droits (aucune restriction). Entre les deux (troisième ligne), les machines du réseau local (2001:db8:b19:3bb0::/64) ont le droit de parler au serveur seulement si elles sont authentifiées cryptographiquement. Enfin, la machine 2001:db8:2fab:e9d0:d40b:5ff:fee8:a36b a le droit de lire le temps chez nous mais pas de le modifier.

On avait parlé plus haut de l'importance de superviser ses services de temps. Voici une configuration avec Icinga pour faire cela :

apply Service "ntp-time" {
  import "generic-service"
  check_command = "ntp_time"
    assign where (host.address || host.address6) && host.vars.ntp 
}
...
object Host "foobar" {
...
   vars.ntp = true 
Avec cette configuration, la machine foobar sera supervisée. On peut tester depuis la ligne de commande que le monitoring plugin arrive bien à lui parler :
% /usr/lib/nagios/plugins/check_ntp_time -H foobar
NTP OK: Offset 7.331371307e-06 secs|offset=0.000007s;60.000000;120.000000;
 
Si la réponse avait été CRITICAL - Socket timeout after 10 seconds, on aurait su que le serveur refuse de nous parler.

Ah, et puisqu'on a parlé de sécurité et de protéger (un peu) NTP par la cryptographie, voici un exemple (non, ce ne sont pas mes vrais clés, je vous rassure) :

% cat /etc/ntp/ntp.keys
...   
13 SHA1  cc5b2e7c400e778287a99b273b19dc68369922b9 # SHA1 key

% cat /etc/ntp.conf
...
keys /etc/ntp/ntp.keys
trustedkey 13
 
Avec cette configuration (le fichier ntp.keys peut être généré avec la commande ntp-keygen), le serveur NTP acceptera les messages protégés par la clé numéro 13. Sur le client, la configuration sera :
keys /etc/ntp/ntp.keys
server SERVERNAME key 13
 

Quelques petits trucs pour finir. Avec ntpd, comment voir l'état des pairs avec qui ont est connectés ? Ici, on a configuré l'utilisation du pool :

    
% ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
-162.159.200.123 10.19.11.58      3 u   25  128  377    1.381   -2.439   0.199
-164.132.45.112  43.13.124.203    3 u    8  128  377    5.507   -1.423   0.185
+212.83.145.32   193.200.43.147   2 u    4  128  377    1.047   -1.823   0.455
+5.196.160.139   145.238.203.14   2 u   12  128  377    5.000   -0.981   0.291
-163.172.61.210  145.238.203.14   2 u    8  128  377    1.037   -0.888   0.246
*82.64.45.50     .GPS.            1 u   71  128  377   11.116   -1.178   0.549
-178.249.167.0   193.190.230.65   2 u    3  128  377    6.233   -1.026   0.145
-194.57.169.1    145.238.203.14   2 u    2  128  377   10.660   -0.931   0.233
-151.80.124.104  193.204.114.232  2 u   16  128  377    4.888   -1.414   0.354
Autre commande utile, pour comparer l'heure locale avec les serveurs NTP :
    
%  ntpdate -q ntp.nic.fr
server 2001:67c:2218:2::4:12, stratum 2, offset 0.000520, delay 0.03194
server 2001:67c:2218:2::4:13, stratum 2, offset 0.000746, delay 0.03175
server 192.134.4.12, stratum 2, offset 0.000509, delay 0.03127
server 192.134.4.13, stratum 2, offset 0.000596, delay 0.04376
28 Oct 10:54:08 ntpdate[18996]: adjust time server 192.134.4.12 offset 0.000509 sec

Et avec un serveur NTP complètement différent ? Essayons avec OpenNTPD :

% cat /etc/ntpd.conf
     
# No way to restrict per IP address :-(    Use a firewall       
listen on *
servers fr.pool.ntp.org
sensor *
    
Avec cette configuration, la machine va se synchroniser au pool, cequ'on pourra vérifier avec ntpctl :
% sudo ntpctl -s all
4/4 peers valid, clock synced, stratum 4

peer
   wt tl st  next  poll          offset       delay      jitter
162.159.200.123 from pool fr.pool.ntp.org
    1 10  3   23s   30s        -2.270ms     4.795ms     0.027ms
193.52.136.2 from pool fr.pool.ntp.org
    1 10  2   32s   34s        -1.904ms    18.058ms     1.788ms
91.121.96.146 from pool fr.pool.ntp.org
 *  1 10  3    0s   31s        -1.147ms     1.872ms     0.069ms
62.210.213.21 from pool fr.pool.ntp.org
    1 10  2    1s   34s        -0.367ms     4.989ms     0.067ms
   

2019-10-25

Il n'existe pas de TLD interne standard

Dans beaucoup d'organisations, les noms de domaine locaux sont attribués dans un TLD, un domaine de tête, non normalisé, comme .loc ou .lan. Pourquoi n'y a t-il pas de domaine de premier niveau normalisé pour ces usages « internes » ?

Un certain nombre de personnes, sans avoir vérifié, croient savoir qu'il y a un domaine de premier niveau prévu pour cela. On cite parfois à tort .local (qui est en fait affecté à autre chose par le RFC 6762). Parfois, le .loc, plus court, est utilisé. La plupart du temps, on ne se pose pas la question, et on utilise un TLD non affecté, sans réfléchir.

Alors, peut-on répondre aux administrateurs réseaux de ces organisations « vous auriez dû utiliser le TLD standard prévu pour cela » ? Après tout, il y a des TLD standards pour des usages spécifiques, comme .test pour les essais et le développement ou comme .example pour les exemples dans la documentation. Ils sont normalisés dans le RFC 2606 et, depuis, a été créé un registre IANA, peuplé selon des règles définies dans le RFC 6761, pour stocker tous ces noms « spéciaux ». (Le RFC 8244 peut être aussi une bonne lecture, mais à lire avec son sens critique allumé.)

Mais, parmi eux, il n'y a pas de TLD réservé comme « usage interne des organisations ». Ce n'est pas faute d'avoir essayé, plusieurs tentatives ont été faites pour normaliser un tel nom, mais sans résultat. Pour comprendre, il faut d'abord revenir sur la question « pourquoi ne pas prendre un nom un peu au hasard et l'utiliser ? » Imaginons une organisation nommée « Foobar » et qui nommerait ses ressources internes sous le TLD non-existant .foobar. (Il y a de nombreux exemples réels. Par exemple, la société Belkin livrait des produits pré-configurés avec le TLD .belkin.) Quel(s) problème(s) cela poserait ? Ils sont au nombre de trois :

  • Pendant longtemps, il semblait que la liste des TLD ne changeait pas et qu'un nom libre le resterait longtemps. Les indépendances suite à la fin de la guerre froide, et la création par l'ICANN de centaines de nouveaux TLD à partir de 2013 ont mis fin à cette légende. Si demain, l'ICANN ouvre un nouveau cycle d'enregistrement de TLD, et que quelqu'un demande et obtient .foobar, notre entreprise sera bien embêtée, il y aura de nombreuses collisions entre ses noms internes et les noms externes. Le résultat de la résolution DNS dépendra de beaucoup de choses. Cela avait par exemple posé des problèmes pour .dev.
  • Quand on utilise un nom assez répandu comme, aujourd'hui, .loc, .home ou .corp, un autre danger se présente, celui lié aux fusions/acquisitions. Si une organisation fusionne avec une autre, par exemple une entreprise se fait acheter, et que les deux organisations utilisaient le même TLD interne, on retombe dans le même problème de collisions. La DSI aura bien du mal à gérer ce choc entre les deux utilisations du même nom. Utiliser un nom aléatoire tel que .fa43h7hiowxa3lk9aio comme TLD interne rendrait ce risque peu vraisemblable, mais ça ne serait pas très pratique.
  • Et enfin il y a le problème des fuites. Lorsqu'on crée un TLD interne, c'est pour qu'il reste interne, d'autant plus qu'il recense des ressources privées, mais, en pratique, il est très difficile de s'assurer qu'il n'y aura pas de fuites. Un employé oublie qu'il n'a pas lancé le VPN de l'entreprise, et cherche à accéder à des ressources internes. Ou bien il rapporte le portable chez lui et ses logiciels tentent automatiquement de résoudre ces noms internes. Dans tous ces cas, les noms internes vont fuiter vers les serveurs faisant autorité, et la racine du DNS voit une part significative de requêtes pour des TLD n'existant pas. (Vous pouvez regarder vous-même ces requêtes pour des TLD non existants, par exemple sur la page de statistiques du serveur C-root.) Les fuites ne se produisent d'ailleurs pas que vers la racine du DNS. Le ministère de l'intérieur utilise .mi en interne et a déjà publié des appels d'offres, des offres d'emploi ou des communiqués de presse en indiquant un URL en .mi.
Pour ces trois raisons, utiliser un TLD imaginaire n'est pas une bonne idée. Notez qu'un certain nombre d'administrateurs réseau s'en moquent : ils se disent que le problème n'arrivera que dans plusieurs années, qu'ils auront changé d'entreprise à ce moment et que ce sera leur successeur ou successeuse qui devra gérer les conséquences de leurs décisions erronnées.

Mais alors, puisque ce n'est pas une bonne idée de prendre un TLD au pifomètre, pourquoi est-ce que l'IETF, qui a déjà enregistré plusieurs TLD spéciaux, n'enregistre pas un .internal (ou un autre nom) en le marquant comme « Usage interne seulement » ? Ce serait en gros l'analogue pour le DNS de ce que sont les adresses IP privées du RFC 1918. L'opération a été tentée, et pas qu'une seule fois. Le dernier essai était l'Internet-Draft draft-wkumari-dnsop-internal, qui réservait .internal.

Le brouillon draft-wkumari-dnsop-internal examinait également les autres possibilités, alternatives au .internal :

  • Le TLD .alt avait été proposé (Internet-Draft draft-ietf-dnsop-alt-tld) mais pas (encore ?) approuvé et, de toute façon, il est réservé aux cas où la résolution de noms ne se faisait pas via le DNS mais, par exemple, via GNUnet.
  • L'IETF a déjà un TLD quasiment à sa disposition, .arpa. On aurait pu envisager un quelquechose.arpa. Mais le sigle ARPA n'est pas parlant à M. Toutlemonde, et un suffixe de nom de domaine à deux composants est jugé moins pratique qu'un suffixe à un seul composant, le TLD.
  • Les noms déjà réservés comme spéciaux comme .local ou .invalid ont tous une sémantique bien précise, et restrictive. Bref, ils servent déjà à autre chose.
D'où le choix du .internal par l'auteur du document.

À noter qu'une question intéressante, lorsqu'on décide de réserver un pseudo-TLD pour les sites locaux, est celle de DNSSEC. Si le TLD n'est pas délégué par la racine, les résolveurs validants rejetteront ce nom, puisque la racine est signée. Ce n'est peut-être pas trop grave puisqu'ils auront de toute façon besoin d'une configuration spécifique pour l'utiliser. Un exemple ? Ici, avec Unbound, on délègue .internal à deux serveurs internes :

server:
     domain-insecure: "internal" # Only necessary if there is no
     # insecure delegation from the root.    
    
forward-zone:
     name:   "internal"
     forward-addr: 10.42.1.68
     forward-addr: fd9d:ebf3:dd41:6094::1:53
  
Et si on délègue le nom (par exemple au nouvel AS112 du RFC 7535) ? Pas moyen de signer cette délégation (puisqu'il faudrait distribuer publiquement la clé privée, pour que chacun signe sa zone locale). La seule solution est donc une délégation non signée (des enregistrements NS mais pas de DS). Notez que .alt, s'il avait été accepté, n'aurait pas eu ce problème, puisqu'il était réservé aux usages non-DNS.

Mais le brouillon draft-wkumari-dnsop-internal note que c'est bien joli de choisir un joli nom, encore faut-il, si on a décidé qu'il était mieux de le déléguer, convaincre l'ICANN de le faire. Et, là, on est partis pour dix ans de multistakeholder bottom-up decision process et d'innombrables réunions. C'est en partie ce qui explique le manque d'intérêt qui a finalement coulé le projet .internal. Le marécage de la gouvernance Internet est difficile à traverser.

De toute façon, .internal n'aurait résolu que le premier problème (risque de délégation d'un vrai TLD du même nom). Il aurait un peu aggravé le second (collision lors d'une fusion/acquisition) puisque tout le monde utiliserait le même nom. Et il aurait un peu aidé pour le troisième (les fuites) puisqu'il aurait été plus facile de prendre des mesures standard pour gérer les fuites d'un TLD standard. Bref, l'idée n'est pas forcément excellente, la motivation principale pour le .internal était « c'est une mauvaise idée mais il y a une demande donc on donne ce TLD aux administrateurs réseau pour qu'ils arrêtent de râler ». On a vu que cette motivation n'avait pas été suffisante et que, finalement, on n'a pas de TLD (ou de suffixe) standard pour les noms internes.

Que doit faire l'administrateur réseau, alors ? Le plus simple, étant donné que toute organisation a (ou devrait avoir) un nom de domaine à soi, est de prendre un sous-domaine de ce domaine. Si l'organisation Foobar citée plus haut a foobar.com, qu'elle nomme ses ressources internes en internal.foobar.com. Du fait de la nature arborescente des noms de domaine, aucun risque que ce nom soit attribué à un autre, aucun risque de collision en cas de fusion/acquisition, et aucun risque de fuites.

2019-10-22

Journée de l'APDEN (professeur·e·s documentalistes) sur l'enseignement de l'informatique

Le 16 octobre 2019, les APDEN (association de professeur·e·s documentalistes de l'éducation nationale) franciliennes tenaient une journée d'études au lycée Janson-de-Sailly. Le thème était l'enseignement de l'informatique au lycée, notamment suite à la nouvelle option SNT (Sciences Numériques et Technologie) au lycée. Je parlais quant à moi de l'enseignement de l'Internet.

Les professeur·e·s documentalistes ne sont pas une espèce très connue. Pas mal d'élèves, et de parents d'élèves, ignorent que la « dame du CDI » est une professeure comme les autres. Pour le nouvel enseignement SNT, comme une bonne partie du programme porte sur la recherche d'informations, les professeur·e·s documentalistes sont aussi bien équipés que les autres pour l'enseigner. Si vous souhaitez connaitre le programme, il est disponible en ligne (et le PDF est là.) Tout le monde dans cette journée était d'accord pour dire qu'il est ambitieux. Voici deux manuels de cet enseignement, consultables en ligne : celui de Nathan, et celui d'Hachette.

Commençons par un café :

Bon, je vais utiliser le féminin dans le reste de cet article, pour parler des professeures documentalistes car, en pratique, c'est un métier essentiellement féminin.

J'ai parlé de ma vision de ce qu'il fallait enseigner sur l'Internet. Voici les supports (et leur source).

Autrement, Véronique Bonnet, professeure de philosophie et militante de l'APRIL nous a parlé de philosophie du document (Montaigne disait qu'il fallait pilloter les livres comme les abeilles pillotaient les fleurs…). Elle nous a également fait réfléchir sur les représentations visuelles d'Ada Lovelace. Sur ses portraits, elle n'a pas l'air d'une nerd, est-ce une bonne ou une mauvaise chose ? Est-ce que ça encourage à l'imiter ? (On n'a que des portraits officiels d'elle. On ne sait pas à quoi elle ressemblait quand elle travaillait dans son bureau.)

Tristan Nitot a ensuite parlé de souveraineté numérique, notamment avec l'exemple de Qwant. Qwant ne mémorise pas ses visiteurs : « c'est un guichetier amnésique ». Il y a de la publicité, mais purement liée à la recherche en cours, pas aux recherches précédentes. Plusieurs enseignantes ont fait remarquer que leurs élèves ne semblaient pas sensibles au flicage fait par les GAFA, estimant que la publicité ciblée était même une bonne chose. D'autres ont fait remarquer que le sevrage n'était pas facile : « J'ai essayé d'abandonner Google, j'ai tenu 10 jours. » (Et je rajoute que c'est d'autant plus vrai que les résultats de Qwant sont bien plus mauvais que ceux de Google.) Quant aux objets connectés, notamment aux assistants vocaux, Tristan Nitot a noté que « nous sommes plus crétins que les Troyens, car nous payons les caméras et les micros connectés que nous introduisons dans nos salons. Au moins, les Troyens n'avait pas payé pour le cheval. »

Nous avons eu aussi une présentation par Thierry Bayoud de son documentaire « LOL ; le logiciel libre, une affaire sérieuse », qui cherche actuellement un distributeur. (Le documentaire n'est pas distribué librement. Certains festivals exigent, pour envisager la possible remise d'un prix, d'être en première. Si le film a été diffusé avant, même accidentellement, c'est fichu.).

La journée se terminait avec une table ronde sur l'enseignement SNT (Sciences Numériques et Technologie) : quelle perspective pour les professeurs documentalistes ? Il y avait deux excellents récits d'expériences concrètes, sur le terrain. Céline Caminade a raconté son expérience avec l'implémentation du programme de SNT en lycée. Parmi les difficultés pratiques : les profs sont censés enseigner la programmation en Python mais ne savent pas forcément programmer (et ça ne s'apprend pas en deux semaines). Mais j'ai bien aimé qu'il y ait eu une sortie au théâtre pour voir la pièce « La Machine de Turing », de Benoit Solès, avec la prof d'anglais et la prof de maths. Amélie Chaumette, elle, avait fait une expérience (en dehors de l'enseignement SNT, qui n'existait pas encore) d'enseignement de la cryptographie en classe de première. Histoire (de César à Enigma, en passant par Vigenère) puis protection des données personnelles puis travaux divers pour les élèves.

Merci à Habib pour m'avoir invité, et à toutes les intervenantes et participantes, c'était passionnant, et j'ai appris plein de choses.

Ah, et le plaisir de se retrouver dans un vieux lycée parisien pittoresque…

2019-10-20

Unicode à ses débuts

Sur le site Web du consortium Unicode, consortium qui pilote l'évolution de cette norme, on trouve une très intéressante page d'histoire, rassemblant un certain nombre de documents sur le passé d'Unicode. Parmi eux, « Unicode 88 » qui, en 1988, était le premier document à exposer les bases de ce qui allait devenir la norme Unicode. Il est amusant de voir aujourd'hui ce qui a été gardé de ce projet, et ce qui a été changé.

Ce document « Unicode 88 » était un projet : tout n'était pas encore défini. Mais on y trouve déjà quelques principes importants qui ont été conservés :

  • Encodage de caractères abstraits, et pas de glyphes (la représentation graphique du caractère),
  • Utilisation pour le texte brut, sans caractères de formatage (ce qui n'a pas été complètement respecté).
D'autres principes étaient absents, comme la séparation de l'affectation des points de code et leur encodage en bits. Il y a aussi des principes qui ont été gardés mais qu'on regrette aujourd'hui comme l'unification Han.

Le plus frappant, avec le recul, est l'insistance sur un principe qui n'a pas été conservé, l'encodage de taille fixe (proche du futur UCS-2), en 16 bits (dérivé de XCCS). On sait qu'en fait c'est un encodage de taille variable, UTF-8 (RFC 3629), qui s'est imposé (pour les protocoles Internet, ce choix en faveur d'UTF-8 est formalisé dans les RFC 2277 et RFC 5198.) L'article « Unicode 88 » accuse son âge lorsqu'il écrit que 16 bits seront suffisants dans tous les cas (16 bits permettent d'encoder 65 536 caractères, or il en existe aujourd'hui 137 994). « Unicode 88 » note que cela implique d'abandonner les écritures du passé, qui sont au contraire aujourd'hui une part importante d'Unicode.

À l'époque, un certain nombre de gens critiquaient Unicode en raison de l'augmentation de taille des textes (un caractère sur deux octets au lieu d'un). L'argument a toujours été faible, compte tenu de la rapide augmentation des capacités des processeurs et des disques durs mais, à cette époque où la disquette de trois pouces et demi était une invention récente, il avait du poids. D'ailleurs, encore aujourd'hui, à une époque de documents Word de plusieurs dizaines de mégaoctets, sans même parler des vidéos haute définition, on entend parfois des critiques d'UTF-32 (un autre encodage de taille fixe…) sur la base de la taille des fichiers de texte brut. Le document estime que le problème de la taille est mieux réglé par la compression.

Autre point où le document accuse son âge, le curieux tableau qui mesure l'importance des écritures en fonction du PNB des pays qui les utilisent. Cela rappele qu'Unicode a été conçu par des entreprises capitalistes qui cherchaient le profit, et donc les marchés rentables.

Le choix d'un encodage de taille fixe (qui n'a donc pas été retenu par la suite) était stratégique, et le document revient plusieurs fois sur l'importance de ce choix, en raison de la simplification des programmes qu'il permet. L'argument de la simplicité des programmes a finalement cédé face à l'argument choc d'UTF-8 : la compatibilité avec ASCII (tout document en ASCII est automatiquement un document en UTF-8).

Et l'unification Han ? Cette idée de considérer les caractères chinois et japonais comme équivalents, en raison de leur origine commune, et malgré leurs apparences différentes (mais rappelez-vous qu'Unicode encode des caractères, pas des glyphes), est à peine discutée dans l'article, alors qu'elle est certainement le concept Unicode le plus critiqué depuis.

2019-10-10

Twitter & les gaz lacrymogènes

Beaucoup de textes ont été écrits sur le rôle de l'Internet, et des réseaux sociaux centralisés, comme Facebook ou Twitter, dans des évènements politiques. Ce fut le cas, par exemple, du printemps arabe. L'auteure explore, dans ce livre très riche et très rigoureux, tous les aspects de cette relation entre les militants et les techniques d'information et de communication. Twitter peut-il battre les gaz lacrymogènes ?

(Le livre a été écrit en anglais, Zeynep Tufekci étant étatsunienne - d'origine turque. Il a été publié dans sa langue originale en 2017. Je l'ai lu dans la traduction française, tout à fait correcte, à part une certaine tendance à utiliser le mot anglais en français, comme traduire activist par activiste ou devastated par dévasté.)

Une grande partie des articles et messages écrits au sujet de l'utilisation de l'Internet par les militants des quatre coins du globe sont assez excessifs dans un sens ou dans l'autre. Soit on estime que l'Internet change tellement de choses qu'il ouvre une façon toute nouvelle de faire de la politique, et rend donc dépassées les méthodes traditionnelles, soit on se moque des « révolutions Twitter » et on affirme que le pouvoir se prend dans la rue, comme avant. La vérité est évidemment plus complexe : l'arrivée de l'Internet n'a pas supprimé les lois de la politique, les questions posées aux militants et aux révolutionnaires restent les mêmes, ainsi que les problèmes auxquels ils et elles font face. Mais l'Internet n'est pas non plus un épiphénomène : comme d'autres techniques avant lui (l'imprimerie est l'exemple canonique, d'ailleurs analysé de façon originale par l'auteure), l'Internet a changé les moyens dont les gens disposent, a créé de nouvelles affordances (là, je ne critiquerai pas la traduction : il n'y a pas de bon terme en français), c'est-à-dire de nouvelles potentialités, des encouragements à aller dans de nouvelles directions. Sur la question récurrente de la neutralité de la technique, Zeynep Tufekci cite à juste titre la citation classique de Melvin Kranzberg : « La technologie n'est ni bonne, ni mauvaise ; et n'est pas neutre non plus. »

Une des raisons pour lesquelles bien des discours sur les mouvements politiques utilisant l'Internet sont très unilatéraux est que beaucoup de leurs auteurs sont des férus de technique qui ne connaissent pas grand'chose à la politique, et qui découvrent comme s'ils étaient les premiers à militer, ou bien ils sont des connaisseurs de la politique, mais complètement ignorants de la technique, dont ils font un tout, animé d'une volonté propre (les fameux « algorithmes »), et pas des outils que les gens vont utiliser. L'auteure, au contraire, informaticienne, puis chercheuse en sciences politiques, connait bien les deux aspects. Elle a étudié en profondeur de nombreux mouvements, les zapatistes au Mexique, Occupy Wall Street, l'occupation du parc Gezi, Black Lives Matter, les révolutions tunisienne et égyptienne, en étant souvent sur le terrain, à respirer les gaz lacrymogènes. (Les gilets jaunes n'y sont pas, bien que ce mouvement mériterait certainement d'être étudié dans son rapport à Facebook, mais le livre a été publié avant.) Et elle analyse le rôle de l'Internet, en chercheuse qui le connait bien, en voit les forces et les limites.

En contraste, elle étudie également le mouvement des droits civiques aux États-Unis. Voici un mouvement de très grande importance, qui a tout fait sans disposer de l'Internet. Alors qu'aujourd'hui, deux ou trois messages sur Facebook peuvent être le point de départ d'une manifestation très importante, et très rapidement prête, le mouvement des droits civiques a dû ramer pendant de nombreux mois pour, par exemple, organiser sa grande manifestation à Washington. L'auteure ne dit pas que c'était mieux à l'époque ou mieux aujourd'hui : elle insiste plutôt sur les permanences de l'action politique. Mais elle note aussi les différences : si l'organisation était bien plus laborieuse à l'époque (pas question de coordonner les aspects matériels avec une feuille de calcul mise en ligne et partagée), cela avait également des avantages. Les militants apprenaient à se connaitre, à se faire confiance, même des activités a priori sans intérêt politique, comme l'organisation pratique des voyages pour aller sur le lieu de la manifestation, avaient l'avantage de créer des liens, qui allaient permettre au mouvement de rester solide dans les tempêtes, face à la répression, et surtout face aux choix tactiques et stratégiques nécessaires lorsque la situation évolue.

Au contraire, l'Internet permet de se passer de cette organisation, au moins au début. Un individu seul peut se créer son blog et s'exprimer là où, auparavant, il aurait dû mendier un espace d'expression aux médias officiels, ou bien rejoindre un parti ou un mouvement critique, pour pouvoir faire relayer ses idées. C'est un énorme avantage et un des grands succès de l'Internet. Mais cela entraine de nouveaux risques, comme le fait qu'on n'a plus besoin de supporter les difficultés du travail collectif, ce qui peut rendre plus compliquée la traduction des idées en actions qui changent les choses.

Parmi les affordances de l'Internet, il y a le fait que beaucoup de choses sont possibles sans organisation formelle. Des mouvements très forts (comme celui du parc Gezi) ont été possibles sans qu'un parti traditionnel ne les structure et ne les dirige. Mais, bien sûr, cet avantage a aussi une face négative : puisque la nécessité d'une organisation n'est pas évidente, on peut se dire qu'on peut s'en passer. Au début, ça se passe effectivement bien, sans les lourdeurs bureaucratiques exaspérantes. Mais, ensuite, les problèmes surgissent : le pouvoir en place fait des ouvertures. Comment y répondre ? Ou bien il change de tactique, et le mouvement doit s'adapter. Et, là, l'absence d'un mécanisme de prise de décision commun se fait sentir, et beaucoup de mouvements s'affaiblissent alors, permettant à la répression de disperser ce qui reste. J'avais été frappé, sur les ronds-points, par la fréquence du discours « ah non, surtout pas de partis, surtout pas de syndicats, surtout pas d'organisations et de porte-paroles », chez des gilets jaunes qui n'avaient sans doute pas étudié les théoriciens de l'anarchisme. Mais c'est que le débat est aussi ancien que la politique. L'Internet le met en évidence, en rendant possible des fonctionnements moins centralisés, mais il ne l'a pas créé.

Léger reproche à l'auteure : elle ne discute pas ce qui pourrait arriver avec d'autres outils que les gros réseaux centralisés étatsuniens comme Facebook ou Twitter. Il est vrai qu'on manque encore d'exemples détaillés à utiliser, il n'y a pas encore eu de révolution déclenchée sur le fédivers ou via Matrix.

Je n'ai donné qu'une idée très limitée de ce livre. Il est très riche, très nuancé, l'auteure a vraiment tenu à étudier tout en détail, et aucun résumé ne peut donc suffire. En conclusion, un livre que je recommande à toutes celles et tous ceux qui veulent changer le monde et se demandent comment faire. Il n'est ni optimiste, ni pessimiste sur le rôle de l'Internet dans les révolutions : « ni rire, ni pleurer, mais comprendre » (Spinoza, il semble).

Autre(s) article(s) en français sur ce livre :

Petit avertissement : j'ai reçu un exemplaire gratuit de ce livre.

2019-10-08

Version 12 d'Unicode

En mars dernier est sortie la version 12 d'Unicode. Une description officielle des principaux changements est disponible mais voici ceux qui m'ont intéressé particulièrement. (Il n'y a pas de changement radical.)

Pour explorer plus facilement la grande base Unicode, j'utilise un programme qui la convertit en SQL et permet ensuite de faire des analyses variées. Faisons quelques requêtes SQL :

ucd=> SELECT count(*) AS Total FROM Characters;
 total  
--------
 137994
Combien de caractères sont arrivés avec la version 12 ?
ucd=> SELECT version,count(version) FROM Characters GROUP BY version ORDER BY version::float;
...
 10.0    |  8518
 11.0    |   684
 12.0    |   554
 12.1    |     1
554 nouveaux, cette version 12 est très modérée. Quels sont ces nouveaux caractères ?
ucd=> SELECT To_U(codepoint) AS Codepoint, name FROM Characters WHERE version='12.0';
 codepoint |                                    name                                    
-----------+----------------------------------------------------------------------------
...
 U+1FA70   | BALLET SHOES
 ...
 U+2E4F    | CORNISH VERSE DIVIDER
 ...
 U+A7C3    | LATIN SMALL LETTER ANGLICANA W
 ...
 U+10FE0   | ELYMAIC LETTER ALEPH
 U+10FE1   | ELYMAIC LETTER BETH
 U+10FE2   | ELYMAIC LETTER GIMEL
 ...
 U+1E100   | NYIAKENG PUACHUE HMONG LETTER MA
 U+1E101   | NYIAKENG PUACHUE HMONG LETTER TSA
 U+1E102   | NYIAKENG PUACHUE HMONG LETTER NTA
 ...
 U+1F6D5   | HINDU TEMPLE
 U+1F6FA   | AUTO RICKSHAW
 ...
 U+1F97B   | SARI
 ...
 U+1F9A7   | ORANGUTAN
 ...
 U+1F9BB   | EAR WITH HEARING AID
 U+1F9BC   | MOTORIZED WHEELCHAIR
 U+1F9BD   | MANUAL WHEELCHAIR
 ...
 U+1FA30   | WHITE CHESS KNIGHT ROTATED TWO HUNDRED TWENTY-FIVE DEGREES
 U+1FA31   | BLACK CHESS KNIGHT ROTATED TWO HUNDRED TWENTY-FIVE DEGREES
Parmi les emojis de cette version, beaucoup concernent l'Inde, comme le sari ou le rickshaw. Beaucoup de caractères liés au handicap ont été créés, ainsi, mais c'est plus anecdotique, que beaucoup de caractères pour le jeu d'échecs. On trouve aussi des caractères étonnants comme U+2E4F, qui ne sert apparemment qu'à la poésie cornouaillaise. Et il y a bien sûr de nouvelles écritures comme l'élymaïque ou le nyiakeng puachue hmong. Même l'alphabet latin voit arriver de nouveaux caractères comme le U+A7C3.

Au fait, l'unique caractère de la version 12.1, c'était quoi ?

ucd=> SELECT To_U(codepoint) AS Codepoint, name FROM Characters WHERE version='12.1';
 codepoint |         name          
-----------+-----------------------
 U+32FF    | SQUARE ERA NAME REIWA
Une version d'Unicode uniquement pour introduire un caractère japonais permettant de noter l'ère Reiwa… (Merci à John Shaft pour avoir repéré celui-là.)

Tiens, d'ailleurs, combien de caractères Unicode sont des symboles (il n'y a pas que les emojis parmi eux, mais Unicode n'a pas de catégorie « emoji ») :

 ucd=> SELECT count(*) FROM Characters  WHERE category IN ('Sm', 'Sc', 'Sk', 'So');
 count 
-------
  7564
Ou, en plus détaillé, et avec les noms longs des catégories :
ucd=> SELECT description,count(category) FROM Characters,Categories WHERE Categories.name = Characters.category AND category IN ('Sm', 'Sc', 'Sk', 'So') GROUP BY category, description;
   description   | count 
-----------------+-------
 Modifier_Symbol |   123
 Other_Symbol    |  6431
 Math_Symbol     |   948
 Currency_Symbol |    62

Si vous avez les bonnes polices de caractères, voici les caractères pris en exemple plus haut : 🩰, , , 𐿠, 𐿡, 𐿢, 𞄀, 𞄁, 𞄂, 🛕, 🛺, 🥻, 🦧, 🦻, 🦼, 🦽, 🨰, 🨱, … (Si vous n'avez pas les bonnes polices, chaque lettre est un lien vers Uniview.)

2019-10-07

Une histoire populaire de la France

Excellent (vraiment excellent) livre d'histoire de la France, vu sous un angle différent de l'habituel : moins de rois et de princes, et d'avantage de gens du peuple.

Le titre fait référence à un livre très connu d'histoire des États-Unis. L'idée de départ est la même : les livres d'histoire traditionnels privilégient les gens importants, les « premiers de cordée », comme dirait Macron, et oublient les « 99 % ». On voit ainsi des historiens écrire sans sourciller que « Louis XIV a construit le château de Versailles », sans tenir compte des ouvriers.

Si les historiens tendent à privilégier ces « gens d'en haut », ça n'est pas forcément par conviction politique aristocratique, ou par mépris du peuple. C'est aussi parce que c'est plus facile. On dispose de tas de textes sur Louis XIV, de sa main, de celle de ses courtisans, de celle de ses ennemis, tout est bien documenté. Les nobles et les bourgeois de l'époque ont aussi parlé de leur classe sociale respective. Mais que sait-on des travailleurs de base ? Ils ne savaient en général pas écrire et, même quand c'était le cas, leurs textes ont rarement été gardés. On a des traces matérielles, mais peu de choses sur ce qu'ils ressentaient, leurs opinions, la vie quotidienne.

Et l'auteur ne résout pas complètement ce problème : il reconnait dès le début que l'historien manque de matériaux sur lesquels s'appuyer pour une histoire des classes populaires. Son livre est donc plutôt une histoire de France, en gardant sans cesse comme perspective que la France ne se limitait pas au roi et à la cour.

Le plan est classique, chronologique, de la guerre de Cent Ans à nos jours, soit 800 pages bien tassées. La question des débuts de la France est étudiée en détail ; à partir de quand les gens se disaient-ils français ? L'histoire traditionnelle est souvent anachronique, en qualifiant par exemple Jeanne d'Arc de patriote française, notion qui lui était bien étrangère. Les questions religieuses occupent ensuite beaucoup de place : au Moyen-Âge, tout conflit interne était présenté comme religieux, même quand ses causes profondes étaient politiques. L'auteur explique d'ailleurs que les guerres de religion ne méritaient que partiellement leur nom, et qu'elles avaient des racines qui n'étaient pas toujours religieuses.

L'esclavage et le colonialisme sont largement traités. Ils sont parfois absents des « histoires de la France », soit parce que ce n'était pas très glorieux, soit parce que les pays qui en furent victimes n'étaient pas la France. Ici, au contraire, ces questions sont vues en détail. Ces peuples n'avaient pas voulu faire partie de l'histoire de France, mais ils en sont devenus une composante importante. Comme l'accent du livre est mis sur le peuple, pas seulement comme sujet mais aussi comme acteur, les révoltes d'esclaves et les luttes anti-colonialistes jouent un rôle important.

Comme le peuple s'obstine à ne pas comprendre que les dirigeants veulent son bien, et qu'il se révolte de temps en temps, et de diverses manières, l'État développe ses moyens de contrôle. Noiriel explique ainsi le développement successif de la notion d'identité (comme dans « carte d'identité »), et le contrôle qu'elle permet.

La révolution industrielle fait franchir une nouvelle étape à ces processus, avec la création du prolétariat de masse, et la prise de conscience qui a suivi, permettant les nombreuses révoltes du 19e siècle. Mais l'articulation entre l'appartenance de classe et les opinions politiques est restée compliquée. Le parti communiste, par exemple, n'a jamais hésité à jouer la carte de la culpabilisation, écartant toutes les critiques de sa politique d'un « nous sommes un parti ouvrier, donc nous avons forcément raison ». Lorsque l'opposant était en effet né dans une famille bourgeoise, l'argument avait du poids. Comme le note Noiriel, « la culpabilité est mauvaise conseillère ». (Et elle continue à l'être.)

Par la suite, les changements dans l'organisation de la société, et une offensive idéologique importante, ont remis en cause cette conscience de classe. Aujourd'hui, l'idéologie dominante est identitaire et racialiste, faisant croire au prolétaire que sa nationalité, sa couleur de peau ou sa religion sont les choses importantes, niant les classes sociales. Cette méthode est efficace pour limiter le risque de révolte contre les dominants. Mais l'histoire n'est jamais terminée et les choses vont continuer à changer, peut-être en mieux, peut-être pas.

Je recommande fortement la lecture de ce livre, si vous voulez une histoire de France très complète, très documentée, et qui ne cherche pas à faire des raccourcis au milieu des chemins souvent complexes que cette histoire a empruntés.

2019-09-30

IPv6 sur un VPS Arch Linux chez OVH

L'hébergeur OVH a une offre nommée « VPS » (pour Virtual Private Server ») qui permet de disposer d'une machine virtuelle connectée à l'Internet, par exemple pour y héberger ses serveurs. Par défaut, on n'a que de l'IPv4 mais IPv6 est possible. Comme je n'ai pas trouvé de documentation qui marche pour le cas où la machine virtuelle tourne sous Arch Linux, je documente ici ma solution, pour que les utilisateurs des moteurs de recherche la trouvent.

Donc, le problème est le suivant. Soit un VPS OVH utilisant le système d'exploitation Arch Linux. Configuré et démarré, il n'a qu'une adresse IPv4 ce qui, en 2019, est inacceptable. OVH permet de l'IPv6, mais ce n'est pas configuré automatiquement par leur système « Cloud Init ». Il faut donc le faire soi-même. OVH documente la façon de faire mais Arch Linux n'y est pas mentionné. Du côté de ce système d'exploitation, IPv6 est documenté (il faut utiliser NetCtl). A priori, c'est simple, en utilisant les deux documentations, on devrait y arriver. Sauf que cela n'a pas marché, la machine, après redémarrage, n'a toujours pas d'adresse IPv6, et qu'il n'y a pas d'information de déboguage disponible. Pas moyen de savoir où je me suis trompé.

Après une heure d'essais infructueux, je suis donc passé à une méthode simple et qui marche immédiatement : écrire un script shell de deux lignes et le faire exécuter au démarrage de la machine. Le script était simplement :

ip -6 addr add 2001:41d0:302:2200::180/128 dev eth0
ip -6 route add 2001:41d0:302:2200::1 dev eth0
ip -6 route add default via 2001:41d0:302:2200::1
    
Cette façon de faire est un peu bizarre, avec ce préfixe de longueur 128 (normalement, cela devrait être 64), qui oblige à mettre une route vers… le routeur, mais c'est cohérent avec ce qui est fait par défaut pour IPv4. Une solution plus propre aurait été :
ip -6 addr add 2001:41d0:5fa1:b49::180/64 dev eth0
ip -6 route add default via 2001:41d0:5fa1:b49::1
    
Et cela marche mais je ne suis pas sûr que cela permette de joindre les machines du même réseau.

Les adresses IP à utiliser (votre machine, et le routeur par défaut) sont obtenues via l'espace client (manager) de votre compte OVH, rubrique Serveur → VPS → IP.

Une fois ce script écrit, stocké en /usr/local/sbin/start-ipv6, et rendu exécutable, il reste à le lancer au démarrage. Pour cela, je me sers de systemd. Je crée un fichier /etc/systemd/system/ipv6.service. Il contient :

[Unit]
Description=Starts IPv6
After=systemd-networkd.service
Before=network.target 

[Service]
ExecStart=/bin/true
ExecStartPost=/usr/local/sbin/start-ipv6

[Install]
WantedBy=multi-user.target
    
J'active ce service avec systemctl enable ipv6 et, au redémarrage de la machine, tout va bien et on a IPv6.

Documentation technique de mon résolveur DoH

Cet article documente le fonctionnement interne du résolveur DoH https://doh.bortzmeyer.fr/ et du résolveur DoT dot.bortzmeyer.fr. Il concerne donc essentiellement les technicien·ne·s. Si vous vous intéressez plutôt aux conditions d'utilisation de ce service, voyez l'article décrivant la politique.

Pour comprendre les protocoles DoH et DoT, il faut relire les normes qui les décrivent, respectivement les RFC 8484 et RFC 7858.

C'est le même résolveur qui gère les deux protocoles. Si une version initiale de ce résolveur DoH utilisait une mise en œuvre en Python que j'avais écrite lors d'un hackathon de l'IETF, la version « de production » se sert de l'excellent logiciel dnsdist. dnsdist est un frontal pour serveurs DNS, assurant des fonctions telles que la répartition de charge et, ce qui nous intéresse surtout ici, le relais entre différents protocoles. Ici, dnsdist a été configuré pour accepter des connexions DoH et DoT (mais pas le traditionnel DNS sur UDP, ni sur TCP en clair, d'ailleurs) et pour relayer les requêtes DNS vers le « vrai » résolveur.

La machine est une Arch Linux tournant chez OVH, sur l'offre nommée « VPS ».

La configuration de dnsdist se trouve dans un fichier de configuration, dnsdist.conf. N'hésitez pas à consulter la documentation très complète de dnsdist. Voyons les points essentiels.

On fait du DoH donc on lance un service DoH, en IPv4 et en IPv6 :

    
addDOHLocal("0.0.0.0:443", "/etc/dnsdist/server-doh.pem", "/etc/dnsdist/server-doh.key", "/", {minTLSVersion="tls1.2", customResponseHeaders={["link"]="<https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html> rel=\"service-meta\"; type=\"text/html\""}}) 
addDOHLocal("[::]:443", "/etc/dnsdist/server-doh.pem", "/etc/dnsdist/server-doh.key", "/", {minTLSVersion="tls1.2", customResponseHeaders={["link"]="<https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html> rel=\"service-meta\"; type=\"text/html\""}})

  
Pour améliorer un peu la sécurité, on exige du TLS 1.2 au minimum. Notez qu'il y aurait plein d'autres paramètres à configurer (refuser des algorithmes trop faibles), pour avoir une meilleure note sur SSLlabs. Et les trucs bizarres qui commencent par customResponseHeaders ? Il s'agit d'utiliser la technique du RFC 8631 pour indiquer des méta-informations sur le service, ici, la politique suivie. Cela donne :

% curl -v https://doh.bortzmeyer.fr/help
...
< HTTP/2 200 
< server: h2o/dnsdist
< link: <https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html> rel="service-meta"; type="text/html"
< content-length: 86
< 

  
Pour avoir des URL « spéciaux » ne faisant pas du DoH, on ajoute aussi :

supportpagemap = { newDOHResponseMapEntry("^/rfc$", 307, "https://www.rfc-editor.org/info/rfc8484"),
                   newDOHResponseMapEntry("^/about$", 307, "https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html"),
                   newDOHResponseMapEntry("^/policy$", 307, "https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html"),
		   newDOHResponseMapEntry("^/help$", 200, "For the server policy, see <https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html>.") }
dohFE = getDOHFrontend(0)
dohFE:setResponsesMap(supportpagemap)
dohFE6 = getDOHFrontend(1)
dohFE6:setResponsesMap(supportpagemap)

Ces instructions disent à dnsdist de rediriger /policy vers l'article décrivant la politique, et d'afficher un court message pour /help.

Et on veut faire du DoT, pas seulement du DoH, donc on met aussi :

addTLSLocal("0.0.0.0:853", "/etc/dnsdist/server-dot.pem", "/etc/dnsdist/server-dot.key", {minTLSVersion="tls1.2"})
addTLSLocal("[::]:853", "/etc/dnsdist/server-dot.pem", "/etc/dnsdist/server-dot.key", {minTLSVersion="tls1.2"})

Le résolveur est public, donc les ACL autorisent tout le monde :

addACL('0.0.0.0/0')
addACL('[::]/0')
  
Mais on se méfie quand même des clients trop enthousiastes donc on les limite à cent requêtes par seconde :
addAction(MaxQPSIPRule(100), DropAction()) 
  
Au passage, il faut dire un mot de addAction car il sert souvent. dnsdist permet de définir des politiques à appliquer lors du traitement d'une requête DNS (la documentation dit « paquet », mais, apparemment, il s'agit bien d'une requête). La syntaxe générale (cf. la documentation) est addAction(critère, action) avec de nombreux critères possibles (ici, « a fait plus de 100 r/s ») et plein d'actions disponibles (ici, ignorer la requête).

dnsdist est un répartiteur de charge, il n'est pas un résolveur DNS. Il faut donc un ou plusieurs « vrais » résolveurs derrière. Le principal résolveur, pour le service https://doh.bortzmeyer.fr, est un Unbound qui tourne sur la même machine. Au cas où quelque chose irait mal, un second résolveur, complètement indépendant, est fourni par OVH. dnsdist permet de choisir quel résolveur utiliser et j'ai mis :

  
setServerPolicy(firstAvailable)
newServer({address="127.0.0.1:53", name="Local-Unbound"})	
newServer({address="213.186.33.99:53", name="OVH"})
Pourquoi firstAvailable ? Parce que je voulais éviter autant que possible d'envoyer des requêtes à ce second résolveur que je ne contrôle pas et dont je ne connais pas la politique en matière de vie privée. Comme voulu, la quasi-totalité des requêtes arrivent donc au premier résolveur :
> showServers()
#   Name                 Address                       State     Qps    Qlim Ord Wt    Queries   Drops Drate   Lat Outstanding Pools
0   Local-Unbound        127.0.0.1:53                     up     0.0       0   1  1       2509       0   0.0  70.4           0 
1   OVH                  213.186.33.99:53                 up     0.0       0   1  1          0       0   0.0   0.0           0 
All                                                              0.0                      2509       0                         
  

Pour pouvoir utiliser la console de dnsdist, comme ci-dessus, il faut l'activer dans le fichier de configuration :

controlSocket('[::1]:5199')
setKey("kg...=")
  
(La documentation explique quelle valeur indiquer à setKey().) L'accès à la console se fait ensuite avec dnsdist -c :
%  dnsdist -c
> dumpStats()
acl-drops              	          0    latency0-1             	       5058
cache-hits             	       4429    latency1-10            	        351
cache-misses           	       2571    latency10-50           	        785
cpu-sys-msec           	      12929    latency100-1000        	        388
cpu-user-msec          	      47305    latency50-100          	        280
...
 

dnsdist dispose également d'un serveur Web minimal, permettant de regarder l'état du service (ce n'est pas un site Web d'administration, c'est juste pour jeter un coup d'œil). Voici une configuration typique :

webserver("[::1]:8082", "2e...", "a5..")
 
Les deux derniers paramètres indiquent le mot de passe à utiliser pour les accès au site Web et la clé pour l'API. Ici, le serveur n'écoute que sur une adresse locale. Si vous voulez le rendre accessible de l'extérieur, comme il ne gère pas HTTPS, il vaut mieux le mettre derrière un relais. J'ai utilisé stunnel, avec cette configuration :
[dnsdist]
accept  = 8083
connect = localhost-ipv6:8082
cert = /etc/stunnel/stunnel.pem
key = /etc/stunnel/stunnel.key
 
Cela me permet de regarder de l'extérieur :

Et pour l'API de ce serveur interne, qui renvoie des résultats en JSON :

% curl -s --header "X-API-Key: XXXX" https://doh.bortzmeyer.fr:8083/api/v1/servers/localhost/statistics | jq .
[
  {
    "name": "responses",
    "type": "StatisticItem",
    "value": 2643
  },
  {
    "name": "queries",
    "type": "StatisticItem",
    "value": 3698
  },
...
   

Il y a aussi quelques paramètres liés aux performances du serveur. Celui-ci active la mémoire de dnsdist, qui gardera au maximum 100 000 enregistrements DNS :

  
pc = newPacketCache(100000)
getPool(""):setCache(pc)			
Pour l'instant, cette valeur est énorme pour ce modeste serveur. Dans la console :
> getPool(""):getCache():printStats()
Entries: 84/100000
Hits: 1127
Misses: 2943
...
Cette mémoire explique pourquoi, plus haut, le serveur indiquait davantage de requêtes que de réponses (il ne compte comme réponse que ce qui a été traité par les vrais résolveurs). Autres réglages, portant sur le réseau, qu'il me reste à ajuster dès que le serveur recevra du trafic abondant :
setMaxUDPOutstanding(65535)     -- Nombre maximum de requêtes en attente pour un résolveur
setMaxTCPClientThreads(30) 	-- Nombre maximum de fils d'exécution TCP (chacun pouvant traiter plusieurs clients)
setMaxTCPConnectionDuration(1800) -- Après trente minutes, on raccroche
setMaxTCPQueriesPerConnection(300) -- Après trois cents requêtes, on raccroche 
setMaxTCPConnectionsPerClient(10) -- Dix connexions pour un seul client, c'est déjà beaucoup, mais il faut penser à des choses comme le CG-NAT
  

dnsdist permet d'enregistrer chaque requête DNS, par exemple dans un fichier. Cette fonction n'est pas activée sur https://doh.bortzmeyer.fr car elle serait contraire aux promesses faites quant au respect de la vie privée. Mais c'est un bon exemple d'utilisation de addAction pour toutes les requêtes (AllRule) :

-- addAction(AllRule(), LogAction("/tmp/dnsdist.log", false, true, false))
(Attention si vous utilisez systemd, avec l'option PrivateTmp=true, le fichier journal sera mis quelque part sous /tmp/systemd-private-XXXXXXX-dnsdist.service-Ijy8yw, pour être plus difficile à trouver.) Les lignes journalisées sont du genre :
Packet from [2001:db8::a36b::64]:44364 for www.ietf.org. AAAA with id 8283
Pour la même raison de vie privée, je n'utilise pas la TeeAction (qui permet de copier les requêtes ailleurs) ou dnstap.

De même qu'on ne journalise pas, on ne ment pas. dnsdist peut le faire via SpoofAction() ou bien avec un script Lua spécifique, pour faire des choses horribles comme bloquer un type de données particulier :

luarule(dq) if (dq.qtype==dnsdist.NAPTR) then return DNSAction.Nxdomain, "" else return DNSAction.Allow, "" end end
addLuaAction(AllRule(), luarule)
  

DoH et DoT fonctionnent tous les deux sur TLS (RFC 8446) et utilisent donc son mécanisme d'authentification via des certificats PKIX (RFC 5280). Il faut donc obtenir des certificats raisonnablement reconnus par les clients donc, comme tout le monde, j'ai utilisé Let's Encrypt. dnsdist n'inclut pas de client ACME (RFC 8555), j'ai donc utilisé certbot que je fais tourner en mode autonome (standalone). Cela marche car dnsdist n'écoute que sur le port 443 alors qu'ACME n'utilise que le 80. Pour créer le certificat initial :

certbot certonly -n --standalone --domain doh.bortzmeyer.fr
  
Et pour le renouveler :
certbot renew --standalone --reuse-key --deploy-hook /usr/local/sbin/restart-dnsdist
  
(restart-dnsdist contient dnsdist -e 'reloadAllCertificates()'.) Et voici les liens symboliques configurés pour pointer vers les répertoires utilisés par Let's Encrypt :
% ls -lt                                                                        
total 28
lrwxrwxrwx  1 root root   51 Sep 24 15:50 server-dot.key -> /etc/letsencrypt/live/dot.bortzmeyer.fr/privkey.pem
lrwxrwxrwx  1 root root   53 Sep 24 15:50 server-dot.pem -> /etc/letsencrypt/live/dot.bortzmeyer.fr/fullchain.pem
lrwxrwxrwx  1 root root   51 Sep 15 16:31 server-doh.key -> /etc/letsencrypt/live/doh.bortzmeyer.fr/privkey.pem
lrwxrwxrwx  1 root root   53 Sep 15 16:31 server-doh.pem -> /etc/letsencrypt/live/doh.bortzmeyer.fr/fullchain.pem
...
  
Avec gnutls-cli, on peut voir le certificat utilisé :
% gnutls-cli dot.bortzmeyer.fr:853
...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=dot.bortzmeyer.fr', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x047aa99cbff8ac180c4c3b14935d9599b1f5, RSA key 2048 bits, signed using RSA-SHA256, activated `2019-09-24 12:46:32 UTC', expires `2019-12-23 12:46:32 UTC', key-ID `sha256:787005b3173d1c95bc425241ea40e5474b644f00fded7fd35d87350331644c56'
	Public Key ID:
		sha1:696c94f0f093a3b1037ffcb2fcd9d23859d539bc
		sha256:787005b3173d1c95bc425241ea40e5474b644f00fded7fd35d87350331644c56
	Public key's random art:
		+--[ RSA 2048]----+
		|      o          |
		|       = o       |
		|    . . O     ...|
		|     o B +    .+.|
		|      = S    .  o|
		|       = .  .  E |
		|        . .=     |
		|       . o=o.    |
		|        o.oo.    |
		+-----------------+

- Certificate[1] info:
 - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x0a0141420000015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', key-ID `sha256:60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18'
- Status: The certificate is trusted. 
- Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM)
...
  
Pour pouvoir authentifier le serveur par d'autres moyens que la chaîne de confiance PKIX (par exemple par épinglage de la clé, ou par DANE), je demande à certbot de ne pas changer la clé lors des renouvellements de certificats, avec l'option --reuse-key (cf. mon précédent article sur la question).

À propos de DANE (RFC 6698), j'ai créé les enregistrements nécessaires avec hash-slinger :

% tlsa --create --selector 1  --port 853 dot.bortzmeyer.fr
Got a certificate with Subject: /CN=dot.bortzmeyer.fr
_853._tcp.dot.bortzmeyer.fr. IN TLSA 3 1 1 787005b3173d1c95bc425241ea40e5474b644f00fded7fd35d87350331644c56
  
Puis je les mets dans le fichier de zone DNS, et on peut voir les enregistrements avec dig :
    
% dig TLSA _853._tcp.dot.bortzmeyer.fr
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15141
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 11
...
;; ANSWER SECTION:
_853._tcp.dot.bortzmeyer.fr. 86400 IN TLSA 3 1 1 (
				787005B3173D1C95BC425241EA40E5474B644F00FDED

  
Et on peut les vérifier :
  
% tlsa --verify --resolvconf="" doh.bortzmeyer.fr
SUCCESS (Usage 3 [DANE-EE]): Certificate offered by the server matches the TLSA record (193.70.85.11)
SUCCESS (Usage 3 [DANE-EE]): Certificate offered by the server matches the TLSA record (2001:41d0:302:2200::180)
Et superviser le tout depuis Icinga.

On a vu qu'il y avait deux résolveurs DNS derrière dnsdist, le principal, géré par moi, et un résolveur de secours. Le résolveur principal utilise Unbound. Pour mieux protéger la vie privée, il utilise la QNAME minimisation du RFC 7816. Dans le unbound.conf, on a  :

server:
  qname-minimisation: yes
  
Vous pouvez vérifier que c'est bien activé avec le domaine de test qnamemintest.internet.nl et l'outil test-doh présenté plus loin :
% test-doh https://doh.bortzmeyer.fr qnamemintest.internet.nl TXT
...
a.b.qnamemin-test.internet.nl. 10 IN TXT "HOORAY - QNAME minimisation is enabled on your resolver :)!"
  
Alors qu'avec un autre résolveur DoH, moins soucieux de vie privée :
% test-doh https://dns.google/dns-query qnamemintest.internet.nl TXT   
...
a.b.qnamemin-test.internet.nl. 9 IN TXT "NO - QNAME minimisation is NOT enabled on your resolver :("
  
J'ai aussi mis quelques autres paramètres Unbound, typiquement pour durcir la résolution face à diverses menaces :
  harden-glue: yes
  harden-below-nxdomain: yes
  harden-dnssec-stripped: yes
  harden-referral-path: yes
  aggressive-nsec: yes
  

Avec tout ça, je crois ne pas avoir dit comment j'avais installé dnsdist. Comme il n'existe pas de paquetage dnsdist dans Arch Linux (mais il existe dans AUR), j'ai téléchargé le source et compilé moi-même, selon les instructions. D'abord, j'ai téléchargé et installé la bibliothèque libh2o, qui permet à dnsdist de parler HTTP/2 (RFC 7540) :

cmake .
make
make install
  
Puis on peut installer dnsdist :
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig  ./configure --enable-dns-over-tls --enable-dns-over-https
make
make install
  

Testons maintenant, d'abord avec kdig (qui fait partie de Knot, et notez la première ligne de la réponse) :

    
% kdig  +tls @dot.bortzmeyer.fr nextinpact.com
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 56403
;; Flags: qr rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; nextinpact.com.     		IN	A

;; ANSWER SECTION:
nextinpact.com.     	118	IN	A	45.60.122.203
nextinpact.com.     	118	IN	A	45.60.132.203

;; Received 75 B
;; Time 2019-10-03 17:34:29 CEST
;; From 2001:41d0:302:2200::180@853(TCP) in 14.1 ms
  
Puis grâce aux sondes RIPE Atlas, le service. Les Atlas savent faire du DoT. Voyons d'abord en IPv6 (le choix par défaut) :
%  blaeu-resolve --dnssec --displayvalidation --displayrtt --tls --nameserver=dot.bortzmeyer.fr --nsid --sort --requested=1000   cyberstructure.fr  
Nameserver dot.bortzmeyer.fr
[ (Authentic Data flag)  2001:4b98:dc0:41:216:3eff:fe27:3d3f] : 956 occurrences Average RTT 1572 ms
[TIMEOUT] : 17 occurrences Average RTT 0 ms
[TUCONNECT (may be a TLS negotiation error)] : 14 occurrences Average RTT 0 ms
Test #22928943 done at 2019-09-30T09:37:15Z
  
Il y a quand même trop d'échecs. Ceci dit, il s'agit parfois de problèmes réseau et pas de problèmes DoT. Essayons ICMP Echo avec les mêmes sondes :
  
% blaeu-reach --old_measurement=22928943 --by_probe 2001:41d0:302:2200::180

493 probes reported
Test #22929082 done at 2019-09-30T09:48:25Z
Tests: 487 successful probes (98.8 %), 6 failed (1.2 %), average RTT: 72 ms
Donc, au moins une partie des problèmes n'est pas spécifique à DoT. Pour les autres cas d'échec, on peut aussi imaginer que certains réseaux ne laissent pas sortir les communications vers le port 853, qu'utilise DoT (c'est d'ailleurs une des principales raisons qui a motivé le développement de DoH qui, utilisant HTTPS, est plus difficile à bloquer). En attendant, essayons en IPv4 :
%  blaeu-resolve --dnssec --displayvalidation --displayrtt --tls --nameserver=dot.bortzmeyer.fr --nsid --sort --requested=1000  -4 cyberstructure.fr  
Nameserver dot.bortzmeyer.fr
[ (Authentic Data flag)  2001:4b98:dc0:41:216:3eff:fe27:3d3f] : 971 occurrences Average RTT 975 ms
[TIMEOUT] : 9 occurrences Average RTT 0 ms
[TUCONNECT (may be a TLS negotiation error)] : 6 occurrences Average RTT 0 ms
Test #22929087 done at 2019-09-30T09:51:59Z

% blaeu-reach --old_measurement=22929087  --by_probe  193.70.85.11
494 probes reported
Test #22929254 done at 2019-09-30T11:35:16Z
Tests: 494 successful probes (100.0 %), 0 failed (0.0 %), average RTT: 78 ms
  
C'est clair, on a moins d'erreurs. L'Internet est hélas moins fiable en IPv6 (surtout vu les difficultés de configuration d'IPv6 chez OVH).

J'ai utilisé plus haut le script test-doh pour tester le serveur. Ce script est écrit en Python et disponible en test-doh.py. Exemple d'utilisation :

% test-doh https://doh.bortzmeyer.fr netflix.com AAAA
id 0
opcode QUERY
rcode NOERROR
flags QR RD RA
;QUESTION
netflix.com. IN AAAA
;ANSWER
netflix.com. 60 IN AAAA 2a01:578:3::3431:7806
netflix.com. 60 IN AAAA 2a01:578:3::22fd:6807
netflix.com. 60 IN AAAA 2a01:578:3::36e5:444d
...
;AUTHORITY
;ADDITIONAL
  
On peut aussi utiliser doh-client.sh, qui appelle curl, et utilise deux programmes Python, dns-t2b.py et dns-b2t.py pour créer les messages DNS en entrée et les lire à la sortie (DoH n'utilise pas JSON ou XML, mais le format binaire du DNS.)

Le service est supervisé par Icinga. Pour DoT, je me sers d'un programme développé lors d'un hackathon IETF. (Il y a depuis une version plus propre dans getdns, le programme dans le paquetage Debian getdns-utils se nomme getdns_server_mon.) Lancé à la main, il donne :

 % /usr/local/lib/nagios/plugins/check_dns_with_getdns -H 2001:41d0:302:2200::180 -n nextinpact.com
GETDNS OK - 16 ms, expiration date 2019-12-23, auth. None:  Address 45.60.132.203 Address 45.60.122.203
  
Pour DoH, certains des tests sont les tests génériques des monitoring plugins, par exemple le test de l'expiration du certificat (pour ne pas être surpris si les renouvellements Let's Encrypt se sont mal passés). Cela se configure avec :
vars.http_vhosts["doh-http"] = {
    http_uri = "/"
    http_vhost = "doh.bortzmeyer.fr"
    http_ssl = true
    http_sni = true
    http_timeout = 15
    http_certificate = "4,2"
    }
  
Ainsi, je suis prévenu s'il reste moins de quatre jours au certificat (et une alarme est levée s'il ne reste que deux jours). Autre test générique, que le serveur renvoie bien un échec si on ne lui parle pas en DoH correctement :
vars.http_vhosts["doh-raw-http"] = {
    http_uri = "/"
    http_vhost = "doh.bortzmeyer.fr"
    http_ssl = true
    http_sni = true
    http_timeout = 15
    http_expect = 400
    http_string = "Unable to parse the request"
    }
  
Mais il faut évidemment tester que le serveur répond bien aux requêtes DoH. On utilise pour cela un script dérivé du test-doh cité plus haut, check_doh.py. Utilisé à la main, ça donne :
% /usr/local/lib/nagios/plugins/check_doh -H doh.bortzmeyer.fr -n nextinpact.com
https://doh.bortzmeyer.fr/ OK - No error for nextinpact.com/AAAA, 107 bytes received
   
Et pour l'intégrer dans Icinga, on déclare une commande dans commands.conf :
object CheckCommand "doh_monitor" {                                               
  command = [ PluginContribDir + "/check_doh" ]                                          
                                                                 
  arguments = {                                                                
          "-H" = "$address6$",
          "-n" = "$doh_lookup$",                                    
          "-p" = "$doh_path$",                                   
          "-V" = "$doh_vhost$",                                         
          "-t" = "$doh_type$",                                        
          "-p" = "$doh_post$",                                                   
          "-i" = "$doh_insecure$",                                       
          "-h" = "$doh_head$"                                                  
          }                                                        
}                                                                                     
  
Puis un service dans services.conf :
Apply Service "doh" {                                                                   
  import "generic-service"                                                     
                                                                                 
  check_command = "doh_monitor"                                                                   
    assign where (host.address || host.address6) && host.vars.doh                                        
}                                                                                          
  
On peut alors configurer la machine à superviser :
     vars.doh = true
     vars.doh_vhost = "doh.bortzmeyer.fr"
     vars.doh_lookup = "fr.wikipedia.org"
     vars.doh_post = true
   
On supervise également le serveur Web internet :
vars.http_vhosts["doh-admin"] = {
    http_uri = "/api/v1/servers/localhost"
    http_port =	8083
    http_vhost = "doh.bortzmeyer.fr"
    http_ssl = true
    http_sni = true
    http_timeout = 15
    http_header = "X-API-Key: 23b..."
    http_string = "dohFrontends"
    }
}
   

Il existe d'autres résolveurs DoH gérés par des associations ou des individus, comme celui du .cz, https://www.nic.cz/odvr/ ou comme celui de l'association 42l. Mais je n'en trouve pas (pour l'instant) qui ait documenté en détail leur configuration technique.

Sinon, si vous aimez lire, il y a les très bons supports de l'exposé de Shaft à Pas Sage En Seine (plein de DoT et un peu de DoH.)

2019-09-29

Permanent record

Tout le monde connait bien sûr Edward Snowden, le héros grâce à qui les citoyens ordinaires ont des informations précises et étayées sur la surveillance de masse qu'exercent les États sur les citoyens. S'il a fait plusieurs interventions à distance, depuis son exil, il n'avait pas encore raconté de manière détaillée son parcours. C'est ce qu'il fait dans ce livre.

(J'ai lu ce livre en anglais car le titre de la traduction française m'avait semblé bizarre. Permanent record, c'est « Dossier qui vous suivra toute la vie » ou « Fiché pour toujours », certainement pas « Mémoires vives ».)

Je n'étais pas sûr de l'intérêt de ce livre : on peut être un héros sans savoir écrire, un informaticien compétent sans capacités pédagogiques, un lanceur d'alerte sans avoir guère de connaissances politiques. Mais j'ai été agréablement surpris : le livre est très bien écrit (Snowden remercie à la fin ceux qui ont lui ont appris à faire un livre intéressant), souvent drôle, malgré la gravité des faits, et Snowden explique très bien les questions informatiques comme le fonctionnement des services de surveillance étatiques.

Une partie du livre, surtout au début, est plutôt personnelle : enfance, jeunesse, débuts dans l'informatique. L'auteur décrit très bien la passion qu'est l'informatique, comment le hacker veut savoir comment ça marche, comment les erreurs aident à progresser. Tout informaticien se reconnaitra sans peine. (Si vous croisez quelqu'un qui dit « je ne comprends pas comment on peut être passionné par l'informatique », faites-lui lire ce livre.) Après commence la vie professionnelle, et Snowden démonte très bien le mécanisme pervers de recrutement des agences gouvernementales étatsuniennes : plutôt que d'avoir des fonctionnaires, on fait appel à des sous-traitants, qui facturent cher et font vivre un certain nombre de boites parasites, qui se contentent de mettre en rapport les informaticiens et l'État. Toute personne qui a travaillé dans une SSII reconnaitra ce monde, où on n'est jamais dans l'entreprise qui vous a embauché, et où on est parfois sous-traitant du sous-traitant. La majorité des gens qui conçoivent et font fonctionner le système de surveillance de masse sont des employés du privé…

Les amateurs de récits d'espionnage, même s'il n'y a évidemment aucun secret militaire dans ce livre, seront ravis des explications sur le fonctionnement interne des services de sécurité étatsuniens, monde très opaque et très complexe, qui est ici bien décortiqué.

La divergence entre Snowden et ses collègues a lieu après : la plupart des passionnés d'informatique accepteront sans problème de travailler pour Palantir, pour Facebook, pour Criteo ou pour la NSA. Ils ne se poseront pas de questions, se disant « de toute façon, c'est comme ça, on ne peut rien y faire » ou bien « la technique est neutre, je ne suis pas responsable de ce que les chefs font de mes programmes ». C'est là que Snowden suit une autre voie : il s'interroge, il se pose des questions, il lit, au grand étonnement de ses collègues de la CIA ou de la NSA, le texte de la constitution, et il finit par décider d'alerter le public sur le système d'espionnage qui avait été mis en place de manière complètement illégale (et qui l'est toujours).

Les amateurs de sécurité informatique pratique liront avec intérêt les réflexions d'Edward Snowden qui, sans pouvoir en parler avec personne, a dû concevoir un mécanisme pour sortir des locaux de la NSA, les innombrables documents qui ont fait les « révélations Snowden ». Je vous divulgue tout de suite un truc : les cartes SD (surtout microSD) sont bien plus discrètes que les clés USB, ne font pas sonner les détecteurs de métaux, et peuvent être avalées plus rapidement en cas d'urgence. Pendant qu'on en est aux conseils techniques, Snowden insiste sur l'importance du chiffrement, la principale protection technique sérieuse (mais pas à 100 %) contre la surveillance. Un des intérêts de ce livre est de revenir sur des points sur lesquels les discussions suite aux révélations de Snowden avaient parfois été brouillées par du FUD, où des gens plus ou moins bien intentionnés avaient essayé de brouiller le message en disant « mais, le chiffrement, ça ne protège pas vraiment », ou bien « mais non, PRISM, ce n'est pas une récolte directement auprès des GAFA ». Snowden explique clairement les programmes de la NSA, aux noms pittoresques, et les mécanismes de protection existants, au lieu de pinailler pour le plaisir de pinailler comme cela se fait parfois en matière de sécurité informatique.

Puis, une fois les documents sortis, c'est le départ pour Hong Kong et l'attente dans la chambre d'hôtel avant la rencontre avec Glen Greenwald et Laura Poitras, qui a filmé ces journées pour son remarquable documentaire « Citizenfour » (si vous ne l'avez pas vu, arrêtez de lire ce blog et allez voir ce documentaire).

Le livre n'a pas vraiment de conclusion : c'est à nous désormais de l'écrire.

2019-09-24

Assises régionales de la cyber-sécurité à Bordeaux

À Bordeaux, le 23 septembre 2019, se sont tenues les RSSIA, « Assises régionales de la cyber-sécurité », organisées par le CLUSIR Aquitaine. J'y ai parlé de choix politiques en matière de sécurité informatique.

Je suis parti de mon livre, « Cyberstructure », qui parle des relations entre l'infrastructure technique et la politique. Comme le sujet de cette réunion était la sécurité, je me suis focalisé sur les questions liées à la « cybersécurité ». Voici les supports de ma présentation : au format PDF et le source LaTeX/Beamer. Désolé pour celles et ceux qui n'étaient pas présents, il n'y a pas eu de captation vidéo.

Comme dans la plupart des événements du même genre, il y avait également une exposition avec de nombreux stands. Sur l'un d'eux, une boite annonçait sur ses kakemonos qu'elle fournissait un « cryptage renforcé » qui m'a laissé perplexe.

Lors du discours de bienvenue en séance plénière, le président du conseil régional, Alain Rousset, a plaisanté sur le futur « campus de cybersecurité » aquitain en proposant qu'il soit baptisé Lisbeth Salander.

Dans les conférences techniques, Renaud Lifchitz a parlé de calculateurs quantiques, résumant l'état de l'art et ses conséquences pour la cryptographie (voir à ce sujet mon exposé à Pas Sage En Seine). J'y ai appris que le nombre de vrais calculateurs quantiques accessibles gratuitement sur l'Internet augmentait. Il n'y a pas que celui d'IBM, même Alibaba en propose un. L'auteur a également rappelé que, trois jours plus tôt, Google avait annoncé (puis retiré l'article) avoir atteint la « suprématie quantique », ce moment où un calculateur quantique va plus vite qu'un ordinateur classique émulant le calculateur quantique.

Et Rayna Stamboliyska a fait le bilan de son livre « La face cachée d'Internet ». Depuis sa parution il y a deux ans, la cybersécurité a-t-elle progressé ? Pas tellement, par rapport à l'ampleur de la menace. Il y a eu des changements : la quasi-disparition de l'« hacktivisme » indépendant, le progrès des attaques menées par des groupes proches de l'État, comme en Russie (tel que CyberBerkut) ou en Chine, le développement de l'Internet des objets, catastrophique pour la sécurité. Mais on voit toujours des machines connectées à l'Internet avec un RabbitMQ grand ouvert, laissant lire tous les messages, voire permettant d'en injecter. L'auteure est également revenue sur le mythe journalistique du « darknet » en notant qu'il n'y a guère que 50 000 domaines en .onion, la plupart avec un niveau de fiabilité très bas (« vu l'uptime des .onion, heureusement qu'ils ne signent pas de SLAs »), alors que les opérations et ventes illégales se font plutôt sur Instagram, WhatsApp, etc.

Le protocole DoH et pourquoi il y a tant de discussions

Le 6 septembre dernier, Mozilla a annoncé l'activation du protocole DoH par défaut dans leur navigateur Firefox. (Et, même si ce n'est pas explicite, il est prévu que ce soit par défaut avec le résolveur de Cloudflare.) Cette annonce a suscité beaucoup de discussions, souvent confuses et mal informées. Cet article a pour but d'expliquer la question de DoH, et de clarifier le débat.

DoH veut dire « DNS sur HTTPS ». Ce protocole, normalisé dans le RFC 8484, permet l'encapsulation de requêtes et de réponses DNS dans un canal cryptographique HTTPS menant au résolveur. Le but est double : empêcher un tiers de lire les requêtes DNS, qui sont souvent révélatrices (cf. RFC 7626), et protéger les réponses DNS contre des modifications, faites par exemple à des fins de censure. Le statu quo (laisser le DNS être le seul protocole important qui ne soit pas protégé par la cryptographie) n'est pas tolérable, et il faut donc féliciter Mozilla d'avoir agi. Mais cela ne veut pas dire que tout soit parfait dans leur décision. Notamment, DoH, comme toutes les solutions reposant sur TLS, ne fait que sécuriser le canal de communication contre la surveillance et la manipulation par un tiers. Il ne garantit pas que le partenaire à l'autre bout du canal est gentil. Faire du DoH vers un méchant résolveur ne serait donc pas très utile, et le choix du résolveur est donc crucial.

Voyons maintenant les principales critiques qui ont été faites contre DoH et/ou contre la décision de Mozilla (si j'en ai oublié, écrivez-moi). Rappelez-vous bien que le débat est très confus, en partie par mauvaise foi de certains, en partie par ignorance (du DNS ou de la sécurité). Notamment, certaines des critiques formulées contre DoH n'ont rien à voir avec DoH mais, par exemple, avec un aspect spécifique de la décision de Mozilla. Et, parfois, d'autres protocoles, comme DoT (DNS sur TLS, RFC 7858), présentent exactement les mêmes propriétés.

  • DoH empêche (en réalité : rend plus difficile) d'appliquer une politique, par exemple de censurer Sci-Hub. Aucun doute à ce sujet, c'est même le but explicite. Ceux qui le présentent comme un inconvénient avouent franchement que leur but est le contrôle des utilisateurs. L'IETF, qui a normalisé le protocole, travaille pour un Internet ouvert. Si vous voulez utiliser les technologies TCP/IP dans un réseau fermé, vous avez le droit, mais c'est à vous de trouver des solutions. Cette critique n'est pas spécifique à DoH, DoT offre exactement le même avantage (ou le même inconvénient, si on est du côté des censeurs).
  • DoH empêche (en réalité : rend plus difficile) la surveillance des utilisateurs. L'examen des requêtes DNS peut être très révélateur (cf. RFC 7626) et être utilisé pour le bien (détection de l'activité de logiciels malveillants) ou pour le mal (repérer qui visite tel ou tel site Web). Là encore, c'est le but explicite de DoH (comme de TLS en général) de rendre plus difficile la surveillance (cf. RFC 7258). Cette critique n'est pas spécifique à DoH, DoT offre exactement le même avantage (ou le même inconvénient, si on est du côté des surveillants).
  • On a souvent lu que DoH aggravait la centralisation (déjà bien trop importante) de l'Internet et notamment du Web. C'est une drôle de façon de poser le problème que de l'attribuer à DoH. Lorsque Gmail rassemble la majorité du courrier électronique (oui, même si vous n'êtes pas client de Gmail, et n'avez pas accepté leurs conditions d'utilisation, une bonne partie de votre courrier est chez Gmail), est-ce qu'on décrit ce problème comme étant de la faute de SMTP ? (Notez que la relation entre les protocoles et les résultats de leurs déploiements est une question complexe, cf. RFC 8280.) Je suis personnellement d'accord que ce n'est pas une bonne idée d'envoyer tout le trafic DNS à Cloudflare, mais la solution n'est pas de supprimer DoH, ou de le limiter à parler aux résolveurs des FAI, précisément ceux auxquels on ne fait pas forcément confiance. La solution est au contraire de multiplier les serveurs DoH, de même que la solution aux réseaux sociaux centralisés est d'avoir plein d'instances décentralisées. C'est ce que je fais avec mon résolveur DoH personnel, c'est ce que font, en plus sérieux, les CHATONS. Bref, la centralisation du Web autour d'une poignée de GAFA est un vrai problème, mais pas lié à DoH. Les résolveurs DNS publics, comme Google Public DNS posent le même problème.
  • On a lu parfois que DoH diminuait la vie privée car HTTP est bavard, très bavard. Ainsi, une requête DNS contient très peu d'informations sur le client, alors que HTTP transmet plein d'informations inutiles et dangereuses comme Accept-Language: ou User-Agent:, qui peuvent servir à identifier un utilisateur. Sans compter bien sûr les très dangereux biscuits (RFC 6265). Il s'agit là d'un vrai problème. Des solutions ont été proposées (cf. l'Internet-Draft draft-dickinson-doh-dohpe) mais n'ont guère suscité d'intérêt. C'est probablement l'une des deux seules critiques de DoH qui soit réellement spécifique à DoH (DoT n'a pas ce problème), le reste étant confusion et mauvaise foi.
  • Un reproche plus conceptuel et abstrait qui a été fait à DoH (par exemple par Paul Vixie) est d'ordre architectural : selon cette vision, le DNS fait partie du plan de contrôle et pas du plan de données, ce qui fait qu'il doit être contrôlé par l'opérateur réseau, pas par l'utilisateur. Le positionnement du DNS ne fait pas l'objet d'un consensus : protocole situé dans la couche Application, il fait pourtant partie de l'infrastructure de l'Internet. Disons que cette ambiguïté est consubstantielle à l'Internet : plusieurs protocoles d'infrastructure (c'est aussi le cas de BGP) tournent dans la couche 7. Dans tous les cas, le DNS ne peut pas être vu comme purement technique (comme, par exemple, ARP), son utilisation massive pour la censure montre bien qu'il est aussi un protocole de contenu, et devrait donc être protégé contre la censure. Si les gens qui clament que le DNS fait partie de l'infrastructure et que l'utilisateur ne devrait pas pouvoir bricoler sa résolution DNS étaient cohérents, ils réclameraient également que les FAI s'engagent à ne jamais interférer (ce que suggérait l'IAB dans une récente déclaration). Mais cela semble peu réaliste à court terme.
  • Un autre reproche de nature architecturale a été fait à DoH : tout faire passer sur HTTPS n'est pas « propre ». Ce reproche est justifié du point de vue technique (l'Internet n'a pas été conçu pour fonctionner comme cela, normalement, les applications doivent tourner sur SCTP, TCP, UDP, pas sur HTTPS). Mais, en pratique, « le bateau a déjà quitté le port », comme disent les anglophones. De plus en plus de réseaux bloquent tous les ports sauf 80 et 443 et, si on veut faire un protocole qui passe partout, il doit utiliser HTTPS. Si cela vous déplait, plaignez-vous aux gérants des points d'accès WiFi, pas à DoH. Notez que cette remarque est une des rares à être effectivement spécifique à DoH.
  • Tel qu'il est mis en œuvre dans Firefox, DoH est fait par l'application, pas par le système d'exploitation (ce qu'on nomme parfois ADD, pour Applications Doing DNS). Ce n'est pas du tout une propriété de DoH, juste un choix de Firefox. Les nombreux schémas où on voit « avec DoH, c'est l'application qui fait les requêtes DNS » révèlent qu'ils ont été faits par des gens qui ne comprennent pas ce qu'est un protocole. DoH peut parfaitement être utilisé par les couches basses du système d'exploitation (par exemple, sur les systèmes qui ont le malheur d'utiliser systemd, par systemd-resolve ou, plus sérieusement, par un démon comme Stubby). Le choix de Mozilla est à mon avis erroné, mais n'a rien à voir avec DoH. Là encore, rien de spécifique à DoH, une application a toujours pu faire des requêtes DNS directement avec UDP, ou utiliser DoT, ou avoir son propre protocole privé de résolution de noms (ce que font souvent les logiciels malveillants).
  • Enfin, on lit parfois que DoH poserait des problèmes lorsque la réponse DNS dépend de la localisation du client (ce qui est courant avec les CDN). C'est un effet déplorable de la centralisation du Web : comme l'essentiel du trafic est concentré sur un petit nombre de sites, ces sites doivent se disperser sur la planète et utiliser des bricolages dans le DNS pour diriger le client vers « le plus proche », estimé en fonction de l'adresse IP du client. Si le résolveur est loin de l'utilisateur, on sera renvoyé vers un endroit sous-optimal. Il existe une solution technique (RFC 7871) mais elle est très dangereuse pour la vie privée, et c'est pour cela que Cloudflare, contrairement à Google, ne l'utilise actuellement pas. Ceci dit, cela n'a rien de spécifique à DoH, tout résolveur DNS public (notez que ce terme est défini dans le RFC 8499) soulève les mêmes questions (c'est également le cas si vous avez des noms de domaine privés, spécifiques à une organisation).

Articles intéressants sur le sujet :

Et pour finir, une petite image (prise sur Wikimedia Commons) du détroit de Messine où, selon les légendes, les marins qui tentaient d'éviter Scylla tombaient sur Charybde. Bref, ce n'est pas parce qu'on n'aime pas Cloudflare qu'il faut maintenir le statu-quo et continuer à envoyer ses requêtes DNS au résolveur fourni par le réseau d'accès

La politique du serveur DoH doh.bortzmeyer.fr et ce qu'il faut savoir

Ce texte est la politique suivie par le résolveur DoH doh.bortzmeyer.fr et par le résolveur DoT dot.bortzmeyer.fr. Il explique ce qui est garanti (ou pas), ce qui est journalisé (ou pas), etc. (Vous pouvez également accéder à ce texte par l'URL https://doh.bortzmeyer.fr/policy .)

[If you don't read French, sorry, no translation is planned. But there are many other DoH resolvers available (or DoT), sometimes with policies in English.]

Les protocoles DoH (DNS sur HTTPS), normalisé dans le RFC 8484, et DoT (DNS sur TLS), normalisé dans le RFC 7858, permettent d'avoir un canal sécurisé (confidentialité et intégrité) avec un résolveur DNS qu'on choisit. DoH est mis en œuvre dans plusieurs clients comme Mozilla Firefox. Ce texte n'est pas un mode d'emploi (qui dépend du client) mais une description de la politique suivie. La sécurisation du canal (par la cryptographie) vous protège contre un tiers mais évidemment pas contre le gérant du résolveur DoH ou DoT. C'est pour cela qu'il faut évaluer le résolveur DoH qu'on utilise, juger de la confiance à lui accorder, à la fois sur la base de ses déclarations, et sur la base d'une évaluation du respect effectif de ces déclarations.

Le résolveur DoH doh.bortzmeyer.fr et le résolveur DoT dot.bortzmeyer.fr sont gérés par moi. C'est un projet individuel, avec ce que cela implique en bien ou en mal.

Ce résolveur :

  • Est public (au sens du RFC 8499), ce qui veut dire que tout le monde peut l'utiliser,
  • Est authentifiable par le nom dans le certificat, ou bien par DANE (RFC 6698) ou encore par l'épinglage de la clé qui vaut, pour le serveur DoT, eHAFsxc9HJW8QlJB6kDlR0tkTwD97X/TXYc1AzFkTFY= (en SHA-256/Base64, comme spécifié par le RFC 7858),
  • N'offre aucune garantie de bon fonctionnement. Il est supervisé mais les ressources humaines et financières disponibles ne permettent pas de s'engager sur sa stabilité. (Mais vous êtes bien sûr encouragé·e·s à signaler tous les problèmes ou limites que vous rencontreriez.)
  • Accepte tous les clients gentils, mais avec une limitation de trafic (actuellement cent requêtes par seconde mais cela peut changer sans préavis). Les clients méchants pourraient se retrouver bloqués.
  • N'enregistre pas du tout les requêtes DNS reçues. Elles ne sont jamais mises en mémoire stable. Notez que la liste des adresses IP des clients, et celle des noms de domaines demandés est gardée en mémoire temporaire, et ne survit donc pas à un redémarrage du logiciel serveur (ou a fortiori de la machine). Les deux listes sont stockées séparément donc je peux voir que 2001:db8:99:fa4::1 a fait une requête, ou que quelqu'un a demandé toto.example, mais je ne sais pas si c'est la même requête.
  • Et les requêtes complètes ne sont pas copiées vers un autre serveur. (Certaines politiques de serveurs disent « nous ne gardons rien » mais sont muettes sur l'envoi de copies à un tiers.) Notez que, pour faire son travail, le résolveur DoH doit bien transmettre une partie de la requête aux serveurs faisant autorité, mais cette partie est aussi minimisée que possible (RFC 7816).
  • Le résolveur ne ment pas, il transmet telles quelles les réponses reçues des serveurs faisant autorité. Même des domaines dangereux pour la vie privée comme google-analytics.com sont traités de manière neutre.
  • Je suis sincère (si, si, faites-moi confiance) mais ce serveur dépend d'autres acteurs. C'est une simple machine virtuelle et l'hébergeur peut techniquement interférer avec son fonctionnement. C'est d'autant plus vrai que la machine est en France et donc soumise à diverses lois liberticides comme la loi Renseignement.

Comme indiqué plus haut, il s'agit d'un projet individuel, donc sa gouvernance est simple : c'est moi qui décide (mais, en cas de changement des règles, je modifierai cet article, et en changeant la date pour que les utilisateurices de la syndication aient la nouvelle version). Si cela ne vous convient pas, je vous suggère de regarder les autres serveurs DoH disponibles (plus il y en a, mieux c'est). Voyez aussi les serveurs DoT.

Et si vous êtes technicien·ne, j'ai également publié sur la mise en œuvre de ce résolveur.

2019-09-17

Using the CowBoy HTTP server from an Elixir program

Among the people who use the CowBoy HTTP server, some do it from an Erlang program, and some from an Elixir program. The official documentation only cares about Erlang. You can find some hints online about how to use CowBoy from Elixir but they are often outdated (CowBoy changed a lot), or assume that you use CowBoy with a library like Plug or a framework like Phoenix. Therefore, I document here how I use plain CowBoy, from Elixir programs, because it may help. This is with Elixir 1.9.1 and CowBoy 2.6.3.

I do not find a way to run CowBoy without the mix tool. So, I start with mix:

% mix new myserver 
...
Your Mix project was created successfully.
    
I then add CowBoy dependencies to the mix.exs file:
 defp deps do                                                                                                                      
    [                                                                                                                               
      {:cowboy, "~> 2.6.0"}                                                                                                         
    ]                                                                                                                               
 end        
    
(Remember that CowBoy changes a lot, and a lot of CowBoy examples you find online are for old versions. Version number is important. I used 2.6.3 for the examples here.) Then, get the dependencies:
% mix deps.get
...
  cowboy 2.6.3
  cowlib 2.7.3
  ranch 1.7.1
...
    
We can now fill lib/myserver.ex with the main code:
 defmodule Myserver do                                                                                                               
                                                                                                                                    
  def start() do                                                                                                                    
    dispatch_config = build_dispatch_config()                                                                                       
    { :ok, _ } = :cowboy.start_clear(:http,                                                                                         
      [{:port, 8080}],                                                                                                              
      %{ env: %{dispatch: dispatch_config}}                                                                                         
    )                                                                                                                               
  end                                                                                                                               
                                                                                                                                    
  def build_dispatch_config do                                                                                                      
    :cowboy_router.compile([                                                                                                        
      { :_,                                                                                                                         
        [                                                                                                                           
          {"/", :cowboy_static, {:file, "/tmp/index.html"}}
        ]}                                                                                                                          
    ])                                                                                                                              
  end                                                                                                                               
                                                                                                                                    
end                
    
And that's all. Let's test it:
      
% iex -S mix
Erlang/OTP 22 [erts-10.4.4] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1]

Compiling 1 file (.ex)
Interactive Elixir (1.9.1) - press Ctrl+C to exit (type h() ENTER for help)

iex(1)> Myserver.start()
{:ok, #PID<0.197.0>}

iex(2)> 
      
    
If you have HTML code in /tmp/index.html, you can now use any HTTP client such as curl, lynx or another browser, to visit http://localhost:8080/.

The start_clear routine (which was start_http in former versions) starts HTTP (see its documentation.) If you want explanation about the behaviour :cowboy_static and its parameters like :file, see the CowBoy documentation. If you are interested in routes (the argument of :cowboy_router.compile, directives for CowBoy telling it "if the request is for /this, then do that"), see also the documentation. There are many other possibilities, for instance, we could serve an entire directory:

 def build_dispatch_config do                                                                                                      
    :cowboy_router.compile([                                                                                                        
                                                                                                                                    
      { :_,                                                                                                                         
        [                                                                                                                           
          # Serve a single static file on the route "/".                                                                            
          {"/", :cowboy_static, {:file, "/tmp/index.html"}},                                                                        

          # Serve all static files in a directory.                                                                                  
          # PathMatch is "/static/[...]" -- string at [...] will be used to look up the file                                        
          # Directory static_files is relative to the directory where you run the server                                            
          {"/static/[...]", :cowboy_static, {:dir, "static_files"}}                                                                 
        ]}                                                                                                                          
    ])                                                                                                                              
  end     
    

You can now start from this and improve:

  • Use start_tls instead of start_clear, to provide security through HTTPS,
  • Replace def start() do by def start(_type, _args) do (or def start(type, args) do if you want to use the parameters) to follow OTP conventions, in order for instance to run the HTTP server under a supervisor (see this example - untested), or simply to create a standalone application,
  • Serve dynamic content by using Elixir (or Erlang) modules to produce content on the fly.

2019-09-12

« Entrée libre » à Quimper

Du 27 au 29 août, à Quimper, s'est tenu l'évènement libriste « Entrée Libre ».

À cette occasion, j'avais préparé un exposé sur « Qu'est-ce qu'Internet ? ». Bien sûr, tout le monde connait l'Internet, mais sans savoir en général ce qui se passe derrière l'écran. Or, ce système pas directement visible peut avoir de sérieuses conséquences sur ce que l·e·a citoyen·ne peut faire sur l'Internet. Voici les supports de cet exposé, et leur source (en LaTeX). La vidéo, quant à elle, se trouve sur PennarWeb et sur Vimeo. (Oui, je sais, il faudrait aussi les mettre sur PeerTube.)

Il y avait également plein d'activités intéressantes, notamment des ateliers interactifs, et d'autres exposés passionnants (les vidéos sont sur Vimeo). Citons, entre autres, celle sur les données de santé, celle sur les logiciels libres pour les professionnels de la santé, celle sur Exodus Privacy.

Merci mille fois à Brigitte et à tous les bénévoles et salariés du Centre Social des Abeilles. (Et j'avais déjà eu le plaisir de venir à ce Centre des Abeilles.)

2019-09-10

L'avenir de Salto

Le 12 août dernier, les médias ont annoncé en fanfare le lancement de Salto, le « Netflix français », lancement déjà annoncé en juin 2018. En réalité, une étape (purement bureaucratique) a été franchie. Mais quel avenir attend Salto ?

Les réseaux sociaux ont déjà fait d'innombrables blagues sur ce projet caricatural : décisions d'en haut, ignorance abyssale de ce qui existe, mépris pour les problèmes concrets, Salto cumule en effet de quoi faire ricaner. Mais de quoi s'agit-il et quelles sont les chances de réussite de Salto ?

Autrefois, il y a bien longtemps, la télévision était diffusée par ondes hertziennes, captées par tous. Il n'y avait qu'une seule chaîne de télévision, dirigée par l'État. Le ministre de l'information officielle et gaulliste y dictait les sujets (« la télévision est la voix de la France »), et tout le monde obéissait. Paradoxalement, dans cet environnement si contrôlé, des échappées étaient possibles et quelques émissions créatives (comme les Shadoks) ont quand même pu éclore. Pas d'enregistrement possible, ni de télévision à la demande des anciennes émissions, la France s'asseyait donc aux heures imposées devant l'unique écran de la maison, et regardait. Puis le magnétoscope est arrivé, d'autres chaînes sont apparues, puis les entreprises privées en ont créé ou bien ont mis la main sur d'ex-chaînes publiques, et il y a eu beaucoup de choix, enfin au moins en apparence.

Après l'Internet s'est répandu et, logiquement, on s'est mis à diffuser de la télévision via l'Internet, même si tous les experts français de l'expertise étaient d'accord au début des années 1990 pour dire que cela ne serait jamais possible, qu'il fallait plutôt utiliser les technologies françaises. Le nombre d'écrans par foyer a explosé, comme le choix, plus réel cette fois, puisque, avec l'Internet, M. Michu peut non seulement « accéder à du contenu » mais en produire.

Comme d'habitude, les élites dirigeantes françaises ont mis du temps à comprendre et, plutôt que de se féliciter de ces nouvelles possibilités, ont tout fait pour les contrôler et les limiter. La création de la HADOPI est sans doute le plus bel exemple de cet aveuglement, partagé par tous les partis politiques officiels, et par les médias dominants. Entre autres, on a diabolisé le pair-à-pair, c'est-à-dire les techniques qui exploitaient le mieux les caractéristiques techniques de l'Internet. En voulant ainsi défendre les intérêts de l'industrie du divertissement nationale, on a donc laissé se développer des GAFA centralisés comme YouTube et, plus tard, Netflix. Aujourd'hui, les gens qui regardent « la télévision », le font en général via ces plate-formes Internet, sur un écran d'ordinateur ou d'ordiphone, et plus en s'asseyant devant « la télévision ». (Notez qu'il existe un gros fossé générationnel : TF1 reste très regardé, chez la frange la plus âgée de la population, ce qui fait du monde. Les chaînes de télévision traditionnelles déclinent, mais il faudra de nombreuses années pour qu'elles disparaissent complètement.)

Ajoutons aussi que, déconnecté des demandes des utilisateurs, on a également ajouté de plus en plus de publicité à la télé, comme si on cherchait à encourager la migration vers Netflix…

Là, des gens dans les sphères d'en haut ont fini par se dire qu'il y avait un problème. Netflix, qui repose sur un système d'abonnement, croît continuellement, et se fait « un pognon de dingue », et les jeunes ne savent même plus ce que c'est que de lire Télé 7 jours pour savoir à quelle heure commence le film. C'est là qu'est né le projet Salto, baptisé « le Netflix français ».

Bien sûr, la comparaison avec Netflix est absurde. Salto n'aura jamais un budget comparable, et même les plus optimistes ne le voient pas prendre une part non-microscopique de la part de marché de Netflix. Mais l'enflure verbale est souvent appréciée des politiques et des journalistes, transformant un projet peu enthousiasmant (les télévisions du passé s'unissent pour mourir un peu moins vite…) en une croisade tricolore contre la sous-culture yankee.

Une grande partie des critiques contre Salto ont porté sur le catalogue : c'est la grande force de Netflix, la disponibilité d'une étonnante quantité de contenus, très souvent d'origine étrangère aux États-Unis. (Quelle chaîne de télévision française aurait diffusé une série comme « 3 % » ?) Face à cette offre surabondante, les catalogues des créateurs de Salto, TF1, France Télévisions et M6 paraissent en effet bien pâles… (D'autant plus qu'il semble bien qu'on n'aura sur Salto qu'une petite partie du catalogue des membres du projet.) Je ne vais donc pas insister sur cette question du catalogue, bien qu'elle soit en effet cruciale. Et je vais plutôt parler de l'opérationnel, et de la gouvernance.

Il me semble qu'il y a un sérieux problème pratique : une plate-forme comme celle de Netflix est un défi permanent pour l'ingéniérie. Il faut distribuer la vidéo, qui est très gourmande et prend énormément de capacité, il va falloir d'innombrables serveurs pour héberger ces vidéos, du devops pour lier le tout et une interface humaine adaptée à des millions d'utilisateurs qui veulent juste que ça marche, et se détourneront vite de Salto s'il y a des problèmes techniques. C'est d'autant plus sérieux que Netflix a de nombreuses années d'avance, et a déjà beaucoup innové en ce domaine (comme avec leur célèbre - à juste titre - singe du chaos.) Jusqu'à présent, les responsables de Salto ont fait preuve d'une légèreté inquiétante dans ce domaine. Ils ne communiquent que sur des succès bureaucratiques (la signature de l'accord initial, l'approbation de l'Autorité de la concurrence…) et jamais sur le travail concret qui sera colossal. Affirmer que le projet avance alors que pas une seule ligne de code n'a été écrite est révélateur d'une certaine vision : celle qui ne connait que les réunions au sommet, et jamais les considérations opérationnelles. Le Monde parlait de l'« accouchement » du projet. Mais l'accouchement de quoi, puisque rien n'a encore été produit, il n'y a eu que réunions et paperasses. Le plus dur, avoir une plateforme technique qui fonctionne, reste à faire.

On peut être d'autant plus inquiet pour Salto que la France a vécu plusieurs mauvaises expériences de projets informatique comparables. On fait des réunions, on signe des papiers, et on oublie complètement la réalisation concrète. Des années après, le projet est une catastrophe et il faut fermer boutique. On se souvient de l'escroquerie qu'avait été le « cloud souverain », définitivement clos en juillet 2019 après des années de gaspillage. Ou bien le « Google européen » lancé par Chirac, Quaero. Citons aussi le ridicule projet « OS souverain » qui, lui, a heureusement sombré vite, avant de coûter trop cher. Et concernant la distribution de vidéos, la liste des échecs est longue. A priori, un des scénarios les plus probables pour Salto était que des millions de lignes de Java seraient écrites par une grosse ESN habituée des contrats, et que rien ne marcherait jamais vraiment techniquement. Un gros projet informatique est quelque chose de complexe, qui ne se fait pas juste en signant des papiers et en sous-traitant à une entreprise importante. Souvent, il vaut mieux faire appel à une petite équipe, ayant une vision claire et ne dépendant pas de cahiers des charges de milliers de pages.

Selon certaines sources (non officielles, on ne trouve rien sur https://www.salto.fr/), le développement serait finalement fait par M6, un des membres du projet. (Ou peut-être en utilisant la technologie de SteamRoot, qui a l'avantage d'inclure du pair-à-pair.) J'ai donc voulu tester https://www.6play.fr/, le service de ce même M6, pour voir, et j'ai :

(Ce n'est pas un problème avec cette vidéo particulière, ça le fait pour toutes.)

Mais à part ces considérations pratiques, Salto a deux autres gros défauts, qui mettent sérieusement en danger le projet. L'un est son côté peu disruptif : il s'agit uniquement de copier Netflix, en plus petit et en moins bien. Battre un mastodonte comme Netflix, sans parler des autres entreprises qui vont tenter de faire la même chose comme Disney ou Warner, qui ont des projets similaires (Disney+ et HBO Max), est impossible si on se place sur le même terrain. Quand on n'a pas les moyens de Netflix (moyens financiers et humains), on n'essaie pas de lutter dans la même catégorie : on change de terrain. La distribution de vidéo depuis un service centralisé, comme Netflix ou Salto, est de toute façon une mauvaise façon d'utiliser l'Internet. Elle mène à des déséquilibres dans la répartition du trafic qui, à leur tour, mènent à des attaques contre la neutralité de l'Internet. La bonne solution, pour distribuer un contenu lourd en nombre de gigaoctets, est au contraire le pair-à-pair. Au lieu de laisser les ayant-trop-de-droits diaboliser ce mécanisme, il faudrait au contraire décentraliser au maximum la distribution, utilisant des petits services un peu partout au lieu de chercher à se faire aussi gros que le bœuf Netflix. Et ça tombe bien, il existe des solutions techniques pour cela, notamment le logiciel libre PeerTube, qui permet l'installation de plein de petits services partout, eux-même distribuant en pair-à-pair (grâce à WebTorrent) les vidéos. C'est ce genre de services, fondés sur le logiciel libre et le pair-à-pair que les pouvoirs publics devraient encourager et aider !

Certaines personnes qui défendent Salto estiment que toutes les critiques sont du « french bashing », de la critique systématique et masochiste de ce qui vient de France. Cet argument aurait plus de poids si Salto n'utilisait pas, pour son propre hébergement, un étranger (AWS) plutôt qu'un hébergeur français. Et PeerTube, que j'ai cité, est développé en France donc, si on veut vraiment faire du nationalisme, Salto n'est pas la bonne voie.

Outre ce problème technique, et ce manque d'intérêt pour les questions concrètes, Salto souffre d'un autre problème : il est entièrement conçu d'en haut, dans un entre-soi complet. Les gens qui connaissent vraiment Netflix, et/ou qui connaissent vraiment l'Internet, n'ont pas été consultés. (Tous et toutes auraient pu dire que le projet n'avait aucun sens.) Au lieu de discuter avec les personnes qui ont une expérience de l'Internet, Salto a été conçu dans des bureaux fermés, entre des dirigeants qui ne connaissent que la télé d'autrefois. Cela n'augure pas bien de son avenir.

En conclusion, mon pronostic est clair : Salto est fichu. Dans le meilleur des cas, il coulera vite. Dans le pire, cela durera des années, en engloutissant diverses aides et subventions pour « soutenir la création française » ou bien parce que « on ne peut pas laisser Netflix en numéro un ». Déjà, le gouvernement en est à menacer d'utiliser la contrainte (« S'ils ne le font pas, ils ne pourront plus être disponibles en France »), en annonçant que Netflix pourrait être censuré en France, ce qui montre bien que je ne suis pas le seul à être sceptique quant aux capacités de Salto.

Je ne changerai pas cet article dans le futur, vous pourrez donc voir en 2020 ou 2021 si j'avais raison…

Notez toutefois qu'une autre possibilité existe : derrière les rodomontades ridicules reprises en boucle par les médias (« faire un Netflix français »), il y a peut-être de tout autres projets, moins ambitieux. Par exemple, il est parfaitement possible que le vrai but de Salto soit de concurrencer Molotov plutôt que Netflix. Ou bien tout bêtement de remplacer l'accès aux émissions précédentes (replay) gratuit par un accès payant via Salto. Ce serait un objectif moins glorieux mais plus réaliste. Dans ce cas, le discours sur Netflix serait juste un écran de fumée.

Bon, j'ai fini cet article, je retourne regarder Arte.

2019-09-06

RFC 8620: The JSON Meta Application Protocol (JMAP)

Le protocole JMAP, JSON Meta Application Protocol, permet de bâtir des mécanismes d'accès à des objets distants (par exemple des boîtes aux lettres, ou des agendas), en envoyant et recevant du JSON au dessus de HTTPS. Son principal « client » est le protocole « JMAP for mail », un concurrent d'IMAP normalisé dans le RFC 8621.

Au début, JMAP était même conçu uniquement pour l'accès au courrier, comme l'indique son nom, qui évoque IMAP. Mais, dans le cadre de la normalisation de JMAP, est apparu le désir de séparer le protocole générique, adapté à toutes sortes d'objets distants, du protocole spécifique du courrier. D'où les deux RFC : ce RFC 8620 normalise le protocole générique, alors que le RFC 8621 normalise « JMAP for mail ». Dans le futur, d'autres protocoles fondés sur JMAP apparaitront peut-être, par exemple pour l'accès et la synchronisation d'un agenda (en concurrence avec le CalDAV du RFC 4791, donc).

Parmi les concepts techniques importants de JMAP, notons :

  • Utilisation de JSON (RFC 8259) pour encoder les données, parce que tout le monde utilise JSON aujourd'hui,
  • Transport sur HTTPS (RFC 2818 et RFC 7230), là encore comme tout le monde aujourd'hui, avec toutes les propriétés de sécurité de HTTPS (notamment, le client JMAP doit authentifier le serveur, typiquement via un certificat),
  • Possibilité de regrouper (batching) les requêtes en un seul envoi, pour les cas où la latence est élevée,
  • Possibilité de notification par le serveur (push), pour éviter l'interrogation répétée par le client (polling),
  • Un mécanisme de transfert incrémental des objets, pour limiter le débit sur le réseau.
Du fait de l'utilisation de JSON, il est bon de réviser le vocabulaire JSON, notamment le fait qu'un objet (object) JSON est en fait un dictionnaire.

Outre les types de données de base de JSON, comme les booléens, les chaînes de caractères et les entiers, JMAP définit quelques types à lui, notamment le type Id, qui stocke l'identificateur d'un objet. Syntaxiquement, c'est une chaîne de caractères LDH (Letter-Digit-Hyphen, lettres ASCII, chiffres et trait d'union). Par exemple, dans le RFC 8621, la première boîte aux lettres mentionnée a comme identificateur MB23cfa8094c0f41e6. Notre RFC crée aussi le type Date, puisque JSON ne normalise pas les dates. Ce type utilise le format du RFC 3339.

À ce stade, je peux avouer que j'ai fait un abus de langage. J'ai parlé de JSON mais en fait JMAP utilise un sous-ensemble de JSON, nommé I-JSON, et décrit dans le RFC 7493, afin d'éviter certaines ambiguités de JSON (section 8.4 de notre RFC). Tout le contenu échangé en JMAP doit être du I-JSON. D'ailleurs, si vous connaissez un logiciel libre qui vérifie qu'un texte JSON est du I-JSON, je suis preneur.

JMAP nécessite que le client se connecte au serveur (section 2 du RFC, sur la session). Pour cela, il lui faut l'URL du serveur (rappelez-vous que JMAP tourne sur HTTPS), qui peut être obtenu manuellement, ou par un processus de découverte décrit plus loin. Et il faut évidemment les moyens d'authentification (par exemple nom et phrase de passe), ceux-ci n'étant pas précisés dans notre RFC. Un mécanisme unique avait été prévu mais avait suscité trop de controverses à l'IETF. Finalement, les mécanismes utilisables sont ceux habituels de HTTPS (enregistrés à l'IANA). Lors de la connexion, le serveur va envoyer un objet JSON décrivant entre autres ses capacités, comme la taille maximale des objets téléversés, ou comme les extensions gérées (comme le « JMAP for mail » du RFC 8621). Voici un exemple (tiré du RFC, car je n'ai pas trouvé de serveur JMAP où je pouvais avoir facilement un compte pour tester, si vous en avez un, n'hésitez pas à m'écrire) :


   {
     "capabilities": {
       "urn:ietf:params:jmap:core": {
         "maxSizeUpload": 50000000,
         "maxSizeRequest": 10000000,
...
         "collationAlgorithms": [
           "i;ascii-numeric",
           "i;ascii-casemap",
           "i;unicode-casemap"
         ]
       },
       "urn:ietf:params:jmap:mail": {}
       "urn:ietf:params:jmap:contacts": {},
       "https://example.com/apis/foobar": {
         "maxFoosFinangled": 42
       }
     },
     "accounts": {
       "A13824": {
         "name": "john@example.com",
         "isPersonal": true,
         "isReadOnly": false,
         "accountCapabilities": {
           "urn:ietf:params:jmap:mail": {
             "maxMailboxesPerEmail": null,
             "maxMailboxDepth": 10,
             ...
           },
           "urn:ietf:params:jmap:contacts": {
             ...
           }
...
      "apiUrl": "https://jmap.example.com/api/",
...

    
Notez que ce serveur annonce qu'il sait faire du JMAP pour le courrier (RFC 8621, cf. la ligne urn:ietf:params:jmap:mail) et qu'il a également une extension privée, https://example.com/apis/foobar. Les capacités publiques sont dans un registre IANA. On peut ajouter des capacités par la procédure (cf. RFC 8126) « Spécification nécessaire » pour les capacités marquées « fréquentes » (common), et par la procédure « Examen par un expert » pour les autres.

La méthode standard pour découvrir le serveur JMAP, si on n'en connait pas l'URL, est d'utiliser un enregistrement SRV (RFC 2782, mais voir aussi le RFC 6186) puis un URL bien connu. Imaginons que le domaine soit example.net. On cherche le SRV pour _jmap._tcp.example.net. (jmap a donc été ajouté au registre des services.) On récupère alors le nom du serveur et le port (a priori, ce sera 443, le port standard de HTTPS). Et on n'a plus qu'à se connecter à l'URL bien connu (RFC 8615), à https://${hostname}[:${port}]/.well-known/jmap. jmap figure à cet effet dans le registre des URL bien connus. (Notez que l'étape SRV est facultative, certains clients iront directement au /.well-known/jmap.) Ainsi, si vous utilisez JMAP pour le courrier, et que votre adresse est gerard@example.net, vous partez du domaine example.net et vous suivez l'algorithme ci-dessus. (Je ne sais pas pourquoi JMAP n'utilise pas plutôt le WebFinger du RFC 7033.)

Puisqu'on utilise le DNS pour récupérer ces enregistrements SRV, il est évidemment recommandé de déployer DNSSEC.

Une fois qu'on a récupéré le premier objet JSON décrit plus haut, on utilise la propriété (le membre, pour parler JSON) apiUrl de cet objet pour faire les requêtes suivantes (section 3 du RFC). On utilise la méthode HTTP POST, le type MIME application/json, et on envoie des requêtes en JSON, qui seront suivies de réponses du serveur, également en JSON. Les méthodes JMAP (à ne pas confondre avec les méthodes HTTP comme GET ou POST) sont écrites sous la forme Catégorie/Méthode. Il existe une catégorie Core pour les méthodes génériques de JMAP et chaque protocole utilisant JMAP définit sa (ou ses) propre(s) catégorie(s). Ainsi, le RFC 8621 définit les catégories Mailbox, Email (un message), etc. Comme Core définit une méthode echo (section 4, le ping de JMAP), qui ne fait que renvoyer les données, sans les comprendre, un exemple de requête/réponse peut être :

      
[[ "Core/echo", {
      "hello": true,
      "high": 5
}, "b3ff" ]]

[[ "Core/echo", {
      "hello": true,
      "high": 5
}, "b3ff" ]]

    
(Oui, la réponse - le second paragraphe - est identique à la question.)

En cas d'erreur, le serveur devrait renvoyer un objet décrivant le problème, en utilisant la syntaxe du RFC 7807. Une liste des erreurs connues figure dans un registre IANA.

Il existe des noms de méthodes standard qu'on retrouve dans toutes les catégories, comme get. Si on a une catégorie Foo décrivant un certain type d'objets, le client sait qu'il pourra récupérer les objets de ce type avec la méthode Foo/get, les modifier avec Foo/set et récupérer uniquement les modifications incrémentales avec Foo/changes. La section 5 du RFC décrit ces méthodes standard.

Une méthode particulièrement utile est query (section 5.5). Elle permet au client de demander au serveur de faire une recherche et/ou un tri des objets. Au lieu de tout télécharger et de faire recherche et tri soi-même, le client peut donc sous-traiter cette opération potentiellement coûteuse. Cette méthode est une de celles qui permet de dire que JMAP est bien adapté aux machines clientes disposant de faibles ressources matérielles, et pas très bien connectées. Le RFC cite (section 5.7) un type (imaginaire) Todo décrivant des tâches à accomplir, et l'exemple avec query permet d'illustrer le membre filter de la méthode, pour indiquer les critères de sélection :


[[ "Todo/query", {
       "accountId": "x",
       "filter": {
              "operator": "OR",
              "conditions": [
                         { "hasKeyword": "music" },
                         { "hasKeyword": "video" }
	      ]
       }
    }			 
]]                     

    
Comme beaucoup de méthodes JMAP, query peut imposer un travail important au serveur. Un client maladroit, ou cherchant déliberement à créer une attaque par déni de service pourrait planter un serveur trop léger. Les serveurs JMAP doivent donc avoir des mécanismes de protection, comme une limite de temps passé sur chaque requête.

On l'a dit, un des intérêts de JMAP est la possibilité d'obtenir des notifications du serveur, sans obliger le client à vider sa batterie en interrogeant périodiquement le serveur. La section 7 du RFC détaille ce mécanisme. Deux alternatives pour le client : garder la connexion HTTPS ouverte en permanence, pour y recevoir ces notifications, ou bien utiliser un service tiers comme celui de Google. Notons que ces notifications, par leur seule existence, même si le canal est chiffré, peuvent révéler des informations. Comme noté dans la revue du protocole par la direction Sécurité à l'IETF "I.e., if someone can see that wikileaks smtp server sends email to corporate smtp server, but the smtp traffic is encrypted so they do not know the recipient of the email, but then few seconds later see push event notification stream going to the Joe's laptop indicating something has happened in his mail box, they can find out the who the recipient was.".

Il existe une page « officielle » présentant le protocole et plusieurs mises en oeuvre (actuellement, la plupart sont, expérimentales et/ou en cours de développement). C'est une des raisons pour lesquelles je ne présente pas ici d'essais réels. Notez toutefois que Fastmail a du JMAP en production.

2019-09-04

RFC 8618: Compacted-DNS (C-DNS): A Format for DNS Packet Capture

Lorsque l'opérateur d'un service DNS veut conserver les données de trafic, il peut demander au serveur d'enregistrer requêtes et réponses (mais, la plupart du temps, le serveur n'écrit qu'une petite partie des informations) ou bien écouter le trafic réseau et enregistrer le pcap. Le problème est que le format pcap prend trop de place, est de trop bas niveau (une connexion TCP, par exemple, va être éclatée en plusieurs paquets), et qu'il est difficile de retrouver les informations spécifiquement DNS à partir d'un pcap. D'où la conception de ce format de stockage, spécifique au DNS, et qui permet d'enregistrer la totalité de l'information, dans un format optimisé en taille et de plus haut niveau. C-DNS s'appuie sur CBOR pour cela.

Le DNS est un service d'infrastructure absolument critique. Il est donc nécessaire de bien le connaitre et de bien l'étudier. Cela passe par une récolte de données, en l'occurrence le trafic entrant et sortant des serveurs DNS, qu'ils soient des résolveurs ou bien des serveurs faisant autorité. Ce genre de récolte peut être coordonnée par l'OARC pour des projets comme DITL (« un jour dans la vie de l'Internet »). Un exemple d'une telle récolte, faite avec le classique tcpdump (qui, en dépit de son nom, ne fait pas que du TCP) :

% tcpdump -w /tmp/dns.pcap port 53
    
Le fichier produit (ici, sur un serveur faisant autorité pour eu.org), au format pcap, contient les requêtes DNS et les réponses, et peut être analysé avec des outils comme tcpdump lui-même, ou comme Wireshark. Il y a aussi des outils spécifiques au DNS comme PacketQ ou comme dnscap. Ici, avec tcpdump :
% tcpdump -n -r /tmp/dns.pcap      
15:35:22.432746 IP6 2001:db8:aa:101::.40098 > 2400:8902::f03c:91ff:fe69:60d3.53: 41209% [1au] A? tracker.torrent.eu.org. (51)
15:35:22.432824 IP6 2400:8902::f03c:91ff:fe69:60d3.53 > 2001:db8:aa:101::.40098: 41209- 0/4/5 (428)
    
Au lieu des outils tous faits, on peut aussi développer ses propres programmes en utilisant les nombreuses bibliothèques qui permettent de traiter du pcap (attention si vous analysez du trafic Internet : beaucoup de paquets sont mal formés, par accident ou bien délibérément, et votre analyseur doit donc être robuste). C'est ce que font en général les chercheurs qui analysent les données DITL.

Le problème du format pcap (ou pcapng) est qu'il y a à la fois trop de données et pas assez. Il y a trop de données car il inclut des informations probablement rarement utiles, comme les adresses MAC et car il ne minimise pas les données. Et il n'y en a pas assez car il ne stocke pas les informations qui n'étaient pas visibles sur le réseau mais qui l'étaient uniquement dans la mémoire du serveur DNS. Ainsi, on ne sait pas si la réponse d'un résolveur avait été trouvée dans le cache ou pas. Ou bien si les données étaient dans le bailliage ou pas (cf. RFC 8499, section 7). Les captures DNS peuvent être de très grande taille (10 000 requêtes par seconde est banal, 100 000, ça arrive parfois) et on désire les optimiser autant que possible, pour permettre leur rapatriement depuis les serveurs éloignés, puis leur stockage parfois sur de longues périodes. (Les formats « texte » comme celui du RFC 8427 ne conviennent que pour un message isolé, ou un tout petit nombre de messages.)

Le cahier des charges du format C-DNS (Compacted DNS) est donc :

  • Minimiser la taille des données,
  • Minimiser le temps de traitement pour compacter et décompacter.

La section du RFC détaille les scénarios d'usage de C-DNS. En effet, la capture de données DNS peut être faite dans des circonstances très différentes. Le serveur peut être une machine physique, une virtuelle, voire un simple conteneur. La personne qui gère le capture peut avoir le contrôle des équipements réseau (un commutateur, par exemple, pour faire du port mirroring), le serveur peut être surdimensionné ou, au contraire, soumis à une attaque par déni de service qui lui laisse peu de ressources. Le réseau de collecte des données capturées peut être le même que le réseau de service ou bien un réseau différent, parfois avec une capacité plus faible. Bref, il y a beaucoup de cas. C-DNS est optimisé pour les cas où :

  • La capture des données se fait sur le serveur lui-même, pas sur un équipement réseau,
  • Les données seront stockées localement, au moins temporairement, puis analysées sur une autre machine.
Donc, il est crucial de minimiser la taille des données récoltées. Mais il faut aussi faire attention à la charge que représente la collecte : le serveur de noms a pour rôle de répondre aux requêtes DNS, la collecte est secondaire, et ne doit donc pas consommer trop de ressources CPU.

Compte-tenu de ces contraintes, C-DNS a été conçu ainsi (section 4 du RFC) :

  • L'unité de base d'un fichier C-DNS est le couple R/R, {requête DNS, réponse DNS} (Q/R data item), ce qui reflète le fonctionnement du protocole DNS, et permet d'optimiser le stockage, puisque bien des champs ont des valeurs communes entre une requête et une réponse (par exemple le nom de domaine demandé). Notez qu'un couple R/R peut ne comporter que la requête, ou que la réponse, si l'autre n'a pas pu être capturée, ou bien si on a décidé délibérément de ne pas le faire.
  • C-DNS est optimisé pour les messages DNS syntaxiquement corrects. Quand on écrit un analyseur de paquets DNS, on est frappés du nombre de messages incorrects qui circulent sur le réseau. C-DNS permet de les stocker sous forme d'un « blob » binaire, mais ce n'est pas son but principal, il ne sera donc efficace que pour les messages corrects.
  • Pratiquement toute les données sont optionnelles dans C-DNS. C'est à la fois pour gagner de la place, pour tenir compte du fait que certains mécanismes de capture ne gardent pas toute l'information, et pour permettre de minimiser les données afin de préserver la vie privée.
  • Les couples R/R sont regroupés en blocs, sur la base d'élements communs (par exemple l'adresse IP source, ou bien la réponse, notamment les NXDOMAIN), qui permettent d'optimiser le stockage, en ne gardant cet élément commun qu'une fois par bloc. (Par contre, cela complexifie les programmes. On n'a rien sans rien.)

C-DNS repose sur CBOR (RFC 7049). La section 5 du RFC explique pourquoi :

  • Format binaire, donc prenant moins d'octets que les formats texte comme JSON (l'annexe C discute des autres formats binaires),
  • CBOR est un format normalisé et répandu,
  • CBOR est simple et écrire un analyseur peut se faire facilement, si on ne veut pas dépendre d'une bibliothèque extérieure,
  • CBOR a désormais un langage de schéma, CDDL (RFC 8610), qu'utilise notre RFC.

Avec la section 6 du RFC commence la description du format. Classiquement, un fichier C-DNS commence par un en-tête, puis une série de blocs. Chaque bloc comprend un certain nombre de tables (par exemple une table d'adresses IP pour les adresses apparaissant dans le bloc), suivies des éléments R/R. Ceux-ci référencent les tables. Ainsi, une requête de 2001:db8:1::cafe à 2001:db8:ffff::beef pour le nom www.example.org contiendra des pointeurs vers les entrées 2001:db8:1::cafe et 2001:db8:ffff::beef de la table des adresses IP, et un pointeur vers l'entrée www.example.org de la table des noms de domaine. S'il n'y a qu'un seul élément R/R dans le bloc, ce serait évidemment une complication inutile, mais l'idée est de factoriser les données qui sont souvent répétées.

On l'a vu, dans C-DNS, plein de choses sont optionnelles, car deux dispositifs de capture différents ne récoltent pas forcément les mêmes données. Ainsi, par exemple, un système de capture situé dans le logiciel serveur n'a pas forcément accès à la couche IP et ne peut donc pas enregistrer le nombre maximal de sauts (hop limit). Cela veut dire que, quand on lit un fichier C-DNS :

  • Il faut déterminer si une donnée est présente ou pas, et ne pas supposer qu'elle l'est forcément,
  • Il peut être utile de déterminer si une donnée manquante était absente dès le début, ou bien si elle a été délibérément ignorée par le système de capture. Si un message ne contient pas d'option EDNS (RFC 6891), était-ce parce que le message n'avait pas cette option, ou simplement parce qu'on ne s'y intéressait pas et qu'on ne l'a pas enregistrée ?
C-DNS permet donc d'indiquer quels éléments des données initiales ont été délibérément ignorés. Cela permet, par exemple, à un programme de lecture de fichiers C-DNS de savoir tout de suite si le fichier contient les informations qu'il veut.

Ces indications contiennent aussi des informations sur un éventuel échantillonnage (on n'a gardé que X % des messages), sur une éventuelle normalisation (par exemple tous les noms de domaine passés en caractères minuscules) ou sur l'application de techniques de minimisation, qui permettent de diminuer les risques pour la vie privée. Par exemple, au lieu de stocker les adresses IP complètes, on peut ne stocker qu'un préfixe (par exemple un /32 au lieu de l'adresse complète), et il faut alors l'indiquer dans le fichier C-DNS produit, pour que le lecteur comprenne bien que 2001:db8:: est un préfixe, pas une adresse.

La section 7 du RFC contient ensuite le format détaillé. Quelques points sont à noter (mais, si vous écrivez un lecteur C-DNS, lisez bien tout le RFC, pas juste mon article !) Ainsi, toutes les clés des objets (maps) CBOR sont des entiers, jamais des chaînes de caractère, pour gagner de la place. Et ces entiers sont toujours inférieurs à 24, pour tenir sur un seul octet en CBOR (lisez le RFC 7049 si vous voulez savoir pourquoi 24). On peut aussi avoir des clés négatives, pour les extensions au format de base, et elles sont comprises entre -24 et -1.

La syntaxe complète, rédigée dans le format CDDL du RFC 8610, figure dans l'annexe A de notre RFC.

On peut reconstruire un fichier pcap à partir de C-DNS. Une des difficultés est qu'on n'a pas forcément toutes les informations, et il va donc falloir être créatif (section 9). Une autre raison fait qu'on ne pourra pas reconstruire au bit près le fichier pcap qui aurait été capturé par un outil comme tcpdump : les noms de domaines dans les messages DNS étaient peut-être comprimés (RFC 1035, section 4.1.4) et C-DNS n'a pas gardé d'information sur cette compression. (Voir l'annexe B pour une discussion détaillée sur la compression.) Pareil pour les informations de couche 3 : C-DNS ne mémorise pas si le paquet UDP était fragmenté, s'il était dans un ou plusieurs segments TCP, s'il y avait des messages ICMP liés au trafic DNS, etc.

Si vous voulez écrire un lecteur ou un producteur de C-DNS, la section 11 du RFC contient des informations utiles pour la programmeuse ou le programmeur. D'abord, lisez bien le RFC 7049 sur CBOR. C-DNS utilise CBOR, et il faut donc connaitre ce format. Notamment, la section 3.9 du RFC 7049 donne des conseils aux implémenteurs CBOR pour produire un CBOR « canonique ». Notre RFC en retient deux, représenter les entiers, et les types CBOR, par la forme la plus courte possible (CBOR en permet plusieurs), mais il en déconseille deux autres. En effet, la section 3.9 du RFC 7049 suggérait de trier les objets selon la valeur des clés, et d'utiliser les tableaux de taille définie (taille indiquée explicitement au début, plutôt que d'avoir un marqueur de fin). Ces deux conseils ne sont pas réalistes pour le cas de C-DNS. Par exemple, pour utiliser un tableau de taille définie, il faudrait tout garder en mémoire jusqu'au moment où on inscrit les valeurs, ce qui augmenterait la consommation mémoire du producteur de données C-DNS. (D'un autre côté, le problème des tableaux de taille indéfinie est qu'ils ont un marqueur de fin ; si le programme qui écrit du C-DNS plante et ne met pas le marqueur de fin, le fichier est du CBOR invalide.)

Le RFC a créé plusieurs registres IANA pour ce format, stockant notamment les valeurs possibles pour le transport utilisé, pour les options de stockage (anonymisé, échantillonné...), pour le type de réponse (issue de la mémoire du résolveur ou pas).

Bien sûr, récolter des données de trafic DNS soulève beaucoup de problèmes liés à la vie privée (cf. RFC 7626). Il est donc recommander de minimiser les données, comme imposé par des réglements comme le RGPD, ou comme demandé dans le rapport « Recommendations on Anonymization Processes for Source IP Addresses Submitted for Future Analysis ».

Les passionnés de questions liées aux formats regarderont l'annexe C, qui liste des formats alternatifs à CBOR, qui n'ont finalement pas été retenus :

  • Apache Avro, trop complexe car on ne peut lire les données qu'en traitant le schéma,
  • Protocol Buffers, qui a le même problème,
  • JSON (RFC 8259), qui n'est pas un format binaire, mais qui a été ajouté pour compléter l'étude.
Cette annexe décrit également le résultat de mesures sur la compression obtenue avec divers outils, sur les différents formats. C-DNS n'est pas toujours le meilleur, mais il est certainement, une fois comprimé, plus petit que pcap, et plus simple à mettre en œuvre qu'Avro ou Protocol Buffers.

Notez que j'ai travaillé sur ce format lors d'un hackathon de l'IETF, mais le format a pas mal changé depuis (entre autres en raison des problèmes identifiés lors du hackathon).

Voyons maintenant une mise en œuvre de ce format, avec l'outil DNS-STATS plus exactement son Compactor (source sur Github, et documentation). Je l'ai installé sur une machine Debian :

aptitude install libpcap-dev libboost1.67-all-dev liblzma-dev libtins-dev
git clone https://github.com/dns-stats/compactor.git
cd compactor
sh autogen.sh
autoconf
automake
./configure
make
    
Et après, on peut l'utiliser pour transformer du C-DNS en pcap et réciproquement. J'ai créé un fichier pcap d'un million de paquets avec tcpdump sur un serveur faisant autorité, avec tcpdump -w dns.pcap -c 1000000 port 53. Puis :
%   ./compactor -o /tmp/dns.cdns  /tmp/dns.pcap
    
Et en sens inverse (reconstituer le pcap) :
%  ./inspector /tmp/dns.cdns
    
Cela nous donne :
% ls -lth /tmp/dns*                        
-rw-r--r-- 1 stephane stephane  98M Jul 31 08:13 /tmp/dns.cdns.pcap
-rw-r--r-- 1 stephane stephane 3.2K Jul 31 08:13 /tmp/dns.cdns.pcap.info
-rw-r--r-- 1 stephane stephane  27M Jul 31 07:27 /tmp/dns.cdns
-rw-r--r-- 1 root     root     339M Jul 30 20:05 /tmp/dns.pcap
    
Notez que dns.cdns.pcap est le pcap reconstitué, on remarque qu'il est plus petit que le pcap original, certaines informations ont été perdues, comme les adresses MAC. Mais il reste bien plus gros que la même information stockée en C-DNS. Le /tmp/dns.cdns.pcap.info nous donne quelques informations :
% cat /tmp/dns.cdns.pcap.info
CONFIGURATION:
  Query timeout        : 5 seconds
  Skew timeout         : 10 microseconds
  Snap length          : 65535
  Max block items      : 5000
  File rotation period : 14583
  Promiscuous mode     : Off
  Capture interfaces   : 
  Server addresses     : 
  VLAN IDs             : 
  Filter               : 
  Query options        : 
  Response options     : 
  Accept RR types      : 
  Ignore RR types      : 

COLLECTOR:
  Collector ID         : dns-stats-compactor 0.12.3
  Collection host ID   : ns1.example

STATISTICS:
  Total Packets processed                  : 1000000
  Matched DNS query/response pairs (C-DNS) : 484407
  Unmatched DNS queries            (C-DNS) : 98
  Unmatched DNS responses          (C-DNS) : 69
  Malformed DNS packets                    : 68
  Non-DNS packets                          : 0
  Out-of-order DNS query/responses         : 1
  Dropped C-DNS items (overload)           : 0
  Dropped raw PCAP packets (overload)      : 0
  Dropped non-DNS packets (overload)       : 0

RFC 8605: vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)

Ce RFC décrit des extensions au format vCard afin d'ajouter dans les réponses RDAP deux informations exigées par l'ICANN. Il concerne donc surtout registres et utilisateurs des TLD ICANN.

Le protocole RDAP (RFC 7483) sert à récupérer des informations sur un objet enregistré, par exemple un nom de domaine. Une partie des informations, par exemple les adresses et numéros de téléphone, est au format vCard (RFC 6350). Mais l'ICANN a des exigences supplémentaires, décrites dans la Specification for gTLD Registration Data. Par exemple, l'ICANN exige (cf. leur politique) que, si les informations sur un contact ne sont pas publiées (afin de préserver sa vie privée), le registre fournisse au moins un URI indiquant un moyen de contact (section 2.7.5.2 de la politique ICANN), par exemple un formulaire Web (comme https://www.afnic.fr/fr/resoudre-un-litige/actions-et-procedures/joindre-le-contact-administratif-d-un-domaine/). Cette propriété CONTACT-URI est désormais dans le registre IANA. (Si vous voulez réviser les notions de propriété et de paramètre en vCard, plus exactement jCard, cf. RFC 7095.)

D'autre part, la norme vCard, le RFC 6350, précise dans sa section 6.3.1, que le nom du pays doit être spécifié en langue naturelle, alors que l'ICANN exige (section 1.4 de leur politique) un code à deux lettres tiré de la norme ISO 3166. (Notez qu'à l'heure actuelle, certains registres mettent le nom du pays, d'autres le code à deux lettres…) Le paramètre CC, qui va indiquer le code, est désormais dans le registre IANA.

Ainsi, une réponse vCard suivant notre RFC pourrait indiquer (je ne peux pas vous montrer d'exemples réels d'un registre, aucun n'a apparemment déployé ces extensions, mais, si vous êtes curieux, lisez jusqu'à la fin) :

      
%  curl -s https://rdap.nic.example/domain/foobar.example | jq . 
...
    [
            "contact-uri",  <<< Nouveauté
            {},
            "uri",
            "https://rds.nic.example/get-in-touch"
    ]
...
    [
            "adr",
            {"cc": "US"},  <<< Nouveauté
	    "text",
            ["", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A."]
   ]    
...

    

J'ai parlé jusqu'à présent des registres, mais l'ICANN impose également RDAP aux bureaux d'enregistrement. Cela a en effet un sens pour les registres minces, comme .com, où les données sociales sont chez les bureaux en question. La liste des bureaux d'enregistrement ICANN contient une colonne indiquant leur serveur RDAP. Testons avec Blacknight, qui est souvent à la pointe :

% curl https://rdap.blacknight.com/domain/blacknight.com | jq .  
...
          [
            "fn",
            {},
            "text",
            "Blacknight Internet Solutions Ltd."
          ],
          [
            "adr",
            {
              "cc": "IE"
            },
...
          [
            "contact-uri",
            {},
            "uri",
            "https://whois.blacknight.com/contact.php?fqdn=blacknight.com&contact_type=owner"
          ]
    
On a bien un usage de ces extensions dans le monde réel (merci à Patrick Mevzek pour ses remarques et ajouts).

2019-09-03

RFC 8615: Well-Known Uniform Resource Identifiers (URIs)

Plusieurs normes du Web s'appuient sur l'existence d'un fichier à un endroit bien connu d'un site. Les deux exemples les plus connus sont robots.txt et favicon.ico. Autrefois, ces endroits « bien connus » étaient alloués sans schéma central. Depuis le RFC 5785, c'est mieux organisé, avec tous ces fichiers « sous » /.well-known/. Notre RFC remplace le RFC 5785 (et le RFC 8307), avec peu de changements significatifs.

Prenons l'exemple le plus connu, robots.txt, fichier stockant la politique d'autorisation des robots qui fouillent le Web. Si un robot examine le site Web http://www.example.org/, il va tenter de trouver ledit fichier en http://www.example.org/robots.txt. Même chose pour, par exemple, sitemap.xml ou P3P (section 1 du RFC). Ce système avait plusieurs inconvénients, notamment le risque de collision entre deux noms (puisqu'il n'y avait pas de registre de ces noms) et, pire, le risque de collision entre un de ces noms et une ressource normale du site. D'où l'importance d'un « rangement » de ces ressources bien connues. Elles doivent dorénavant être préfixées de /.well-known/. Ainsi, si le protocole d'autorisation des robots était normalisé aujourd'hui, on récupérerait la politique d'autorisation en http://www.example.org/.well-known/robots.txt.

À noter que le RFC spécifie uniquement un préfixe pour le chemin de la ressource, /.well-known/ n'est pas forcément un répertoire sur le disque du serveur (même si c'est une mise en œuvre possible).

Le RFC 8615 note aussi qu'il existe déjà des mécanismes de récupération de métadonnées par ressource (comme les en-têtes de HTTP ou les propriétés de WebDAV) mais que ces mécanismes sont perçus comme trop lourds pour remplacer la ressource unique située en un endroit bien connu.

Le nom .well-known avait été choisi (cf. annexe A de notre RFC) car il avait peu de chances de rentrer en conflit avec un nom existant (traditionnellement, sur Unix, système d'exploitation le plus utilisé sur les serveurs Web, les fichiers dont le nom commencent par un point ne sont pas affichés).

Bref, passons à la section 3 qui donne les détails syntaxiques. Le préfixe est donc /.well-known/, les noms en « dessous » doivent être enregistrés (cf. section 5.1), et ils doivent se conformer à la production segment-nz du RFC 3986 (en clair, cela veut dire qu'ils doivent être une suite de caractères ASCII imprimables, avec quelques exclusions comme la barre oblique). Du point de vue sémantique, ils doivent être précis, pour éviter l'appropriation de termes génériques (par exemple, l'application Toto qui veut stocker ses métadonnées devrait utiliser toto-metadata et pas juste metadata.) À noter que l'effet d'une requête GET /.well-known/ (tout court, sans nom de ressource après), est indéfini (sur mon blog, cela donne ça ; devrais-je le configurer pour renvoyer autre chose ? Sur Mastodon, ça donne 404.)

Quelques conseils de sécurité pour le webmestre (section 4) : ces ressources « bien connues » s'appliquent à une origine (un « site Web ») entière, donc attention à contrôler qui peut les créer ou les modifier, et d'autre part, dans le contexte d'un navigateur Web, elles peuvent être modifiées par du contenu, par exemple JavaScript.

La section 5 décrit les conditions d'enregistrement des noms bien connus à l'IANA. Le registre contient par exemple les métadonnées du RFC 6415. Y mettre des noms supplémentaires nécessite un examen par un expert et une description publiée (pas forcément un RFC). Dans les termes du RFC 8126, ce sera Spécification Nécessaire et Examen par un Expert. Il y a un mini-formulaire à remplir (section 3.1 du RFC) et hop, le nom bien connu sera enregistré. Plusieurs existent désormais.

Notez qu'il est très difficile de savoir combien de sites ont des ressources /.well-known. Bien sûr, Google le sait, mais ne donne pas accès à cette information (une requête inurl:/.well-known ou inurl:"/.well-known" ignore hélas le point initial et trouve donc surtout des faux positifs). Si on n'a pas accès à la base de Google, il faudrait donc faire soi-même une mesure active avec un client HTTP qui aille visiter de nombreux sites.

Les changements depuis le RFC 5785 sont résumés dans l'annexe B du RFC :

  • Les plans d'URI pour WebSocket, du RFC 8307, ont été intégrés,
  • D'ailleurs, le préfixe /.well-known/ n'est plus réservé au Web, il peut être utilisé pour d'autres plans d'URI, ce qui a modifié le registre des plans pour y ajouter une colonne indiquant s'ils permettent ce préfixe (section 5.2),
  • Les instructions pour l'enregistrement d'un nouveau nom ont été légèrement assouplies,
  • La section sur la sécurité est nettement plus détaillée.

2019-09-02

RFC 8624: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

Quel algorithme de cryptographie choisir pour mes signatures DNSSEC, se demande l'ingénieur système. Lesquels doivent être reconnus par le logiciel que j'écris, s'interroge la programmeuse. Il y a bien un registre IANA des algorithmes normalisés mais c'est juste une liste non qualifiée, qui mêle des algorithmes de caractéristiques très différentes. Ce nouveau RFC vise à répondre à cette question en disant quels sont les algorithmes recommandés. Il remplace l'ancien RFC 6944, qui est modifié considérablement. Notamment, il marque l'avantage désormais donné aux courbes elliptiques par rapport à RSA.

La précédente liste d'algorithmes possibles datait donc du RFC 6944. D'autres algorithmes ont été ajoutés par la suite. Certains sont devenus populaires. Par exemple, ECDSA est maintenant suffisamment répandu pour qu'un résolveur validant ne puisse plus raisonnablement l'ignorer. D'autres algorithmes ont été peu à peu abandonnés, par exemple parce que les progrès de la cryptanalyse les menaçaient trop.

Aujourd'hui, le développeur qui écrit ou modifie un signeur (comme ldns, utilisé par OpenDNSSEC) ou un logiciel résolveur validant (comme Unbound ou Knot) doit donc se taper pas mal de RFC mais aussi pas mal de sagesse collective distillée dans plusieurs listes de diffusion pour se faire une bonne idée des algorithmes que son logiciel devrait gérer et de ceux qu'il peut laisser tomber sans trop gêner ses utilisateurs. Ce RFC vise à lui simplifier la tâche, en classant ces algorithmes selon plusieurs niveaux.

Notre RFC 8624 détermine pour chaque algorithme s'il est indispensable (MUST, nécessaire pour assurer l'interopérabilité), recommandé (RECOMMENDED, ce serait vraiment bien de l'avoir, sauf raison contraire impérieuse), facultatif (MAY, si vous n'avez rien d'autre à faire de vos soirées que de programmer) ou tout simplement déconseillé (NOT RECOMMENDED), voire à éviter (MUST NOT, pour le cas de faiblesses cryptographiques graves et avérées). Il y a deux catégorisations, une pour les signeurs (le cas de l'administratrice système cité au début), et une pour les résolveurs qui valideront. Par exemple, un signeur ne devrait plus utiliser RSA avec SHA-1, vu les faiblesses de SHA-1, mais un résolveur validant doit toujours le traiter, car des nombreux domaines sont ainsi signés. S'il ignorait cet algorithme, bien des zones seraient considérées comme non signées.

La liste qualifiée des algorithmes se trouve dans la section 3 : ECDSA avec la courbe P-256, et RSA avec SHA-256, sont les seuls indispensables pour les signeurs. ED25519 (RFC 8080) est recommandé (et sera probablement indispensable dans le prochain RFC). Plusieurs algorithmes sont à éviter, comme DSA, GOST R 34.10-2001 (RFC 5933) ou RSA avec MD5 (RFC 6151). Tous les autres sont facultatifs.

Pour les résolveurs validants, la liste des indispensables et des recommandés est un peu plus longue. Par exemple, ED448 (RFC 8080) est facultatif pour les signeurs mais recommandé pour les résolveurs.

La même section 3 justifie ces choix : RSA+SHA-1 est l'algorithme de référence, celui qui assure l'interopérabilité (tout logiciel compatible DNSSEC doit le mettre en œuvre) et c'est pour cela qu'il reste indispensable pour les résolveurs, malgré les faiblesses de SHA-1. RSA+SHA-256 est également indispensable car la racine et la plupart des TLD l'utilisent aujourd'hui. Un résolveur qui ne comprendrait pas ces algorithmes ne servirait pas à grand'chose. RSA+SHA-512 ne pose pas de problème de sécurité, mais a été peu utilisé, d'où son statut « non recommandé » pour les signeurs.

D'autre part, le RFC insiste sur le fait qu'on ne peut pas changer le statut d'un algorithme trop vite : il faut laisser aux ingénieurs système le temps de changer leurs zones DNS. Et les résolveurs sont forcément en retard sur les signeurs : même si les signeurs n'utilisent plus un algorithme dans leurs nouvelles versions, les résolveurs devront continuer à l'utiliser pour valider les zones pas encore migrées.

Depuis le RFC 6944, ECDSA a vu son utilisation augmenter nettement. Les courbes elliptiques sont clairement l'avenir, d'où leur statut mieux placé. Ainsi, une zone DNS qui n'était pas signée et qui va désormais l'être devrait choisir un algorithme à courbes elliptiques, comme ECDSA ou EdDSA (RFC 8032 et RFC 8080). Avec ECDSA, il est recommandé d'utiliser l'algorithme déterministe du RFC 6979 pour générer les signatures. Les zones actuellement signées avec RSA devraient migrer vers les courbes elliptiques. Une chose est sûre, la cryptographie évolue et ce RFC ne sera donc pas éternel.

Le RFC note d'ailleurs (section 5) que le remplacement d'un algorithme cryptographique par un autre (pas juste le remplacement d'une clé) est une opération complexe, à faire avec prudence et après avoir lu les RFC 6781 et RFC 7583.

Ah, et parmi les algorithmes à courbes elliptiques, GOST (RFC 5933) régresse car l'ancien algorithme R 34.10-2001 a été remplacé par un nouveau qui n'est pas, lui, normalisé pour DNSSEC. L'algorithme venant du GOST avait été normalisé pour DNSSEC car les gérants du .ru disaient qu'ils ne pouvaient pas signer avec un algorithme étranger mais, finalement, ils ont utilisé RSA, ce qui diminue sérieusement l'intérêt des algorithmes GOST.

Outre les signeurs et les résolveurs, le RFC prévoit le cas des registres, qui délèguent des zones signées, en mettant un enregistrement DS dans leur zone. Ces enregistrements DS sont des condensats de la clé publique de la zone fille, et, ici, SHA-1 est à éviter et SHA-256 est indispensable.

Aujourd'hui, les mises en œuvre courantes de DNSSEC sont en général compatibles avec ce que demande le RFC. Elles sont parfois trop « généreuses » (RSA+MD5 encore présent chez certains), parfois un peu trop en retard (ED448 pas encore présent partout).

2019-08-30

RFC 5933: Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC

L'algorithme de signature russe GOST R 34.10-2001 ayant été spécifié en anglais dans le RFC 5832, plus rien ne s'opposait à son utilisation dans DNSSEC. Ce RFC marque donc l'arrivée d'un nouvel algorithme dans les enregistrements DNSSEC, algorithme portant le numéro 12. (Depuis, le GOST R 34.10-2012 a été publié, mais pas normalisé pour DNSSEC.)

La liste originelle des algorithmes DNSSEC figurait dans le RFC 4034, annexe A.1. La liste actuelle est un registre à l'IANA, https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml#dns-sec-alg-numbers-1. Elle comprend désormais GOST. Notez que GOST désigne en fait une organisation de normalisation, le terme correcte serait plutôt « GOST R 34.10-2001 » pour l'algorithme de signature et « GOST R 34.11-94 » pour celui de condensation, décrit dans le RFC 5831 (voir la section 1 de notre RFC 5933).

La section 2 décrit le format des enregistrements DNSKEY avec GOST, dans lequel on publie les clés GOST R 34.10-2001. Le champ Algorithme vaut 12, le format de la clé sur le réseau suit le RFC 4491. GOST est un algorithme à courbes elliptiques, courbes décrites par Q = (x,y). Les 32 premiers octets de la clé sont x et les 32 suivants y (en petit-boutien, attention, contrairement à la majorité des protocoles Internet). Les autres paramètres de la clé figurent dans le RFC 4357.

Les bibliothèques cryptographiques existantes sont parfois capables de lire des clés GOST (section 2.1). Pour OpenSSL, il existe une distribution de GOST (par la même entreprise où travaille l'auteur des RFC GOST).

La section 2.2 donne un exemple de clé GOST publiée dans le DNS mais autant utiliser ici un exemple réel (ce domaine a des clés GOST et aussi des clés RSA de type 5) :


% dig +multi DNSKEY caint.su

; <<>> DiG 9.9.2 <<>> +multi DNSKEY caint.su
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61873
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;caint.su.              IN DNSKEY

;; ANSWER SECTION:
caint.su.               3600 IN DNSKEY 256 3 12 (
                                HQUwRfZDsGuso1XEVztO9nIt7S6MrC/XNYQ9Agup8oW0
                                FCfy0T52buB3czWe9YHa0kLgrcFP1pHpu19jdmO70A==
                                ) ; ZSK; alg = ECCGOST; key id = 35724
caint.su.               3600 IN DNSKEY 257 3 5 (
                                AwEAAdfmAyxcSu09Ik449sIGygbD78jxCKaBek3fhC1a
                                hO7363pdMGlXf8ZEzv7Kl+9yOokmMoTI0peVUqF57it3
                                hmqcIJQ+OsrKdsF1XBwa8VULaLh+TNb67dkdbj6iZ6Gd
                                WxkD6i2vbjvmVHtoQyKswgeR7lUn42XMRYRbYiIrI5r8
                                zT/xllwtCCxaC68V6azpk//7GrYpnwS9NGzr2cBignwj
                                Jj6VeAGfrBe5AM0XNplaFLf7NNU34qqGBKpYbogdAYzM
                                Il02dhPvruzDcadbm2a53OI2/fqchjOgZ8wSTfekuJQb
                                ReYWsNUasgqxjydMU5vweSiogGqkrUEzqn5PD/0=
                                ) ; KSK; alg = RSASHA1; key id = 697
caint.su.               3600 IN DNSKEY 257 3 12 (
                                qMxkfdx4fNxdLDU3z5KGAxrEiL1fm+dxw03js+ACY996
                                wc1wYiVbmqA1QVUmLg5bO3/IawdItM3jQcigFEi/3A==
                                ) ; KSK; alg = ECCGOST; key id = 33831
caint.su.               3600 IN DNSKEY 256 3 5 (
                                AwEAAawWrWjeYqJ+07pakuybnkLQz3xbe1rnG2g7ihfO
                                NpSLNYrNOyhcCTRbt3cgJLWR29Qh6uko9Zcd9uylHlY1
                                ru1HpBQxpzKffwUUki2e7SiTiGrj/DvJz9UH52VZyxi5
                                qf9neYBz0sxvlrLWC5JMqqGIBRUMx/clPjab72BV7exR
                                ) ; ZSK; alg = RSASHA1; key id = 15876

;; Query time: 326 msec
;; SERVER: 192.168.2.254#53(192.168.2.254)
;; WHEN: Tue Oct 23 15:59:57 2012
;; MSG SIZE  rcvd: 621


La section 3 décrit le format des enregistrements RRSIG, les signatures. On suit les RFC 4490 et RFC 4357. Voici un exemple actuellement présent dans le DNS (notez qu'il y a double signature, avec RSA et GOST, la clé GOST étant la 35724) :


dig +dnssec MX caint.su

; <<>> DiG 9.9.2 <<>> +dnssec MX caint.su
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61031
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 10

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;caint.su.                      IN      MX

;; ANSWER SECTION:
caint.su.               3600    IN      MX      10 mail.caint.su.
caint.su.               3600    IN      RRSIG   MX 5 2 3600 20121027063752 20120927063752 15876 caint.su. E5d1eZxLgYxNg1YiNXEyQ5UGJFOyd09bmpo9AtwnpJn0ezSX0wsAnvd1 ExBWf9ue0TnPSknZxofevtOHD3cBw09Lq/ZathhEOvNhHaK4kbMEXWm7 KzwLeNDDhqNbhAbY0duDLEPCA69ege00dJFjBMtqV17TTJ13BxrFXNzs Hmk=
caint.su.               3600    IN      RRSIG   MX 12 2 3600 20121027063752 20120927063752 35724 caint.su. 52NgPC9ZmFwIgL8CsK0C+wwoM+brh4uTfw70yRDJTjbkUVivkdCakDIS YVxPLWaQO6mDMzNwC53QYqwUyEYlEQ==

...

Attention, une particularité de GOST fait que deux signatures des mêmes données peuvent donner des résultats différents, car un élément aléatoire est présent dans la signature.

La section 4 décrit le format des enregistrements DS pour GOST. La clé publique de la zone fille est condensée par GOST R 34.11_94, algorithme de numéro 3. Voici un exemple dans la nature :

% dig DS caint.su
...
caint.su.               345330  IN      DS      33831 12 3 267B93EB54BF7707BF5500900722F3B0FBFCA04FF4F1BF22735F9ABB 607832E2
Notez que ce domaine a d'autres clés et aussi la même clé condensée par les algorithmes de la famille SHA, soit six DS en tout. Ou un autre exemple dans .fr ?
absolight.fr.		172724 IN DS 12545 8 3 (
				DDA74E5E94CEA6057072B073F60A5DD37D16DC8E896A
				EC57B055888DB84B4210 )

Les sections 5 et 6 couvrent des questions pratiques liées au développement et au déploiement de systèmes GOST, par exemple un rappel sur la taille de la clé (512 bits) et sur celle du condensat cryptographique (256 bits).

GOST peut se valider avec Unbound (au moins depuis la version 1.4.4, voir l'option de compilation --enable-gost) et avec BIND (depuis la version 9.8, si elle est compilée avec un OpenSSL qui a GOST). nsd a GOST depuis la version 3.2.11, pubiée en juillet 2012. Pour les programmeurs Java, DNSjava a GOST depuis la version 2.1.7. Pour le statut (recommandé ou non) de l'algorithme GOST pour DNSSEC, voir le RFC 8624. On peut trouver des conseils pratiques pour l'utilisation de GOST en anglais à http://www.cryptocom.ru/dns/dnssec-cryptocom-en.html.

SÉLECTION

Cette planète rassemble les principaux carnets web d'auteurs francophones traitant de XML. Ces blogs sont souvent bilingues français/anglais et éclectiques. Cette page rassemble l'ensemble de leurs billets et vous permet de sélectionner ceux que vous voulez voir.


Lien permanent pour cette sélection :
feed /actualites/planete/xmlfr/fr/
Les documents publiés sur ce site le sont sous licence " Open Content".

Valid XHTML 1.0 Transitional

logo DYOMEDEA
Conception, réalisation et hébergement

Questions ou commentaires
redacteurs@xmlfr.org