Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

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.


RFC Origins of Domain Names

Première rédaction de cet article le 10 mai 2021


Qu'est-ce qu'un nom de domaine ? La question semble simple puisque les noms de domaine sont aujourd'hui partout, y compris sur les affiches publicitaires. Mais cette question apparemment simple soulève bien d'autres questions, que ce texte d'Edward Lewis étudie. Notamment, il est très difficile de trouver la définition originale de « nom de domaine ».

Par exemple, quelles sont les relations des noms de domaine avec le DNS ? Les noms de domaine ont-ils été inventés par le DNS, ou bien est-ce que le DNS a été créé pour fournir un nouveau protocole pour faire des résolutions de noms de domaine ? La question n'est pas purement philosophique, elle s'est posée ces dernières années à l'IETF lorsqu'il a fallu travailler sur des protocoles de résolution de noms autres que le DNS, et utiliser les noms de domaine dans de nouveaux contextes. Cela a été le cas, par exemple, du .onion du RFC 7686. Un nom comme 7j3ncmar4jm2r3e7.onion (qui pointe vers le blog que vous êtes en train de consulter, si vous utilisez Tor) est-il un nom de domaine, bien qu'il n'utilise pas du tout le DNS ? Le débat est d'autant plus confus que, en raison de l'immense succès du DNS, même ses opposants et ceux qui prétendent offrir une solution alternative appellent souvent n'importe quel protocole de résolution de noms « DNS ».

D'autres RFC ont eu une genèse difficile car ils nécessitaient des définitions claires de certains termes et concepts, définitions qu'on ne trouvait pas dans les textes fondateurs. C'est ainsi que les RFC 4592 et RFC 5936 ont suscité beaucoup de débats terminologiques.

En outre, le problème n'est pas purement technique ; les noms de domaine sont des enjeux financiers et politiques importants, et les débats sont rudes au sujet de leur gouvernance (notez au passage que l'auteur du texte travaille à l'ICANN, mais son embauche est récente, et son document n'est pas du tout langue de bois). Ainsi, l'ICANN décide des politiques d'enregistrement dans les gTLD et, dans une certaine mesure, à la racine des noms de domaine, mais l'IETF a aussi son mécanisme d'enregistrement, spécifié dans le RFC 6761. La délimitation de leurs pouvoirs et rôles respectifs est formalisée dans le RFC 2860 et, comme tous les textes sacrés, chacun l'interprète d'une manière différente. Notamment, le terme « assignments of domain names for technical uses » (qui sont pour l'IETF) a suscité des trésors d'exégèse : qu'est-ce qu'une « utilisation technique » ?

Pour traiter cette difficile question, la démarche de ce texte est historique : plongeons-nous dans le passé, relisons les vieux RFC et voyons ce qu'ils nous racontent. Je vous révèle la vérité tout de suite : les RFC parlaient de noms de domaine avant que le DNS ne soit inventé. Mais, en même temps, le concept de nom de domaine a évolué. Le texte ne propose pas de solution, ou de « définition définitive », il décrit plutôt qu'il ne spécifie. À l'origine, il avait été écrit comme Internet-Draft, pour être publié sous forme de RFC mais ce projet n'a pas abouti.

Aujourd'hui, la norme de base du DNS est constituée des RFC 1034 et RFC 1035. Ces documents anciens, jamais mis à jour, sont complétés par un grand nombre de RFC plus récents, formant un cauchemar pour le programmeur qui veut écrire un serveur ou un client DNS. Et aucun des deux RFC de référence ne définit ce qu'est un nom de domaine… Ils citent des textes précédents (IEN-116, RFC 799, RFC 819, et RFC 830), sans donner de définition précise, même si les concepts essentiels (la nature hiérarchique des noms, le point comme séparateur des composants dans la représentation textuelle) sont mentionnés. Mais il est clair que le concept de nom de domaine existait avant le DNS : il était utilisé par SMTP. Le RFC 788 y fait déjà allusion, des années avant la création du DNS, même si c'est seulement avec le RFC 821 que SMTP utilisera officiellement ces noms, « Domains are a recently [en 1982] introduced concept in the ARPA Internet mail system ». Et avant le DNS, il y avait déjà des protocoles de nommage utilisant ces noms de domaines, par exemple dans les RFC 819 ou surtout le RFC 830. Donc, la question est tranchée : ce n'est pas le DNS qui définit les noms de domaine. Cela a pour conséquence, entre autre, qu'il est absurde de parler d'un « DNS sur la blockchain » ou d'un « DNS pair-à-pair », sous prétexte que tel ou tel protocole de nommage utilise des noms de domaine.

Bon, mais si ce n'est pas le DNS qui a créé le concept de nom de domaine, c'est qui ? Le courrier électronique, comme semble l'indiquer les RFC sur SMTP ? Comme indiqué ci-dessus, la première occurrence du terme apparait dans le RFC 788, en novembre 1981, mais sans définition (le concept était encore en discussion). La première définition apparait dans le RFC 799 mais c'est encore très confus, le nom de domaine n'est pas encore hiérarchique. (Traditionnellement, « domaine » est utilisé pour désigner une entité administrative unique, avec ses règles propres, et ce sens est encore utilisé dans des documents comme le RFC 5598. Les gens du routage utilisent le terme « système autonome » là où ceux du courrier se serviront plutôt de « domaine ». Les noms de domaine d'aujourd'hui viennent de là. Un exemple est donné par IEN 19.) Puis le RFC 805, en février 1982, saute le pas et introduit pour la première fois explicitement la notion de nom de domaine hiérarchique (le premier RFC sur le DNS ne sera publié qu'un an plus tard, et le DNS ne sera pas adopté instantanément, loin de là). Le RFC 819 précisera le concept, et créera en même temps celui de TLD, avec le premier domaine de tête, .arpa.

Le texte de Lewis note bien que cette histoire n'est que celle transcrite dans les RFC. La réalité n'est pas exactement ce qui a été écrit, les choses sont sans doute plus compliquées. Mais les points importants ne font pas de doute : les noms de domaine existaient avant le DNS, et ils ont été créés surtout pour une application spécifique, SMTP, pas pour servir de système d'identificateurs généralisé. Par exemple, le RFC sur FTP, RFC 959, bien que publié deux ans après les premiers RFC sur le DNS, ne mentionne pas une seule fois les noms de domaine.

Et le concept de résolution, central dans le DNS, d'où vient-il ? La première mention semble être dans le RFC 724, quasiment dans le sens actuel, celui de trouver une information (par exemple une adresse) à partir d'un nom. Selon les auteurs des premiers RFC, interrogés par Ed Lewis, le terme venait de la programmation (par exemple la résolution des noms en adresses lors de l'édition de liens).

Bien, maintenant qu'on a renoncé à trouver la source unique et originale du concept de nom de domaine, voyons les variantes. Car il existe plusieurs types de noms de domaine. Déjà, il y a ceux utilisés dans le DNS. Ce sont un sous-ensemble de tous les noms de domaine, avec des restrictions spécifiques, et des règles de correspondance particulières :

  • La taille maximale d'un nom est de 255 octets (j'ai bien dit octets et pas caractères), celle d'un composant de 63 caractères.
  • La correspondance est faite de manière insensible à la casse.

En revanche, la limitation aux caractères ASCII et l'interdiction des symboles comme + ou & est une légende : le DNS autorise tous les octets, comme le rappelle bien le RFC 2181 (section 11). Ces restrictions existent par contre dans d'autres variantes des noms de domaine. Notez bien que j'ai écrit que le protocole DNS autorise tous les octets. Les registres de noms de domaine, eux, peuvent imposer des restrictions supplémentaires, notamment parce que les gens qui réservent des noms de domaine le font souvent pour créer des noms de machine, présentés plus loin.

Le DNS introduit deux autres concepts importants : une séparation entre la représentation des noms aux humains, et leur encodage dans les paquets effectivement échangés. Sur le câble, les noms de domaine ne comportent pas de point, par exemple (RFC 1035, section 3.1). Et le second concept est la notion d'autorité, lié à une zone (un sous-arbre géré par les mêmes serveurs faisant autorité).

Autre sous-ensemble, les noms de machines (host names). Ce n'est pas la même chose qu'un nom de domaine. Ils sont soumis à une syntaxe plus restrictive, décrite dans le RFC 952, légèrement assouplie ensuite par le RFC 1123. Là, les caractères comme le * ou le _ sont vraiment interdits. Cette règle est souvent nommée LDH, pour Letters Digits Hyphen, puisque seuls les lettres (ASCII), les chiffres (arabes) et le tiret sont admis.

À propos des lettres ASCII, il faut aussi parler des noms en Unicode, puisque la planète n'est pas peuplée que de gens qui écrivent en ASCII. Ces noms internationalisés, les IDN, sont normalisés dans le RFC 5890. Pourquoi un RFC supplémentaires puisque le DNS admet tous les octets, même non-ASCII, dans un nom ? Parce que le DNS ne permet pas d'indiquer l'encodage, et qu'en prime ses règles d'insensibilité à la casse ne sont pas celles, bien plus complexes, d'Unicode. Enfin, certaines vieilles applications ou bibliothèques auraient pu mal réagir à la présence des caractères non-ASCII. D'où la séparation des noms en deux : les U-label, le nom normal, en Unicode, et le A-label, une représentation en pur ASCII, normalisée dans le RFC 3492, qui permettait de minimiser les risques de mauvaises surprises. Ainsi, lorsque potamochère.fr est le U-label,x xn--potamochre-66a.fr sera le A-label.

Le système IDN est donc une chose de plus dans l'univers déjà riche des noms de domaine. Pour approfondir, vous pouvez aussi lire le RFC 6055, qui traite du cas des noms en Unicode en dehors du DNS, et le RFC 4290, qui parle de règles que peuvent suivre les registres de noms de domaines.

Et, justement, un protocole proche du DNS, le Multicast DNS du RFC 6762, utilise des noms qui ne sont pas passés en punycode (la forme xn--…) mais utilisent un encodage plus traditionnel d'Unicode, UTF-8, tel que décrit dans le RFC 5198. (L'annexe F du RFC 6762 explique ce choix.)

Notez que le texte considère que les adresses IP sont une forme de nom de domaine, puisqu'on peut les utiliser, par exemple, dans les URL. (En théorie, on peut aussi dans les adresses de courrier électronique mais, en pratique, cela ne marche pas.)

Mettons maintenant notre hoodie et nos gants, pour ressembler au hacker dans les reportages de BFM TV, et descendons dans les profondeurs du darknet. Non, je plaisante, on va simplement regarder les noms des services Tor, en .onion. Ce blog, par exemple, est accessible avec Tor en 7j3ncmar4jm2r3e7.onion. S'agit-il d'un nom de domaine ? Oui, certainement. Sa syntaxe est définie dans la documentation Tor, et est celle d'un nom de domaine. (Notez que le TLD .onion a été réservé par le RFC 7686.) Mais ce n'est pas du tout un nom DNS : ces noms ne sont jamais résolus par le DNS, mais par un protocole spécifique à Tor (cf. le protocole de rendez-vous), utilisant le fait que le nom est une clé cryptographique.

Et le fichier /etc/hosts ? Historiquement, il servait à stocker des noms de machine et leurs adresses IP. Il fonctionne encore aujourd'hui, et sur de nombreux systèmes d'exploitation. La syntaxe des noms qu'il contient n'est pas définie très rigoureusement. La section 6 du RFC 3493 parle de ce cas.

Bref, si on veut assurer l'interopérabilité, ce n'est pas facile. Il n'y a pas une définition unique des noms de domaine, mais plusieurs sous-ensembles plus ou moins bien définis. La tâche des interfaces utilisateur qui permettent d'indiquer des noms de domaine n'est pas facile ! Cela rend compliquée l'addition de nouveautés. Ainsi, les IDN n'avaient pas été normalisés sans mal. Le texte de Lewis cite un dernier exemple de cette difficulté à déterminer ce qui est acceptable : un nom d'un seul composant (comme dk) est-il valable ? C'est clairement un nom de domaine légal pour le DNS. Il peut avoir des adresses IP associées, comme dans l'exemple. Mais il ne marchera pas pour certaines applications, comme le courrier électronique.

Sinon, quelques autres articles sur le DNS sur ce blog :


L'article seul

Un rapport de la RAND sur l'utilisation des cryptomonnaies par les terroristes

Première rédaction de cet article le 8 mai 2021


« Les cryptomonnaies, comme le Bitcoin, financent le terrorisme » est un cliché classique lors des discussions sur ces cryptomonnaies. Dans quel mesure est-ce vrai ? L'argent, c'est le nerf de la guerre et, sans argent, une organisation ne va pas bien loin. Comment font les terroristes ? Sans avoir besoin de risquer votre vie en allant enquêter sur le financement de Daech, ce rapport de la RAND « Terrorist Use of Cryptocurrencies » est une analyse intéressante.

(Pour celles et ceux qui ne connaissent pas, la RAND n'est pas Framasoft ou la Quadrature du Net. Politiquement, c'est d'un tout autre bord, et il faut lire leurs analyses en se rappelant que leur but est défendre l'impérialisme étatsunien. Mais cela n'empêche pas que ces études contiennent souvent des informations utiles.)

Évidemment, connaitre le fonctionnement financier d'une organisation clandestine est difficile. Il n'y a pas d'informations publiques fiables, et on rencontre par contre beaucoup de discours sensationnalistes, fondés sur l'ignorance ou bien la mauvaise foi. Annoncer que les terroristes utilisent les cryptomonnaies précède en général des discours appelant à interdire ou en tout cas à restreindre sérieusement l'utilisation de ces cryptomonnaies. Comme on manque de faits précis (mais la bibliographie contient beaucoup d'éléments), ce rapport repose plutôt sur l'analyse : quels sont les propriétés utiles d'un mécanisme financier pour un groupe terroriste, et en quoi les cryptomonnaires ont, ou pas, ces propriétés ? Le rapport est détaillé, largement sourcé, et manifestement écrit par des gens qui connaissent bien le monde des cryptomonnaies, contrairement à la grande majorité des déclarations ou articles sur le Bitcoin. Une lecture que je vous recommande, donc.

Je vous divulgue tout de suite les conclusions : il n'y a pas d'utilisation significative des cryptomonnaies par les organisations terroristes, mais ça pourrait changer dans le futur. Voyons ces deux points.

(Point de terminologie au passage : je sais bien que « terrorisme » est un terme très polysémique, et d'un usage délicat. J'ai choisi la solution de facilité en reprenant ce terme tel que l'utilise le rapport. Notez que la RAND se focalise sur le terrorisme au Moyen-Orient, notamment Daech, même si les narcos latino-américains sont brièvement mentionnés.)

Une organisation terroriste a plusieurs activités financières ; par exemple, la levée de fonds auprès de donateurs, le financement d'attaques, le financement de l'infrastructure, les trafics illégaux pour remplir les caisses, etc. Certaines de ces activités sont proches de celles d'autres entreprises ou associations, d'autres sont plus spécifiques au terrorisme. Une organisation terroriste importante doit s'attendre à avoir des adversaires redoutables et doit donc bien réfléchir aux outils et aux méthodes employées, pour diminuer les risques. Sécuriser son portefeuille Bitcoin ne pose pas les mêmes problèmes quand on est un particulier visé uniquement par des attaques opportunistes et quand on est un groupe terroriste en guerre ouverte contre un État puissant. Les auteurs du rapport listent ensuite une série de propriétés des cryptomonnaies, essayant de voir si elles sont importantes ou pas pour les activités financières citées plus haut. Ainsi, l'utilisabilité d'une cryptomonnaie (disponibilité de logiciels sûrs et simples d'utilisation) est importante pour les dons des sympathisants, beaucoup de donateurs renonceront s'ils n'arrivent pas à envoyer de l'argent, mais elle est nettement moins cruciale pour les trafics illégaux, où seuls quelques professionnels entrainés manipuleront les fonds.

Le rapport analyse ensuite les cryptomonnaies par rapport à ces propriétés. Ainsi, Bitcoin est jugé pas facile à utiliser, pas très répandu dans les pays où opèrent les groupes terroristes considérés, et pas très anonyme. D'autres cryptomonnaies comme Monero ou Zcash sont bien meilleures question anonymat mais encore pires que le Bitcoin question facilité d'utilisation et diffusion. La tonalité générale du rapport est plutôt pessimiste sur les cryptomonnaies, considérant qu'une organisation terroriste rationnelle et compétente n'a guère de raisons de les utiliser. Des membres de Daech ont pu faire des essais, mais on est loin d'une utilisation significative.

Le rapport ne s'arrête pas à cette situation actuelle, et essaie d'analyser ce qui peut arriver dans le futur. C'est évidemment une partie plus faible du rapport, car prédire l'avenir est délicat. Les auteurs notent à plusieurs reprises que des changements dans les cryptomonnaies (apparition d'une nouvelle cryptomonnaie vraiment anonyme, simple à utiliser, répandue, etc) pourrait changer sérieusement la donne. Même chose si la répression sur les flux financiers ne laissait pas d'autres choix aux terroristes. Mais c'est purement théorique, on n'a pas d'indication en ce sens. Le rapport conclut qu'on ne sait pas trop mais qu'il faut rester vigilant.

Merci à Éric Freyssinet pour avoir attiré mon attention sur cet intéressant rapport, suite à un petit déjeuner du FIC.


L'article seul

La vulnérabilité DNS tsuNAME

Première rédaction de cet article le 6 mai 2021


L'Internet est plein de failles de sécurité donc, aujourd'hui, pas de surprise qu'une nouvelle faille soit publiée : tsuNAME est une faille DNS permettant des attaques par déni de service en exploitant un cycle dans les dépendances des noms de domaine.

Le principe est simple : l'attaquant doit contrôler deux noms de domaine, avec un parent qui est la victime visée. Mettons que le méchant veuille attaquer le TLD .example, il a deux noms, foo.example et bar.example, il crée un cycle en faisant en sorte que les serveurs de noms de foo.example soient tous dans bar.example et réciproquement. En syntaxe de fichier de zone :

foo IN NS ns.bar.example.
bar IN NS ns.foo.example.
  

(C'est une présentation simplifiée : un attaquant peut faire des cycles plus complexes.) Aucun nom en foo.example ou bar.example ne peut être résolu avec succès, en raison de ce cycle. Mais le but de l'attaquant n'est pas là : lorsqu'un résolveur veut résoudre www.foo.example, le serveur faisant autorité pour .example le renvoie à ns.bar.example. Pour résoudre ce nom, il interroge à nouveau le pauvre serveur faisant autorité pour .example, qui le renvoie à ns.foo.example et ainsi de suite. (Si vous aimez les vidéos, je vous renvoie à celle de l'Afnic sur le fonctionnement du DNS.) Et, pire, certains résolveurs ne se souviennent pas que la résolution a échoué et recommencent donc la fois suivante. Un attaquant qui a configuré le cycle (ou bien repéré un cycle existant) peut donc utiliser les résolveurs auxquels il a accès (directement, ou bien via un botnet qu'il contrôle) pour faire l'attaque à sa place.

Normalement, les résolveurs limitent le nombre de requêtes déclenchées par une requête originale. Ils le font surtout pour se protéger eux-mêmes, par exemple contre les attaques en récursion infinie. Mais la nouveauté de tsuNAME est de se servir d'un éventuel manque de limites pour attaquer les serveurs faisant autorité. En pratique, peu de résolveurs sont assez imprudents pour être vraiment intéressants pour l'attaquant. La principale exception était Google Public DNS, qui a ainsi involontairement participé à une attaque contre le .nz. (Il a été corrigé depuis.)

Une leçon pour les programmeurs de résolveurs DNS : ne vous laissez pas entrainer dans des cycles, pensez à jeter l'éponge rapidement, et à mémoriser cet échec pour la prochaine fois.


L'article seul

Fiche de lecture : L'homme préhistorique est aussi une femme

Auteur(s) du livre : Marylène Patou-Mathis
Éditeur : Allary
978-2370-733412
Publié en 2020
Première rédaction de cet article le 2 mai 2021


La représentation traditionnelle des humains de la préhistoire montre les hommes en train de chasser et les femmes en train de coudre, faire la cuisine ou s'occuper des enfants. Est-ce que cette représentation repose sur des données scientifiques sérieuses sur la répartition des tâches à la préhistoire ? Pas forcément, dit l'auteure.

Dans ce livre, Marylène Patou-Mathis examine ce que l'on sait de la répartition genrée des activités chez nos ancêtres. Je vous le dis tout de suite : il y a beaucoup de choses qu'on ne sait pas. On n'a pas de photos prises sur le vif des humains préhistoriques. On n'a que leurs squelettes, leurs outils et les produits de leur activité, par exemple les peintures pariétales ou les statuettes, produits qui ne sont pas faciles à interpréter. La représentation traditionnelle des rôles des deux genres reflétait davantage ce qui se faisait dans la société où vivait les auteurs de ces représentations que ce qui se faisait à la préhistoire. Souvent, on plaquait donc notre conception de la division du travail entre genres sur nos ancêtres. Ou bien on supposait qu'ils étaient forcément comme les peuples « primitifs », ou plutôt comme on voyait les peuples « primitifs » contemporains.

Bon, mais maintenant qu'on a progressé, est-ce que la science peut répondre à des questions comme « Les femmes chassaient-elles ? Autant que les hommes ? » Là, c'est plus délicat. L'auteure note que, pour la majorité des squelettes retrouvés, on n'est pas sûr de leur sexe. Et ce n'est pas mieux pour les dessins qu'on retrouve. Souvent, on suppose, justement en fonction de ce qu'on estime être la société du passé. Une tombe contient des armes ? On suppose que le défunt était un homme. (L'excellent chapitre 2 est une véritable « histoire de la misogynie chez les penseurs » et montre bien que les hommes, même scientifiques, étaient largement aveuglés par leurs préjugés sexistes.) Et, par un raisonnement circulaire, on en déduit que les hommes chassaient et faisaient la guerre. Lorsqu'on examine de plus près (comme dans le cas de la fameuse guerrière de Birka p. 169), on a parfois des surprises. Une fois qu'on a déterminé le sexe de la personne dont on retrouve le squelette, on peut étudier des choses comme les déformations liées à une activité physique répétée (le lancer de javelot semblait pratiqué par les hommes et par les femmes chez les Néandertal). Mais il est difficile, avec ce qu'on retrouve de nos ancêtres, de décrire avec précision comment les deux genres se répartissaient les tâches. L'ADN peut aider (cas de Birka), ou certaines caractéristiques du corps (la forme différente des mains entre les deux sexes montre que certaines images de mains sur les parois des grottes étaient faites par des femmes, p. 144) mais il n'y aura pas de certitude, d'autant plus que rien n'indique que toutes les sociétés préhistoriques étaient identiques.


L'article seul

RFC 9019: A Firmware Update Architecture for Internet of Things

Date de publication du RFC : Avril 2021
Auteur(s) du RFC : B. Moran, H. Tschofenig (Arm Limited), D. Brown (Linaro), M. Meriac (Consultant)
Pour information
Réalisé dans le cadre du groupe de travail IETF suit
Première rédaction de cet article le 1 mai 2021


On le sait, le « S » dans « IoT » veut dire « sécurité ». Cette plaisanterie traditionnelle rappelle une vérité importante sur les brosses à dents connectées, les télés connectées, les voitures connectées et les sextoys connectés : leur sécurité est catastrophique. Les vendeurs de ces objets ont vingt ou trente ans de retard en matière de sécurité et c'est tous les jours qu'un nouveau piratage spectaculaire d'un objet connecté est annoncé. Une partie des vulnérabilités pourrait être bouchée en mettant à jour plus fréquemment les objets connectés. Mais cela ne va pas sans mal. Ce RFC fait partie d'un projet qui vise à construire certaines briques qui seront utiles pour permettre cette mise à jour fréquente. Il définit l'architecture générale.

Une bonne analyse du problème est décrite dans le RFC 8240, qui faisait le compte-rendu d'un atelier de réflexion sur la question. L'atelier avait bien montré l'ampleur et la complexité du problème ! Notre nouveau RFC est issu du groupe de travail SUIT de l'IETF, créé suite à cet atelier. La mise à jour du logiciel des objets connectés compte beaucoup d'aspects, et l'IETF se focalise sur un format de manifeste (en CBOR) qui permettra de décrire les mises à jour. (Le format effectif sera dans un futur RFC.)

Le problème est compliqué : idéalement, on voudrait que les mises à jour logicielles de ces objets connectés se passent automatiquement, et sans casse. Ces objets sont nombreux, et beaucoup d'objets connectés sont installés dans des endroits peu accessibles ou, en tout cas, ne sont pas forcément bien suivis. Et ils n'ont souvent pas d'interface utilisateur du tout. Une solution réaliste doit donc être automatique (on sait que les injonctions aux humains « mettez à jour vos brosses à dents connectées » ne seront pas suivies). D'un autre côté, cette exigence d'automaticité va mal avec celle de consentement de l'utilisateur, d'autant plus que des mises à jour peuvent éliminer certaines fonctions de l'objet, ou en ajouter des peu souhaitables (cf. RFC 8240). En moins grave, elles peuvent aussi annuler des réglages ou modifications faits par les utilisateurs.

Le format de manifeste sur lequel travaille le groupe SUIT vise à authentifier l'image (le code), par exemple en la signant. Un autre point du cahier des charges, mais qui n'est qu'optionnel [et que je trouve peu réaliste dans la plupart des environnements] est d'assurer la confidentialité de l'image, afin d'empêcher la rétro-ingénierie du code. Ce format de manifeste vise avant tout les objets de classe 1 (selon la terminologie du RFC 7228). Il est prévu pour du logiciel mais peut être utilisé pour décrire d'autres ressources, comme des clés cryptographiques.

On l'a dit, le travail du groupe SUIT se concentre sur le format du manifeste. Mais une solution complète de mise à jour nécessite évidemment bien plus que cela, le protocole de transfert de fichiers pour récupérer l'image, un protocole pour découvrir qu'il existe des mises à jour (cf. le status tracker en section 2.3), un pour trouver le serveur pertinent (par exemple avec DNS-SD, RFC 6763). Le protocole LwM2M (Lightweight M2M) peut par exemple être utilisé.

Et puis ce n'est pas tout de trouver la mise à jour, la récupérer, la vérifier cryptographiquement. Une solution complète doit aussi fournir :

  • La garantie que la mise à jour ne va pas tout casser (si beaucoup d'utilisateurs débrayent les mises à jour automatiques, ce n'est pas par pure paranoïa), ce qui implique des mises à jour bien testées, et une stratégie de repli si la mise à jour échoue,
  • des mises à jour rapides, puisque les failles de sécurité sont exploitées dès le premier jour, alors que les mises à jour nécessitent souvent un long processus d'approbation, parfois pour de bonnes raisons (les tests dont je parlais au paragraphe précédent), parfois pour des mauvaises (processus bureaucratiques), et qu'elles doivent souvent passer en cascade par plusieurs acteurs (bibliothèque intégrée dans un système d'exploitation intégré dans un composant matériel intégré dans un objet, tous les quatre par des acteurs différents),
  • des mises à jour économes en énergie, l'objet pouvant être contraint dans ce domaine,
  • des mises à jour qui fonctionnent même après que les actionnaires de l'entreprise aient décidé de mettre leur argent ailleurs et aient abandonné les objets vendus (on peut toujours rêver).

Bon, maintenant, après cette liste au Père Noël, au travail. Un peu de vocabulaire pour commencer :

  • Image (ou firmware) : le code qui sera téléchargé sur l'objet et installé (je n'ai jamais compris pourquoi ça s'appelait « ROM » dans le monde Android). L'image peut être juste le système d'exploitation (ou une partie de celui-ci) ou bien un système de fichiers complet.
  • Manifeste : les métadonnées sur l'image, par exemple date, numéro de version, signature, etc.
  • Point de départ de la validation (trust anchor, RFC 5914 et RFC 6024) : la clé publique à partir de laquelle se feront les validations cryptographiques.
  • REE (Rich Execution Environment) : un environnement logiciel général, pas forcément très sécurisé. Par exemple, Alpine Linux est un REE.
  • TEE (Trusted Execution Environment) : un environnement logiciel sécurisé, typiquement plus petit que le REE et doté de moins de fonctions.

Le monde de ces objets connectés se traduit par une grande dispersion des parties prenantes. On y trouve par exemple :

  • Les auteurs de logiciel, qui sont souvent très loin du déploiement et de la maintenance des objets,
  • les fabricants de l'objet,
  • les opérateurs des objets qui ne sont pas les propriétaires de l'objet : la plupart du temps, pour piloter votre objet, celui que vous avez acheté, vous devez passer par cet opérateur, en général le fabricant, s'il n'a pas fait faillite ou abandonné ces objets,
  • les gestionnaires des clés (souvent le fabricant),
  • et le pauvre utilisateur tout en bas.

[Résultat, on a des chaînes d'approvisionnement longues, compliquées, opaques et vulnérables. Une grande partie des problèmes de sécurité des objets connectés vient de là, et pas de la technique. Par exemple, il est fréquent que les auteurs des logiciels utilisés se moquent de la sécurité et ne fournissent pas de mise à jour pour combler les failles dans les programmes.]

La section 3 du RFC présente l'architecture générale de la solution. Elle doit évidemment reposer sur IP (ce RFC étant écrit par l'IETF, un choix contraire aurait été étonnant), et, comme les images sont souvent de taille significative (des dizaines, des centaines de kilo-octets, au minimum), il faut utiliser en prime un protocole qui assurera la fiabilité du transfert et qui ne déclenchera pas de congestion, par exemple TCP, soit directement, soit par l'intermédiaire d'un protocole applicatif comme MQTT ou CoAP. En dessous d'IP, on pourra utiliser tout ce qu'on veut, USB, BLE, etc. Outre IP et TCP (pas évident pour un objet contraint, cf. RFC 9006), l'objet devra avoir le moyen de consulter le status tracker pour savoir s'il y a du nouveau, la capacité de stocker la nouvelle image avant de l'installer (si la mise à jour échoue, il faut pouvoir revenir en arrière, donc stocker l'ancienne image et la nouvelle), la capacité de déballer, voire de déchiffrer l'image et bien sûr, puisque c'est le cœur du projet SUIT, la capacité de lire et de comprendre le manifeste. Comme le manifeste comprend de la cryptographie (typiquement une signature), il faudra que l'objet ait du logiciel pour des opérations cryptographiques typiques, et un magasin de clés cryptographiques. Notez que la sécurité étant assurée via le manifeste, et non pas via le mécanisme de transport (sécurité des données et pas du canal), le moyen de récupération de l'image utilisé n'a pas de conséquences pour la sécurité. Ce sera notamment pratique pour le multicast.

Le manifeste peut être inclus dans l'image ou bien séparé. Dans le second cas, l'objet peut décider de charger l'image ou pas, en fonction du manifeste.

La mise à jour du code d'un objet contraint pose des défis particuliers. Ainsi, ces objets ne peuvent souvent pas utiliser de code indépendant de sa position. La nouvelle image ne peut donc pas être mise n'importe où. Cela veut dire que, lorsque le code est exécuté directement à partir du moyen de stockage (et donc pas chargé en mémoire), il faut échanger l'ancienne et la nouvelle image, ce qui complique un éventuel retour en arrière, en cas de problème.

Avec tout ça, je n'ai pas encore tellement parlé du manifeste lui-même. C'est parce que notre RFC ne décrit que l'architecture, donc les généralités. Le format du manifeste sera dans deux futurs RFC, un pour décrire le format exact (fondé sur CBOR, cf. RFC 8949) et un autre pour le modèle d'information (en gros, la liste des éléments qui peuvent être mis dans le manifeste).

La section 7 de notre RFC fait la synthèse des questions de sécurité liées à la mise à jour. Si une mise à jour fréquente du logiciel est cruciale pour la sécurité, en permettant de fermer rapidement des failles découvertes dans le logiciel de l'objet, la mise à jour peut elle-même présenter des risques. Après tout, mettre à jour son logiciel, c'est exécuter du code récupéré via l'Internet… L'architecture présentée dans ce RFC fournit une sécurité de bout en bout, par exemple en permettant de vérifier l'authenticité de l'image récupérée (et, bien sûr, son intégrité). Pas question d'exécuter un code non authentifié, ce qui est pourtant couramment le cas aujourd'hui avec les mises à jour de beaucoup d'équipements informatiques.

Cette même section en profite pour noter que la cryptographie nécessite de pouvoir changer les algorithmes utilisés. Le RFC cite même l'importance de la cryptographie post-quantique. (C'est un des tous premiers RFC publiés à en parler, après le RFC 8773.) D'un côté, ce genre de préoccupations est assez décalée : la réalité de l'insécurité des objets connectés est tellement abyssale qu'on aura bien des problèmes avant que les calculateurs quantiques ne deviennent une menace réelle. De l'autre, certains objets connectés peuvent rester en service pendant longtemps. Qui sait quelles seront les menaces dans dix ans ? (Un article comme « Quantum Annealing for Prime Factorization » estimait que, dans le pire des cas, les algorithmes pré-quantiques commenceraient à être cassés vers 2030, mais il est très difficile d'estimer la fiabilité de ces prédictions, cf. mon exposé à Pas Sage En Seine.)

J'insiste, mais je vous recommande de lire le RFC 8240 pour bien comprendre tous les aspects du problème. D'autre part, vous serez peut-être intéressés par l'évaluation faite du projet SUIT sous l'angle des droits humains. Cette évaluation suggérait (ce qui n'a pas été retenu) que le chiffrement des images soit obligatoire.


Téléchargez le RFC 9019


L'article seul

La curieuse annonce des adresses IPv4 de l'armée états-unienne

Première rédaction de cet article le 26 avril 2021


Le 20 janvier 2021, l'armée des États-Unis a soudainement annoncé sur l'Internet des millions d'adresses IP qui n'avaient jamais été actives sur l'Internet. Les causes exactes ne sont pas connues (il y a des explications officielles mais qui ne répondent pas à toutes les questions). Comment a-t-on vu cela et quelles conclusions (forcément assez spéculatives) peut-on en tirer ?

Au début, cela ressemblait à un détournement BGP classique, provoqué soit par une erreur humaine (cas de l'accident malaisien), soit par une volonté délibérée de détourner du trafic (cas de l'attaque contre MyEtherWallet). Le protocole BGP permet à un routeur Internet d'annoncer les préfixes d'adresses IP qu'il sait joindre. S'il se trompe ou qu'il ment, ses pairs vont parfois accepter l'annonce et l'utiliser, envoyant alors le trafic vers les détourneurs. Le 20 janvier 2021, ce fut la première réaction, « quelqu'un annonce les adresses IP de l'armée ». Comment le voit-on ? Rappelez-vous que l'Internet est très transparent. Tout routeur de la DFZ va voir les annonces et, même si vous n'avez pas accès à un tel routeur, plusieurs services vous fournissent les données. Servons-nous du classique RouteViews. Vous pouvez récupérer toutes les annonces du 20 janvier 2021 et les analyser (ici, on convertit les données qui étaient au format MRT du RFC 6396, avec l'outil bgpdump) :

% wget http://archive.routeviews.org/bgpdata/2021.01/UPDATES/updates.20210120.1645.bz2
% bunzip2 updates.20210120.1645.bz2
% bgpdump updates.20210120.1645 > updates.20210120.1645.txt
  

On a alors un fichier texte avec les annonces BGP, qu'on peut regarder avec l'éditeur ou l'afficheur de son choix. Voici la première annonce bizarre (l'heure est évidemment UTC) :

TIME: 01/20/21 16:57:35.081428
TYPE: BGP4MP_ET/MESSAGE/Update
FROM: 64.71.137.241 AS6939
TO: 128.223.51.102 AS6447
ORIGIN: IGP
ASPATH: 6939 8003
NEXT_HOP: 64.71.137.241
ANNOUNCE
   11.0.0.0/8
  

(La dernière annonce pour ce même préfixe, relayée par plusieurs routeurs avant d'atteindre RouteViews, a été vue à 17:04:19.316776, ce qui donne une idée de la rapidité de la propagation des routes dans l'Internet.)

En quoi est-ce que cette annonce était bizarre ? D'abord, le préfixe 11.0.0.0/8, un préfixe comportant beaucoup d'adresses (surtout depuis l'épuisement des adresses IPv4) n'avait jamais été annoncé publiquement sur l'Internet avant (comme on peut le voir sur RIPEstat) ou, plus exactement, jamais été annoncé en dehors de quelques détournements ponctuels. Mais qui, en 2021, a encore un préfixe /8 non annoncé ? whois nous montre que c'est le DoD :

% whois 11.0.0.0  
...
NetRange:       11.0.0.0 - 11.255.255.255
CIDR:           11.0.0.0/8
NetName:        DODIIS
NetType:        Direct Allocation
OriginAS:       
Organization:   DoD Network Information Center (DNIC)
RegDate:        1984-01-19
Updated:        2007-08-22
...
OrgName:        DoD Network Information Center
  

(Pour la petite histoire, ce préfixe a été alloué au DoD en 1985, dans le RFC 943 ; oui, à l'époque, les RFC servaient de registres d'adresses IP.)

Tout de suite, on pense à un détournement des adresses IP de l'armée états-unienne par des Chinois/Russes/Cubains/Iraniens. D'autant plus que la date est curieuse : 16:57:35.081428 UTC, c'est moins de trois minutes avant la fin officielle du mandat de Trump, fin de mandat qui avait été marquée par plusieurs troubles graves. Et puis l'AS qui a fait les annonces, l'AS 8003, n'était pas tellement connu avant, appartenant à une entreprise très discrète et sur laquelle les investigations n'ont pas révélé grand-chose, à part son association passée à des activités bizarres. (whois AS8003 pour avoir les informations sur cet AS.)

Dans les jours et les semaines suivants, d'autres préfixes autrefois inutilisés ont été annoncés, par exemple le 7.0.0.0/8.

Finalement, le Pentagone (via son service DDS) a révélé que l'annonce était normale : il ne s'agit pas d'un détournement mais d'une opération légitime. Mais quels sont ses buts ? Pourquoi l'armée qui n'annonçait pas ses adresses IP depuis si longtemps (ce qui ne veut pas dire qu'elles n'étaient pas utilisées en interne) a-t-elle tout à coup changé sa politique ? Inutile de préciser qu'on ne saura de toute façon pas tout. Mais on peut toujours spéculer :

  • Un tel volume d'adresses IP représente beaucoup d'argent en période de pénurie (le marché est entre 20 et 30 dollars par adresse),
  • ou bien l'armée est en train de monter un pot de miel géant, pour attraper plein de trafic malveillant,
  • certains administrateurs réseau ont été assez incompétents et imprudents pour utiliser ces préfixes d'adresses IP apparemment inutilisés pour numéroter leurs réseaux internes ; l'annoncer sur l'Internet permettrait de capter ce trafic interne (on dit que l'armée chinoise était dans ce cas),
  • ou encore le but est vraiment de s'en servir, par exemple pour y héberger des services.

La possibilité d'une vente de ces adresses, et donc peut-être d'un test pour s'assurer qu'elles ne posaient pas de problèmes techniques, a été souvent mentionnée, vu le « trésor » d'adresses IP de l'armée. Mais relativisons : au cours actuel (mais qui baisserait si le DoD vendait d'un coup toutes ces adresses), cela ferait certes plusieurs centaines de millions de dollars mais c'est une goutte d'eau par rapport aux budgets militaires de ce pays. Et puis le GAO (la « Cour des Comptes ») avait noté dans un rapport de 2020 les difficultés, notamment légales, à vendre ces adresses IP. Un rapport parlementaire estimait que la vente d'adresses IP par le DoD soulevait de nombreux problèmes et n'était pas forcément une solution viable.

Autre hypothèse, celle du pot de miel. C'est nettement plus vraisemblable : tout préfixe important annoncé sur l'Internet reçoit un « rayonnement de fond », l'Internet Background Radiation (IBR), et les nouveaux préfixes annoncés vont certainement attirer beaucoup de trafic, permettant des études qui intéressent certainement les services de cyberguerre.

Et, en parlant de cyberguerre, qu'en est-il de l'hypothèse d'un détournement délibéré du trafic des réseaux qui ont été assez stupides pour utiliser ces préfixes d'adresses IP ? Là, je ne vous étonnerai pas en vous disant que mes contacts au Pentagone sont muets et ne m'ont pas tenu informé :-)

Enfin, s'agissant de l'hébergement de services, ça reste possible mais l'annonce faite par une petite société inconnue et discrète ne plaide pas en ce sens. Notez que le très utile Shodan trouve déjà des machines connectées dans le préfixe 11.0.0.0/8. (Attention si vous essayez de les pirater : le propriétaire n'a pas le sens de l'humour.) Ma préférée (mais rappelez-vous qu'il peut s'agir d'un pot de miel) est un routeur Ubiquiti annonçant comme nom HACKED-ROUTER-HELP-SOS-HAD-DUPE-PASSWORD.

Quelques lectures en plus :


L'article seul

Fiche de lecture : Leur progrès et le nôtre

Auteur(s) du livre : François Ruffin
Éditeur : Seuil
978-2-02-147770-2
Publié en 2021
Première rédaction de cet article le 25 avril 2021


Le progrès technique est-il une bonne ou une mauvaise chose ? Avec tous les philosophes et militants politiques qui ont réfléchi à la question depuis je ne sais plus combien de siècles, on se doute bien qu'il n'y aura pas de réponse simple. Et puis, posé comme ça, c'est trop binaire. Dans ce court livre, François Ruffin estime que ça dépend, ça dépend de quel progrès, de qui le décide, de comment c'est déployé.

Nous voyons en ce moment beaucoup d'« injonctions au progrès », d'affirmations peu subtiles comme quoi le « progrès » (au sens du progrès technique) est à la fois forcément positif, inévitable et que de toute façon ceux et celles qui s'y opposent sont à coup sûr des amish attardés. Ce discours de la « startup nation », porté par exemple par Emmanuel Macron, est tellement idiot qu'il permet à Ruffin de se faire plaisir facilement, par exemple en dressant p. 20 la liste des cérémonies d'adoration des entreprises du numérique auxquelles a participé le président de la république, qui préfère se faire photographier en présence de patrons du numérique qu'avec des infirmières ou des éboueurs. L'auteur oublie d'ailleurs parfois son point de vue de classe par exemple en affirmant p. 23 que Macron aime s'entourer d'une « cour de geeks » comme s'il y avait le moindre rapport entre les patrons des grandes entreprises du numérique et le développeur de logiciel libre dans son garage. De même, taper sur Musk (p. 123) n'est pas difficile, tant le personnage prend soin d'être sa propre caricature.

Ruffin peut donc, vu le ridicule des propagandistes de « la Tech », facilement expliquer que tout progrès n'est pas bon à prendre. Le progrès technique n'est pas toujours un progrès social, et l'auteur liste de nombreux exemples où les techniques modernes, notamment autour du numérique, peuvent servir à opprimer, à surveiller, à contrôler et pas à augmenter le bonheur humain. D'où le titre, il y a ce qu'ils appellent le progrès, et ce que les lecteurs du livre considéreraient comme le vrai progrès (augmenter le salaire des enseignants plutôt que de chercher à tout prix à se faire voir serrant la main de Zuckerberg). Même sans parler de cas où le progrès technique a été un recul social (la surveillance généralisée est probablement le meilleur exemple), l'auteur cite aussi avec raison des cas où le progrès n'est pas linéaire et où ses effets peuvent s'épuiser. Un réfrigérateur dans la maison est un progrès, un deuxième n'apporte pas tellement d'avantages. (Comme le dit un des protagonistes de la série Mad Men à un débutant dans le monde de la publicité « notre rôle est de convaincre le consommateur d'acheter un objet alors qu'il en a déjà un qui sert à la même chose ».)

Cette partie où Ruffin explique que le progrès technique est un moyen, pas un but en soi, est la meilleure du livre. Il l'illustre de nombreux exemples. Après, les difficultés commencent : il ne faut pas avaler tout sous prétexte que ce serait « le progrès » mais comment décider ? L'auteur suggère quelques pistes, mais plutôt vagues. La démocratie, que le déploiement de telle ou telle technique, soit décidé par les citoyens, d'accord, mais les modalités pratiques ne vont pas aller sans mal. (C'est un des points que notait, à juste titre, le RFC 8890.) François Ruffin propose p. 139, une « Convention citoyenne permanente sur le numérique », l'idée me semble intéressante mais elle n'est pas développée, alors que cette suggestion fait surgir plein de questions. Une autre proposition, formulée par une personne interrogée par l'auteur (p. 140), serait que les ingénieurs décident « quelles applications autoriser », ce qui, cette fois, fait plutôt froid dans le dos.

Il faut dire qu'analyser les conséquences d'un progrès technique, surtout s'il n'a pas encore été déployé, est difficile. François Ruffin cite souvent la 5G, sujet à la mode. Heureusement, il ne reprend pas les délires complotistes entendus souvent (par exemple sur le « danger des ondes ») mais il traite le sujet de manière trop superficielle, par exemple en disant que la 5G n'a « pas d'utilité », ce qui est toujours une conclusion imprudente.

L'auteur dérape également un peu lorsqu'il brode p. 69 sur la légende comme quoi toutes les écoles de la Silicon Valley seraient sans ordinateurs car les cadres des entreprises du numérique voudraient mettre leurs enfants à l'abri de ce danger. Non seulement ce récit ne repose que sur quelques déclarations isolées de quelques personnages, mais il est amusant de constater que des gens qui critiquent, à juste titre, le manque de culture politique de pas mal d'acteurs du numérique, considèrent comme crédibles toutes les théories qu'ils peuvent émettre sur l'éducation. Pourquoi ne pas également les citer quand ils deviennent végétaliens ou bien se convertissent au bouddhisme, autres modes californiennes ?

Ce livre a le mérite de poser les bonnes questions : qui décide ? La 5G, l'Internet, l'infomatique, les ordiphones ne sont pas arrivés tout seuls. Des gens ont décidé, et ont mis les moyens nécessaires. Toute la question du progrès est de savoir qui va pouvoir prendre ces décisions, aujourd'hui confisquées par une minorité.


L'article seul

RFC 9011: Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN

Date de publication du RFC : Avril 2021
Auteur(s) du RFC : O. Gimenez (Semtech), I. Petrov (Acklio)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF lpwan
Première rédaction de cet article le 23 avril 2021


Le RFC 8724 décrivait un mécanisme général de compression pour les réseaux LPWAN (réseaux contraints pour objets contraints). Ce nouveau RFC 9011 précise ce mécanisme pour le cas spécifique de LoRaWAN.

Ces « réseaux contraints pour objets contraints » sont décrits dans le RFC 8376. Ils ont des concepts communs mais aussi des différences, ce qui justifie la séparation de SCHC en un cadre générique (celui du RFC 8724) et des spécifications précises par réseau, comme ce que fait notre RFC pour LoRaWAN, la technique qui est utilisée dans divers réseaux déployés. Donc, rappelez-vous, LoRaWAN = la technologie, LoRa = un réseau déployé utilisant cette technologie (mais d'autres réseaux concurrents peuvent utiliser LoRaWAN). LoRaWAN est normalisé par l'alliance LoRa (cf. le texte de la norme) et les auteurs du RFC sont actifs dans cette alliance. Si vous voulez un exemple d'utilisation de LoRaWAN, je recommande cet article en français sur une Gateway LoRaWAN réalisée sur un Raspberry Pi.

La section 3 du RFC fait un rappel de SCHC : si vous n'avez pas le courage de lire le RFC 8724, apprenez que SCHC a deux parties, une de compression des en-têtes, et une de fragmentation, les liens des réseaux contraints ayant souvent une faible MTU. La section 4, elle, explique LoRaWAN (vous avez aussi le RFC 8376, notamment sa section 2.1). La terminologie de SCHC et celle de LoRaWAN ne coïncident pas parfaitement donc il faut se souvenir que Gateway dans LoRaWAN s'appelle plutôt RGW (Radio GateWay) dans SCHC, que le Network Server de LoRaWAN est le NGW (Network GateWay) de SCHC et que les utilisateurs de LoRaWAN doivent se souvenir que leur Application Server est nommé C/D (Compression/Décompression) ou F/R (Fragmentation/Réassemblage) chez SCHC. Les objets connectés par LoRaWAN sont très souvent contraints et LoRaWAN définit trois classes d'objets, de la classe A, la plus contrainte, à la C. Notamment, les objets de la classe A émettent sur le réseau mais n'ont pas de moment d'écoute dédié, ceux de la classe B écoutent parfois, et ceux de la classe C écoutent en permanence, ce qui consomme pas mal d'énergie. Autant dire que les objets de classe C sont en général alimentés en électricité en permanence.

La section 5 est le cœur du RFC, expliquant en détail comment on met en correspondance les concepts abstraits de SCHC avec les détails du protocole LoRaWAN. Ainsi, le RuleID de SCHC est mis sur huit bits, dans le port (Fport) LoRaWAN (norme LoRaWAN, version 1.04, section 4.3.2), juste avant la charge utile. L'annexe A du RFC donne des exemples d'encodage des paquets.

Merci à Laurent Toutain pour sa relecture.


Téléchargez le RFC 9011


L'article seul

Name:Wreck, vulnérabilité Internet du jour

Première rédaction de cet article le 14 avril 2021


Comme souvent, une vulnérabilité logicielle a reçu un nom commercial (« Name:Wreck », notez le deux-points) et a eu droit à des articles dans les médias. Plongeons-nous un peu dans cette vulnérabilité et ce qu'elle nous apprend.

Name:Wreck est décrite dans un rapport (en anglais) de la société Forescout dont je vous recommande la lecture, c'est bien expliqué et avec une dose relativement limitée de sensationnalisme et de marketing. Name:Wreck n'est pas, comme cela a parfois été dit, une « vulnérabilité DNS » ou une « faille DNS » mais une bogue dans des logiciels client DNS. La bogue exploite une fonction peu connue du DNS, la compression des données dans les réponses. Comme le même nom de domaine peut apparaitre plusieurs fois dans une réponse DNS, l'encodage des noms dans le paquet peut se faire en ne mettant qu'une fois le nom et, le reste du temps, en mettant un pointeur vers ce nom. J'ai simplifié, pour avoir tous les détails, il faut lire le RFC 1035, section 4.1.4. (Notez que le rapport mentionne d'autres vulnérabilités, qui n'ont pas grand'chose à voir avec les pointeurs de compression.)

Si vous êtes programmeuse ou programmeur, vous avez déjà senti le problème : que se passe-t-il, par exemple, si le pointeur pointe en dehors du paquet ? Eh bien vous avez gagné, ce genre de problèmes est fréquent, beaucoup de mises en œuvre du DNS analysent les paquets sans faire assez attention. La section 6 du rapport cité plus haut liste un certain nombre d'erreurs courantes dans l'analyse des paquets DNS. Ces erreurs sont encore plus graves si on programme en C, langage qui, par défaut, vous laissera écrire au-delà des bornes. J'ajoute que mon expérience personnelle d'analyse de paquets DNS réels montre que les paquets mal formés sont une réalité, soit par désir de malveillance, soit par erreur. Ainsi, comme le note la sous-section 6.5 du rapport, un client DNS qui ferait une boucle sur le nombre d'enregistrements dans une section DNS sans précautions découvrirait rapidement que les paquets annonçant des milliers d'enregistrements, mais de taille bien trop courte pour les contenir, existent en vrai dans l'Internet. La règle de base de l'analyse de paquets entrants « soyez paranoïaques » s'applique au DNS.

Donc, en envoyant un paquet soigneusement calculé, avec des pointeurs de compression incorrects, on peut déclencher une boucle sans fin chez le client, ou un plantage, ou, pire, une exécution de code. Notons que si tout programme, quel que soit le langage dans lequel il est écrit, peut être vulnérable aux deux premières conséquences, la possibilité qu'une bogue mène à une exécution de code est quand même assez spécifique à C. Cela pourrait être un argument pour prôner l'utilisation de langages supposés plus sûrs, comme Rust (après, comme je n'ai pas appris à programmer en Rust, je réserve mon opinion).

La vulnérabilité existe par exemple dans le client DNS du système d'exploitation Nucleus de Siemens, conçu pour les objets connectés (cf. l'avis de sécurité). Elle touche aussi le système d'exploitation FreeBSD (cf. l'avis). Un des mérites des auteurs de l'étude est en effet de ne pas s'être limités aux clients DNS classiques mais d'avoir regardé d'autres logiciels qui analysent des informations DNS. C'est le cas des clients DHCP, qui peuvent recevoir des informations DNS, comme la liste des domaines à ajouter aux noms cherchés (option 119 en DHCP v4). En l'occurrence, chez FreeBSD, c'est en effet le client dhclient qui était vulnérable. (Quoique certaines mesures de protection peuvent, si elles sont utilisées, limiter les conséquences de la faille.)

Bien, donc, la faille existe. Maintenant, soyons positifs, agissons. Quelles sont les actions possibles ? Évidemment, les auteurs des logiciels concernés ont patché. Mais cela ne concerne que le code d'origine, pas toutes ses utilisations, loin en aval. Ce n'est pas parce qu'un patch existe chez FreeBSD, ou même qu'une nouvelle version de ce système d'exploitation sort, que toutes les machines FreeBSD de la planète vont recevoir le nouveau code. En outre, FreeBSD est souvent utilisé indirectement, par des gens qui ne savent même pas que le joli boitier très cher qu'ils ont acheté (répartiteur de charge, pare-feu, etc) utilise en fait FreeBSD. Ces boitiers spécialisés utilisent souvent des versions très en retard des logiciels (libres ou privateurs) qu'ils intègrent. Des versions vulnérables continueront donc à être en production pendant longtemps.

Et c'est encore pire dans le monde merveilleux de l'« Internet des Objets ». Là, la règle est le n'importe quoi, des objets vendus sans aucune mise à jour, ou bien une mise à jour compliquée, et qui ne dure de toute façon pas éternellement. Là, on peut parier que les versions vulnérables dureront bien plus longtemps. Un bonne lecture à rappeler est le RFC 8240, le compte-rendu d'un atelier IAB sur cette question de la mise à jour des objets connectés. Au passage, ce problème a une composante technique (ce sur quoi travaille le groupe de travail IETF SUIT) et surtout une composante business. Rien n'oblige les vendeurs d'objets connectés à assurer une maintenance rapide et correcte de leurs logiciels sur le long terme.

Bon, alors que faire en attendant ? Le rapport suggère d'isoler et de segmenter, pour éviter que les objets vulnérables se trouvent directement exposés au grand méchant Internet. C'est par exemple l'argument de Paul Vixie quand il dit qu'il faut s'assurer que les objets en entreprise ne parlent pas directement à des serveurs DNS externes mais passent forcément par un résolveur interne (qui ne leur enverra que des paquets DNS correctement formés). Le problème est que cela suppose que l'entreprise ait un résolveur interne, correct, à jour, qui rende le service attendu… (Par exemple, beaucoup de ces résolveurs internes ne valident pas.) Autrement, pas mal d'objets (via une décision de leur programmeur, ou de leur utilisateur) vont essayer de court-circuiter le résolveur local.

Et à l'IETF, peut-on faire quelque chose ? Changer le protocole DNS pour supprimer la compression n'est clairement pas possible, mais on pourrait attirer l'attention des programmeuses et des programmeurs sur ces dangers. C'est ce que propose un Internet-Draft écrit par les auteurs du rapport Name:Wreck, draft-dashevskyi-dnsrr-antipatterns. Le rapport suggère également de modifier le RFC 5625, qui dit qu'un relais DNS peut jeter les paquets mal formés. Le rapport suggère de dire qu'il le doit. Le problème est que certains de ces relais analysent la totalité des paquets (et peuvent donc les « proprifier ») alors que d'autres passent juste des bits et ne savent donc pas quels sont les paquets incorrects.

On peut quand même en tirer une leçon pour la conception de systèmes informatiques critiques : la compression dans le DNS est compliquée, mal spécifiée, et dangereuse. Comme la fragmentation/réassemblage dans IP, elle a déjà mené à pas mal de failles. On peut donc rappeler que la complexité est l'ennemie de la sécurité et que, pour gagner quelques octets, les auteurs du DNS ont créé une fonction dangereuse. Pensez-y la prochaine fois que vous entendrez quelqu'un dire que rajouter « juste une petite fonction simple » dans une spécification ou un code ne peut pas poser de problème.


L'article seul

Fiche de lecture : Cavanna, paléontologue !

Auteur(s) du livre : Pascal Tassy
Éditeur : Éditions Matériologiques
978-2-37361-252-3
Publié en 2020
Première rédaction de cet article le 7 avril 2021


Si, comme beaucoup de personnes (comme moi, par exemple), vous ignoriez que Cavanna était féru de paléontologie, vous allez l'apprendre dans ce court livre où l'auteur nous raconte ses échanges scientifiques avec le fondateur de Charlie Hebdo.

Cavanna avait de nombreuses cordes à son arc. Mais ce récit de Pascal Tassy se focalise sur une seule corde : la passion du « rital » pour l'étude des espèces disparues. Cavanna était curieux de sciences et aimait discuter avec les scientifiques. Son arrivée à la soutenance de thèse de l'auteur (thèse sur les mastodontes) avait sérieusement déstabilisé le bientôt docteur. Ils ont finalement parlé d'adaptation, de sélection naturelle, de cladistique, d'écologie… pendant de nombreuses années.

Si Cavanna et Pascal Tassy étaient d'accord sur beaucoup de choses (par exemple pour se moquer des créationnistes), il leur restait des sujets de controverses. J'ai ainsi appris que Cavanna, contrairement à son ami, était plutôt favorable au transhumanisme et tenté par l'idée d'immatérialisme.

Il était même prévu entre les deux amis d'écrire ensemble un livre… qui ne s'est finalement pas fait. À défaut, vous aurez dans ce récit quelques idées sur ce qu'aurait pu être ce livre.

Autre compte-rendu de ce livre, dans Charlie Hebdo.


L'article seul

RFC 9018: Interoperable Domain Name System (DNS) Server Cookies

Date de publication du RFC : Avril 2021
Auteur(s) du RFC : O. Sury (Internet Systems Consortium), W. Toorop (NLnet Labs), D. Eastlake 3rd (Futurewei Technologies), M. Andrews (Internet Systems Consortium)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 6 avril 2021


Le RFC 7873 normalisait un mécanisme, les cookies, pour qu'un serveur DNS authentifie raisonnablement l'adresse IP du client (ce qui, normalement, n'est pas le cas en UDP). Comme seul le serveur avait besoin de reconnaitre ses cookies, le RFC 7873 n'imposait pas un algorithme particulier pour les générer. Cela posait problème dans certains cas et notre nouveau RFC propose donc un mécanisme standard pour fabriquer ces cookies.

L'un des scénarios d'utilisation de ces « cookies standards » est le cas d'un serveur anycast dont on voudrait que toutes les instances génèrent des cookies standardisés, pour qu'une instance puisse reconnaitre les cookies d'une autre. Le RFC 7873, section 6, disait bien que toutes les instances avaient intérêt à partir du même secret mais ce n'était pas plus détaillé que cela. La situation actuelle, où chaque serveur peut faire différemment, est décrite dans le RFC par un mot en anglais que je ne connaissais pas, gallimaufry. D'où l'idée de spécifier cet algorithme, pour simplifier la vie des programmeuses et programmeurs avec un algorithme de génération de cookie bien étudié et documenté ; plus besoin d'en inventer un. Et cela permet de créer un service anycast avec des logiciels d'auteurs différents. S'ils utilisent cet algorithme, ils seront compatibles. Il ne s'agit que d'une possibilité : les serveurs peuvent utiliser cet algorithme mais ne sont pas obligés, le RFC 7873 reste d'actualité.

Comment, donc, construire un cookie ? Commençons par celui du client (section 3). Rappel : le but est d'authentifier un minimum donc, par exemple, le client doit choisir un cookie différent par serveur (sinon, un serveur pourrait se faire passer pour un autre, d'autant plus que le cookie circule en clair), et, donc, il faut utiliser quelque chose de spécifique au serveur dans l'algorithme, par exemple son adresse IP. Par contre, pas besoin de le changer souvent, il peut parfaitement durer des mois, sauf évidemment si un élément entrant dans sa construction change, ou est compromis. Autrefois, il était suggéré d'utiliser l'adresse IP du client dans la construction du cookie client, mais cette suggestion a été retirée car le logiciel ne connait parfois son adresse IP que trop tard (ça dépend de l'API réseau utilisée et, par exemple, avec l'API sockets de si on a déjà fait un bind() et, de toute façon, si on est derrière un routeur NAT, connaitre l'adresse IP locale ne sert pas à grand'chose). Néanmoins, pour éviter qu'un cookie ne permette à un observateur de relier deux requêtes d'une même machine, le cookie doit changer quand l'adresse IP change, comme rappelé par la section 8.1. (C'est particulièrement important si on utilise des techniques de protection de la vie privée comme celle du RFC 8981.)

Voilà, c'est tout parce que ce qui est important dans notre RFC, c'est le cookie serveur (section 4), puisque c'est là qu'on voudrait un cookie identique pour toutes les instances du service. Les éléments utilisés pour le générer sont le cookie du client, l'adresse IP du serveur, quelques métadonnées et un secret (qu'il faudra donc partager au sein du service anycast). Le secret changera, par exemple une fois par mois. Une fois qu'on a tous ces éléments, on va ensuite condenser le tout, ici avec SipHash (cf. J. Aumasson, et D. J. Bernstein, « SipHash: A Fast Short- Input PRF »). (Parmi les critères de choix d'une fonction de condensation, il y a les performances, un serveur DNS actif pouvant avoir à faire ce calcul souvent, pour vérifier les cookies.) Le cookie comprendra un numéro de version, un champ réservé, une estampille temporelle et le condensat. L'algorithme de génération du condensat inclus dans le cookie est donc : Condensat = SipHash-2-4 ( Cookie client | Version | Réservé | Estampille | Client-IP, Secret ), avec :

  • Le signe | indique la concaténation.
  • Le champ Version vaut actuellement 1 (les futures versions seront dans un registre IANA).
  • Le champ Réservé ne comporte pour l'instant que des zéros.
  • L'estampille temporelle sert à éviter les attaques par rejeu et permet de donner une durée de validité aux cookies (le RFC recommande une heure, avec cinq minutes de battement pour tenir compte des horloges mal synchronisées).

On a vu qu'il fallait changer le secret connu du serveur de temps en temps (voire plus rapidement s'il est compromis). Pour que ça ne casse pas tout (un serveur ne reconnaissant pas les cookies qu'il avait lui-même émis avec l'ancien secret…), il faut une période de recouvrement où le serveur connait déjà le nouveau secret (et accepte les cookies ainsi générés, par exemple par les autres instances du service anycast), puis une période où le serveur génère les cookies avec le nouveau secret, mais continue à accepter les cookies anciens (par exemple gardés par des clients). La section 5 rappelle, comme on le fait pour les remplacements de clés DNSSEC, de tenir compte des TTL pour calculer les délais nécessaires.

Si vous voulez mettre en œuvre vous-même cet algorithme, notez que l'annexe A du RFC contient des vecteurs de test, permettant de vérifier si vous ne vous êtes pas trompé.

La section 2 de notre RFC décrit les changements depuis le RFC 7873. Les algorithmes données comme simples suggestions dans les annexes A.1 et B.1 sont trop faibles et ne doivent pas être utilisés. Celui de l'annexe B.2 ne pose pas de problèmes de sécurité mais celui de notre nouveau RFC est préféré.

Plusieurs mises en œuvre de ce nouvel algorithme ont été faites, et leur interopérabilité testée (notamment au cours du hackathon de la réunion IETF 104 à Prague). Au moins BIND, Knot et getdns ont déjà cet algorithme dans leurs versions publiées.


Téléchargez le RFC 9018


L'article seul

Faut-il forcément passer du temps à étudier les techniques qui semblent farfelues ?

Première rédaction de cet article le 29 mars 2021


J'ai vu récemment, mais ce n'était la première fois, une personne se prétendant « inventeur » affirmer que ceux qui riaient de ses prétentions fantaisistes n'avaient pas pris le temps d'examiner son travail et que leurs critiques n'étaient donc pas pertinentes. Le bon sens dit en effet qu'il ne faut pas critiquer sans connaitre, et que connaitre nécessite de passer un peu de temps sur l'objet de la critique. Est-ce que le bon sens a raison ?

Le cas précis auquel je fais allusion concernait la sécurité informatique et l'inventeur prétendait avoir trouvé une solution de sécurité universelle. J'ai rencontré ce cas plusieurs fois en informatique (les participants à l'IETF penseront bien sûr à « IPv10 »). Mais ce serait la même chose avec quelqu'un prétendant avoir trouvé un remède contre toutes les maladies, ou bien une personne affirmant avoir mis au point le mouvement perpétuel. (On trouve même ce syndrome de l'inventeur génial dans les sciences humaines, par exemple les gens annonçant avoir déchiffré le disque de Phaistos.) Dans tous ces cas, face aux première réactions négatives, l'inventeur génial se drape dans sa dignité et dit bien haut que ses opposants n'ont pas lu ses textes, n'ont pas étudié sa machine, et qu'on ne doit donc pas les croire puisqu'ils n'ont même pas fait l'effort minimal de chercher à comprendre.

Ce raisonnement semble s'appuyer sur un principe de base de la science et de la technique : comprendre une invention n'est pas facile, il faut y passer du temps, et, tant qu'on ne l'a pas fait, on doit rester prudent dans ses affirmations. Mais il faut poursuivre plus loin ce raisonnement : c'est justement parce qu'évaluer sérieusement une invention prend du temps qu'on ne peut pas le faire pour chaque type qui annonce à l'univers qu'il a inventé un truc extraordinaire. Toute personne connue dans son domaine voit passer de nombreuses annonces d'inventions géniales, et si elle consacrait à chacune le temps nécessaire pour être absolument sûre de sa vacuité, cette personne n'aurait pas le temps de faire du travail sérieux.

Est-ce injuste ? Peut-être. Mais c'est ainsi. Les journées n'ont que 24 heures et il faut bien dormir de temps en temps. Si vous êtes inventeur, ne croyez pas qu'un·e expert·e du domaine va consacrer gratuitement des heures ou des jours de son temps à analyser patiemment tout ce que vous racontez. Trépigner du pied en enjoignant les expert·es de se pencher sur vos élucubrations ne produira pas de succès.

Mais, alors, une invention disruptive, surprenante, remettant en cause des certitudes n'a aucune chance de percer ? On ne travaillera que sur des choses déjà connues, sans surprise ? Non, évidemment. Mais on sélectionnera. L'expert·e passera du temps sur les propositions dont ielle estime, à première vue, qu'elles offrent des chances sérieuses de ne pas être une perte d'efforts. Pour celles qui sont très surprenantes, inhabituelles, et qui remettent en cause des certitudes, l'expert·e va d'abord utiliser des « signaux d'alarme ». Ce sont des heuristiques (terme prétentieux pour dire qu'elles ne sont pas parfaites, mais quand même utiles). Si vous êtes inventeur génial et que vous voulez augmenter vos chances d'être écouté, ne déclenchez pas ces signaux d'alarme :

  • Prétentions délirantes (« Ce mode de communication […] est insaisissable, intraçable, anonyme et totalement sécurisé »). Rappelez-vous que les annonces extraordinaires nécessitent des preuves extraordinaires. Plus vous vous vantez, plus vous aurez du mal à convaincre.
  • Applicabilité excessive. Les vraies inventions marchent dans certains cas, résolvent certains problèmes, et pas d'autres. Affirmer que vous allez « stopper les cyberattaques, les demandes de rançons informatiques ou encore les usurpations d'identité » ou « il pourrait aussi s'avérer très utile pour l'armée, puisqu'il s'agit là d'un outil idéal pour transmettre des ordres, des plans » ne contribue pas à votre crédibilité. Au contraire, une preuve de sérieux est quand vous exposez clairement les limites de votre invention (toute technique a des limites).
  • Ignorance complète des bases du domaine dans lequel vous prétendez avoir inventé quelque chose. Cette heuristique est d'un usage délicat car, parfois (« parfois » au sens de « une fois sur un zillion »), quelqu'un d'extérieur au domaine fait une percée, en partie justement car ielle n'était pas du domaine et pouvait donc penser « en dehors de la boite ». Mais c'est beaucoup plus rare que le cas où l'inventeur est simplement ignorant des difficultés du domaine. Un exemple est, en cryptographie, quelqu'un qui ne saurait pas ce qu'est une attaque de l'homme du milieu, ou qui ne comprendrait pas la différence entre cryptographie symétrique et asymétrique (« votre correspondant, une fois le message reçu, passe de la même façon sa carte, qui a la même clé de chiffrement que la vôtre »).
  • Propos vagues. Annoncer des résultats mirobolants sans donner de détails précis va allumer un signal d'alarme. Prétendre que cette absence de détails est due à votre souci d'éviter que les Chinois vous copient n'arrange rien (voir le point suivant).
  • Paranoïa. Un inventeur qui commence par « je suis génial mais le système / les puissants / les GAFA / Framasoft / les polytechniciens / les énarques conspirent pour me faire taire » allume également le plus puissant des signaux d'alarme. (J'en profite pour signaler que se comparer à Galilée n'aide pas. 1) Galilée n'a pas été rejeté par les autres scientifiques mais par les religieux, qui sont toujours opposés à la science 2) pour un Galilée, combien d'escrocs ?)
  • Grands mots. Ajouter « blockchain », « quantique » ou « IA » n'ajoute pas de la crédibilité à votre discours, sauf si vous pouvez expliquer en détail ce que ces techniques apportent à votre œuvre.
  • La forme compte aussi. Bien sûr, un inventeur génial peut avoir une orthographe catastrophique. Mais un texte bacler PLEIN D'AFFIRMATIONS EN MAJUSCULES et de ponctation !!! eksèssive car votre invantion est GÉNIALE !!! ne va pas vous aider. Respirez et prenez le temps de relire. (Au passage, n'avoir comme documentation que des vidéos convient si vous êtes influenceur beauté, pas si vous prétendez être inventeur.)

Tous les inventeurs ne déclenchent pas la totalité de ces signaux d'alarme. Mais ils en allument en général plusieurs. Comme toutes les heuristiques, elles ne sont pas parfaites. On ne connait pas de mécanisme parfait pour déterminer si une invention est géniale ou débile. Et les expert·es, comme tout le monde, peuvent se tromper. Mais, en raison de la finitude de la journée de travail, on doit utilise ces heuristiques, sinon on ne produirait jamais rien.


L'article seul

RFC 9006: TCP Usage Guidance in the Internet of Things (IoT)

Date de publication du RFC : Mars 2021
Auteur(s) du RFC : C. Gomez (UPC), J. Crowcroft (University of Cambridge), M. Scharf (Hochschule Esslingen)
Pour information
Réalisé dans le cadre du groupe de travail IETF lwig
Première rédaction de cet article le 28 mars 2021


À côté de machines disposant de ressources matérielles suffisantes (électricité, processeur, etc), qui peuvent faire tourner des protocoles comme TCP sans ajustements particuliers, il existe des machines dites contraintes, et des réseaux de machines contraintes, notamment dans le cadre de l'Internet des Objets. Ces machines, pauvres en énergie ou en capacités de calcul, doivent, si elles veulent participer à des communications sur l'Internet, adapter leur usage de TCP. Ce RFC documente les façons de faire du TCP « léger ».

Ces CNN (Constrained-Node Networks, réseaux contenant beaucoup d'objets contraints) sont décrits dans le RFC 7228. On parle bien d'objets contraints, soit en processeur, soit en énergie. Un Raspberry Pi ou une télévision connectée ne sont pas des objets contraints, ils peuvent utiliser les systèmes habituels, avec un TCP normal, au contraire des objets contraints, qui nécessitent des technologies adaptées. Le RFC 8352 explique ainsi les problèmes liés à la consommation électrique de certains protocoles. Des protocoles spéciaux ont été développés pour ces objets contraints, comme 6LoWPAN (RFC 4944, RFC 6282 et RFC 6775) ou comme le RPL du RFC 6550 ou, au niveau applicatif, le CoAP du RFC 7252.

Côté transport, on sait que les principaux protocoles de transport actuels sur l'Internet sont UDP et TCP. TCP a été parfois critiqué comme inadapté à l'Internet des Objets. Ces critiques n'étaient pas forcément justifiées mais il est sûr que le fait que TCP ait des en-têtes plutôt longs, pas de multicast et qu'il impose d'accuser réception de toutes les données peut ne pas être optimal pour ces réseaux d'objets contraints. D'autres reproches pouvaient être traités, comme expliqué dans l'article «  TCP in the Internet of Things: from ostracism to prominence ». Notez que CoAP, à l'origine, tournait uniquement sur UDP mais que depuis il existe aussi sur TCP (RFC 8323). Les CNN (Constrained-Node Networks) utilisent parfois d'autres protocoles applicatifs tournant sur TCP comme HTTP/2 (RFC 7540) ou MQTT.

TCP est certes complexe si on veut utiliser toutes les optimisations qui ont été développées au fil du temps. Mais elles ne sont pas nécessaires pour l'interopérabilité. Un TCP minimum peut parfaitement communiquer avec des TCP optimisés, et notre RFC explique comment réduire l'empreinte de TCP, tout en restant évidemment parfaitement compatible avec les TCP existants. (Notez qu'il y avait déjà eu des travaux sur l'adaptation de TCP à certains environnements, voir par exemple le RFC 3481.)

Bon, maintenant, au travail. Quelles sont les propriétés des CNN (RFC 7228) qui posent problème avec TCP (section 2 du RFC) ? Ils manquent d'énergie et il ne peuvent donc pas émettre et recevoir en permanence (RFC 8352), ils manquent de processeur, ce qui limite la complexité des protocoles, et ils utilisent souvent des réseaux physiques qui ont beaucoup de pertes (voire qui corrompent souvent les paquets), pas vraiment les réseaux avec lesquels TCP est le plus à l'aise (RFC 3819).

La communication d'un objet contraint se fait parfois à l'intérieur du CNN, avec un autre objet contraint et parfois avec une machine « normale » sur l'Internet. Les types d'interaction peuvent aller de l'unidirectionnel (un capteur transmet une mesure qu'il a faite), à la requête/réponse en passant par des transferts de fichiers (mise à jour du logiciel de l'objet contraint, par exemple). Voyons maintenant comment TCP peut s'adapter (section 3 du RFC).

D'abord, la MTU. En IPv6, faire des paquets de plus de 1 280 octets, c'est prendre le risque de la fragmentation, qui n'est pas une bonne chose pour des objets contraints en mémoire (RFC 8900), qui n'ont en plus pas très envie de faire de la Path MTU discovery (RFC 8201). Donc, notre RFC conseille d'utiliser la MSS (Maximum Segment Size) de TCP pour limiter la taille des paquets. Attention, les CNN tournent parfois sur des réseaux physiques assez spéciaux, où la MTU est bien inférieure aux 1 280 octets dont IPv6 a besoin (RFC 8200, section 5). Par exemple, IEEE 802.15.4 a une MTU de 127 octets seulement. Dans ce cas, il faut prévoir une couche d'adaptation entre IPv6 et le réseau physique (ce que fait le RFC 4944 pour IEE 802.15.4, le RFC 7668 pour Bluetooth LE, le RFC 8105 pour DECT LE, etc). Heureusement, d'autres technologies de réseau physique utilisées dans le monde des CNN n'ont pas ces limites de MTU, c'est le cas par exemple de Master-Slave/Token-Passing (cf. RFC 8163), IEEE 802.11ah, etc.

Deuxième endroit où on peut optimiser, ECN (RFC 3168). ECN permet aux routeurs intermédiaires de marquer dans un paquet que la congestion est proche ; le destinataire peut alors prévenir l'émetteur de ralentir. Le RFC 8087 décrit les avantages de l'ECN. Permettant de détecter l'approche de la congestion avant qu'on ait perdu un seul paquet (et donc sans qu'on ait à dépenser des watts pour retransmettre), l'ECN est particulièrement intéressant pour les CNN. Le RFC 7567 donne des conseils pratiques pour son déploiement.

Un problème classique de TCP sur les liens radio est que TCP interprète une perte de paquet comme signal de congestion, le poussant à ralentir, alors que cette perte peut en fait être due à la corruption d'un paquet (suite à une perturbation radio-électrique, par exemple). Il serait donc intéressant de pouvoir signaler explicitement ce genre de perte (la question était déjà discutée dans le RFC 2757 mais aussi dans l'article « Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks »). Pour l'instant, il n'existe aucun mécanisme standard pour cela, ce qui est bien dommage.

Pour faire tourner TCP sur une machine contrainte, une technique parfois utilisée est de n'envoyer qu'un segment à la fois (et donc d'annoncer une fenêtre dont la taille est d'un MSS - Maximum Segment Size). Dans ce cas, pas besoin de mémoriser plus qu'un segment de données envoyé mais dont l'accusé de réception n'a pas encore été reçu. C'est très économique, mais ça se paie cher en performances puisqu'il faut attendre l'accusé de réception de chaque segment avant d'en envoyer un autre. La capacité effective du lien va chuter, d'autant plus que certaines optimisations de TCP comme le fast recovery dépendent d'une fenêtre plus grande qu'un seul segment. Au niveau applicatif, on voit la même technique avec CoAP, qui est par défaut purement requête/réponse.

Si on veut faire du TCP « un seul segment », le code peut être simplifié, ce qui permet de gagner encore en octets, mais notre RFC rappelle quand même que des options comme MSS (évidemment), NoOp et EndOfOptions restent nécessaires. En revanche, on peut réduire le code en ne gérant pas les autres options comme WindowScaling (RFC 7323), Timestamps (RFC 7323) ou SACK (RFC 2018). TCP a le droit d'ignorer ces options, qui, en « un seul segment » sont parfois inutiles (WindowScaling, SACK) et parfois moins importantes (Timestamps). En tout cas, si la machine a assez de mémoire, il est sûr que transmettre plusieurs segments avant d'avoir eu l'accusé de réception du premier, et utiliser des algorithmes comme le fast recovery améliore certainement les performances. Même chose pour les accusés de réception sélectifs, les SACK du RFC 2018.

La détermination du RTO (Retransmission TimeOut) est un des points cruciaux de TCP (RFC 6298). S'il est trop long, on attendra longtemps la retransmission, quand un paquet est perdu, s'il est trop court, on ré-émettra parfois pour rien, gâchant des ressources alors que le paquet était juste en retard. Bref, une mise en œuvre de TCP pour les CNN doit soigner ses algorithmes de choix du RTO (cf. RFC 8961).

Continuons avec des conseils sur TCP dans les réseaux d'objets contraints. Notre RFC rappelle que les accusés de réception retardés, utiles pour accuser réception d'une plus grande quantité de données et ainsi diminuer le nombre de ces accusés, peuvent améliorer les performances… ou pas. Cela dépend du type de trafic. Si, par exemple, le trafic est surtout dans une direction, avec des messages courts (ce sera typiquement le cas avec CoAP), retarder les accusés de réception n'est sans doute pas une bonne idée.

Les paramètres par défaut de TCP sont parfois inadaptés aux CNN. Ainsi, le RFC 5681 recommande une taille de fenêtre initiale d'environ quatre kilo-octets. Le RFC 6298 fait des recommandations qui peuvent aboutir à des tailles de fenêtre initiale encore plus grandes. C'est très bien pour un PC connecté via la fibre mais pas pour la plupart des objets contraints, qui demandent des paramètres adaptés. Bref, il ne faut pas lire le RFC 6298 trop littéralement, car il faut en général une taille de fenêtre initiale plus petite.

Il n'y a pas que TCP lui-même, il y a aussi les applications qui l'utilisent. C'est l'objet de la section 4 du RFC. En général, si un objet contraint communique avec un non-contraint, c'est le premier qui initie la connexion (cela lui permet de dormir, et donc d'économiser l'énergie, s'il n'a rien à dire). L'objet contraint a tout intérêt à minimiser le nombre de connexions TCP, pour économiser la mémoire. Certes, cela crée des problèmes de head-of-line blocking (une opération un peu lente bloque les opérations ultérieures qui passent sur la même connexion TCP) mais cela vaut souvent la peine.

Et combien de temps garder la connexion TCP ouverte ? Tant qu'on a des choses à dire, c'est évident, on continue. Mais lorsqu'on n'a plus rien à dire, l'application doit-elle fermer les connexions, qui consomment de la mémoire, sachant que rouvrir la connexion prendra du temps et des ressources (la triple poignée de mains…). C'est un peu le problème de l'automobiliste arrêté qui se demande s'il doit couper son moteur. S'il faut redémarrer tout de suite, il consommera davantage de carburant. D'un autre côté, s'il laisse son moteur tourner, ce sera également un gaspillage. Le problème est soluble si l'application sait exactement quand elle aura à nouveau besoin d'émettre, ou si l'automobiliste sait exactement combien de temps durera l'arrêt mais, en pratique, on ne le sait pas toujours. (Ceci dit, pour l'automobile, le système d'arrêt-démarrage automatique dispense désormais le conducteur du choix.)

Une autre raison pour laquelle il faut être prudent avec les connexions TCP inactives est le NAT. Si un routeur NAT estime que la connexion est finie, il va retirer de ses tables la correspondance entre l'adresse IP interne et l'externe et, lorsqu'on voudra recommencer à transmettre des paquets, ils seront perdus. Le RFC 5382 donne des durées minimales avant ce retrait (deux heures…) mais elles ne sont pas forcément respectées par les routeurs NAT. Ainsi, l'étude « An Experimental Study of Home Gateway Characteristics » trouve que la moitié des boitiers testés ne respectent pas la recommandation du RFC 5382, avec des délais parfois aussi courts que quelques minutes ! Une des façons d'empêcher ces coupures est d'utiliser le mécanisme keep-alive de TCP (RFC 1122, section 4.2.3.6), qui envoie régulièrement des paquets dont le seul but est d'empêcher le routeur NAT d'oublier la connexion. Une autre est d'avoir des « battements de cœur » réguliers dans les applications, comme le permet CoAP (RFC 8323). Et, si on coupe rapidement les connexions TCP inutilisées, avant qu'une stupide middlebox ne le fasse, comment reprendre rapidement ensuite, si le trafic repart ? TCP Fast open (RFC 7413) est une solution possible.

Enfin, la sécurité pose des problèmes particuliers dans les CNN, où les ressources de certaines machines peuvent être insuffisantes pour certaines solutions de sécurité. Ainsi, pour TCP, la solution d'authentification AO (RFC 5925) augmente la taille des paquets et nécessite des calculs supplémentaires.

Il existe un certain nombre de mises en œuvre de TCP qui visent les objets contraints mentionnés dans ce RFC. Une machine 32 bits alimentée en courant en permanence, comme un vieux Raspberry Pi, n'est pas concernée, elle fait tourner le TCP habituel de Linux. On parle ici de TCP pour objets vraiment contraints. C'est par exemple (annexe A du RFC) le cas de :

  • uIP, qui vise les microcontrôleurs à 8 et 16 bits. Elle est utilisée dans Contiki et sur la carte d'extension Ethernet (shield) pour Arduino. En 5 ko, elle réussit à faire IP (dont IPv6 dans les dernières versions) et TCP. Elle fait partie de celles qui utilisent le « un segment à la fois », ce qui évite les calculs de fenêtres (qui nécessitent des calculs sur 32 bits, qui seraient lents sur ces processeurs). Et c'est à l'application de se souvenir de ce qu'elle a envoyé, TCP ne le fait pas pour elle. L'utiliser est donc difficile pour le programmeur.
  • lwIP, qui vise le même genre de processeurs, mais dont l'empreinte mémoire est supérieure (entre 14 et 22 ko). Il faut dire qu'elle n'est pas limitée à envoyer un segment à la fois et que TCP mémorise les données envoyées, déchargeant l'application de ce travail. Et elle dispose de nombreuses optimisations comme SACK.
  • RIOT a sa propre mise en œuvre de TCP, nommée GNRC TCP. Elle vise aussi les engins de classe 1 (cf. RFC 7228 pour cette terminologie). Elle est de type « un segment à la fois » mais c'est TCP, et pas l'application, qui se charge de mémoriser les données envoyées (et qu'il faudra peut-être retransmettre). Par défaut, une application ne peut avoir qu'une seule connexion et il faut recompiler si on veut changer cela. Par contre, RIOT dispose d'une interface sockets, familière à beaucoup de programmeurs.
  • freeRTOS a aussi un TCP, pouvant envoyer plusieurs segments (mais une option à un seul segment est possible, pour économiser la mémoire). Il a même les accusés de réception retardés.
  • uC/OS peut également faire du TCP avec plusieurs segments en vol.

Un tableau comparatif en annexe A.7 résume les principales propriétés de ces différentes mises en œuvre de TCP sur objets contraints.


Téléchargez le RFC 9006


L'article seul

RFC 8997: Deprecation of TLS 1.1 for Email Submission and Access

Date de publication du RFC : Mars 2021
Auteur(s) du RFC : L. Velvindron (cyberstorm.mu), S. Farrell (Trinity College Dublin)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF uta
Première rédaction de cet article le 24 mars 2021


Dans le cadre général de l'abandon des versions 1.0 et 1.1 du protocole TLS (cf. RFC 8996), ce RFC déclare que ces vieilles versions ne doivent plus être utilisées pour le courrier (mettant ainsi à jour le RFC 8314).

Ce RFC 8314 spécifiait l'usage de TLS pour la soumission et la récupération de courrier. Sa section 4.1 imposait une version minimale de TLS, la 1.1. Cette 1.1 étant officiellement abandonnée pour obsolescence dans le RFC 8996, la version minimale est maintenant la 1.2. C'est tout, ce RFC est simple et court.


Téléchargez le RFC 8997


L'article seul

RFC 8996: Deprecating TLSv1.0 and TLSv1.1

Date de publication du RFC : Mars 2021
Auteur(s) du RFC : K. Moriarty (Dell EMC), S. Farrell (Trinity College Dublin)
Réalisé dans le cadre du groupe de travail IETF tls
Première rédaction de cet article le 24 mars 2021
Dernière mise à jour le 25 mars 2021


Ce RFC est très court, car il s'agit juste de formaliser une évidence : les versions 1.0 et 1.1 du protocole de cryptographie TLS ne devraient plus être utilisées, elles souffrent de diverses failles, notamment de sécurité. Les seules versions de TLS à utiliser sont la 1.2 (recommandée depuis 2008 !) et la 1.3 (publiée en 2018). Ainsi, une bibliothèque TLS pourra retirer tout le code correspondant à ces versions abandonnées, ce qui diminuera les risques (moins de code, moins de bogues).

Que reproche-t-on exactement à ces vieux protocoles (section 1 du RFC) ?

  • Ils utilisent des algorithmes de cryptographie dépassés et dangereux, par exemple TLS 1.0 impose de gérer Triple DES, et SHA-1 est utilisé à plusieurs endroits. Un des points les plus problématiques à propos des vieilles versions de TLS est en effet leur dépendance vis-à-vis de cet algorithme de condensation SHA-1. Celui-ci est connu comme vulnérable.
  • Ils ne permettent pas d'utiliser les algorithmes modernes, notamment le chiffrement intègre.
  • Indépendamment des défauts de ces vieux protocoles, le seul fait d'avoir quatre versions à gérer augmente les risques d'erreur, pouvant mener à des attaques par repli.
  • Des développeurs de bibliothèques TLS ont manifesté leur souhait de retirer les vieilles versions de TLS, ce qui implique leur abandon officiel par l'IETF.
  • Pour davantage de détails sur les faiblesses reprochées aux vieilles versions de TLS, regardez le rapport SP800-52r2 du NIST ou bien le RFC 7457. S'il existe bien des contournements connus pour certaines de ces vulnérabilités, il est quand même plus simple et plus sûr d'abandonner ces anciennes versions 1.0 et 1.1.

Désormais, la programmeuse ou le programmeur qui veut faire mincir son code en retirant TLS 1.0 et 1.1 peut, si des utilisateurs contestent, s'appuyer sur cette décision de l'IETF. Désormais, la règle est simple : le client ne doit pas proposer TLS 1.0 et 1.1, et s'il le fait le serveur ne doit pas l'accepter. Cela concerne de nombreux RFC, qui mentionnaient 1.0 et 1.1, et tous n'ont pas encore été mis à jour. Ainsi, le RFC 7562 est toujours d'actualité, simplement la mention qu'il fait de TLS 1.1 est réputée supprimée. De même, le RFC 7525, qui résume les bonnes pratiques d'utilisation de TLS doit désormais se lire en oubliant les quelques endroits où il cite encore TLS 1.1. D'autres RFC avaient déjà été abandonnés, comme par exemple le RFC 5101.

Donc, pour résumer les points pratiques de ce RFC (sections 4 et 5) :

  • N'utilisez pas TLS 1.0. Le client TLS ne doit pas le proposer dans son ClientHello, le serveur TLS ne doit jamais l'accepter.
  • N'utilisez pas TLS 1.1. Le client TLS ne doit pas le proposer dans son ClientHello, le serveur TLS ne doit jamais l'accepter.

Si vous êtes programmeu·r·se, virez le code de TLS 1.0 et 1.1 de vos logiciels. (OpenSSL a prévu de le faire en 2022.) Notez que certains protocoles récents comme Gemini ou DoH (RFC 8484) imposaient déjà TLS 1.2 au minimum.

Comme le note la section 7 du RFC, suivre les recommandations de sécurité exposées ici va affecter l'interopérabilité : on ne pourra plus communiquer avec les vieilles machines. J'ai à la maison une vieille tablette pour laquelle le constructeur ne propose pas de mise à jour logicielle et qui, limitée à TLS 1.0, ne peut d'ores et déjà plus se connecter à beaucoup de sites Web en HTTPS. L'obsolescence programmée en raison de la sécurité… Plus grave, des organisations peuvent être coincées avec une vieille version de TLS sur des équipements, par exemple de contrôle industriel, qu'on ne peut pas mettre à jour. (Lors des discussions à l'IETF sur ce RFC, des personnes avaient suggéré d'attendre que le niveau d'utilisation de TLS 1.0 et 1.1 tombe en dessous d'une certaine valeur, avant d'abandonner officiellement ces protocoles. L'IETF a finalement choisi une approche plus volontariste. Mais pensez aux établissements comme les hôpitaux, avec tous les systèmes contrôlés par des vieux PC pas mettables à jour.) Comme toujours en sécurité, il n'y a pas de solution parfaite, uniquement des compromis. Le site de test TLS https://www.ssllabs.com/ montre ici un site Web d'une banque qui continue à proposer TLS 1.0 et 1.1, ce qui baisse sa note globale mais est peut-être justifié par le désir de ne pas laisser tomber les clients qui ne peuvent pas facilement changer leur logiciel : labanquepostale-tls1.png

Au contraire, voici ce qu'affiche un Firefox récent quand on essaie de se connecter à un vieux site Web qui n'accepte toujours pas TLS 1.2 : cig-old-tls.png

À noter que DTLS 1.0 (RFC 4347) est également abandonné. Cela laisse DTLS 1.2, le 1.1 n'ayant jamais été normalisé, et le 1.3 n'étant pas prêt.

Les RFC 2246 (TLS 1.0) et RFC 4346 (TLS 1.1) ont été officiellement reclassifiés comme n'ayant plus qu'un intérêt historique. Le RFC 7507 est également déclassé, le mécanisme qu'il décrit n'étant utile qu'avec TLS 1.0 et 1.1.


Téléchargez le RFC 8996


L'article seul

RFC 9007: Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP)

Date de publication du RFC : Mars 2021
Auteur(s) du RFC : R. Ouazana (Linagora)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF jmap
Première rédaction de cet article le 23 mars 2021


Les avis de remise d'un message (MDN, Message Disposition Notification) sont normalisés dans le RFC 8098. Ce nouveau RFC normalise la façon de les gérer depuis le protocole d'accès au courrier JMAP (qui est, lui, dans les RFC 8620 et RFC 8621).

Un petit rappel sur JMAP : c'est un protocole générique pour accéder à des données distantes, qu'elles concernent la gestion d'un agenda ou celle du courrier. Il est normalisé dans le RFC 8620. Une extension spécifique, JMAP for Mail, décrit comment l'utiliser pour le cas du courrier (rôle pour lequel JMAP concurrence IMAP).

Quant à MDN (Message Disposition Notifications), c'est un format qui décrit des accusés de réception du courrier. Il a été spécifié dans le RFC 8098. Un MDN est un message structuré (en MIME, avec une partie de type message/disposition-notification) qui indique ce qui est arrivé au message. On peut donc envoyer un MDN en réponse à un message (c'est un accusé de réception, ou avis de remise), on peut demander l'envoi d'un tel MDN lorsqu'on envoie un message, on peut recevoir des MDN et vouloir les analyser, par exemple pour les mettre en rapport avec un message qu'on a envoyé.

Avant de manier les MDN, il faut les modéliser (section 2). Comme tout en JMAP, un MDN est un objet JSON comprenant entre autres les membres :

  • forEmailId : l'identifiant JMAP du message auquel se réfère ce MDN,
  • originalMessageId, le Message ID du message auquel se réfère ce MDN, à ne pas confondre avec l'identifiant JMAP,
  • includeOriginalMessage, qui indique qu'un envoyeur souhaite recevoir le message original dans les éventuels MDN,
  • disposition : voir le RFC 8098, section 3.2.6, pour cette notion. Elle indique ce qui est arrivé au message, et les conditions dans lesquelles l'action d'émission du MDN a été prise, par exemple automatiquement, ou bien par une action explicite de l'utilisateur.

L'objet JSON MDN sert à modéliser les MDN reçus mais aussi les options envoyées, comme la demande de génération de MDN par le receveur.

Pour envoyer un MDN, notre RFC introduit une nouvelle méthode JMAP, MDN/send. Pour analyser un MDN entrant, la méthode se nomme MDN/parse. Voici un exemple de MDN JMAP :

  
[[ "MDN/send", {
...
  "send": {
     ...
     "forEmailId": "Md45b47b4877521042cec0938",
     "subject": "Read receipt for: World domination",
     "textBody": "This receipt shows that the email has been
         displayed on your recipient's computer. There is no
         guaranty it has been read or understood.",
     "reportingUA": "joes-pc.cs.example.com; Foomail 97.1",
     "disposition": {
       "actionMode": "manual-action",
       "sendingMode": "mdn-sent-manually",
       "type": "displayed"
     },
     ...

On y voit l'identifiant du message concerné, et l'action qui a été entreprise : le destinataire a activé manuellement l'envoi du message, après avoir vu ledit message.

Et pour demander l'envoi d'un MDN lorsqu'on crée un message ? C'est la méthode Email/set du RFC 8621 qui permet de créer le message. On doit juste ajouter l'en-tête Disposition-Notification-To: du RFC 8098 :

[[ "Email/set", {
     "accountId": "ue150411c",
     "create": {
        ...
        "header:Disposition-Notification-To:asText": "joe@example.com",
        "subject": "World domination",
...
  

Comme un serveur JMAP annonce ses capacités lors de la connexion (RFC 8620, section 2), notre RFC ajoute une nouvelle capacité, urn:ietf:params:jmap:mdn, ce qui permet à un serveur de dire qu'il sait gérer les MDN. Elle est enregistrée à l'IANA.

Question mise en œuvre de JMAP qui gère les MDN, il y a le serveur Cyrus, voir ce code, et aussi Apache James.

Merci à Raphaël Ouazana pour sa relecture.


Téléchargez le RFC 9007


L'article seul

Fiche de lecture : La fabuleuse histoire de l'invention de l'écriture

Auteur(s) du livre : Silvia Ferrara
Éditeur : Seuil
978-2-02-146412-2
Publié en 2021
Première rédaction de cet article le 22 mars 2021


L'écriture est un sujet passionnant, sur lequel beaucoup a déjà été écrit. Un livre de plus sur cette géniale invention et ses débuts ? Pas tout à fait, ce livre n'est pas un cours, ou un livre de vulgarisation, c'est une suite de réflexions de l'auteure sur la façon dont l'écriture a (peut-être) été inventée et sur le travail de ceux et celles qui essaient de jeter quelques lumières sur ce processus d'invention.

Comme vous le savez, il y a quatre (ou cinq ? ou six ? ou seulement trois ?) inventions indépendantes de l'écriture, en Égypte, en Mésopotamie, en Chine et en Méso-Amérique. Le processus est donc, sinon courant, du moins pas exceptionnel, et rentre donc tout à fait dans les capacités humaines. Mais comment en est-on arrivé là ? Quelles ont été les prémisses ? Typiquement, on part de petits dessins, puis on les abstrait de plus en plus et on finit par avoir une écriture. (Le cas de l'écriture chinoise est plus compliqué car on n'a pas retrouvé les étapes préalables.) L'excellent dessin p. 224 nous donne une idée de comment ça a pu se passer. Le processus étant continu, il est parfois difficile de dire à partir de quand on a affaire à une « vraie » écriture. C'est d'ailleurs un des obstacles qui se posent aux déchiffreurs d'écritures inconnues : cet ensemble d'émojis est-il une vraie écriture ? L'aveuglement des déchiffreurs, leur tendance à s'illusionner, peut les aider ou les freiner (comme dans le cas de l'écriture maya, longtemps tenue, à tort, pour « juste des dessins »).

L'auteure nous fait voyager, au rythme de sa fantaisie, de la Crète (sa spécialité scientifique) à l'île de Pâques en passant par le Mexique. Vous y trouverez les écritures inconnues les plus célèbres (le linéaire A ou l'IVS) et les Mystères Mystérieux comme évidemment le disque de Phaistos. L'auteure suggère d'ailleurs de ne pas passer trop de temps sur ce disque : vu le nombre réduit de caractères, elle estime qu'il n'y a aucune chance qu'on le déchiffre un jour. (Au fait, si vous voulez vous informer sur toutes les écritures connues, je vous recommande « The World's Writing Systems ».)

Mais la partie la plus intéressante concerne l'évolution des écritures, les mécanismes à l'œuvre, les tendances, les « lois » de l'évolution. Si certaines écritures sont très stables (à part à leur origine), d'autres ont changé, ont grandi, parfois ont disparu.

De même que M. Bidouille reçoit régulièrement des messages de gens qui ont découvert le mouvement perpétuel, de même que les chercheurs en réseaux informatiques sont agacés par les personnes qui ont trouvé la FUSSP, la solution au problème du spam, les chercheuses et chercheurs en écritures anciennes ont des lettres annonçant le déchiffrement du chypro-minoen ou celui du manuscrit de Voynich. L'auteure leur donne (p. 251) dix conseils très instructifs si vous voulez mieux comprendre comment s'analysent les écritures. Et le dixième conseil est « ne m'écrivez pas » (la quasi-totalité de ces annonces sont bidon).


L'article seul

Fiche de lecture : How the Internet really works

Auteur(s) du livre : Article 19, Catnip
Éditeur : No Starch Press
978-1-7185-0029-7
Publié en 2021
Première rédaction de cet article le 21 mars 2021


L'Internet, c'est important, toute notre vie et nos activités s'y passent, mais c'est compliqué. Tout le monde ne comprend pas comment ça marche. En fait, même les professionnels de l'informatique ne savent pas forcément. C'est ennuyeux car cette ignorance laisse les acteurs dominants dicter les règles et faire ce qu'ils veulent. Il serait préférable que les citoyen·nes puissent accéder à un minimum de compréhension de fonctionnement du réseau. C'est ce que propose ce livre.

D'abord, un point important : contrairement à la grande majorité des reportages, documentaires, livres, articles prétendant expliquer le fonctionnement de l'Internet, celui-ci est écrit par des gens qui connaissent et savent de quoi ils parlent. (Notez que deux des auteurs, Niels ten Oever et Corinne Cath, sont les auteurs du RFC 8280). Vous n'y trouverez pas d'erreur technique (ou pas beaucoup), d'explication bâclée ou de raccourcis journalistiques, genre « l'ICANN est le régulateur mondial d'Internet ».

Mais être correct ne suffit pas, il faut encore pouvoir expliquer des concepts complexes et un réseau dont le moins qu'on puisse dire est qu'il n'est pas évident à assimiler. Les auteur·es ont beaucoup travaillé l'aspect pédagogique. (Et, oui, il y a des dessins, et c'est un chat qui explique.) Le livre est relativement court, mais complet, et présente bien le sujet. Il sera très utile à tous les gens qui font de l'EMI, de la formation à la littératie numérique et autres activités d'éducation. Le livre couvre IP, TCP, DNS, BGP, HTTP, mais aussi le chiffrement, les points d'échange, l'allocation d'adresses IP, etc.

Je l'ai dit, les auteur·es sont impliqué·es dans les activités politiques de l'Internet (ce qu'on nomme « gouvernance de l'Internet », mais, bon, c'est juste de la politique sous un nouveau nom). Le livre insiste donc sur les aspects qui touchent aux droits humains fondamentaux comme le droit à la vie privée, la lutte contre la censure, et bien sûr les mécanismes de décision dans l'Internet : qui fait les choix ?

Sur cette question du pouvoir, le livre décrit également le fonctionnement d'organismes qui contribuent à façonner l'Internet tel qu'il est (comme l'IETF) et encourage la participation de tous et toutes à ces organismes, pour faire bouger les choses dans le bon sens.


L'article seul

Deux mots sur les NFT

Première rédaction de cet article le 13 mars 2021


Je suis la mode, tout le monde parle des NFT donc je m'y mets aussi. Comment ça marche et ça sert à quoi ?

L'idée de base s'inspire de l'humoriste Alphonse Allais. Un de ses personnages a déposé un brevet pour « enlever au caoutchouc cette élasticité qui le fait impropre à tant d'usages. Au besoin, il le rend fragile comme du verre. ». Les données numériques ont la propriété de pouvoir être copiées à un coût très bas, diffusées largement (grâce à l'Internet) et sans priver le détenteur originel de ces données. Les NFT visent à supprimer cette propriété et à faire des données numériques uniques et non copiables. Pourquoi donc, à part pour rendre hommage à Alphonse Allais ? Parce que cette rareté artificiellement créée permet de mettre en place un marché d'objets uniques, donc chers.

L'idée est que cela permettra des ventes d'objets numériques, ce qui intéresse particulièrement le marché de l'art. Ainsi, il y a deux jours, une vente d'une œuvre d'art (ou plutôt d'un NFT) a rapporté des millions d'euros. Mais l'idée est relativement ancienne, les premiers NFT populaires ayant été les CryptoKitties.

Mais comment peut-on transformer un fichier numérique en un truc unique et non copiable ? Je vous le dis tout de suite, on ne peut pas. C'est en fait le NFT dont on peut « prouver » le propriétaire (et l'unicité), pas l'œuvre d'art elle-même. Descendons un peu dans la technique. Fondamentalement, un NFT (Non-Fungible Token) est un certificat numérique, rassemblant un condensat cryptographique de l'œuvre d'art et une signature par une place de marché. Ce certificat est ensuite placé sur une chaîne de blocs (en général Ethereum) où un contrat automatique permettra de gérer les transactions sur ce certificat, et donc de déterminer de manière fiable le propriétaire. Sur cette idée de base, on peut ajouter diverses améliorations, comme le versement automatique d'un pourcentage des ventes successives au créateur de l'œuvre.

On le voit, le NFT est une idée simple mais qui ne garantit pas grand'chose : si la place de marché est sérieuse, et que le contrat automatique est correct, le NFT garantit uniquement :

  • que la place de marché a certifié l'œuvre d'art,
  • qu'il n'y a à un moment donné, qu'un seul propriétaire (la traçabilité est le point fort des chaînes de blocs).

C'est tout. Les places de marché peuvent générer n'importe quel NFT (il faut leur faire une confiance aveugle), le fichier original peut toujours être copié. Le cours d'un NFT, comme celui de toute monnaie ou bien, dépend uniquement de la valeur qu'on lui accorde. Comme l'argent, le NFT est « une illusion partagée ».

Pour les technicien·ne·s, fabriquons un NFT pour voir. Je prends une image de chat. Elle n'est pas de moi mais cela n'est pas un problème. Calculons un condensat cryptographique avec SHA-256 :

% sha256sum Cat_November_2010-1a.jpg
59ec9bf12a5b63e0913e986b9566b96228c9f8921fda4fb87bf2a7f9acff3dd2  Cat_November_2010-1a.jpg
  

Puis ajoutons quelques métadonnées et signons le tout en OpenPGP (RFC 4880) :

% gpg --sign --armor > Cat_November_2010-1a.asc 
gpg: using "CCC66677" as default secret key for signing
Je soussigné, Stéphane Bortzmeyer, certifie que cette image représente un chat.
https://commons.wikimedia.org/wiki/File:Cat_November_2010-1a.jpg
59ec9bf12a5b63e0913e986b9566b96228c9f8921fda4fb87bf2a7f9acff3dd2  Cat_November_2010-1a.jpg
  

Le fichier Cat_November_2010-1a.asc va alors contenir une signature, vérifiable :


% gpg --decrypt Cat_November_2010-1a.asc 
Je soussigné, Stéphane Bortzmeyer, certifie que cette image représente un chat.
https://commons.wikimedia.org/wiki/File:Cat_November_2010-1a.jpg
59ec9bf12a5b63e0913e986b9566b96228c9f8921fda4fb87bf2a7f9acff3dd2  Cat_November_2010-1a.jpg
gpg: Signature made Sat Mar 13 13:10:27 2021 CET
gpg:                using RSA key C760CAFC6387B0E8886C823B3FA836C996A4A254
gpg: Good signature from "Stéphane Bortzmeyer (Main key) <stephane@bortzmeyer.org>" [unknown]
...

  

En fait, vu la façon dont fonctionnent les signatures OpenPGP, j'aurais pu me passer de l'étape du calcul du condensat. C'était juste pour illustrer le principe des NFT.

Bref, un NFT est un pointeur vers l'œuvre, pas l'œuvre. Contrairement à l'adage bien connu, avec les NFT, quand on montre la lune, il faut regarder le doigt. Et j'emprunte à Framasky une blague de programmeur :

/*  À vendre, pointeur, peu servi */
char *my_nft;
  

Du fait que le NFT n'est qu'un pointeur, il faut penser à stocker l'œuvre originale proprement (avec sauvegardes).

Il reste bien sûr à tout mettre sur une chaîne de blocs, sous le contrôle d'un contrat automatique qui se chargera entre autres des achats successifs. Je n'ai rien publié, pour éviter de payer des frais. (Prudence si vous entendez que les NFT permettront aux artistes de gagner enfin de l'argent. La seule certitude, avec les NFT, c'est que l'artiste va payer pour publier le NFT. Son NFT sera-t-il acheté ? Il n'y a évidemment aucune certitude. Tout le monde n'est pas Grimes ou Jack Dorsey.) Si j'avais publié les métadonnées signées plus haut, cela aurait été un vrai NFT. Je vous en aurais bien montré un vrai, mais la plupart des places de marché, tout en se réclamant bien fort de la « blockchain » ne font pas preuve de transparence et ne donnent pas beaucoup de détails sur, par exemple, l'adresse dans la chaîne où se trouve le NFT.

Notez qu'il n'existe pas de normes sur les NFT, chaque place de marché a la sienne. Tout au plus existe-t-il des normes sur l'interface des NFT (et d'autres jetons), comme ERC-721, qui standardise des opérations communes à tous les NFT, comme ownerOf (renvoie le propriétaire actuel) ou Transfer (vente par le propriétaire).

Il est tout à fait mensonger, comme on le lit souvent, de prétendre que le NFT garantit « l’authenticité ». N'importe qui, pas seulement l'auteur de l'œuvre, peut générer un NFT, et cela s'est déjà produit sans l'autorisation de l'auteur. (Pour celles et ceux qui ne connaissent pas, David Revoy est l'auteur de Pepper & Carrot).

Quelle confiance faire à un NFT ? Pour la première étape, la génération du NFT, il faut faire confiance à la place de marché. Pour la seconde, les opérations de vente et de revente successives, on a les garanties qu'offre la chaine de blocs et le contrat automatique.

Est-ce une escroquerie ? S'il y a des prétentions malhonnêtes (comme l'authenticité de l'œuvre) dans le discours marketing sur les NFT, d'un autre côté, on peut dire que vendre du virtuel n'a rien de mal en soi, cela se fait tout le temps, entre autre dans le marché de l'art, qui est souvent du grand n'importe quoi (mon projet actuel est de laisser un fromage dehors, d'attendre qu'il se couvre de moisissure et de le vendre ensuite comme œuvre d'art). Si des gens achètent, et sont bien informés et conscients de ce qu'ils achètent, pourquoi pas ?

Quelques lectures en plus :


L'article seul

Un exemple de nom de domaine inhabituel (IDN et émojis)

Première rédaction de cet article le 12 mars 2021


C'est vendredi, bientôt le week-end, détendons-nous avec un nom de domaine rigolo, 📪.ws. Oui, vous avez déjà vu des noms de domaines avec des émojis. Mais celui-ci a une particularité.

Un petit retour en arrière s'impose. D'abord, contrairement à une légende répandue, le DNS, le protocole qui résoud les noms de domaine en informations concrètes, ce protocole n'est pas limité à l'ASCII, encore moins au sous-ensemble LDH (Letters-Digits-Hyphen) d'ASCII. On peut mettre n'importe quel octet dans un nom de domaine. Toutefois, le faire peut entrainer des surprises, parce qu'il n'existe pas d'encodage standard (si le DNS était créé aujourd'hui, UTF-8 serait l'encodage standard mais, à l'époque, ce n'était pas aussi clair) et surtout parce qu'il n'y a pas de règles de canonicalisation (depuis, le RFC 5198 fournirait certainement une solution mais, là encore, c'est trop tard). Et, surtout, pas mal d'applications (mais, répétons-le, pas le DNS lui-même) seraient surprises de recevoir des noms qui ne sont pas en ASCII. C'est pour ces raisons (que j'ai détaillées dans un autre article) que, si on veut de l'Unicode dans les noms de domaine (que l'on nommera alors IDN), on doit utiliser la norme décrite dans les RFC 5890 et suivants. Cette norme impose notamment :

Mais il y a les normes techniques (les RFC) et il y a la réalité. Il n'existe pas de police de l'Internet qui ferait régner l'ordre normatif et fusillerait les contrevenants qui violent les normes techniques. Si l'ICANN impose ce respect des normes dans les TLD qu'elle contrôle, ce n'est pas le cas dans les autres TLD. Donc, on voit des TLD (comme .ws) autoriser des noms théoriquement invalides comme i❤️tacos.ws.

Mais revenons à notre 📪.ws. Si nous essayons de résoudre ce nom en adresse IP avec l'outil dig (il faut une version compilée avec la gestion des IDN) :

% dig  A 📪.ws         
dig: 'xn--gu8h.ws.' is not a legal IDNA2008 name (string contains a disallowed character), use +noidnout
  

dig a protesté, et à juste titre, la norme (IDNA2008 : norme IDN in Applications, version 2008, c'est celle du RFC 5890) ne permettant pas les émojis. Comme dig nous le suggère, essayons avec l'option +noidnout qui lui dit de ne pas afficher d'Unicode en sortie :


% dig +noidnout A 📪.ws
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10659
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
;; QUESTION SECTION:
;xn--gu8h.ws.		IN A

Cette fois, on a une réponse (status: NOERROR) mais pas de données (ANSWER: 0). C'est parce que dig, comme il l'affiche dans sa répétition de la question, a converti en Punycode, comme dicté par la norme, et qu'il n'y avait pas de données pour le nom en Punycode. Maintenant, débrayons complètement IDN et essayons le nom dans son encodage natif ce qui, sur ma machine, est UTF-8 :


% dig +noidnout +noidnin A 📪.ws
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45985
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 9, ADDITIONAL: 7
...
;; QUESTION SECTION:
;\240\159\147\170.ws.	IN A

;; ANSWER SECTION:
\240\159\147\170.ws.	300 IN A 64.70.19.203
...

  

Cette fois, on a des données (et même deux, car il y a aussi la signature DNSSEC), et on récupère une adresse IP, 64.70.19.203. La question (\240\159\147\170.ws) est le nom en UTF-8, \240\159\147\170.ws étant bien la représentation en UTF-8 du caractère Unicode U+1F4EA, l'émoji « boite aux lettres ».

C'est donc un cas assez rare : un IDN qui a des données pour l'encodage UTF-8 mais rien en Punycode. (J'ai trouvé des noms qui avaient les deux.) À cause de cela, il est très probable que l'URL http://📪.ws/ ne marchera pas dans votre navigateur (qui, sans doute, suit la norme technique fidèlement).

John Shaft m'a mis sur la piste de l'explication de cette étrangeté. Le domaine encodé en UTF-8 n'existe pas, donc les serveurs faisant autorité pour .ws devraient répondre NXDOMAIN (No Such Domain). Mais .ws a un joker dans la zone et répond donc pour tous les noms inexistants avec cette adresse IP, 64.70.19.203.

Merci à Sean Conner pour avoir attiré mon attention sur ce domaine, dans le cadre d'une discussion sur le projet Gemini. Victor Héry m'a appris ensuite que ce nom de domaine faisait partie du projet Mailoji, une pure escroquerie (car les noms vendus aux pigeons ne marcheront que dans un environnement fermé et contrôlé par le vendeur).


L'article seul

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

Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.

Un article de ce blog au hasard.