Mon blog

Il y à en ce moment en France, et dans d'autres pays, un débat vigoureux sur le déploiement de la 5G. Je vous rassure, je ne vais pas donner un avis définitif sur tous les aspects de ce débat, mais il me semble que plusieurs points importants n'ont que peu ou pas été abordés.

5G est un terme qui regroupe un ensemble de techniques et de normes pour les télécommunications mobiles, techniques qui peuvent être déployées ensemble ou séparément. Les promoteurs de la 5G promettent des miracles, mais il y a des opposants.

D'abord, je voudrais dire que ce débat, cette friction, est une excellente chose. (Et c'est relativement récent.) Les techniques jouent un rôle crucial dans notre société, les techniques de communication sont partout et influencent fortement ce que nous pouvons faire ou ne pas faire, et il est donc très bien que les citoyens et citoyennes soient informés qu'un désaccord existe. Déployer ou pas la 5G est en effet un choix politique (politique au sens « concerne la vie de la société », évidemment pas au sens « qui sera ministre des Déclarations Ridicules à la Télé ».) Il n'y a pas de loi physique (ou sociale) qui ferait du déploiement de la 5G un événement inéluctable, comme la chute des pommes ou comme l'explosion de Bételgeuse. « On n'arrête pas le progrès » est une phrase idiote, d'abord parce que toute nouvelle technique n'est pas forcément un progrès (ce peut être une régression) et ensuite parce que, justement, le progrès se décide. C'est le cas pour l'invention (ce qui se fait dans les labos, et qui dépend des thèmes à la mode, et de leur financement) et encore plus pour l'innovation (le déploiement hors des labos, qui nécessite des investissements lourds et donc des décisions difficiles.)

Donc, le débat actuel sur la 5G est une bonne chose. Mais sur quoi porte-t-il ? Les partisans de la 5G mettent en avant :

• Les performances accrues, en capacité et surtout en latence,
• La possibilité de nouveaux services, par exemple pour les objets connectés, via des nouveautés comme une qualité de service garantie.

Les opposants critiquent (j'ai essayé de faire une liste exhaustive, mais il faut bien noter que tous les opposants ne partagent pas tous ces arguments) :

• Les risques d'espionnage liés au fait que les équipements 5G sont souvent fabriqués par des entreprises chinoises, notamment Huawei, qui fait en ce moment l'objet d'une campagne menée par le gouvernement des États-Unis,
• Plus généralement, le risque de perte de souveraineté liés à cette dépendance vis-à-vis d'un fournisseur chinois,
• Les problèmes de santé liés au rayonnement électromagnétique,
• Les problèmes écologiques liés à la consommation énergétique des nombreux équipements nécessaires (puisque la portée de la 5G est inférieure, il faudra davantage de stations de base),
• Lié au précédent, le problème philosophique du « progrès ». Voulons-nous de cette course à la communication toujours plus rapide ?

Je ne vais pas faire un dossier complet sur la 5G, sujet sur lequel je ne suis pas un expert. Mais je voudrais mettre en avant quelques points qui, il me semble, ont été un peu oubliés dans le débat. Je vais suivre l'ordre des arguments donnés ci-dessus, en commençant par les arguments « pour ».

Sur les performances, il est important de rappeler que le vécu d'un utilisateur ou d'une utilisatrice ne dépend pas que de la 5G. Quand M. Michu ou Mme Toutlemonde, dans la rue, regarde le site Web de Wikipédia, le résultat final, en terme de performances, dépend de toute une chaîne, les performances des deux ordinateurs aux extrémités, celles du réseau mobile, mais aussi celles de tous les liens Internet entre M. Michu et Wikipédia. Le goulet d'étranglement, le point le moins performant et qui limite la performance globale, n'est pas forcément le réseau mobile. Par exemple, les sites Web modernes nécessitent souvent des calculs complexes pour leur affichage, et la rapidité de chargement des fichiers n'y changera rien. Dire « la 5G permettra d'accélérer la visualisation des pages Web » est au mieux une simplification, au pire un mensonge publicitaire.

Et puis ces performances mirifiques sont très théoriques : elles reposent sur des comparaisons faites en laboratoire, or les ondes sont très sensibles à l'environnement extérieur, et la réalité ne sera donc jamais aussi belle que la théorie. Regardez simplement comment, aujoud'hui, vous n'avez pas la 4G partout et que votre ordiphone se rabat souvent en 3G voire moins.

Concernant les services nouveaux, on a entendu beaucoup d'arguments marketing. Le record étant sans doute la promesse de pouvoir faire de la téléchirurgie via la 5G car elle offrirait « des garanties de service ». La réalité est moins rose : aucune technique ne peut promettre qu'il n'y aura jamais de panne. Faire de la téléchirurgie sans avoir de solution de secours (par exemple un autre chirurgien sur place) serait criminel, 5G ou pas 5G.

Il faut aussi rajouter que ces nouveaux services ne sont pas forcément quelque chose de positif. Globalement, la 5G est surtout poussée par les opérateurs de télécommunications traditionnels, qui sont historiquement des adversaires de la neutralité du réseau. La 5G, par la virtualisation du réseau, permettrait plus facilement de faire des services différenciés, donc probablement de violer ladite neutralité.

Et les arguments des opposants, ou des gens critiques vis-à-vis de la 5G ? Commençons par le risque d'espionnage, souvent mentionné, et qui a mené à une guerre commerciale entre le gouvernement étatsunien et Huawei. Grosso-modo, disent les inquiets, si on laisse faire, une grande partie des équipements 5G installés seront fabriqués par Huawei (puisque ce sont les moins chers), et Huawei aura donc la possibilité technique d'espionner tout le trafic. Le problème de cet argument, c'est que ce n'est pas mieux avec les fournisseurs non-chinois. Il faudrait être naïf pour croire que seul Huawei a des portes dérobées. D'autre part, le modèle de menace de l'Internet a toujours été qu'on ne pouvait pas faire confiance au réseau, car on ne peut pas évaluer la totalité de la chaîne. Le RFC 3552 en déduit logiquement que la sécurité doit être de bout en bout, donc qu'il faut chiffrer la communication de bout en bout, 5G ou pas, Huawei ou pas. (Rappelez-vous que le lien 5G n'est qu'une partie de la chaîne qui connecte deux personnes qui communiquent et qu'analyser la sécurité en ne regardant que la 5G serait une sérieuse erreur.) Évidemment, ce point de vue comme quoi le chiffrement de bout en bout est indispensable n'est pas partagé par les opérateurs de télécommunications, qui voudraient bien continuer à surveiller le trafic (cf. RFC 8404.)

D'autre part, il n'y a pas que le fournisseur de matériel, il y a aussi les boites qui gèrent le réseau, et, là, la sous-traitance est fréquente, et la perte de compétence inquiétante, comme le démontre l'excellent article de Bert Hubert.

Si le chiffrement protège bien contre la surveillance, il ne protège pas contre les dénis de service. Que se passe-t-il si un ordre venu de Beijing bloque subitement toutes les commmunications ? Le problème est réel (mais bien moins cité que celui de confidentialité, pourtant plus facile à résoudre.) Pour ce problème, en effet, le choix du fournisseur des équipements 5G est crucial mais, comme on l'a dit, les Chinois n'ont pas le monopole des portes dérobées. La solution ici, nécessite au minimum de n'utiliser que du logiciel libre dans les équipements de communication, afin de pouvoir les évaluer, mais on en est loin.

Et les conséquences sur la santé ? La question est très difficile à analyser car on a peu d'études scientifiques sérieuses sur la question. (PS : si vous avez une bonne bibliographie sur ce sujet, n'hésitez pas à me la communiquer. Il y a entre autre cette étude de l'IARC et cette synthèse des Décodeurs du Monde.) Il ne fait aucun doute que les ondes électromagnétiques peuvent être dangereuses (exposez-vous au soleil au Sahara sans protection et vous constaterez douloureusement que les ondes font parfois mal.) La question est de savoir dans quelles conditions (fréquence, puissance, durée d'exposition, etc.) Si les ondes ont vraiment un effet sur la santé, cet effet dépend forcément de ces conditions, et les discours anti-ondes sont toujours muets sur ce point. La recherche en ce domaine est d'autant plus difficile qu'il est possible que les éventuels effets médicaux soient à long terme, surtout pour des doses faibles. Et le débat est brouillé par des « anti-ondes » qui racontent n'importe quoi sur le Web, parfois relayés par des médias peu rigoureux, et par des commerçants charlatans qui cherchent à placer des remèdes miracles. On est rarement dans la rationalité ici, les effets, pourtant, eux, bien connus, de la pollution due au trafic routier ne suscitent pas la même mobilisation que « les ondes ».

Voyons maintenant l'argument écologique. Les fréquences utilisées par la 5G portent moins loin, il va falloir davantage de stations de base (ce qui va poser d'intéressants problèmes de main d'œuvre), donc a priori davantage de consommation énergétique. Mais en contrepartie, la puissance dépassée par chaque base sera inférieure, donc les partisans de la 5G avancent qu'elle pourrait diminuer la facture énergétique. J'avoue ne pas connaitre les chiffres exacts. (Là encore, si vous avez des études sérieuses, je prends. Je connais déjà cet exposé détaillé de la Commission Européenne et l'étude de Jancovici souvent citée.) Je vais donc passer mon tour sur ce point. Notez que, comme souvent dans les débats techniques, on voit parfois passer des erreurs qui font douter de la qualité générale du texrte. Par exemple dans ce document de la GSMA, on lit « can potentially increase cell energy consumption from 5-7 kW per 4G site per month to over 20 kW », mélangeant puissance (en watts) et énergie (en joules ou à la rigueur en watts*heures.)

Notez aussi qu'une conséquence du déploiement de la 5G serait sans doute le grand remplacement des terminaux (les ordiphones) et que cela a un coût (les équipements informatiques ont une empreinte écologique bien plus forte lors de la fabrication que lors de l'utilisation. Éteindre l'appareil qu'on n'utilise pas, c'est bien, ne pas le remplacer trop vite, c'est mieux.)

Il reste un dernier argument contre le déploiement de la 5G, l'argument qu'on pourrait appeler « philosophique ». En gros, en a-t-on besoin ? Le débat ne peut évidemment pas être tranché par la technique ou par les experts. D'un côté, on peut dire que l'augmentation des performances (dont on a vu qu'elle n'était pas garantie) est un but en soi. Après tout, chaque fois qu'on a augmenté les performances des ordinateurs et des réseaux, on a trouvé des usages (pas forcément souhaitables…) à cette augmentation. D'un autre côté, il n'y a pas de loi fondamentale disant que cela devrait continuer éternellement. Contrairement aux prévisions de la science-fiction, voitures volantes et avions à propulsion nucléaire ne se sont pas généralisés. Donc, le « progrès » n'est pas automatique. La question de fond est « qui va décider ? » Comment se font les choix qui impactent toute notre société ? Qui a décidé de déployer la 5G, et pour quels intérêts ?

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.

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.)

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.)

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).

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.

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.

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.

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.

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.

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 :

• Les autres sketchnotes de Kevin Ottens.