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.


Fiche de lecture : Twitter & les gaz lacrymogènes

Auteur(s) du livre : Zeynep Tufekci
Éditeur : C&F Éditions
978-2-915825-95-4
Publié en 2019
Première rédaction de cet article le 10 octobre 2019


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

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

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

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

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

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

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

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

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

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


L'article seul

Version 12 d'Unicode

Première rédaction de cet article le 8 octobre 2019


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

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

ucd=> SELECT count(*) AS Total FROM Characters;
 total  
--------
 137994

Combien de caractères sont arrivés avec la version 12 ?

ucd=> SELECT version,count(version) FROM Characters GROUP BY version ORDER BY version::float;
...
 10.0    |  8518
 11.0    |   684
 12.0    |   554
 12.1    |     1

554 nouveaux, cette version 12 est très modérée. Quels sont ces nouveaux caractères ?

ucd=> SELECT To_U(codepoint) AS Codepoint, name FROM Characters WHERE version='12.0';
 codepoint |                                    name                                    
-----------+----------------------------------------------------------------------------
...
 U+1FA70   | BALLET SHOES
 ...
 U+2E4F    | CORNISH VERSE DIVIDER
 ...
 U+A7C3    | LATIN SMALL LETTER ANGLICANA W
 ...
 U+10FE0   | ELYMAIC LETTER ALEPH
 U+10FE1   | ELYMAIC LETTER BETH
 U+10FE2   | ELYMAIC LETTER GIMEL
 ...
 U+1E100   | NYIAKENG PUACHUE HMONG LETTER MA
 U+1E101   | NYIAKENG PUACHUE HMONG LETTER TSA
 U+1E102   | NYIAKENG PUACHUE HMONG LETTER NTA
 ...
 U+1F6D5   | HINDU TEMPLE
 U+1F6FA   | AUTO RICKSHAW
 ...
 U+1F97B   | SARI
 ...
 U+1F9A7   | ORANGUTAN
 ...
 U+1F9BB   | EAR WITH HEARING AID
 U+1F9BC   | MOTORIZED WHEELCHAIR
 U+1F9BD   | MANUAL WHEELCHAIR
 ...
 U+1FA30   | WHITE CHESS KNIGHT ROTATED TWO HUNDRED TWENTY-FIVE DEGREES
 U+1FA31   | BLACK CHESS KNIGHT ROTATED TWO HUNDRED TWENTY-FIVE DEGREES

Parmi les emojis de cette version, beaucoup concernent l'Inde, comme le sari ou le rickshaw. Beaucoup de caractères liés au handicap ont été créés, ainsi, mais c'est plus anecdotique, que beaucoup de caractères pour le jeu d'échecs. On trouve aussi des caractères étonnants comme U+2E4F, qui ne sert apparemment qu'à la poésie cornouaillaise. Et il y a bien sûr de nouvelles écritures comme l'élymaïque ou le nyiakeng puachue hmong. Même l'alphabet latin voit arriver de nouveaux caractères comme le U+A7C3.

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

ucd=> SELECT To_U(codepoint) AS Codepoint, name FROM Characters WHERE version='12.1';
 codepoint |         name          
-----------+-----------------------
 U+32FF    | SQUARE ERA NAME REIWA

Une version d'Unicode uniquement pour introduire un caractère japonais permettant de noter l'ère Reiwa… (Merci à John Shaft pour avoir repéré celui-là.)

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

 ucd=> SELECT count(*) FROM Characters  WHERE category IN ('Sm', 'Sc', 'Sk', 'So');
 count 
-------
  7564

Ou, en plus détaillé, et avec les noms longs des catégories :

ucd=> SELECT description,count(category) FROM Characters,Categories WHERE Categories.name = Characters.category AND category IN ('Sm', 'Sc', 'Sk', 'So') GROUP BY category, description;
   description   | count 
-----------------+-------
 Modifier_Symbol |   123
 Other_Symbol    |  6431
 Math_Symbol     |   948
 Currency_Symbol |    62

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


L'article seul

Fiche de lecture : Une histoire populaire de la France

Auteur(s) du livre : Gérard Noiriel
Éditeur : Agone
978-2-7489-0301-0
Publié en 2018
Première rédaction de cet article le 7 octobre 2019


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

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

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

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

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

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

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

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

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

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


L'article seul

Documentation technique de mon résolveur DoH

Première rédaction de cet article le 30 septembre 2019


Vous voulez connaitre tous les détails techniques du fonctionnement d'un résolveur public DoH (DNS sur HTTPS) ? Voici comment fonctionne le service https://doh.bortzmeyer.fr/.


L'article complet

Fiche de lecture : Permanent record

Auteur(s) du livre : Edward Snowden
Éditeur : MacMillan
9781529035667 90100
Publié en 2019
Première rédaction de cet article le 29 septembre 2019


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

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

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

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

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

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

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

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

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


L'article seul

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

Première rédaction de cet article le 24 septembre 2019


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

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

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

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

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

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


L'article seul

Le protocole DoH et pourquoi il y a tant de discussions

Première rédaction de cet article le 24 septembre 2019


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

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

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

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

Articles intéressants sur le sujet :

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


L'article seul

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

Première rédaction de cet article le 22 septembre 2019
Dernière mise à jour le 24 septembre 2019


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

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

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

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

Ce résolveur :

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

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


L'article seul

Using the CowBoy HTTP server from an Elixir program

First publication of this article on 17 September 2019


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

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

% mix new myserver 
...
Your Mix project was created successfully.
    

I then add CowBoy dependencies to the mix.exs file:

 defp deps do                                                                                                                      
    [                                                                                                                               
      {:cowboy, "~> 2.6.0"}                                                                                                         
    ]                                                                                                                               
 end        
    

(Remember that CowBoy changes a lot, and a lot of CowBoy examples you find online are for old versions. Version number is important. I used 2.6.3 for the examples here.) Then, get the dependencies:

% mix deps.get
...
  cowboy 2.6.3
  cowlib 2.7.3
  ranch 1.7.1
...
    

We can now fill lib/myserver.ex with the main code:

 defmodule Myserver do                                                                                                               
                                                                                                                                    
  def start() do                                                                                                                    
    dispatch_config = build_dispatch_config()                                                                                       
    { :ok, _ } = :cowboy.start_clear(:http,                                                                                         
      [{:port, 8080}],                                                                                                              
      %{ env: %{dispatch: dispatch_config}}                                                                                         
    )                                                                                                                               
  end                                                                                                                               
                                                                                                                                    
  def build_dispatch_config do                                                                                                      
    :cowboy_router.compile([                                                                                                        
      { :_,                                                                                                                         
        [                                                                                                                           
          {"/", :cowboy_static, {:file, "/tmp/index.html"}}
        ]}                                                                                                                          
    ])                                                                                                                              
  end                                                                                                                               
                                                                                                                                    
end                
    

And that's all. Let's test it:

      
% iex -S mix
Erlang/OTP 22 [erts-10.4.4] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1]

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

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

iex(2)> 
      
    

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

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

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

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

You can now start from this and improve:

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

L'article seul

IPv6 sur un VPS Arch Linux chez OVH

Première rédaction de cet article le 16 septembre 2019
Dernière mise à jour le 30 septembre 2019


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

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

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

ip -6 addr add 2001:41d0:302:2200::180/128 dev eth0
ip -6 route add 2001:41d0:302:2200::1 dev eth0
ip -6 route add default via 2001:41d0:302:2200::1
    

Cette façon de faire est un peu bizarre, avec ce préfixe de longueur 128 (normalement, cela devrait être 64), qui oblige à mettre une route vers… le routeur, mais c'est cohérent avec ce qui est fait par défaut pour IPv4. Une solution plus propre aurait été :

ip -6 addr add 2001:41d0:5fa1:b49::180/64 dev eth0
ip -6 route add default via 2001:41d0:5fa1:b49::1
    

Et cela marche mais je ne suis pas sûr que cela permette de joindre les machines du même réseau.

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

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

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

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

[Install]
WantedBy=multi-user.target
    

J'active ce service avec systemctl enable ipv6 et, au redémarrage de la machine, tout va bien et on a IPv6.


L'article seul

« Entrée libre » à Quimper

Première rédaction de cet article le 12 septembre 2019


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

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

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

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


L'article seul

L'avenir de Salto

Première rédaction de cet article le 10 septembre 2019


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


L'article seul

RFC 8620: The JSON Meta Application Protocol (JMAP)

Date de publication du RFC : Juillet 2019
Auteur(s) du RFC : N. Jenkins (Fastmail), C. Newman (Oracle)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF jmap
Première rédaction de cet article le 6 septembre 2019


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

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

Parmi les concepts techniques importants de JMAP, notons :

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

Du fait de l'utilisation de JSON, il est bon de réviser le vocabulaire JSON, notamment le fait qu'un objet (object) JSON est en fait un dictionnaire.

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

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

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


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

    

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

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

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

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

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

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

    

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

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

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

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


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

    

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

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

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


Téléchargez le RFC 8620


L'article seul

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

Date de publication du RFC : Septembre 2019
Auteur(s) du RFC : J. Dickinson (Sinodun), J. Hague (Sinodun), S. Dickinson (Sinodun), T. Manderson (ICANN), J. Bond (ICANN)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 4 septembre 2019


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

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

% tcpdump -w /tmp/dns.pcap port 53
    

Le fichier produit (ici, sur un serveur faisant autorité pour eu.org), au format pcap, contient les requêtes DNS et les réponses, et peut être analysé avec des outils comme tcpdump lui-même, ou comme Wireshark. Il y a aussi des outils spécifiques au DNS comme PacketQ ou comme dnscap. Ici, avec tcpdump :

% tcpdump -n -r /tmp/dns.pcap      
15:35:22.432746 IP6 2001:db8:aa:101::.40098 > 2400:8902::f03c:91ff:fe69:60d3.53: 41209% [1au] A? tracker.torrent.eu.org. (51)
15:35:22.432824 IP6 2400:8902::f03c:91ff:fe69:60d3.53 > 2001:db8:aa:101::.40098: 41209- 0/4/5 (428)
    

Au lieu des outils tous faits, on peut aussi développer ses propres programmes en utilisant les nombreuses bibliothèques qui permettent de traiter du pcap (attention si vous analysez du trafic Internet : beaucoup de paquets sont mal formés, par accident ou bien délibérément, et votre analyseur doit donc être robuste). C'est ce que font en général les chercheurs qui analysent les données DITL.

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

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

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

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

  • La capture des données se fait sur le serveur lui-même, pas sur un équipement réseau,
  • Les données seront stockées localement, au moins temporairement, puis analysées sur une autre machine.

Donc, il est crucial de minimiser la taille des données récoltées. Mais il faut aussi faire attention à la charge que représente la collecte : le serveur de noms a pour rôle de répondre aux requêtes DNS, la collecte est secondaire, et ne doit donc pas consommer trop de ressources CPU.

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

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

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

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

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

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

  • Il faut déterminer si une donnée est présente ou pas, et ne pas supposer qu'elle l'est forcément,
  • Il peut être utile de déterminer si une donnée manquante était absente dès le début, ou bien si elle a été délibérément ignorée par le système de capture. Si un message ne contient pas d'option EDNS (RFC 6891), était-ce parce que le message n'avait pas cette option, ou simplement parce qu'on ne s'y intéressait pas et qu'on ne l'a pas enregistrée ?

C-DNS permet donc d'indiquer quels éléments des données initiales ont été délibérément ignorés. Cela permet, par exemple, à un programme de lecture de fichiers C-DNS de savoir tout de suite si le fichier contient les informations qu'il veut.

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

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

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

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

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

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

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

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

  • Apache Avro, trop complexe car on ne peut lire les données qu'en traitant le schéma,
  • Protocol Buffers, qui a le même problème,
  • JSON (RFC 8259), qui n'est pas un format binaire, mais qui a été ajouté pour compléter l'étude.

Cette annexe décrit également le résultat de mesures sur la compression obtenue avec divers outils, sur les différents formats. C-DNS n'est pas toujours le meilleur, mais il est certainement, une fois comprimé, plus petit que pcap, et plus simple à mettre en œuvre qu'Avro ou Protocol Buffers.

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

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

aptitude install libpcap-dev libboost1.67-all-dev liblzma-dev libtins-dev
git clone https://github.com/dns-stats/compactor.git
cd compactor
sh autogen.sh
autoconf
automake
./configure
make
    

Et après, on peut l'utiliser pour transformer du C-DNS en pcap et réciproquement. J'ai créé un fichier pcap d'un million de paquets avec tcpdump sur un serveur faisant autorité, avec tcpdump -w dns.pcap -c 1000000 port 53. Puis :

%   ./compactor -o /tmp/dns.cdns  /tmp/dns.pcap
    

Et en sens inverse (reconstituer le pcap) :

%  ./inspector /tmp/dns.cdns
    

Cela nous donne :

% ls -lth /tmp/dns*                        
-rw-r--r-- 1 stephane stephane  98M Jul 31 08:13 /tmp/dns.cdns.pcap
-rw-r--r-- 1 stephane stephane 3.2K Jul 31 08:13 /tmp/dns.cdns.pcap.info
-rw-r--r-- 1 stephane stephane  27M Jul 31 07:27 /tmp/dns.cdns
-rw-r--r-- 1 root     root     339M Jul 30 20:05 /tmp/dns.pcap
    

Notez que dns.cdns.pcap est le pcap reconstitué, on remarque qu'il est plus petit que le pcap original, certaines informations ont été perdues, comme les adresses MAC. Mais il reste bien plus gros que la même information stockée en C-DNS. Le /tmp/dns.cdns.pcap.info nous donne quelques informations :

% cat /tmp/dns.cdns.pcap.info
CONFIGURATION:
  Query timeout        : 5 seconds
  Skew timeout         : 10 microseconds
  Snap length          : 65535
  Max block items      : 5000
  File rotation period : 14583
  Promiscuous mode     : Off
  Capture interfaces   : 
  Server addresses     : 
  VLAN IDs             : 
  Filter               : 
  Query options        : 
  Response options     : 
  Accept RR types      : 
  Ignore RR types      : 

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

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

Téléchargez le RFC 8618


L'article seul

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

Date de publication du RFC : Mai 2019
Auteur(s) du RFC : M. Nottingham
Chemin des normes
Première rédaction de cet article le 3 septembre 2019


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

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

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

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

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

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

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

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

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

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

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

Téléchargez le RFC 8615


L'article seul

RFC 8624: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

Date de publication du RFC : Juin 2019
Auteur(s) du RFC : P. Wouters (Red Hat), O. Sury (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 2 septembre 2019


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

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

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

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

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

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

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

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

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

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

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

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

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


Téléchargez le RFC 8624


L'article seul

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

Date de publication du RFC : Mai 2019
Auteur(s) du RFC : S. Hollenbeck (Verisign Labs), R. Carney (GoDaddy)
Pour information
Première rédaction de cet article le 1 septembre 2019
Dernière mise à jour le 4 septembre 2019


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

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

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

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

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

    

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

% curl https://rdap.blacknight.com/domain/blacknight.com | jq .  
...
          [
            "fn",
            {},
            "text",
            "Blacknight Internet Solutions Ltd."
          ],
          [
            "adr",
            {
              "cc": "IE"
            },
...
          [
            "contact-uri",
            {},
            "uri",
            "https://whois.blacknight.com/contact.php?fqdn=blacknight.com&contact_type=owner"
          ]
    

On a bien un usage de ces extensions dans le monde réel (merci à Patrick Mevzek pour ses remarques et ajouts).


Téléchargez le RFC 8605


L'article seul

RFC 8612: DDoS Open Threat Signaling (DOTS) Requirements

Date de publication du RFC : Mai 2019
Auteur(s) du RFC : A. Mortensen (Arbor Networks), T. Reddy (McAfee), R. Moskowitz (Huawei)
Pour information
Réalisé dans le cadre du groupe de travail IETF dots
Première rédaction de cet article le 22 août 2019


Les attaques par déni de service, et notamment les dDoS (distributed Denial of Service), sont une des principales plaies de l'Internet. Le projet DOTS (DDoS Open Threat Signaling) à l'IETF vise à développer un mécanisme de signalisation permettant à des acteurs de la lutte anti-dDoS d'échanger des informations et de se coordonner, même lorsque l'attaque fait rage. Par exemple, un mécanisme DOTS permettra à un client d'un service de traitement des attaques de demander à son fournisseur d'activer le filtrage anti-dDoS. Ce RFC est le premier du projet : il décrit le cahier des charges.

Ces attaques par déni de service (décrites dans le RFC 4732) peuvent être utilisées à des fins financières (racket), lors d'affrontements inter-étatiques (comme dans le cas estonien souvent cité), à des fins de censure contre des opposants politiques. Le risque est particulièrement élevé pour les « petits ». En effet, beaucoup d'attaques par déni de service reposent sur la taille : par exemple, l'attaquant envoie tellement d'octets qu'il sature la ou les connexions Internet de sa victime. La seule solution est alors de louer un tuyau plus gros, ce qui n'est pas toujours financièrement possible. Les attaques dDoS favorisent donc les plus riches. Aujourd'hui, par exemple, un petit hébergeur Web a le plus grand mal à faire face à d'éventuelles attaques, ce qui rend difficile l'hébergement associatif et/ou décentralisé. Les attaques par déni de service ont donc des conséquences bien au-delà des quelques heures d'indisponibilité du service : elles encouragent la centralisation des services, puisqu'il faut être gros pour encaisser le choc. C'est ainsi qu'aujourd'hui beaucoup d'organisations sont chez Cloudflare, dépendant de cette société privée étatsunienne pour leur « protection ». On est dans l'équivalent moderne de la relation féodale au Moyen-Âge : le paysan seul, ou même le village, est trop vulnérable, il doit chercher la protection d'un seigneur, en échange de sa soumission.

Il est très difficile de se protéger contre les attaques par déni de service. Et le projet DOTS ne va pas proposer de solution magique, uniquement des mécanismes de cooordination et d'échange en cas d'attaque. La réponse à une attaque dDoS consiste typiquement à examiner les paquets entrants, et à jeter ceux qui semblent faire partie de l'attaque. (Voir par exemple mon article sur le filtrage.) Il faut bien sûr le faire le plus tôt possible. Si vous êtes connecté à l'Internet par un lien de capacité 1 Gb/s, et que l'attaquant arrive à le saturer par les paquets qu'il envoie, trier les paquets de votre côté ne servira à rien, cela serait trop tard ; ils doivent être triés en amont, par exemple chez votre opérateur. Et, évidemment, trier n'est pas trivial, les paquets ne sont pas marqués comme participant à l'attaque (sauf si on utilise le RFC 3514, mais regardez sa date de publication). Il y aura donc toujours des faux positifs, des paquets innocents jetés. (Pour un exemple de solution anti-dDoS, voir le VAC d'OVH, et les nombreux articles qui lui ont été consacrés.) En 2019, beaucoup d'organisations ne font plus ce tri elles-mêmes (par manque de moyens financiers, et surtout humains) mais sous-traitent à un fournisseur spécialisé (comme Arbor, pour lequel travaille un des auteurs du RFC). On envoie le trafic vers ce fournisseur, par des astuces DNS ou BGP, il le trie, et vous renvoie ce qui lui semble inoffensif. Ce tri se nomme en anglais scrubbing. Ces fournisseurs sont donc un élement critique, par exemple parce qu'ils voient passer tout votre trafic. En général, on active ce service à la demande, et cette activation est un des scénarios d'utilisation de DOTS les plus cités dans le RFC.

Actuellement, l'activation du service de scrubbing se fait via des interfaces privatrices, fournies par le « protecteur », ce qui contribue à enfermer le client dans sa relation avec le fournisseur. Et puis, parfois, il faut que plusieurs acteurs participent à la réponse à attaque. D'où l'idée du projet DOTS (dDoS Open Threat Signaling) qui va développer une interface normalisée, au sein du groupe de travail du même nom à l'IETF.

La section 1.2 du RFC précise le terminologie employée : DOTS sera client/serveur, le client DOTS étant chez la victime, qui cherche une solution, et le serveur DOTS étant chez le protecteur (mitigator dans le RFC). Rappelez-vous que DOTS ne normalise pas les méthodes de protection (elles évoluent vite, même si le motif « tri puis poubellisation des paquets » reste dominant), mais uniquement la communication entre les acteurs impliqués. Les différents acteurs communiquent avec deux sortes de canaux, les canaux de signalisation et les canaux de données. Les premiers sont prévus pour des messages assez courts (« jette tous les paquets à destination du port NNN ») mais qui doivent arriver à tout prix, même en cas d'attaque intense ; ils sont le cœur du système DOTS, et privilégient la survivabilité. Les seconds, les canaux de données, sont prévus pour de grandes quantités de données, par exemple pour envoyer le trafic trié ou bien pour envoyer des informations de configuration, comme la liste des préfixes IP à protéger.

L'essentiel du RFC est la section 2, qui décrit les exigences auxquelles devra se soumettre le futur protocole DOTS. (Notez que le travail est déjà bien avancé, et qu'il y aura un RFC d'architecture générale du systéme.) Il s'agit d'exigences techniques : ce RFC ne spécifie pas d'exigences business ou de politique. Par exemple, il ne dit pas à partir de quand un client DOTS a le droit de demander une action au serveur, ni dans quels cas le client a le droit d'annuler une demande.

Le protocole DOTS a des exigences difficiles ; compte-tenu du caractère très sensible des échanges entre le client et le serveur, il faut absolument fournir authentification, intégrité, confidentialité et protection contre le rejeu par un tiers. Autrement, le protocole DOTS, comme la plupart des techniques de sécurité, pourrait en fait fournir un nouveau moyen d'attaque. Mais, d'un autre côté, le protocole doit être très robuste, puisqu'il est précisément conçu pour fonctionner face à un hostile, qui va essayer de perturber les communications. Combiner toutes ces demandes n'est pas trivial. DOTS fournira de la robustesse en utilisant des messages de petite taille (qui auront donc davantage de chances de passer), asynchrones, et qui pourront être répétés sans dommage (en cas de doute, les acteurs DOTS n'hésiteront pas à envoyer de nouveau un message).

Je ne vais pas répéter ici la longue liste des exigences, vous les trouverez dans la section 2. Elles sont réparties en plusieurs catégories. Il y a d'abord les exigences générales :

  • Le protocole doit être extensible, car les attaques par déni de service vont évoluer, ainsi que les solutions (la lutte de l'épée et de la cuirasse est éternelle),
  • Comme rappelé ci-dessus, le protocole doit être robuste, la survivabilité doit être sa principale qualité puisqu'il est prévu pour fonctionner en situation très perturbée,
  • Un message qui a du mal à passer ne ne doit pas bloquer le suivant (pas de head-of-line blocking),
  • Le client doit pouvoir donner des indications sur les actions souhaitées, puisqu'il dispose parfois d'informations, par exemple issues du renseignement sur les menaces.

Il y a ensuite les exigences sur le canal de signalisation :

  • Il doit utiliser des protocoles existants comme UDP (TCP est possible mais, en cas d'attaque, il peut être difficile, voir impossible, d'établir une connexion),
  • La taille des messages doit être faible, à la fois pour augmenter les chances de passer malgré l'attaque, et pour éviter la fragmentation,
  • Le canal doit être bidirectionnel, entre autres pour détecter une éventuelle coupure du lien (un serveur peut être configuré pour activer les solutions anti-dDoS précisément quand il ne peut plus parler au client, des messages de type battement de cœur sont donc nécessaires, mais pas évidents à faire correctement, cela avait été une des plus grosses discussions à l'IETF),
  • Le client doit pouvoir demander au serveur des actions (c'est le but principal du protocole), et doit pouvoir aussi solliciter des informations sur ce que voit et fait le serveur DOTS (« j'ai jeté 98 % des paquets » ou « je jette actuellement 3,5 Gb/s »),
  • Le client doit pouvoir tenir le serveur au courant de l'efficacité perçue des actions effectuées (« ça marche pas, je reçois toujours autant »),
  • Le client doit pouvoir indiquer une durée pour les actions du serveur, y compris une durée infinie (si le client préfère que tout son trafic soit examiné et filtré en permanence),
  • Le client doit pouvoir demander un filtrage fin, en indiquant une portée (« uniquement ce qui vient de 192.0.2.0/24 » ou « seulement les paquets à destination de 2001:db8:a:b::/64 », voire « seulement les paquets pour www.example.com », et le serveur DOTS doit alors faire la résolution de nom).

Il y a aussi des exigences pour l'autre canal, celui des données. Rappelons que, contrairement au canal de signalisation, il n'est pas indispensable qu'il puisse fonctionner pendant l'attaque. La principale exigence est la transmission fiable des données.

Vu le contexte de DOTS, il y a évidemment des exigences de sécurité :

  • Authentification mutuelle (du serveur par le client et du client par le serveur), un faux serveur ou un faux client pourraient faire des catastrophes, cf. section 4 du RFC,
  • Confidentialité et intégrité, vu le caractère critique des données (imaginez si un attaquant pouvait modifier les messages DOTS…)

La section 3 du RFC se penche sur le problème de la congestion. Le protocole DOTS ne doit pas ajouter à l'attaque en noyant tout le monde sous les données, alors qu'il utilisera sans doute un transport qui ne gère pas lui-même la congestion, UDP (au moins pour le canal de signalisation). Il faudra donc bien suivre les règles du RFC 8085.

À noter qu'Arbor a un brevet sur les mécanismes analogues à DOTS (brevet 20130055374, signalé à l'IETF ici.) Arbor promet des licences RF et RAND. Même les attaques créent du business…


Téléchargez le RFC 8612


L'article seul

RFC 8576: Internet of Things (IoT) Security: State of the Art and Challenges

Date de publication du RFC : Avril 2019
Auteur(s) du RFC : O. Garcia-Morchon (Philips IP&S), S. Kumar (Philips Research), M. Sethi (Ericsson)
Pour information
Réalisé dans le cadre du groupe de recherche IRTF t2trg
Première rédaction de cet article le 16 août 2019


Une blague très courante dit que, dans IoT (Internet of Things, l'Internet des Objets), le S veut dire sécurité… C'est peu dire que la sécurité de l'Iot est mauvaise. Elle est en fait catastrophique, comme l'analyse bien Schneier dans son livre « Click here to kill everybody ». C'est en grande partie dû à des raisons politico-économiques (les fabriquants se moquent de la sécurité notamment, parce que les failles de sécurité n'ont aucune conséquence négative pour eux) et en petite partie aux réelles difficultés techniques qu'il y a à sécuriser des objets qui sont parfois contraints en ressources (énergie électrique limitée, par exemple.) Ce nouveau RFC du groupe de recherche T2T (Thing to Thing) de l'IRTF se penche sur la question et essaie d'identifier les questions à long terme. À lire absolument, si vous vous intéressez à la sécurité des objets connectés. Et à lire également si vous ne vous y intéressez pas car, que vous le vouliez ou non, la sécurité des objets connectés va vous toucher.

On ne part pas de zéro pourtant. Contrairement à ce que disent parfois les vendeurs d'objets connectés pour justifier l'insécurité abyssale de leurs produits, des solutions techniques ont été développées. (Voir par exemple cet article qui parle de la sécurité des sondes Atlas.) Il existe des protocoles adaptés aux objets, comme CoAP (RFC 7252), une alternative légère à HTTP, qu'on peut sécuriser avec DTLS (RFC 6347). Mais il reste à les déployer.

Notre RFC suit un plan classique : il étudie d'abord le cycle de vie des objets connectés (section 2 du RFC), examine ensuite les risques (section 3), l'état de l'art (section 4), puis les défis pour sécuriser les objets (section 5), et enfin les prochaines étapes du travail nécessaire (section 6).

Le terme d'Internet des Objets fait partie de ces termes pipeau qui ne veulent pas dire grand'chose. Les « objets » n'ont pas grand'chose à voir, allant d'un ordiphone plus puissant que certains ordinateurs, à des étiquettes RFID, en passant par des voitures connectées qui disposent d'électricité et de puissance de calcul considérables, et des capteurs industriels qui sont au contraire très contraints. Quant à leur connexion, elle se limite parfois au réseau local et, parfois, à envoyer toutes leurs données, aussi privées qu'elles soient, vers leur maitre dans le mythique cloud. C'est le consortium privé Auto-Id qui a popularisé ce terme à la fin des années 1990, pour de simples raisons marketing. À l'époque, c'était limité à des étiquettes RFID n'ayant qu'une connexion très limitée, sans rapport avec l'Internet. Certains ont suggéré de réserver le terme d'« Internet des Objets » aux objets connectés en IP mais ces appels à la rigueur terminologique n'ont en général que peu d'impact. Bref, chercher des solutions pour l'« Internet des Objets » en général n'a que peu de chances d'aboutir, vu la très grande variété de situations que ce terme recouvre.

Mais revenons au début, au cycle de vie de nos objets connectés (section 2 du RFC). Comme la variété des objets connectés est très grande, le RFC choisit de partir d'un exemple spécifique, un système de gestion de bâtiment. Ce système contrôle la climatisation, le chauffage, la ventilation, l'éclairage, la sécurité, etc. Un tel système représente de nombreux objets, dont certains, notamment les capteurs installés un peu partout, peuvent être très contraints en ressource (processeur lent, énergie fournie uniquement par des batteries, etc). Pire, du point de vue des protocoles réseau, certains de ces objets vont passer beaucoup de temps à dormir, pour économiser l'énergie, et ne répondront pas aux autres machines pendant ce temps. Et les objets seront sans doute fabriqués par des entreprises différentes, ce qui soulèvera des questions amusantes d'interopérabilité.

La figure 1 du RFC représente un cycle de vie simplifié. Je le simplifie encore ici. L'objet est successivement :

  • fabriqué,
  • il peut rester assez longtemps sur l'étagère, attendant un acheteur (ce qui contribue à l'obsolescence de son logiciel),
  • installé et configuré (probablement par différents sous-traitants),
  • mis en service,
  • il va fonctionner un certain temps puis verra des évenements comme une mise à jour logicielle,
  • ou des changements de sa configuration,
  • à un moment, il cessera d'être utilisé,
  • puis sera retiré du bâtiment (à moins qu'il soit oublié, et reste actif pendant des années sans qu'on s'en occupe),
  • mais il aura peut-être droit à une reconfiguration et une remise en service à un autre endroit, recommençant le cycle,
  • sinon, il sera jeté.

Les différents objets présents dans le bâtiment ne seront pas aux mêmes étapes au même moment.

Le RFC remarque que le cycle de vie ne commence pas forcément à la fabrication de l'objet physique, mais avant. Pour des objets comportant du logiciel, le cycle de vie commence en fait lorsque la première bibliothèque qui sera utilisée est écrite. Les logiciels des objets connectés ont une forte tendance à utiliser des versions anciennes et dépassées des bibliothèques, notamment de celles qui assurent des fonctions de sécurité. Les bogues ont donc une longue durée de vie.

La sécurité est une question cruciale pour les objets connectés, car ils sont en contact avec le monde physique et, si ce sont des actionneurs, ils agissent sur ce monde. Comme le note Schneier, une bogue sur un objet connecté, ce n'est plus seulement un programme qui plante ou un fichier qu'on perd, cela peut être des atteintes physiques aux humains. Et les objets sont nombreux : pirater une machine ne donne pas beaucoup de pouvoir à l'attaquant, mais s'il arrive à trouver une faille lui permettant de pirater via l'Internet tous les objets d'un vendeur donné, il peut se retrouver à la tête d'un botnet conséquent (c'est exactement ce qui était arrivé avec Mirai).

Quels sont les risques exactement ? La section 3 du RFC décrit les différentes menaces, une liste longue et un peu fourre-tout. Avant tout, le code peut être incorrect, bogué ou mal conçu. C'est le cas de tout logiciel (ne croyez pas un instant les commerciaux qui assurent, sans rien en savoir eux-mêmes, que « le logiciel est conforme à l'état de l'art et aux préconisations de [insérer ici le nom d'un organisme quelconque] »). Mais comme vu plus haut, les conséquences sont plus graves dans le cas des objets connectés. En outre, il y a deux problèmes logiciels qui sont davantage spécifiques aux objets connectés : les mises à jour, pour corriger les bogues, sont plus difficiles, et rarement faites, et le logiciel est globalement négligé, n'étant pas le « cœur de métier » de l'entreprise vendeuse. On voit ainsi des failles de sécurité énormes, qui n'arrivent plus dans l'informatique plus classique.

Autre raison pour laquelle la sécurité des objets connectés est difficile à assurer, le fait que l'attaquant peut avoir un accès physique aux objets (par exemple s'il s'agit d'un type d'objet vendu publiquement). Il peut le démonter, l'étudier, et acquérir ainsi des informations utiles pour le piratage d'autres objets du même type. Si, par exemple, tous les objets d'un même type partagent une clé cryptographique privée, elle pourrait être récupérée ainsi (l'objet connecté typique n'est pas un HSM). Un modèle de sécurité comme celui de la boite noire ne s'applique donc pas. Dans le futur, peut-être que les PUF seront une solution ?

La sécurité impose de mettre à jour le logiciel de l'objet régulièrement. Mais cette mise à jour ouvre elle-même des failles de sécurité. Si le processus de mise à jour n'est pas sécurisé (par exemple par une signature du logiciel), un malveillant pourra peut-être y glisser sa version du logiciel.

Ensuite, l'objet, même s'il fonctionne comme prévu, peut faire fuiter des informations privées. S'il envoie des informations à des tiers (c'est le cas de presque tous les objets conçus pour l'usage domestique) ou s'il transmet en clair, il permet la surveillance de son propriétaire. Le chiffrement est évidemment indispensable, mais il ne protège pas contre les extrémités de la communication (le sextoy connecté qui envoie les informations sur son usage au vendeur de l'objet) et, s'il n'est pas accompagné d'une authentification du partenaire avec qui on communique, ile ne protège pas contre l'homme du milieu. Une des difficultés de l'authentification est qu'il faut bien, avant la communication, avitailler l'objet en informations (par exemple les clés publiques de ses correspondants), un défi pour des objets fabriqués en masse. Avitailler une fois l'objet sur le terrain est tout aussi difficile : ces objets n'ont souvent pas d'interface utilisateur. Cela impose des solutions comme le TOFU (faire confiance la première fois, puis continuer avec le même correspondant) ou bien l'appairage (on approche deux objets, on appuie sur un bouton et ils sont désormais appairés, ils ont échangé leurs clés).

Les objets ont souvent une histoire compliquée, étant composée de l'assemblage de divers composants matériels et logiciels, parfois promenés sur de longues distances, entre beaucoup d'entreprises différentes. Une des attaques possibles est de s'insérer quelque part dans cette chaîne d'approvisionnement et d'y glisser du logiciel ou du matériel malveillant. Est-ce que quelqu'un sait vraiment ce que fait cette puce dont on a acheté des dizaines de milliers d'exemplaires à un revendeur ? Dans le cas extrême, c'est l'objet entier qui peut être remplacé par un objet apparemment identique, mais malveillant.

Les objets connectés sont souvent dans des lieux qui ne sont pas physiquement protégés. Par exemple, les capteurs sont placés un peu partout, et parfois accessibles à un attaquant. Une fois qu'on peut mettre la main sur un objet, il est difficile d'assurer sa sécurité. Des informations confidentielles, comme une clé privée, peuvent alors se retrouver entre les mains de l'attaquant. Transformer chaque objet connecté en un coffre-fort inviolable n'est évidemment pas réalistes.

Les objets communiquent entre eux, ou bien avec des passerelles les connectant à l'extérieur. Cela ouvre de nouvelles possibilités d'attaque via le routage. Les objets connectés se servent souvent de protocoles de routage non sécurisés, permettant au malveillant d'injecter de fausses routes, permettant ainsi, par exemple, de détourner le trafic vers une machine contrôlée par ce malveillant.

Enfin, il y a la menace des attaques par déni de service. Les objets sont souvent contraints en ressources et sont donc particulièrement vulnérables aux attaques par déni de service, même légères. Et les objets ne sont pas forcément victimes, ils peuvent être aussi devenir zombies et, recrutés par un logiciel malveillant comme Mirai, être complices d'attaques par déni de service comme cela avait été le cas en octobre 2016. (Un outil comme Shodan permet de trouver facilement des objets vulnérables et/ou piratés.)

Bon, ça, c'étaient les menaces. Mais on n'est pas resté les bras ballants, on a déjà des mécanismes possibles pour faire face à ces attaques. La section 4 de notre RFC décrit l'état de l'art en matière de connexion des objets connectés, et de leur sécurisation.

Déjà, il existe plusieurs protocoles pour les objets connectés, comme ZigBee, BACnet ou DALI. Mais l'IETF se focalise évidemment sur les objets qui utilisent IP, le seul cas où on puisse réellement parler d'« Internet des Objets ». IP tel qu'il est utilisé sur les ordinateurs classiques n'est pas forcément bien adapté, et des groupes ont développé des adaptations pour les réseaux d'objets (voir par exemple le RFC 4944). De même, il existe des normes pour faire tourner IP sur des tas de couches physiques différentes, comme Bluetooth (RFC 7668), DECT (RFC 8105) ou NFC (RFC pas encore publié). Au-dessus d'IP, le protocole CoAP (RFC 7252) fournit un protocole applicatif plus adapté aux objets que le HTTP classique.

Questions formats, on a également le choix. On a JSON (RFC 8259), mais aussi CBOR (RFC 7049) qui, lui, est un format binaire, sans doute plus adapté aux objets contraints. Tous les deux ont des solutions de sécurité, par exemple la famille JOSE pour signer et chiffrer les documents JSON, et son équivalent pour CBOR, CORE (RFC 8152).

Le problème de la sécurité de l'IoT est connu depuis longtemps, et ce ne sont pas les solutions techniques qui manquent, que ce soit pour protéger les objets connectés, ou pour protéger le reste de l'Internet contre ces objets. Certains de ces protocoles de sécurité ne sont pas spécifiques aux objets connectés, mais peuvent être utilisés par eux, c'est le cas de TLS (RFC 8446). Une excuse classique des fabricants d'objets connectés pour ne pas sécuriser les communications avec TLS est le caractère contraint de l'objet (manque de ressources matérielles, processeur, mémoire, énergie, etc). Cet argument peut jouer pour des objets vraiment contraints, des capteurs bon marché disséminés dans l'usine et ne fonctionnant que sur leur batterie mais beaucoup d'objets connectés ne sont pas dans ce cas, et ont largement les moyens de faire tourner TLS. Quand on entend des fabriquants de télévisions connectées ou de voitures connectées expliquer qu'ils ne peuvent pas utiliser TLS car ce protocole est trop coûteux en ressources, on rit ou on s'indigne car c'est vraiment un argument ridicule ; une télévision ou une voiture ont largement assez de ressources pour avoir un processeur qui fait tourner TLS. (Je n'utilise que TLS et SSH pour communiquer avec un Raspberry Pi 1, avec son processeur à 700 MHz et sa consommation électrique de 2 W.)

Outre les protocoles, la sécurité repose sur des règles à suivre. La section 4.3 liste les règles formalisées existantes. Ainsi, GSMA a publié les siennes, BITAG également, le DHS étatsunien s'y est mis, l'ENISA aussi et notre RFC liste de nombreux autres documents. Si les fabriquants d'objets connectés ne sont pas au courant, ce n'est pas faute d'information, c'est bien de la mauvaise volonté !

C'est d'autant plus grave que, comme l'a illustré le cas de Mirai, les objets connectés non-sécurisés ne sont pas un problème que pour le propriétaire de l'objet, mais peuvent également toucher tout l'Internet. Il est donc logique que beaucoup de voix s'élèvent pour dire qu'il faut arrêter de compter sur la bonne volonté des fabricants d'objets connectés, qui ont largement démontré leur irresponsabilité, et commencer à réguler plus sévèrement. (C'est par exemple une demande du régulateur étatsunien FCC.)

Cette disponibilité de très nombreuses solutions techniques ne veut pas dire que tous les problèmes sont résolus. La section 5 du RFC fait ainsi le point sur les défis qui nous restent, et sur lesquels chercheu·r·se·s et ingénieur·e·s devraient se pencher. D'abord, certains objets sont contraints en ressources (pas tous, on l'a vu), comme détaillé dans le RFC 7228. L'Internet est un monde très hétérogène, connectant des machines ayant des ressources très diverses, via des réseaux qui ont des capacités hautement variables. Pour ces objets contraints (qui sont une partie seulement des « objets », une caméra de vidéo-surveillance n'est pas un objet contraint), il est raisonnable de chercher à optimiser, par exemple la cryptographie. Ainsi, la cryptographie à courbes elliptiques (RFC 8446) demande en général moins de ressources que RSA.

Les attaques par déni de service sont un autre défi pour les objets connectés, qui disposent de peu de ressources pour y faire face. Des protocoles qui permettent de tester qu'il y a une voie de retour (return routability ou returnability) peuvent aider à éviter certaines attaques que des protocoles sans ce test (comme le DNS ou comme d'autres protocoles fondés sur UDP) rendent facile. C'est pour cela que DTLS (RFC 6347) ou HIP (RFC 7401) intègrent ce test de réversibilité. Évidemment, cela n'aide pas pour les cas de la diffusion, ou bien lorsque le routage est contrôlé par l'attaquant (ce qui est souvent le cas dans les réseaux « mesh ».) Autre protection, qui existe par exemple dans HIP : forcer l'initiateur d'une connexion à résoudre un problème, un « puzzle », afin d'éviter que les connexions soient « gratuites » pour l'initiateur. La principale limite de cette solution est qu'elle marche mal si les machines impliquées ont des capacités de calcul très différentes (un objet contraint contre un PC). Il y a également le cas, non mentionné par le RFC, où l'attaquant dispose d'un botnet et ne « paie » donc pas les calculs.

L'architecture actuelle de l'Internet n'aide pas au déploiement de certaines solutions de sécurité. Ainsi, un principe de base en sécurité est d'avoir une sécurité de bout en bout, afin de ne pas dépendre d'intermédiaires malveillants ou piratés, mais c'est rendu de plus en plus difficile par l'abus de middleboxes, qui interfèrent avec beaucoup de comunications. On est donc forcés d'adapter la sécurité à la présence de ces middleboxes, souvent en l'affaiblissant. Par exemple :

  • Il faut parfois partager les clés avec les middleboxes pour qu'elles puissent modifier les paquets, ce qui est évidemment une mauvaise pratique,
  • Le chiffrement homomorphe peut aider, en permettant d'effectuer certaines opérations sur des données chiffrées, mais toutes les opérations ne sont pas possibles ainsi, et les bibliothèques existantes, comme SEAL, n'ont pas les performances nécessaires,
  • Remonter la sécurité depuis le niveau des communications (ce que fait TLS) vers celui des données échangées pourrait aider. C'est ce que font COSE (RFC 8152), JOSE (RFC 7520) ou CMS (RFC 5652).

Une fois déployés, les objets connectés vont rester en fonctionnement des années, voire des décennies. Il est donc crucial d'assurer les mises à jour de leur logiciel, ne serait-ce que pour réparer les failles de sécurité qui ne manqueront pas d'être découvertes, qu'elles soient dans le code ou dans les algorithmes utilisés. Par exemple, si les promesses des ordinateurs quantiques se concrétisent un jour, il faudra jeter RSA et les courbes elliptiques (section 5.8 du RFC).

Mais assurer des mises à jour sûres n'est pas facile, comme le note Bruce Schneier. C'est que le processus de mise à jour, s'il est insuffisamment sécurisé, peut lui-même servir pour une attaque, par exemple en envoyant du code malveillant à un objet trop naïf. Et puis comment motiver les vendeurs à continuer à fournir des mises à jour logicielles des années après que le dernier exemplaire de ce modèle ait été vendu ? Capitalisme et sécurité ne vont pas bien ensemble. Et il se peut tout simplement que le vendeur ait disparu, que le code source de l'objet ne soit plus disponible, et qu'il soit donc impossible en pratique de développer une mise à jour. (D'où l'importance, même si le RFC ne le dit pas, du logiciel libre.) Enfin, si la mise à jour doit être effectuée manuellement, il est probable qu'elle ne sera pas faite systématiquement. (Un rapport de la FTC états-unienne détaille également ce problème.)

Mais les mises à jour automatiques posent également des tas de problèmes. Par exemple, pour des ampoules connectées (une idée stupide, mais le monde de l'IoT est plein d'idées stupides), il vaut mieux mettre à jour leur logiciel le jour que la nuit. Et il vaut mieux que toutes les ampoules ne soient pas mises à jour en même temps. Et les mises à jour supposent que le système ait été conçu pour cela. Par exemple, en cryptographie, il est souvent nécessaire de remplacer les algorithmes cryptographiques qui ont été cassés avec le temps, mais beaucoup d'objets connectés utilisent des systèmes cryptographiques mal conçus, qui n'ont pas d'agilité cryptographique. (Au passage, la section 5.8 du RFC traite le cas des possibles futurs ordinateurs quantiques, et des conséquences qu'ils auront pour la cryptographie. Les objets connectés peuvent rester actifs de nombreuses années, et il faut donc penser loin dans le futur.) Ces points, et beaucoup d'autres, avaient été traités dans un atelier de l'IAB, qui avait fait l'objet du RFC 8240. À l'IETF, le groupe de travail SUIT développe des mécanismes pour aider les mises à jour (mais qui ne traiteront qu'une petite partie du problème).

Rapidement dépassés, les objets connectés posent également des problèmes de gestion de la fin de vie. Au bout d'un moment, le vendeur va arrêter les différentes fonctions, comme les mises à jour du logiciel ou, plus radicalement, comme les serveurs dont dépend l'objet. Cet arrêt peut être volontaire (l'objet n'intéresse plus le vendeur, qui est passé à d'autres gadgets) ou involontaire (vendeur en faillite). Le RFC note qu'une des voies à explorer est la continuation de l'objet avec du logiciel tiers, qui ne dépend plus de l'infrastructure du vendeur. Bien des ordiphones ont ainsi vu leur vie prolongée par CyanogenMod, et bien des routeurs ont bénéficié d'OpenWrt. (D'où l'importance de pouvoir installer ce logiciel tiers, ce qu'interdisent beaucoup de vendeurs.)

Une autre question intéressante de sécurité posée par les objets connectés est la vérification de leurs capacités réelles et de leur comportement effectif. L'acheteur peut avoir l'impression qu'il est le propriétaire de l'objet acheté mais cet objet est suffisamment complexe pour que l'acheteur ne soit pas au courant de tout ce que l'objet fait dans son dos. Le vrai maitre de l'objet est alors le vendeur, qui continue à communiquer avec l'engin connecté. C'est ainsi que des malhonnêtes comme Lidl ou Google avaient installé des micros dans des objets qu'on installe chez soi, et évidemment sans le dire à l'acheteur. Et encore, un micro est un appareil physique, qu'un examen attentif (avez-vous vérifié tous les objets connectés chez vous ?) peut détecter. Mais savoir ce que raconte l'objet connecté à son maitre est plus difficile. Peu d'utilisateurs ont envie de configurer un routeur local, et d'y faire tourner tcpdump pour voir le trafic. Et encore, ce trafic peut être chiffré et l'acheteur (qui, rappelons-le, n'est pas le véritable propriétaire de l'objet, puisqu'il n'a quasiment aucun contrôle, aucune information) n'a pas les clés.

Le problème de fournir des informations à l'utilisateur n'est pas trivial techniquement. Beaucoup d'objets connectés n'ont pas d'interface utilisateur où afficher « je suis en train d'envoyer plein de données sur vous à mon maitre ». Une solution partielle serait une description des capacités de l'engin, et de ses communications, dans un fichier MUD (Manufacturer Usage Description, RFC 8520). Ceci dit, vu le niveau d'éthique dans le monde de l'IoT, gageons que ces fichiers MUD mentiront souvent, notamment par omission.

Puisqu'on a parlé de vie privée, c'est l'occasion de rappeler que l'IoT est une grave menace pour cette vie privée. Le RFC note que, dans le futur, nous serons peut-être entourés de centaines d'objets connectés. (Malheureusement, le RFC parle surtout des risques dus à des tiers qui observeraient le trafic, et très peu des risques dus aux vendeurs qui récoltent les données.) L'IoT permet une intensification considérable du capitalisme de surveillance.

Bref, la situation est mauvaise et, s'il y a en effet quelques progrès (on voit moins souvent des mots de passe identiques pour tous les objets d'un type), ils sont largement annulés par de nouveaux déploiements.


Téléchargez le RFC 8576


L'article seul

RFC 8621: The JSON Meta Application Protocol (JMAP) for Mail

Date de publication du RFC : Août 2019
Auteur(s) du RFC : N. Jenkins (FastMail), C. Newman (Oracle)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF jmap
Première rédaction de cet article le 14 août 2019


Ce nouveau RFC décrit un remplaçant pour le traditionnel protocole IMAP, remplaçant fondé sur le cadre JMAP (JSON Meta Application Protocol, RFC 8620).

Le protocole décrit dans ce RFC fournit les mêmes services qu'IMAP (RFC 3501) : accéder aux boîtes aux lettres de courrier, chercher dans ces boîtes, gérer les messages (détruire les inutiles, par exemple), etc. Par rapport à IMAP, outre l'utilisation du format JSON, l'accent est mis sur la synchronisation rapide, l'optimisation pour les clients mobiles, et sur la possibilité de notifications. JMAP est sans état (pas besoin de connexion permanente). Ce « JMAP pour le courrier » s'appuie sur JMAP, normalisé dans le RFC 8620. JMAP est un protocole générique, qui peut servir à synchroniser bien des choses entre un client et un serveur (par exemple un agenda, ou bien une liste de contacts). Par abus de langage, je vais souvent dire « JMAP » dans cet article alors que je devrais normalement préciser « JMAP pour le courrier », premier « utilisateur » du JMAP générique.

JMAP manipule différents types d'objets. Le plus important est sans doute Email (section 4 du RFC), qui modélise un message. Il s'agit d'une représentation de haut niveau, le client JMAP n'a pas à connaitre tous les détails de l'IMF (Internet Message Format, RFC 5322), de MIME (RFC 2045), etc. Un objet de type Email a une liste d'en-têtes et un corps, et JMAP fournit des méthodes pour accéder aux différentes parties du corps. Il y a même plusieurs représentations d'un message, pour s'adapter aux différents clients. Par exemple, un message MIME est normalement un arbre, de profondeur quelconque, mais un client JMAP peut décider de demander une représentation aplatie, avec juste une liste d'attachements. (La plupart des MUA présentent à l'utilisateur une vue aplatie de l'objet MIME.) Voilà pourquoi l'objet Email a plusieurs propriétés, le client choisissant à laquelle il accède :

  • bodyStructure : l'arbre MIME, c'est la représentation la plus « authentique »,
  • textBody : une liste des parties MIME à afficher quand on préfère du texte,
  • htmlBody : une liste des parties MIME à afficher quand on préfère de l'HTML,
  • attachments : la liste des « pièces jointes » (rappelez-vous que le concept de « pièces jointes » a été créé pour l'interface avec l'utilisateur ; il n'a pas de sens en MIME, qui ne connait qu'un arbre avec des feuilles de différents types).

Les en-têtes doivent pouvoir être internationaux (RFC 6532).

Un message a évidemment des métadonnées, parmi lesquelles :

  • id, un identifiant du message (ce n'est pas le Message-ID:, c'est attribué par le serveur JMAP), contrairement à IMAP, l'identificateur d'un message ne change pas, même quand le message change de boîte, et il peut apparaitre dans plusieurs boîtes à la fois
  • blobIf, un identifiant du message représenté sous la forme d'une suite d'octets, à analyser par le client, par opposition à l'objet de haut niveau identifié par id,
  • size, la taille du message,
  • keywords, des mots-clés, parmi lesquels certains, commençant par un dollar, ont une signification spéciale.

En IMAP, les mots-clés spéciaux sont précédés d'une barre inverse. En JMAP, c'est le dollar. Parmi ces mots-clés, $seen indique que le message a été lu, $answered, qu'on y a répondu, $junk, que le serveur l'a classé comme spam, etc. Ces mots-clés sont dans un registre IANA.

Et quelles opérations sont possibles avec les objets de type Email ? Ce sont les opérations génériques de JMAP (RFC 8620, section 5). Ainsi, on peut récupérer un message avec Email/get. Cette requête :

[[ "Email/get", {
        "ids": [ "f123u456", "f123u457" ],
        "properties": [ "threadId", "mailboxIds", "from", "subject",
          "receivedAt", "header:List-POST:asURLs",
          "htmlBody", "bodyValues" ],
        "bodyProperties": [ "partId", "blobId", "size", "type" ],
        "fetchHTMLBodyValues": true,
        "maxBodyValueBytes": 256
      }, "#1" ]]      
    

peut récupérer, par exemple, cette valeur :

      
[[ "Email/get", {
     "accountId": "abc",
     "state": "41234123231",
     "list": [
       {
         "id": "f123u457",
         "threadId": "ef1314a",
         "mailboxIds": { "f123": true },
         "from": [{ "name": "Joe Bloggs", "email": "joe@example.com" }],
         "subject": "Dinner on Thursday?",
         "receivedAt": "2013-10-13T14:12:00Z",
         "header:List-POST:asURLs": [
           "mailto:partytime@lists.example.com"
         ],
         "htmlBody": [{
           "partId": "1",
           "blobId": "B841623871",
           "size": 283331,
           "type": "text/html"
         }, {
           "partId": "2",
           "blobId": "B319437193",
           "size": 10343,
           "type": "text/plain"
         }],
         "bodyValues": {
           "1": {
             "isTruncated": true,
             "value": "<html><body><p>Hello ..."
           },
           "2": {
             "isTruncated": false,
             "value": "-- Sent by your friendly mailing list ..."
           }
         }
       }
     ],
     "notFound": [ "f123u456" ]
     }, "#1" ]]

    

Notez que le client a demandé deux messages, mais qu'un seul, le f123u457, a été trouvé.

Tout aussi indispensable, Email/query permet de demander au serveur une recherche, selon de nombreux critères comme la date, les mots-clés, ou bien le contenu du corps du message.

Email/set permet de modifier un message, ou d'en créer un (qu'on pourra ensuite envoyer avec EmailSubmission, décrit plus loin). Notez qu'il n'y a pas de Email/delete. Pour détruire un message, on utilise Email/set en changeant la propriété indiquant la boîte aux lettres, pour mettre la boîte aux lettres spéciale qui sert de poubelle (rôle = trash).

Comme IMAP, JMAP pour le courrier a la notion de boîte aux lettres (section 2 du RFC). Une boîte (vous pouvez appeler ça un dossier ou un label si vous voulez) est un ensemble de messages. Tout message est dans au moins une boîte. Les attributs importants d'une boîte :

  • Un nom unique (par exemple Vacances ou Personnel), en Unicode (RFC 5198),
  • Un identificateur attribué par le serveur (et a priori moins lisible par des humaines que ne l'est le nom),
  • Un rôle, optionnel, qui indique à quoi sert la boîte, ce qui est utile notamment si le serveur peut être utilisé en JMAP et en IMAP. Ainsi, le rôle inbox identifie la boîte où le courrier arrive par défaut. (Les rôles figurent dans un registre IANA créé par le RFC 8457.)
  • Certains attributs ne sont pas fixes, par exemple le nombre total de messages contenus dans la boîte, ou bien le nombre de messages non lus.
  • Les droits d'accès (ACL, cf. RFC 4314.) Les permissions sont par boîte, pas par message.

Ensuite, on utilise les méthodes JMAP pour accéder aux boîtes (révisez donc le RFC 8620, qui décrit le JMAP générique). Ainsi, pour accéder à une boîte,, on utilise la méthode JMAP Mailbox/get, qui utilise le /get JMAP (RFC 8620, section 5.1). Le paramètre ids peut être nul, cela indique alors qu'on veut récupérer tous les messages (c'est ce qu'on fait dans l'exemple ci-dessous).

De même, pour effectuer une recherche sur le serveur, JMAP normalise la méthode /query (RFC 8620, section 5.5) et JMAP pour le courrier peut utiliser Mailbox/query.

Par exemple, si on veut voir toutes les boîtes existantes, le client JMAP envoie le JSON :

[[ "Mailbox/get", {
     "accountId": "u33084183",
     "ids": null
}, "0" ]]
    

et reçoit une réponse du genre (on n'affiche que les deux premières boîtes) :

[[ "Mailbox/get", {
     "accountId": "u33084183","state": "78540",
     "state": "78540",
     "list": [{
         "id": "MB23cfa8094c0f41e6",
         "name": "Boîte par défaut",
         "role": "inbox",
         "totalEmails": 1607,
         "unreadEmails": 15,
         "myRights": {
               "mayAddItems": true,
               ...},
	       {
         "id": "MB674cc24095db49ce",
         "name": "Personnel",
	 ...
    

Notez que state est l'identificateur d'un état de la boîte. Si on veut ensuite récupérer les changements, on pourra utiliser Mailbox/changes avec comme paramètre "sinceState": "88540".

Dans JMAP, les messages peuvent être regroupés en fils de discussion (threads, section 3 du RFC). Tout message est membre d'un fil (parfois membre unique). Le RFC n'impose pas de méthode unique pour constituer les fils mais suggère :

  • D'utiliser les en-têtes du RFC 5322 (In-Reply-To: ou References: indiquant le Message-Id: d'un autre message).
  • Et de vérifier que les messages ont le même sujet (après avoir supprimé des préfixes comme « Re: »), pour tenir compte des gens qui volent les fils. Cette heuristique est imparfaite (le sujet peut avoir changé sans pour autant que le message soit sans rapport avec le reste du fil).

On peut ensuite accéder aux fils. Le client envoie :

[[ "Thread/get", {
       "accountId": "acme",
       "ids": ["f123u4", "f41u44"]
}, "#1" ]]      
    

Et récupère les fils f123u4 et f41u44 :

[[ "Thread/get", {
       "accountId": "acme",
       "state": "f6a7e214",
        "list": [
          {
              "id": "f123u4",
              "emailIds": [ "eaa623", "f782cbb"]
          },
          {
              "id": "f41u44",
              "emailIds": [ "82cf7bb" ]
          }
...
    

Un client qui vient de se connecter à un serveur JMAP va typiquement faire un Email/query sans conditions particulières, pour recevoir la liste des messages (ou alors en se limitant aux N messages les plus récents), puis récupérer les fils de discussion correspondants avec Thread/get, récupérer les messages eux-mêmes. Pour diminuer la latence, JMAP permet au client d'envoyer toutes ces requêtes en une seule fois (batching), en disant pour chaque requête qu'elle doit utiliser le résultat de la précédente (backreference, membre JSON resultOf).

JMAP permet également d'envoyer des messages. Un client JMAP n'a donc besoin que d'un seul protocole, contrairement au cas courant aujourd'hui où il faut IMAP et SMTP, configurés séparement, avec, trop souvent, l'un qui marche et l'autre pas. Cela simplifie nettement les choses pour l'utilisateur. Cela se fait avec le type EmailSubmission (section 7 du RFC). Deux importantes propriétés d'un objet de type EmailSubmission sont mailFrom, l'expéditeur, et rcptTo, les destinataires. Rappel important sur le courrier électronique : il y a les adresses indiquées dans le message (champs To:, Cc:, etc, cf. RFC 5322), et les adresses indiquées dans l'enveloppe (commandes SMTP comme MAIL FROM et RCPT TO, cf. RFC 5321). Ces adresses ne sont pas forcément identiques. Lorsqu'on apprend le fonctionnement du courrier électronique, la distinction entre ces deux catégories d'adresses est vraiment cruciale.

Un EmailSubmission/set va créer l'objet EmailSubmission, et envoyer le message. Ici, on envoie à john@example.com et jane@example.com un message (qui avait été créé par Email/set et qui avait l'identificateur M7f6ed5bcfd7e2604d1753f6c) :

[[ "EmailSubmission/set", {
        "accountId": "ue411d190",
        "create": {
          "k1490": {
            "identityId": "I64588216",
            "emailId": "M7f6ed5bcfd7e2604d1753f6c",
            "envelope": {
              "mailFrom": {
                "email": "john@example.com",
                "parameters": null
              },
              "rcptTo": [{
                "email": "jane@example.com",
                "parameters": null
              },
              ...
              ]
            }
          }
        },
        "onSuccessUpdateEmail": {
          "#k1490": {
            "mailboxIds/7cb4e8ee-df87-4757-b9c4-2ea1ca41b38e": null,
            "mailboxIds/73dbcb4b-bffc-48bd-8c2a-a2e91ca672f6": true,
            "keywords/$draft": null
          }
        }
      }, "0" ]]      
    

Anecdote sur l'envoi de courrier : les premières versions de « JMAP pour le courrier » utilisaient une boîte aux lettres spéciale, nommée Outbox, où on mettait les messages à envoyer (comme dans ActivityPub).

JMAP a d'autres types d'objets amusants, comme VacationResponse (section 8), qui permet de faire envoyer un message automatiquement lorsqu'on est absent (l'auto-répondeur du serveur doit évidemment suivre le RFC 3834, pour éviter de faire des bêtises comme de répondre à une liste de diffusion). On crée un objet avec VacationResponse/set et hop, l'auto-répondeur est amorcé.

Et je n'ai pas parlé de tout, par exemple JMAP permet de pousser des changements depuis le serveur vers le client, si la boîte aux lettres est modifiée par un autre processus (RFC 8620, section 7).

JMAP a le concept de capacités (capabilities), que le serveur annonce au client, dans un objet JSON (rappel : JSON nomme « objets » les dictionnaires), et sous la forme d'un URI. JMAP pour le courrier ajoute trois capacités au registre des capacités JMAP, urn:ietf:params:jmap:mail pour dire qu'on sait gérer le courrier, urn:ietf:params:jmap:submission, pour dire qu'on sait en envoyer (cf. RFC 6409, sur ce concept de soumission d'un message), et urn:ietf:params:jmap:vacationresponse pour dire qu'on sait gérer un auto-répondeur.

Le courrier électronique pose plein de problèmes de sécurité intéressants. La section 9 de notre RFC les détaille. Par exemple, les messages en HTML sont particulièrement dangereux. (Il est toujours amusant de voir des entreprises de sécurité informatique envoyer leur newsletter en HTML, malgré les risques associés, qui sont aujourd'hui bien connus.) Le RFC rappelle donc aux clients JMAP (mais c'est valable pour tous les MUA) que du JavaScript dans le message peut changer son contenu, qu'un message en HTML peut récupérer du contenu sur l'Internet (via par exemple un <img src=…), ce qui trahit le lecteur et fait fuiter des données privées, que CSS, quoique moins dangereux que JavaScript, permet également des trucs assez limites, que les liens en HTML ne pointent pas toujours vers ce qui semble (<a href="http://evil.example/">cliquez ici pour aller sur le site de votre banque https://good-bank.example</a>), etc. Pour faire face à tous ces dangers du courrier en HTML, le RFC suggère de nettoyer le HTML avant de l'envoyer au client. Attention, outre que c'est une modification du contenu, ce qui est toujours délicat politiquement, le faire proprement est difficile, et le RFC recommande fortement d'utiliser une bibliothèque bien testée, de ne pas le faire soi-même à la main (il y a trop de pièges). Par exemple, en Python, on peut utiliser lxml, et son module Cleaner, ici en mode extrémiste qui retire tout ce qui peut être dangereux :

    
from lxml.html.clean import Cleaner
...
cleaner = Cleaner(scripts=True, javascript=True, embedded=True, meta=True, page_structure=True,
                                      links=True, remove_unknown_tags=True,
                                      style=True)

Mais il est probablement impossible de complètement sécuriser HTML dans le courrier. Le RFC explique à juste titre que HTML augmente beaucoup la surface d'attaque. Une organisation soucieuse de sécurité ne devrait pas traiter le HTML dans le courrier.

La soumission du courrier (cf. RFC 6409) pose également des problèmes de sécurité. Imaginez un client JMAP piraté et qui serve ensuite à envoyer du spam de manière massive, utilisant le compte de l'utilisateur ignorant de ce piratage. Les MTA qui acceptent du courrier ont des mécanismes de défense (maximum N messages par heure, avec au plus M destinataires par message…) mais ces mécanismes marchent d'autant mieux que le serveur a davantage d'information. Si la soumission via JMAP est mise en œuvre par un simple relais vers un serveur SMTP de soumission, certaines informations sur le client peuvent être perdues. De tels relais doivent donc veiller à transmettre au serveur SMTP toute l'information disponible, par exemple via le mécanisme XCLIENT.

JMAP a été développé essentiellement au sein de FastMail, qui le met en œuvre sur ses serveurs. Il existe une page « officielle » présentant le protocole, qui explique entre autres les avantages de JMAP par rapport à IMAP. Vous y trouverez également des conseils pour les auteurs de clients, très bien faits et qui donnent une bonne idée de comment le protocole marche. Ce site Web est un passage recommandé.

On y trouve également une liste de mises en œuvre de JMAP. Ainsi, le serveur IMAP bien connu Cyrus a déjà JMAP en expérimental. Le MUA K-9 Mail a, quant à lui, commencé le travail.


Téléchargez le RFC 8621


L'article seul

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

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