Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.


À propos du débat sur la 5G

Première rédaction de cet article le 19 février 2020


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 ?


L'article seul

RFC 8701: Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility

Date de publication du RFC : Janvier 2020
Auteur(s) du RFC : D. Benjamin (Google)
Pour information
Réalisé dans le cadre du groupe de travail IETF tls
Première rédaction de cet article le 29 janvier 2020


Ce nouveau RFC s'attaque à un problème fréquent dans l'Internet : des programmeurs paresseux, incompétents ou pressés par les délais imposés mettent en œuvre un protocole normalisé (comme TLS) sans bien lire les normes, et notamment sans tenir compter des variations que la norme permet. Ils programment rapidement, testent avec une ou deux implémentations trouvées et, si ça marche, en déduisent que c'est bon. Mais dès qu'une autre implémentation introduit des variantes, par exemple un paramètre optionnel et qui n'était pas utilisé avant, la bogue se révèle. Le cas s'est produit de nombreuses fois. Notre RFC propose une solution disruptive : utiliser délibérément, et au hasard, plein de variantes d'un protocole, de façon à détecter rapidement les programmes écrits avec les pieds. C'est le principe de GREASE (Generate Random Extensions And Sustain Extensibility), la graisse qu'on va mettre dans les rouages de l'Internet pour que ça glisse mieux. Ce RFC 8701 commence par appliquer ce principe à TLS.

Le problème n'est évidemment pas spécifique à TLS, on l'a vu arriver aussi dans BGP lorsqu'on s'est aperçu que la simple annonce d'un attribut BGP inconnu pouvait planter les routeurs Cisco. Là aussi, le « graissage » (tester systématiquement des valeurs non allouées pour les différents paramètres, pour vérifier que cela ne plante rien) aurait bien aidé. D'où le projet « Use it or lose it », décrit dans l'Internet-Draft draft-iab-use-it-or-lose-it dont GREASE est un cas particulier. Le draft draft-iab-use-it-or-lose-it analyse le problème des options non utilisées et recommande de les utiliser systématiquement, pour habituer les logiciels à voir ces options.

Le principe de GREASE (Generate Random Extensions And Sustain Extensibility) est donc de faire en sorte que clients et serveurs TLS (RFC 8446) annoncent, pour différents paramètres de la connexion, des valeurs qui ne correspondent à rien. Ainsi, les middleboxes boguées, installées au milieu de la communication parce que le commercial qui les vendait était convaincant, seront vite détectées, au lieu que le problème demeure dormant pendant des années et soit subitement révélé le jour où on essaie des valeurs légales mais nouvelles, comme dans le cas de l'attribut 99.

Qu'est-ce qui est variable dans TLS ? Beaucoup de choses, comme la liste des algorithmes de cryptographie ou comme les extensions. Dans TLS, le client annonce ce qu'il sait faire, et le serveur sélectionne dans ce choix (RFC 8446, section 4.1.3). Voici un exemple vu par tshark, d'abord le message du client (Client Hello), puis la réponse du serveur (Server Hello) :

Secure Sockets Layer
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Handshake Protocol: Client Hello
            Version: TLS 1.2 (0x0303)
            Cipher Suites (28 suites)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                ...
            Extension: ec_point_formats (len=4)
                Type: ec_point_formats (11)
                EC point formats Length: 3
                Elliptic curves point formats (3)
                    EC point format: uncompressed (0)
                    ...
            Extension: SessionTicket TLS (len=0)
                Type: SessionTicket TLS (35)
            Extension: encrypt_then_mac (len=0)
                Type: encrypt_then_mac (22)
            Extension: signature_algorithms (len=48)
                Type: signature_algorithms (13)
                Signature Hash Algorithms (23 algorithms)
                    Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: ECDSA (3)
                        ...

			
Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Handshake Protocol: Server Hello
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
            Compression Method: null (0)
            Extensions Length: 13
            Extension: renegotiation_info (len=1)
                Type: renegotiation_info (65281)
                Length: 1
                Renegotiation Info extension
                    Renegotiation info extension length: 0          
            Extension: ec_point_formats (len=4)
                Type: ec_point_formats (11)
            ...
    

Le client propose de nombreux algorithmes de cryptographie, comme TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, et plusieurs extensions comme le format pour les courbes elliptiques (normalisé dans le RFC 8422), les tickets du RFC 5077, le chiffrement avant le MAC du RFC 7366 et des algorithmes de signature. Le serveur choisit l'algorithme de chiffrement TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, accepte l'extension sur le format des courbes elliptiques, et, puisque le client était d'accord (via l'indication d'un algorithme de chiffrement spécial), le serveur utilise l'extension de renégociation.

Les valeurs inconnues (par exemple une nouvelle extension) doivent être ignorées (RFC 8446, section 4.1.2). Si ce n'était pas le cas, si une valeur inconnue plantait la partie située en face, il ne serait pas possible d'introduire de nouveaux algorithmes ou de nouvelles extensions, en raison des déploiements existants. Prenons les algorithmes de cryptographie, enregistrés à l'IANA. Si un nouvel algorithme apparait, et reçoit une valeur, comment vont réagir, non seulement les pairs avec qui on communique en TLS, mais également tous ces boitiers intermédiaires installés souvent sans raison sérieuse, et pour lesquels il n'existe pas de mécanisme pratique de remontée des problèmes ? Si leurs programmeurs avaient lu la norme, ils devraient ignorer ce nouvel algorithme, mais on constate qu'en pratique, ce n'est souvent pas le cas, ce qui rend difficile l'introduction de nouveaux algorithmes. Dans le pire des cas, le boitier intermédiaire jette les paquets portant les valeurs inconnues, sans aucun message, rendant le déboguage très difficile.

D'où les métaphores mécaniques : dans l'Internet d'aujourd'hui, bien des équipements sur le réseau sont rouillés, et il faut les graisser, en faisant travailler les parties qui ne sont normalement pas testées. C'est le principe de GREASE que d'envoyer des valeurs inconnues pour certains paramètres, dans l'espoir de forcer les mises en œuvre de TLS, surtout celles dans les boitiers intermédiaires, à s'adapter. Une méthode darwinienne, en somme.

La section 2 de notre RFC indique les valeurs choisies pour ces annonces. C'est délibérement qu'elles ne sont pas contiguës, pour limiter le risque que des programmeurs paresseux ne testent simplement si une valeur est incluse dans tel intervalle. Il y a un jeu de valeurs pour les algorithmes de cryptographie et les identificateurs ALPN (RFC 7301), un pour les extensions, un pour les versions de TLS, etc. Toutes sont enregistrées à l'IANA, dans le registre respectif. Par exemple, pour les extensions TLS, (cf. leur liste), les valeurs, 2570, 6682, 10794 et plusieurs autres sont réservées pour le graissage. (Il fallait les réserver pour éviter qu'une future extension TLS ne reçoive le même numéro, ce qui aurait cassé la compatibilité avec les logiciels GREASE.)

Une fois ces valeurs réservées par notre RFC, le client TLS peut, au hasard, ajouter ces valeurs dans, par exemple, la liste des algorithmes de cryptographie qu'il gère, ou la liste des extensions qu'il propose. Si jamais le serveur les accepte (dans son ServerHello), le client doit rejeter la connexion ; le but de ces valeurs était de tester les logiciels, elles ne doivent jamais être sélectionnées. Notez que c'est le comportement normal d'un client TLS d'aujourd'hui de refuser proprement les valeurs inconnues. De même, un serveur normal d'aujourd'hui va ignorer ces valeurs inconnues (et donc ne jamais les sélectionner). Si tout le monde suit la norme, l'introduction des valeurs GREASE ne va rien changer. Les règles de la section 3 ne sont qu'un rappel de règles TLS qui ont toujours existé.

La section 4 de notre RFC traite le cas un peu plus difficile où le serveur propose et le client accepte. C'est par exemple ce qui arrive quand le serveur demande au client de s'authentifier, en envoyant un CertificateRequest. Le serveur peut là aussi utiliser GREASE et indiquer des extensions ou des algorithmes de signature inconnus, et le client doit les ignorer (sinon, si le client sélectionne ces valeurs, le serveur doit rejeter un tel choix).

La section 5 du RFC précise dans quels cas utiliser les valeurs GREASE et lesquelles. Le but étant de révéler les problèmes, le RFC recommande de choisir les valeurs aléatoirement. (Si un programme envoyait toujours la même valeur GREASE, il y aurait un risque que des programmes en face ignorent spécifiquement cette valeur, alors qu'il faut ignorer toutes les valeurs inconnues.) Par contre, pour un même partenaire TLS, il vaut mieux un certain déterminisme, sinon les problèmes seront difficiles à déboguer (parfois, ça marche, parfois, ça ne marche pas…)

Enfin, la section 7 du RFC discute des conséquences de l'absence de graissage sur la sécurité. Si certaines mises en œuvre de TLS résistent mal aux options inconnues, cela peut encourager le repli, c'est-à-dire à réessayer sans les options. Ainsi, un attaquant actif pourrait facilement forcer une machine à ne pas utiliser des options qui rendraient des attaques ultérieures plus compliquées. Les attaques par repli étant particulièrement dangereuses, il est important de ne pas se replier, et donc de s'assurer qu'on peut réellement utiliser toutes les possibilités du protocole. Cela veut dire entre autres que, si une machine TLS utilisant GREASE a du mal à se connecter, elle ne devrait pas essayer sans GREASE : cela annnulerait tous les bénéfices qu'on attend du graissage. Le principe de robustesse est mauvais pour la sécurité.

À noter que Chrome a déjà mis en œuvre ce principe, et que ça semble bien fonctionner. L'article « HTTPS : de SSL à TLS 1.3 », surtout consacré à la version 1.3 de TLS, montre à quoi ressemble les options GREASE pour Wireshark (« Unknown »).

À noter qu'un concept équivalent existe dans le futur HTTP/3, Reserved Stream Types et Reserved Frame Types. Pour HTTP/2 (RFC 7540), où les trames de type inconnu devraient être ignorées, l'expérience a déjà prouvé qu'elles ne l'étaient pas toujours.


Téléchargez le RFC 8701


L'article seul

Google inverse les noms de domaines

Première rédaction de cet article le 16 janvier 2020
Dernière mise à jour le 20 janvier 2020


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 : google-recherche-echos.png

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 : google-recherche-cavendish.png

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 : google-recherche-gouverneur.png

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) : google-recherche-escargot.png

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.


L'article seul

Fiche de lecture : Unix: A history and a Memoir

Auteur(s) du livre : Brian Kernighan
Éditeur : Kindle Direct Publishing
9781695978553
Publié en 2020
Première rédaction de cet article le 14 janvier 2020


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.


L'article seul

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

Première rédaction de cet article le 12 janvier 2020


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


L'article seul

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

Première rédaction de cet article le 10 janvier 2020


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.

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


L'article seul

Historique dans RDAP

Première rédaction de cet article le 9 janvier 2020


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


L'article seul

50 ans

Première rédaction de cet article le 1 janvier 2020


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.


L'article seul

Analyse technique du résolveur DNS public chinois 114dns

Première rédaction de cet article le 29 décembre 2019
Dernière mise à jour le 6 janvier 2020


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 : ripe-stat-prefix-114.png

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.


L'article seul

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

Première rédaction de cet article le 29 décembre 2019


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.


L'article seul

RFC 8700: Fifty Years of RFCs

Date de publication du RFC : Décembre 2019
Auteur(s) du RFC : H. Flanagan (RFC Editor)
Pour information
Première rédaction de cet article le 24 décembre 2019


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 :


Téléchargez le RFC 8700


L'article seul

Fiche de lecture : The box

Auteur(s) du livre : Marc Levinson
Éditeur : Max Milo
9782315002986
Publié en 2011
Première rédaction de cet article le 16 décembre 2019


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 : playmobil-conteneurs-small-2.jpg (Version en taille originale.) playmobil-conteneurs-small-1.jpg (Version en taille originale.)


L'article seul

Vérifier le nom dans un certificat : pas trivial

Première rédaction de cet article le 15 décembre 2019


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.


L'article seul

RFC 8674: The "safe" HTTP Preference

Date de publication du RFC : Décembre 2019
Auteur(s) du RFC : M. Nottingham
Pour information
Première rédaction de cet article le 5 décembre 2019


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.

Téléchargez le RFC 8674


L'article seul

RFC 8689: SMTP Require TLS Option

Date de publication du RFC : Novembre 2019
Auteur(s) du RFC : J. Fenton (Altmode Networks)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF uta
Première rédaction de cet article le 28 novembre 2019


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.


Téléchargez le RFC 8689


L'article seul

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

Première rédaction de cet article le 22 novembre 2019


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.


L'article seul

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

Date de publication du RFC : Novembre 2019
Auteur(s) du RFC : P. Hallam-Baker, R. Stradling (Sectigo), J. Hoffman-Andrews (Let's Encrypt)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF lamps
Première rédaction de cet article le 22 novembre 2019


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.


Téléchargez le RFC 8659


L'article seul

Capitole du Libre 2019

Première rédaction de cet article le 18 novembre 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. dedicace-petits-ruisseaux.jpeg

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 sketchnotes-cdl2019-small.png

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 : capitole-du-libre-2019-fin.jpg

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


L'article seul

Fiche de lecture : Grandir connectés

Auteur(s) du livre : Anne Cordier
Éditeur : C&F Éditions
978-2-915825-49-7
Publié en 2015
Première rédaction de cet article le 5 novembre 2019


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.


L'article seul

RFC 8642: Policy Behavior for Well-Known BGP Communities

Date de publication du RFC : Août 2019
Auteur(s) du RFC : J. Borkenhagen (AT&T), R. Bush (IIJ & Arrcus), R. Bonica (Juniper Networks), S. Bayraktar (Cisco Systems)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF grow
Première rédaction de cet article le 3 novembre 2019


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.


Téléchargez le RFC 8642


L'article seul

Articles des différentes années : 2020  2019  2018  2017  2016  2015  2014  Précédentes années

Syndication : en HTTP non sécurisé, Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu, en HTTPS, Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.