Loading...
An error has occurred

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

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

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

PLANÈTE XMLFR

Agrégation de carnets web.

2018-09-12

☕︎ By default

I thought about replacing Google Analytics with Matomo, but I came to the same conclusion that it didn’t provide anything I need in order to run Feedbin. Better to not collect that data at all.

Private by Default (cache)

Been there, done that. Vanity metrics can be a strong motivator, respect can be another. Do you really use your analytics? Because others actually do. And by others I mean the ones’ computers you store (y)our data on.

Privacy by default (cache), please.

Voir aussi :

La facilité à produire une tyrannie ne doit pas nous faire oublier ce que nous produisons. Si nous avons les moyens de la produire, il nous faut nous interroger sur comment y résister et comment réduire, atténuer voire contester cette production. Si nous sommes capables d’imposer une tyrannie, il faut nous interroger sur comment la défaire.

De la tyrannie des métriques (cache)

2018-09-11

☕︎ Memories and stories

There’s a theory that every time we access a memory, a new memory is created in its place. That the act of recollection is, in fact, an act of destruction–or of augmentation. That each of our memories is replaced by a facsimile of itself.

[…]

In this way, isn’t memory also made of the stories we tell?

Introduction - CapsuleCrit (cache)

Think about it, memorize it.

Tell it.

2018-09-10

☕︎ Notes de lecture

La connectivité et les algorithmes rythment jusqu’à nos vies sociales. Nos objets quotidiens sont tous devenus des code/space. Toutes nos activités sont « de plus en plus gouvernées par une logique algorithmique et policées par des processus informatiques opaques et cachés ». Cette emphase de production physique et culturelle du monde par l’informatique masque les inégalités de pouvoir qu’elles induisent, reproduisent et amplifient.

La pensée computationnelle s’infiltre partout : elle devient notre culture. Elle nous conditionne à la fois parce qu’elle nous est illisible et à la fois parce que nous la percevons comme neutre émotionnellement et politiquement. Les réponses automatisées nous semblent plus dignes de confiance que celles qui ne le sont pas.

Technologie : l’âge sombre (cache)

Hubert nous partage ses fabuleuses notes de lecture enrichies de ses pensées détaillées et documentées. Ça donne envie de lire le livre mais j’ai peur d’être déçu, non pas d’avoir été divulgâché mais de constater à quel point une copie papier est inférieure en terme de ramifications possibles et de rebonds.

2018-09-09

☕︎ Douleur enfouie

Selon les psychologues, pour devenir un adulte en santé sur le plan affectif, l’être humain doit avoir certains de ses besoins émotionnels fondamentaux — outre la nourriture, l’eau, la chaleur, etc. — comblés comme nourrisson et comme enfant ; par exemple, être soigné, recevoir des preuves d’amour et d’affection, être accepté, valorisé et respecté, ressentir de l’empathie et forger des liens profonds. Si le nourrisson ou l’enfant n’est pas suffisamment soigné et aimé, ces besoins seront lestés d’une charge importante associée à la douleur de la perte, laquelle génère la peur inconsciente de ne jamais recevoir suffisamment de soin et d’affection. C’est ainsi que la douleur enfouie consécutivement à l’insatisfaction d’un besoin émotionnel pourra déclencher un conflit dans une communauté 20, 30 ou 40 ans plus tard.

Le problème ne réside pas dans le fait d’avoir profondément enfoui des besoins émotionnellement chargés. Il réside plutôt dans le fait de croire que la communauté y répondra. Ce qui ajoute une aspérité supplémentaire au conflit, c’est l’exigence tacite et silencieuse que la communauté ou les autres membres doivent fournir ce qui semble manquer. Voilà pourquoi les discussions qui, en surface, semblent porter sur les idéologies, les priorités ou les valeurs peuvent s’avérer si intenses. Je pourrais croire que la vie communautaire signifie d’accorder de la valeur au fait d’inclure (parce qu’enfant, j’ai désespérément eu besoin d’être accepté et que je ne l’ai jamais été) ; vous pourriez être d’avis que la vie communautaire doit permettre à chacun d’être libre de faire ce qu’il veut (parce qu’étant jeune, vous avez désespérément voulu être autonome sans pouvoir y parvenir). Et nous voilà en train de nous disputer férocement sur la signification de ce qu’est la « communauté ».

Vivre autrement, Diana Leafe Christian

Toute ressemblance avec nos comportements en ligne serait bien évidement fortuite. Une communauté mise en place par des personnes se réfugiant dans la technique faute d’acceptation, qui aujourd’hui en appelle à davantage d’inclusion, ça me rappelle vaguement un truc quand même.

#autocritique

2018-09-08

☕︎ Dependencies and governments

In 1873 the American government killed 1.5 Million buffalo in that one year alone to starve the native Americans so they would be come more dependent on the American government to survive — @AmericanIndian8

It was done here in Canada as well. Not by killing buffalo, but by killing dogs, the Native People up north used to hunt with. Making them dependent on the Government for food and shelter. — @bramhabs98

I don’t know to which extent it’s true but I never thought about it this way.

2018-09-07

☕︎ Rêves inatteignables

Je me dis de plus en plus qu’il faut laisser la place à des rêves que l’on ne souhaite pas vraiment réaliser mais qui ont quand même leur utilité en terme de défis pour justement ne pas les réaliser. (Sorry.)

Peut-être est-ce ça, la vieillesse…

2018-09-06

☕︎ Équilibre

Sur-extraire des ressources pour sous-exploiter leur usage. Sur-qualifier des humains pour sous-exploiter leur production. Sur-collecter des données pour sous-exploiter leur capacité.

Quel exploit!

2018-09-05

☕︎ (Im)Mor(t)alité

L’espace et le temps. On fait souvent référence à la finitude du monde pour expliquer/justifier des choses alors que celle de la vie a probablement plus d’impact. C’est la prise de conscience du peu de temps à vivre qui nous pousse à la compétition. Une fois l’immortalité atteinte, des concepts comme le capitalisme ou l’héritage se révèlent être abscons.

2018-09-04

☕︎ Moment propice

Le climat sociétal me semble être favorable à l’apparition de nouveaux mouvements d’ampleur pour unifier/faire s’affronter des humains.

Un signe que l’espèce n’aurait toujours pas su dépasser cela.

2018-09-03

☕︎ Libérer les humains

Le véganisme est un mouvement politique, et un art de vivre, de laisser vivre et de vivre avec.

[…]

Le véganisme, par son empathie radicale, n’est rien de moins que le désir d’un changement de civilisation.

[…]

Le véganisme est une avant-garde éthique qui révèle des oppressions socialement admises, mais ce n’est pas qu’une lutte critique, c’est aussi une philosophie positive qui propose des solutions pratiques pour bien vivre. Le véganisme peut paraître compliqué et aride. J’aimerais montrer qu’il est accueillant, excitant, gourmand et émancipateur, pour les animaux, et pour les humains. Le véganisme est une lutte de libération qui a aussi pour but de libérer les humains de leur domination.

Les animaux ne sont pas comestibles, Martin Page

Cela fait 2/3 ans que je réduis drastiquement ma consommation de viande. Je suis encore loin du véganisme mais je considère que c’est l’un des pas à effectuer en direction d’un mieux être. Plus difficile sur le continent du barbecue. Plus facile dans la ville vegan/sans gluten/etc.

Culture et contre-culture.

2018-09-02

☕︎ Terra Perma

Terra Perma est une communauté résidentielle et d’éco-entrepreneurs au cœur des Laurentides. En bordure de la célèbre Rivière Rouge à l’ouest et situés dans la région de Mont-Tremblant, ses 800 hectares sont un sanctuaire où il est possible de pratiquer de nombreuses activités passionnantes sur place et à proximité. Terra Perma c’est aussi un vaste parc de plus de 200 acres géré conjointement avec la Fondation Terra Perma. En soi, la mission de Terra Perma est de préserver l’habitat naturel et de promouvoir le développement durable.

Une vision pour Terra Perma (cache)

Visite en éco-touriste d’un lieu qui présente beaucoup d’avantages à un moment où je me dis qu’un lopin de terre permettrait de faire des cabanes tranquillement. Et plus si affinités.

À suivre.

2018-09-01

☕︎ En devenir

Voici maintenant la définition d’un écovillage selon Robert Gilman, qui est largement utilisée : « Établissement autonome, à échelle humaine, où les activités s’intègrent harmonieusement au milieu naturel de telle sorte qu’elles contribuent à un développement sain de l’être tout en étant suffisamment inoffensives pour être poursuivies indéfiniment. » […] Quoi qu’il en soit, la plupart des militants en la matière étant d’avis qu’aucun véritable écovillage n’existe à ce jour (étant donné que nous ne savons pas encore si les activités de ces établissements pourront « se poursuivre indéfiniment »), on s’entend pour appeler ces communautés des « écovillages en devenir ».

Vivre autrement, Diana Leafe Christian

J’apprécie cette humilité, cela dit si l’on prend le terme « indéfiniment » au sens strict, il n’y aura jamais de véritable écovillage.

Troll en devenir.

2018-08-31

☕︎ Deplorable

The simplicity and beauty of copyleft is that it takes away someone’s software freedom only at the moment when they take away someone else’s software freedom; copyleft ensures that is the only reason your software freedom should be lost. Simple tools work best when your social justice cause is an underdog, and we risk obscurity of our software if we seek to change the fundamental simple design of copyleft licensing to include licensing penalties for other social justice grievances (— even if we could agree on which other non-FOSS causes warrant “copyleft protection”). It means we have a big tent for software freedom, and we sometimes stand under it with people whose behavior we despise. The value we have is our ability to stand with them under the tent, and tell them: “while I respect your right to share and improve that software, I find the task you’re doing with the software deplorable.”. That’s the message I deliver to any ICE agent who used Free Software while forcibly separating parents from their children.

Challenges in Maintaining A Big Tent for Software Freedom (cache)

More infos on the specific ICE topic (cache).

Even if I mention alternatives, that’s a topic I’m still exploring with all its moral implications and it’s great to have articles from both sides. Interpretation is really key when you had some judgement restrictions to your work and it’s easy to mess up and become even worse than the agnostic version. My current take is: at least try to do some good with the initial work, that’s already a win over this whole industry.

Thanks Claude!

2018-08-30

☕︎ État de l’art

Si je considère un bien comme étant de l’art, sa consommation devient dépendante de mes émotions et du contexte. Ainsi la personnalisation du bien ne devient plus sa qualité majeure.

Potentiellement, cela réduit la consommation globale en se concentrant sur quelques déclinaisons du produit. Mais l’éventail des émotions associées à un contexte est-il plus réduit que celui des personnes ? N’est-ce pas justement une partie de la définition d’une personne ?

#musique #vin #snobisme #spirale

Le livre-échange

Le livre, sous ses deux formes, papier ou numérique, est un objet de passion depuis longtemps. Ce ne sont pas juste des lettres qu'on lit. Les lecteurices ont des usages, des pratiques, ils et elles se prêtent les livres, les annotent, les commentent, les échangent, en parlent sur leur blog…

Ce livre est une étude de ces pratiques. Que font les lecteurs de leur livre ? Pour chaque pratique, des lecteurices sont interrogé·e·s, des experts commentent parfois. On ne parle pas du texte, uniquement des usages que les lecteurices font du livre.

Les usages du livre sur papier forment l'essentiel de cet ouvrage, qui note que le livre numérique fait apparemment peu l'objet de ces diverses formes d'échange. On le lit, mais c'est tout.

Les usages du livre papier sont très variés (sans compter, dirait le cynique, celui de caler les meubles). Et les avis des lecteurices sont également divers. L'annotation, par exemple, est sans doute le chapitre où les avis sont les plus tranchés, entre celles et ceux qui considèrent le livre comme « sacré », et qui ne se permettraient pas d'y ajouter la moindre marque, et ceux et celles qui griffonnent, corrigent, et ajoutent des commentaires au stylo rouge. Le livre n'est clairement pas un objet comme les autres. À propos de l'achat de livres d'occasion, une lectrice explique qu'elle n'y recourt pas, car elle lit au lit et qu'elle ne veut pas faire rentrer dans son lit, espace intime, des livres déjà manipulés par un inconnu…

En résumé, un bel hommage à l'abondance de pratiques sociales autour du livre.

Déclaration de conflit d'intérêt : j'ai reçu un exemplaire de ce livre gratuitement.

2018-08-29

☕︎ Confiance et politique

Je vous invite à regarder/écouter cette audition qui a le mérite de donner certaines clés de compréhension de la situation énergétique liée aux transports en France. Attention, c’est relativement direct ! Puis arrive finalement la question de la confiance dans le politique et de la réticence pour les industriels à pouvoir s’engager sur du moyen ou long terme avec un gouvernement qui dit tout et son contraire dans la même année.

Si l’on envisage des changements radicaux, il va falloir y aller ensemble. D’un point de vue anthropocénologue, je trouve cette situation passionnante. D’un point de vue humain, je suis plus mitigé…

Merci Emmanuel !

2018-08-28

☕︎ Collaborer ou renverser

Je n’ai pas les réponses à ses questions. Voilà ce que je sais : je hais la civilisation industrielle, pour ce qu’elle fait à la planète, pour ce qu’elle fait aux communautés, pour ce qu’elle fait à tous les non humains (sauvages et domestiqués), et pour ce qu’elle fait à tous les humains (sauvages et domestiqués). Je hais l’économie salariale, parce qu’elle pousse — ou, plutôt, qu’elle oblige — les humains à vendre leur vie et à la perdre en faisant des choses qu’ils n’aiment pas faire, et parce qu’elle récompense le fait que nous nous faisions du mal entre nous, et que nous détruisions nos territoires. Je hais l’éducation industrielle parce qu’elle commet l’un des plus impardonnables péchés qui soient : elle pousse les êtres humains à ne pas être qui ils sont, elle en fait des travailleurs convaincus qu’il est dans leur meilleur intérêt d’être les esclaves les plus loyaux, de faire voguer la galère qu’est la civilisation industrielle aussi frénétiquement — ardemment, luxurieusement — que possible, vers l’enfer, en les contraignant d’entraîner avec eux tous ceux et tout ce qu’ils croisent. Et je participe à ce processus. J’aide à rendre l’école un peu plus acceptable, un peu plus amusante, tandis que les étudiants sont formés afin de prendre part à la destruction en cours de la planète, tandis qu’ils entrent dans la phase finale du renoncement à leur droit inaliénable d’être des humains libres et heureux et qu’ils endossent les rôles de rouages dans l’immense machinerie industrielle ou, pire, de gardiens du camp de travail/d’esclavage géant que nous percevions autrefois comme une planète vivante. Cela fait-il de moi un collaborateur ?

Lire, écrire et la révolution (par Derrick Jensen) (cache)

Je pense qu’il y a ce questionnement en chacun de nous, et que l’on s’essaye à l’un et à l’autre au cours de nos vies.

Comment se mesure le « succès/impact » de nos intentions présentes ? Là peut-être est la définition du contentement… ou de son illusion.

2018-08-27

☕︎ It only takes one

There is some truth to this illustration of the polarization of feelings felt through coding. However, it is all too common for individuals to wholly identify with one or the other. On the one side we have our rock stars, our 10x developers and brogrammers. On the other we have people dogged by imposter syndrome. In reality, the two abstract states represent a continuous and exaggerated part of us all. Having said that, I believe that everyone is in the middle, but much closer to the second state than the first. All of us.

In my personal experience I have felt a strong feeling of camaraderie when I’m working with people who all humbly admit they don’t really know what they’re doing. This qualification is important - nobody is saying they are truly incompetent, just that there are distinct limits to their knowledge and understanding. There is the sense that we don’t have all the answers, but we will nonetheless figure it out together. It promotes a culture of learning and teamwork. When everyone makes themselves vulnerable in this way great things can happen. The problem is that it only takes one asshole to fuck all that up.

Do the Right Thing (cache)

Great article, this excerpt is just one point of a more profound reflexion on being right vs. doing the right thing.

2018-08-26

☕︎ The cost of connections

In computational simulations, we find that networks without a connection cost do not evolve to be hierarchical, even when the task has a hierarchical structure. However, with a connection cost, networks evolve to be both modular and hierarchical, and these networks exhibit higher overall performance and evolvability (i.e. faster adaptation to new environments). Additional analyses confirm that hierarchy independently improves adaptability after controlling for modularity. Overall, our results suggest that the same force–the cost of connections–promotes the evolution of both hierarchy and modularity, and that these properties are important drivers of network performance and adaptability.

The Evolutionary Origins of Hierarchy (cache (PDF, 5 Mb))

This article gives some insights on why it might be more pertinent to choose a hierarchical network in case of “hierarchical logic problems with many inputs and one output”. The world is more complex though, but the cost of connections is still relevant to choose the appropriate way of being modular given the size of the group considered.

My take away: only small cultures can stay horizontal.

Thanks Aurélien!

2018-08-25

☕︎ Tours de poteau

Il s’agit de la manière réputée être la plus facile pour changer de situation en terme de visa. Aller mettre un pied aux USA, se faire refuser l’accès mais revenir vers la frontière canadienne avec un sésame justifiant la sortie du territoire.

Sauf que les services frontaliers ont d’autres choses à faire et ne prennent que quelques dossiers par jour. Ainsi pour un bureau qui ouvre à 9h, il faut commencer à faire la queue vers 6h si on veut avoir la chance d’être dans les quotas (en tout cas en cette saison). Après deux essais infructueux, on abandonne.

Les alternatives :

  • prendre l’avion pour sortir du territoire…
  • passer par une procédure en ligne qui coûte 200$ avec des questions incompréhensibles.

🤷‍♂️

Il faudra que je vous parle du sentiment d’être immigré.

2018-08-24

☕︎ Faire partie de la solution

La méthode de consensus N. Street : contribuer à la solution

Cette modification au consensus — que je recommande vivement si un groupe veut se servir de ce mode de prise de décision — a été utilisée avec succès par N. Street Cohousing à Davis, en Californie, depuis le milieu des années 1980. Si une ou quelques personnes bloquent une proposition, elles doivent alors rencontrer un ou deux partisans de la proposition dans une série de réunions de résolution. Cependant, si quelques personnes bloquent une proposition, signe qu’elle ne dispose pas d’un soutien suffisant, celle-ci est rejetée et les réunions de résolution n’ont pas lieu.

Si elles ont lieu, les petits groupes peuvent se réunir jusqu’à six fois sur une période de trois mois (ils ne sont pas obligés de se réunir six fois ni de prendre trois mois, c’est simplement la limite permise). Leur travail consiste à élaborer une nouvelle proposition qui concerne les mêmes problèmes que la proposition bloquée.

La ou les personnes qui bloquent sont responsables de l’organisation des réunions.

Si une nouvelle proposition qui fait l’objet d’un accord est formulée, elle sera présentée à la prochaine assemblée comme n’importe quelle nouvelle proposition.

Mais si les parties opposées ne peuvent en arriver à une nouvelle proposition, ou si les réunions de résolution n’ont pas lieu, la proposition originale sera de nouveau présentée à la prochaine assemblée où elle pourra être adoptée par un vote à majorité qualifiée de 67 %.

Cette méthode de consensus oblige quiconque souhaite bloquer une proposition à assumer plus de responsabilités quant aux répercussions de ses actions sur le groupe. « Si vous avez bloqué, vous devez faire partie de la solution », explique Kevin Wolf, cofondateur de N. Street Cohousing et concepteur de cette méthode.

Vivre autrement, Diana Leafe Christian

Transformer la force d’opposition en puissance créatrice. Beaucoup d’alternatives inspirantes dans cet ouvrage, issues de cas réels.

2018-08-23

☕︎ Moving in alignment

“Alignment” is not the same thing as “agreement,” although people often conflate the two. A group might verbally agree on a destination, but its participants might still move in conflicting directions. Conversely, a group might move in perfect lock-step without ever having explicitly agreed on where it’s going or how (as was the case in my pickup game). It might even achieve this while explicitly disagreeing.

This distinction is important, because it’s not necessarily hard to get a group to agree on something. One way is to make a statement that is so abstract, it’s both indisputable and meaningless. An example of something I often hear is, “We value collaboration.” Another one is, “Our goal is to better serve our customers.” Very few people would disagree with either of those statements, but by themselves, they’re too broad to mean anything. Agreement without alignment also often happens in groups with conflict-averse cultures, where people would rather assent than argue.

Being in alignment is different than moving in alignment. If the goal is for everyone to be moving toward the same goal in rhythm and without resistance, then everyone must both want to move in alignment with everyone else and be capable of doing this. You achieve the former by aligning. You achieve the latter by practicing.

How do you get a group into alignment? How can you tell when a group is aligned? And how can groups practice moving in alignment?

The Art of Aligning Groups (cache)

A lot of thoughts and discussions these days about values, with different sizes of (meta)groups. I like this article insisting on the fact that alignment is a constant adjustment of positions from people composing the group. This is a dynamic path requiring a constant attention to keep the alignment.

Without taking the time to readjust continuously, spirals are slowly but surely diverging.

2018-08-22

☕︎ Serment d’Hippocrate

Les deux initiatives s’inspirent du serment d’Hippocrate que les médecins prêtent à la fin de leurs études. Ce rite de passage qui a plus valeur morale que portée juridique (par rapport au code de déontologie par exemple) rappelle aux médecins qu’ils ont des obligations légales, morales et éthiques. Mais, comme l’explique très bien l’écrivain et médecin Martin Winckler dans l’édifiant Les brutes en blanc (2016), son ouvrage sur la maltraitance médicale, l’éthique n’a cessé d’évoluer. Dans le serment d’Hippocrate originel, il est ainsi interdit aux médecins d’offrir aux femmes la possibilité d’avorter sans que leur mari l’ait décidé. L’éthique se définit toujours par rapport à la morale dominante… rappelle Winckler. Pour lui, le serment d’Hippocrate derrière lequel se cache le corps médical est devenu une barrière à l’évolution des pratiques éthiques (comme de reconsidérer les questions de fin de vie ou de maltraitance). Le serment ne protège pas de la culture propre à chaque discipline, et le prêter ne protège pas de l’asymétrie de la relation entre le médecin et le patient, pas plus qu’elle ne protège de l’asymétrie entre le système de calcul et le calculé. Les règles de conduite ne suffisent pas toujours à créer des repères moraux.

Concrètement, comment rendre les algorithmes responsables et équitables ? (cache)

Un précieux rappel pour celles et ceux qui voudraient appliquer un serment (ou assimilé) aux professions autour du développement. Le risque est de ne plus utiliser son cerveau, ses convictions et son expérience pour déterminer ce qui est moralement acceptable ou pas.

Il y a une certaine ironie à vouloir appliquer une règle se rapprochant d’un algorithme pour réguler… les algorithmes :-).

2018-08-21

☕︎ Better informed

Obviously the question then is, why is it that better informed people are more optimistic about the future?

As we have seen, being wrong about global development mostly means being too negative about how the world is changing. Being wrong in these questions means having a cynical worldview. Cynicism suggests that nothing can be done to improve our situation and every effort to do so is bound to fail. Our history, the cynics say, is a history of failures and what we can expect for the future is more of the same.

In contrast to this, answering the questions correctly means that you understand that things can change. An accurate understanding of how global health and poverty are improving leaves no space for cynicism. Those who are optimistic about the future can base their view on the knowledge that it is possible to change the world for the better, because they know that we did.

Most of us are wrong about how the world has changed (especially those who are pessimistic about the future) (cache)

At which price? More people to suffocate? (cache) More slaves to go outside for us?

2018-08-20

☕︎ Qualité poétique

Le salut n’est pas seulement dans une vision politico-historique, il est aussi dans l’exercice quotidien de la vie. Et justement, dans la vie, il faut savoir privilégier ces moments. C’est ce que j’appelle la différence des deux polarités de la vie : la polarité prosaïque et la polarité poétique. La prose, ce sont toutes ces choses qui nous emmerdent, que l’on fait par obligation, que l’on subit… alors que la poésie est ce qui nous dilate, nous donne la communion, exprime la communauté, la jouissance, le jeu… c’est ça la qualité poétique de la vie. En dehors de toute mission, de toute réalisation d’une autre société, nous ne devons jamais oublier cette dimension et c’est peut-être cela qui nous donne ce que vous appelez le courage, cet élan de vivre. Je vis au maximum que je peux la qualité poétique de la vie, et le fait de pouvoir convaincre autrui de vivre la qualité poétique de sa propre vie est déjà une chose positive, sans attendre qu’il y ait une nouvelle société, une nouvelle révolution, etc. De même que Gandhi disait : pratique d’abord sur toi la réforme que tu voudrais appliquer à la société, pratique déjà sur toi cet état poétique que tu voudrais voir régner dans le monde humain…

L’urgence et l’essentiel, Edgar Morin

Alors que mes timelines ne parlent que d’effondrement (c’est devenu tellement à la mode que je n’ose plus creuser en public de peur d’ajouter encore plus de bruit), il est bon d’avoir aussi des messages d’espoirs et de pensées positives.

2018-08-19

☕︎ Conditions de subsistance

Êtes-vous capables de définir ce qui vous permet, vous, de subsister ?

Si oui, alors je prétends que la liste que vous pouvez dresser de vos conditions de subsistance définit le territoire que vous habitez. Peu importe si vous devez y inclure des éléments répartis sur la Terre entière. Ce n’est pas l’espace qui définit un territoire mais les attachements, les conditions de vie. Et j’ajouterais que vous avez un territoire si vous pouvez le visualiser et, bien sûr, que vous tentez de le faire prospérer et de le défendre avec et contre d’autres qui veulent se l’approprier.

Des questions liées : subsistance, visualisation, protection et défense. Mais supposez que vous n’ayez aucune idée précise de ce qui vous permet de subsister, ou une idée tellement abstraite que vous restiez suspendu en l’air, pratiquement hors sol, quand je vous pose la question : « Qui êtes-vous, que voulez-vous, où habitez-vous ? » Eh bien, je prétends que n’ayant pas de monde concret à décrire, vous êtes devenus incapables de définir vos « intérêts » et qu’ainsi, vous ne pourrez plus articuler aucune position politique vaguement défendable. Je prétends que la situation actuelle de retour général à l’Etat-nation derrière des murs vient directement de cette totale impossibilité de préciser quels intérêts on défend. Comment avoir des intérêts si vous ne pouvez pas décrire votre monde ?

La libellule et la muraille. (cache) — En vrai Bruno Latour cité par Olivier Ertzscheid mais je n’ai pas accès à l’article complet sur le monde…

Il faut que je creuse cette notion là lors de ma prochaine escapade car elle me semble essentielle pour comprendre certains des enjeux.

2018-08-18

☕︎ Ni bien-être ni paix

Je m’oppose à cette idée que les idéologies sont mortes, mais force est de constater que nous peinons à produire une pensée construite, complète et sérieuse non seulement de l’alternative mais également philosophique sur une idée de l’homme, du monde et des sociétés. Ce n’est qu’avec la force de cette vision plus globale que nous pourrons contester l’idée désormais reçue et acceptée à droite comme chez la plupart des partis de gauche, devenus socio-capitalistes, que l’économie de marché, la spéculation et le néolibéralisme sont des réalités incontestables, devenus immuables, des vérités vérifiées de l’activité économique. Je pense que les partis dits d’extrême gauche et leurs économistes de gauche se trompent quand ils pensent que l’alternative naîtra de la seule critique des logiques et des excès de l’économie néolibérale. La critique de l’économie a besoin, en amont, d’une conception de l’homme, des sociétés et du monde qui considère la nature et l’ensemble du vivant. Il en est de même pour la démarche critique en politique, dans notre quête d’une meilleure gouvernance, comme dans les dynamiques sociales. Nos approches critiques sont fragmentées et correspondent exactement à ce que l’ordre dominant nous impose : une fragmentation, des cloisonnements, une déconstruction du réel qui invite à la pensée technicienne, opérationnelle, et non au questionnement philosophique et anthropologique sur le sens et les finalités.

[…]

C’est cela que je voulais dire quand je parlais d’établir des liens, des correspondances, qui nous permettent d’extraire des processus et des logiques dans l’évolution du monde et des sociétés. Cette démarche est propre à réinsuffler de l’espoir en donnant du sens à nos combats régionaux ou nationaux. Il faut donc changer notre regard sur le monde et faire nôtres, sur le plan méthodologique, la transdisciplinarité des savoirs et l’interdépendance des situations sociales et politiques. Établir des liens par exemple entre les migrations, la gestion de nos sociétés, et les politiques économiques et sociales que nous imposons au monde. Et, inductivement, éveiller la conscience politique des citoyens à la lumière des enjeux internationaux. Nous ne serons jamais en paix si nos gouvernements répandent la mort dans le monde, soi-disant pour notre bien-être. Il faut aller plus loin et accepter de reconsidérer la nature même de notre bien-être si nous voulons obtenir la paix. Si notre bien-être se mesure sur les indices de production et le pouvoir d’achat alors nous n’aurons ni bien-être ni paix.

L’urgence et l’essentiel, Tariq Ramadan

Je suis à peu près en désaccord avec toutes les interventions de Tariq Ramadan dans cet ouvrage qui est une discussion avec Edgar Morin. Mais c’est aussi le but de l’exercice, ne pas lire que des idées avec lesquelles je suis dans l’acquiescement.

Toujours est-il qu’ici ça me conforte dans ma réflexion précédente. Il ne s’agit pas uniquement de tenter de ralentir l’autoroute vers le ravin mais de montrer des chemins de traverse qui semblent enthousiasmants.

2018-08-17

☕︎ Acroissance

Le mot ne doit donc pas être pris au pied de la lettre : décroître pour décroître serait aussi absurde que croître pour croître. Bien entendu, les décroissants entendent améliorer la qualité de vie, celle de l’air, de l’eau et d’une foule de choses que la croissance pour la croissance a détruites. Pour parler de façon rigoureuse, il faudrait sans doute utiliser le terme « acroissance », comme on parle d’athéisme. L’enjeu est d’ailleurs très exactement celui-ci : l’abandon d’une foi et d’une religion, celles du progrès et du développement.

La décroissance ou le sens des limites (cache)

Est-ce que l’on peut abandonner la croissance sans être motivé par une alternative ? À quel point l’athéisme a mené au capitalisme ?

Vous avez la fin de semaine.

2018-08-16

☕︎ Water is being stolen

Or let’s talk water. We so often hear that the world is running out of water. People are dying from lack of water. Rivers are dewatered from lack of water. Because of this we need to take shorter showers. See the disconnect? Because I take showers, I’m responsible for drawing down aquifers? Well, no. More than 90 percent of the water used by humans is used by agriculture and industry. The remaining 10 percent is split between municipalities and actual living breathing individual humans. Collectively, municipal golf courses use as much water as municipal human beings. People (both human people and fish people) aren’t dying because the world is running out of water. They’re dying because the water is being stolen.

Forget Shorter Showers (cache)

Always interesting to put into perspective some figures.

2018-08-15

☕︎ Modern slavery

Contrary to the story Uber, Lyft, and their peers like to tell, ride-hailing services are not reducing traffic in American cities. Nor will they, even if they meet their goals for converting solo passenger trips to shared rides, according to new research from transportation analyst Bruce Schaller.

While ride-hailing companies add options for people to get around without owning a personal car, Schaller shows that the overall effect of their growth has been to jam more motor vehicle traffic onto crowded city streets. Also known as transportation network companies, or TNCs, Uber and Lyft haven’t just supplanted taxis, they’ve more than tripled total for-hire vehicle mileage in the span of a few short years.

Uber and Lyft Are Overwhelming Urban Streets, and Cities Need to Act Fast (cache)

There is a lot to say about new ways to be served by slaves. Last week, I went to an Italian caterer and I realized I was the only one in the line waiting for a food I would actually eat myself. Other meals were delivered by car with a unique person in it.

Depressing.

2018-08-14

☕︎ Three pillars

To protect folks from these kinds of risks, we’ve made a move to increase the security of the web by doing everything we can to get everything running over HTTPS. It’s undeniably a vital move to make. However this combination—poor performance but good security—now ends up making the web inaccessible to many. The three pillars—security, accessibility and performance—can’t be considered in isolation. All three play a role and must be built-up in concert with each other.

On HTTPS and Hard Questions (cache)

I couldn’t agree more.

2018-08-13

☕︎ Choix de publication

Ici, j’écris des mots. Ici les mots me pensent. De mon cerveau à ma main. De la main au clavier. Du clavier à l’écran. De l’écran à mes yeux. De mes yeux au cerveau. Et nous y retournons. Une fois synchronisés, puis distribués sur vos écrans respectifs, quelque soit votre lieu—maintenant—quand et où vous lisez cela, ses mots vous pensent. De votre écran à vos yeux, de vos yeux à votre cerveau. Ils viennent déranger l’agencement de votre environnement, la respiration de votre mouvement. Ils sont là maintenant, multiples. Ils existent avec vous.

Le talisman - Carnets Web de La Grange (cache)

On m’a récemment demandé pourquoi est-ce que j’avais fait le choix de ne publier qu’à un seul endroit, ici. La réponse est multiple :

  1. pour conserver le contrôle de ce que j’écris, il s’agit d’une partie de ma mémoire que j’estime et que je ne peux confier à une entité tierce ayant une durée de vie inférieure à la mienne ;
  2. par respect pour mes lecteurs, c’est le seul moyen que j’ai trouvé pour que leurs actions ne soient pas épiées de manière centralisée au cours de la consultation de ces contenus ;
  3. par intimité des contenus produits, je pourrais adopter la pratique POSSE mais je suis satisfait que ces idées restent dans un certain contexte.

La suite de la discussion était sur les choix possibles quant à la découverte de ces contenus et comment fixer cette frontière de l’intimité. J’ai l’intuition (faute de statistiques) qu’ils circulent par liens dans un cercle relativement restreint, parfois via les réseaux sociaux. Il m’arrive rarement de lier des billets sur des canaux de discussion et je mets généralement la page d’accueil en profil sur les différents espaces que je côtoie.

Si je devais passer à du push (en complément du pull qui est le modèle du navigateur) ce serait probablement avec une liste de diffusion dédiée pour diverses raisons (cache), je suis notamment sensible au fait que ça décentraliserait les contenus.

Si tant est qu’ils ne finissent pas tous sur les serveurs de GMail…

2018-08-12

☕︎ Do No Harm License

A license for developers who write open source code to make the world a better place

As developers we can no longer close our eyes to the fact that open source code is being used by individuals and organizations to the detriment of our society.

The Do No Harm License is for developers that agree in general with the principles of open source software, but are uncomfortable with their software being used as part of efforts to destroy lives, our environment and our future.

In short, developers who use this license want their code to contribute to a just world for all.

A licence for using software for good (cache)

Reading the current content of the license (cache) I wonder how it can be applicable given how generic the intentions are.

At least, it gives a clear orientation :-).

2018-08-11

☕︎ The History of the Web

The web’s most fascinating stories, delivered each week.

[…]

Prefer RSS? Fine by me

The History of the Web (cache)

Kudos to Jay Hoffmann for these little stories. The last one about clearfix (cache) is pure gold for dinos like me.

Note: please provide an RSS feed if you have a mailing-list 🙏.

RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3

Après un très long processus, et d'innombrables polémiques, la nouvelle version du protocole de cryptographie TLS, la 1.3, est enfin publiée. Les changements sont nombreux et, à bien des égards, il s'agit d'un nouveau protocole (l'ancien était décrit dans le RFC 5246, que notre nouveau RFC remplace).

Vous pouvez voir l'histoire de ce RFC sur la Datatracker de l'IETF. Le premier brouillon a été publié en avril 2014, plus de trois années avant le RFC. C'est en partie pour des raisons techniques (TLS 1.3 est très différent de ses prédécesseurs) et en partie pour des raisons politiques. C'est que c'est important, la sécurité ! Cinq ans après les révélations de Snowden, on sait désormais que des acteurs puissants et sans scrupules, par exemple les États, espionnent massivement le trafic Internet. Il est donc crucial de protéger ce trafic, entre autres par la cryptographie. Mais dire « cryptographie » ne suffit pas ! Il existe des tas d'attaques contre les protocoles de cryptographie, et beaucoup ont réussi contre les prédécesseurs de TLS 1.3. Il était donc nécessaire de durcir le protocole TLS, pour le rendre moins vulnérable. Et c'est là que les ennuis ont commencé. Car tout le monde ne veut pas de la sécurité. Les États veulent continuer à espionner (le GCHQ britannique s'était clairement opposé à TLS 1.3 sur ce point). Les entreprises veulent espionner leurs employés (et ont pratiqué un lobbying intense contre TLS 1.3). Bref, derrière le désir de « sécurité », partagé par tout le monde, il y avait un désaccord de fond sur la surveillance. À chaque réunion de l'IETF, une proposition d'affaiblir TLS pour faciliter la surveillance apparaissait, à chaque fois, elle était rejetée et, tel le zombie des films d'horreur, elle réapparaissait, sous un nom et une forme différente, à la réunion suivante. Par exemple, à la réunion IETF de Prague en juillet 2017, l'affrontement a été particulièrement vif, alors que le groupe de travail TLS espérait avoir presque fini la version 1.3. Des gens se présentant comme enterprise networks ont critiqué les choix de TLS 1.3, notant qu'il rendait la surveillance plus difficile (c'était un peu le but…) gênant notamment leur déboguage. Ils réclamaient un retour aux algorithmes n'ayant pas de sécurité persistante. Le début a suivi le schéma classique à l'IETF : « vous réclamez un affaiblissement de la sécurité » vs. « mais si on ne le fait pas à l'IETF, d'autres le feront en moins bien », mais, au final, l'IETF est restée ferme et n'a pas accepté de compromissions sur la sécurité de TLS. (Un résumé du débat est dans « TLS 1.3 in enterprise networks ».)

Pour comprendre les détails de ces propositions et de ces rejets, il faut regarder un peu en détail le protocole TLS 1.3.

Revenons d'abord sur les fondamentaux : TLS est un mécanisme permettant aux applications client/serveur de communiquer au travers d'un réseau non sûr (par exemple l'Internet) tout en empêchant l'écoute et la modification des messages. TLS suppose un mécanisme sous-jacent pour acheminer les bits dans l'ordre, et sans perte. En général, ce mécanisme est TCP. Avec ce mécanisme de transport, et les techniques cryptographiques mises en œuvre par dessus, TLS garantit :

  • L'authentification du serveur (celle du client est facultative), authentification qui permet d'empêcher l'attaque de l'intermédiaire, et qui se fait en général via la cryptographie asymétrique,
  • La confidentialité des données (mais attention, TLS ne masque pas la taille des données, permettant certaines analyses de trafic),
  • L'intégrité des données (qui est inséparable de l'authentification : il ne servirait pas à grand'chose d'être sûr de l'identité de son correspondant, si les données pouvaient être modifiées en route).
Ces propriétés sont vraies même si l'attaquant contrôle complètement le réseau entre le client et le serveur (le modèle de menace est détaillé dans la section 3 - surtout la 3.3 - du RFC 3552, et dans l'annexe E de notre RFC).

TLS est un protocole gros et compliqué (ce qui n'est pas forcément optimum pour la sécurité). Le RFC fait 147 pages. Pour dompter cette complexité, TLS est séparé en deux composants :

  • Le protocole de salutation (handshake protocol), chargé d'organiser les échanges du début, qui permettent de choisir les paramètres de la session (c'est un des points délicats de TLS, et plusieurs failles de sécurité ont déjà été trouvées dans ce protocole pour les anciennes versions de TLS),
  • Et le protocole des enregistrements (record protocol), au plus bas niveau, chargé d'acheminer les données chiffrées.
Pour comprendre le rôle de ces deux protocoles, imaginons un protocole fictif simple, qui n'aurait qu'un seul algorithme de cryptographie symétrique, et qu'une seule clé, connue des deux parties (par exemple dans leur fichier de configuration). Avec un tel protocole, on pourrait se passer du protocole de salutation, et n'avoir qu'un protocole des enregistrements, indiquant comment encoder les données chiffrées. Le client et le serveur pourraient se mettre à communiquer immédiatement, sans salutation, poignée de mains et négociation, réduisant ainsi la latence. Un tel protocole serait très simple, donc sa sécurité serait bien plus facile à analyser, ce qui est une bonne chose. Mais il n'est pas du tout réaliste : changer la clé utilisée serait complexe (il faudrait synchroniser exactement les deux parties), remplacer l'algorithme si la cryptanalyse en venait à bout (comme c'est arrivé à RC4, cf. RFC 7465) créerait un nouveau protocole incompatible avec l'ancien, communiquer avec un serveur qu'on n'a jamais vu serait impossible (puisque on ne partagerait pas de clé commune), etc. D'où la nécessité du protocole de salutation, où les partenaires :
  • S'authentifient avec leur clé publique (ou, si on veut faire comme dans le protocole fictif simple, avec une clé secrète partagée),
  • Sélectionnent l'algorithme de cryptographie symétrique qui va chiffrer la session, ainsi que ses paramètres divers,
  • Choisir la clé de la session TLS (et c'est là que se sont produites les plus grandes bagarres lors de la conception de TLS 1.3).

Notez que TLS n'est en général pas utilisé tel quel mais via un protocole de haut niveau, comme HTTPS pour sécuriser HTTP. TLS ne suppose pas un usage particulier : on peut s'en servir pour HTTP, pour SMTP (RFC 7672), pour le DNS (RFC 7858), etc. Cette intégration dans un protocole de plus haut niveau pose parfois elle-même des surprises en matière de sécurité, par exemple si l'application utilisatrice ne fait pas attention à la sécurité (Voir mon exposé à Devoxx, et ses transparents.)

TLS 1.3 est plutôt un nouveau protocole qu'une nouvelle version, et il n'est pas directement compatible avec son prédécesseur, TLS 1.2 (une application qui ne connait que 1.3 ne peut pas parler avec une application qui ne connait que 1.2.) En pratique, les bibliothèques qui mettent en œuvre TLS incluent en général les différentes versions, et un mécanisme de négociation de la version utilisée permet normalement de découvrir la version maximum que les deux parties acceptent (historiquement, plusieurs failles sont venues de ce point, avec des pare-feux stupidement configurés qui interféraient avec la négociation).

La section 1.3 de notre RFC liste les différences importantes entre TLS 1.2 (qui était normalisé dans le RFC 5246) et 1.3 :

  • La liste des algorithmes de cryptographie symétrique acceptés a été violemment réduite. Beaucoup trop longue en TLS 1.2, offrant trop de choix, comprenant plusieurs algorithmes faibles, elle ouvrait la voie à des attaques par repli. Les « survivants » de ce nettoyage sont tous des algorithmes à chiffrement intègre.
  • Un nouveau service apparait, 0-RTT (zero round-trip time, la possibilité d'établir une session TLS avec un seul paquet, en envoyant les données tout de suite), qui réduit la latence du début de l'échange. Attention, rien n'est gratuit en ce monde, et 0-RTT présente des nouveaux dangers, et ce nouveau service a été un des plus controversés lors de la mise au point de TLS 1.3, entrainant de nombreux débats à l'IETF.
  • Désormais, la sécurité future est systématique, la compromission d'une clé secrète ne permet plus de déchiffrer les anciennes communications. Plus de clés publiques statiques, tout se fera par clés éphémères. C'était le point qui a suscité le plus de débats à l'IETF, car cela complique sérieusement la surveillance (ce qui est bien le but) et le déboguage.
  • Plusieurs messages de négociation qui étaient auparavant en clair sont désormais chiffrés. Par contre, l'indication du nom du serveur (SNI, section 3 du RFC 6066) reste en clair et c'est l'une des principales limites de TLS en ce qui concerne la protection de la vie privée. Le problème est important, mais très difficile à résoudre (voir par exemple la proposition ESNI, Encrypted SNI.)
  • Les fonctions de dérivation de clé ont été refaites.
  • La machine à états utilisée pour l'établissement de la connexion également (elle est détaillée dans l'annexe A du RFC).
  • Les algorithmes asymétriques à courbes elliptiques font maintenant partie de la définition de base de TLS (cf. RFC 7748), et on voit arriver des nouveaux comme ed25519 (cf. RFC 8422).
  • Par contre, DSA a été retiré.
  • Le mécanisme de négociation du numéro de version (permettant à deux machines n'ayant pas le même jeu de versions TLS de se parler) a changé. L'ancien était très bien mais, mal implémenté, il a suscité beaucoup de problèmes d'interopérabilité. Le nouveau est censé mieux gérer les innombrables systèmes bogués qu'on trouve sur l'Internet (la bogue ne provenant pas tant de la bibliothèque TLS utilisée que des pare-feux mal programmés et mal configurés qui sont souvent mis devant).
  • La reprise d'une session TLS précédente fait l'objet désormais d'un seul mécanisme, qui est le même que celui pour l'usage de clés pré-partagées. La négociation TLS peut en effet être longue, en terme de latence, et ce mécanisme permet d'éviter de tout recommencer à chaque connexion. Deux machines qui se parlent régulièrement peuvent ainsi gagner du temps.
Un bon résumé de ce nouveau protocole est dans l'article de Mark Nottingham.

Ce RFC concerne TLS 1.3 mais il contient aussi quelques changements pour la version 1.2 (section 1.4 du RFC), comme un mécanisme pour limiter les attaques par repli portant sur le numéro de version, et des mécanismes de la 1.3 « portés » vers la 1.2 sous forme d'extensions TLS.

La section 2 du RFC est un survol général de TLS 1.3 (le RFC fait 147 pages, et peu de gens le liront intégralement). Au début d'une session TLS, les deux parties, avec le protocole de salutation, négocient les paramètres (version de TLS, algorithmes cryptographiques) et définissent les clés qui seront utilisées pour le chiffrement de la session. En simplifiant, il y a trois phases dans l'établissement d'une session TLS :

  • Définition des clés de session, et des paramètres cryptographiques, le client envoie un ClientHello, le serveur répond avec un ServerHello,
  • Définition des autres paramètres (par exemple l'application utilisée au-dessus de TLS, ou bien la demande CertificateRequest d'un certificat client), cette partie est chiffrée, contrairement à la précédente,
  • Authentification du serveur, avec le message Certificate (qui ne contient pas forcément un certificat, cela peut être une clé brute - RFC 7250 ou une clé d'une session précédente - RFC 7924).
Un message Finished termine cette ouverture de session. (Si vous êtes fana de futurisme, notez que seule la première étape pourrait être remplacée par la distribution quantique de clés, les autres resteraient indispensables. Contrairement à ce que promettent ses promoteurs, la QKD ne dispense pas d'utiliser les protocoles existants.)

Comment les deux parties se mettent-elles d'accord sur les clés ? Trois méthodes :

  • Diffie-Hellman sur courbes elliptiques qui sera sans doute la plus fréquente,
  • Clé pré-partagée,
  • Clé pré-partagée avec Diffie-Hellman,
  • Et la méthode RSA, elle, disparait de la norme (mais RSA peut toujours être utilisé pour l'authentification, autrement, cela ferait beaucoup de certificats à jeter…)

Si vous connaissez la cryptographie, vous savez que les PSK, les clés partagées, sont difficiles à gérer, puisque devant être transmises de manière sûre avant l'établissement de la connexion. Mais, dans TLS, une autre possibilité existe : si une session a été ouverte sans PSK, en n'utilisant que de la cryptographie asymétrique, elle peut être enregistrée, et resservir, afin d'ouvrir les futures discussions plus rapidement. TLS 1.3 utilise le même mécanisme pour des « vraies » PSK, et pour celles issues de cette reprise de sessions précédentes (contrairement aux précédentes versions de TLS, qui utilisaient un mécanisme séparé, celui du RFC 5077, désormais abandonné).

Si on a une PSK (gérée manuellement, ou bien via la reprise de session), on peut même avoir un dialogue TLS dit « 0-RTT ». Le premier paquet du client peut contenir des données, qui seront acceptées et traitées par le serveur. Cela permet une importante diminution de la latence, dont il faut rappeler qu'elle est souvent le facteur limitant des performances. Par contre, comme rien n'est idéal dans cette vallée de larmes, cela se fait au détriment de la sécurité :

  • Plus de confidentialité persistante, si la PSK est compromise plus tard, la session pourra être déchiffrée,
  • Le rejeu devient possible, et l'application doit donc savoir gérer ce problème.
La section 8 du RFC et l'annexe E.5 détaillent ces limites, et les mesures qui peuvent être prises.

Le protocole TLS est décrit avec un langage spécifique, décrit de manière relativement informelle dans la section 3 du RFC. Ce langage manipule des types de données classiques :

  • Scalaires (uint8, uint16),
  • Tableaux, de taille fixe - Datum[3] ou variable, avec indication de la longueur au début - uint16 longer<0..800>,
  • Énumérations (enum { red(3), blue(5), white(7) } Color;),
  • Enregistrements structurés, y compris avec variantes (la présence de certains champs dépendant de la valeur d'un champ).
Par exemple, tirés de la section 4 (l'annexe B fournit la liste complète), voici, dans ce langage, la liste des types de messages pendant les salutations, une énumération :
       enum {
          client_hello(1),
          server_hello(2),
          new_session_ticket(4),
          end_of_early_data(5),
          encrypted_extensions(8),
          certificate(11),
          certificate_request(13),
          certificate_verify(15),
          finished(20),
          key_update(24),
          message_hash(254),
          (255)
      } HandshakeType;
    
Et le format de base d'un message du protocole de salutation :
      struct {
          HandshakeType msg_type;    /* handshake type */
          uint24 length;             /* bytes in message */
          select (Handshake.msg_type) {
              case client_hello:          ClientHello;
              case server_hello:          ServerHello;
              case end_of_early_data:     EndOfEarlyData;
              case encrypted_extensions:  EncryptedExtensions;
              case certificate_request:   CertificateRequest;
              case certificate:           Certificate;
              case certificate_verify:    CertificateVerify;
              case finished:              Finished;
              case new_session_ticket:    NewSessionTicket;
              case key_update:            KeyUpdate;
          };
      } Handshake;     
    

La section 4 fournit tous les détails sur le protocole de salutation, notamment sur la délicate négociation des paramètres cryptographiques. Notez que la renégociation en cours de session a disparu, donc un ClientHello ne peut désormais plus être envoyé qu'au début.

Un problème auquel a toujours dû faire face TLS est celui de la négociation de version, en présence de mises en œuvre boguées, et, surtout, en présence de boitiers intermédiaires encore plus bogués (pare-feux ignorants, par exemple, que des DSI ignorantes placent un peu partout). Le modèle original de TLS pour un client était d'annoncer dans le ClientHello le plus grand numéro de version qu'on gère, et de voir dans ServerHello le maximum imposé par le serveur. Ainsi, un client TLS 1.2 parlant à un serveur qui ne gère que 1.1 envoyait ClientHello(client_version=1.2) et, en recevant ServerHello(server_version=1.1), se repliait sur TLS 1.1, la version la plus élevée que les deux parties gèraient. En pratique, cela ne marche pas aussi bien. On voyait par exemple des serveurs (ou, plus vraisemblablement, des pare-feux bogués) qui raccrochaient brutalement en présence d'un numéro de version plus élevé, au lieu de suggérer un repli. Le client n'avait alors que le choix de renoncer, ou bien de se lancer dans une série d'essais/erreurs (qui peut être longue, si le serveur ou le pare-feu bogué ne répond pas).

TLS 1.3 change donc complètement le mécanisme de négociation. Le client annonce toujours la version 1.2 (en fait 0x303, pour des raisons historiques), et la vraie version est mise dans une extension, supported_versions (section 4.2.1), dont on espère qu'elle sera ignorée par les serveurs mal gérés. (L'annexe D du RFC détaille ce problème de la négociation de version.) Dans la réponse ServerHello, un serveur 1.3 doit inclure cette extension, autrement, il faut se rabattre sur TLS 1.2.

En parlant d'extensions, concept qui avait été introduit originellement dans le RFC 4366, notre RFC reprend des extensions déjà normalisées, comme le SNI (Server Name Indication) du RFC 6066, le battement de cœur du RFC 6520, le remplissage du ClientHello du RFC 7685, et en ajoute dix, dont supported_versions. Certaines de ces extensions doivent être présentes dans les messages Hello, car la sélection des paramètres cryptographiques en dépend, d'autres peuvent être uniquement dans les messages EncryptedExtensions, une nouveauté de TLS 1.3, pour les extensions qu'on n'enverra qu'une fois le chiffrement commencé. Le RFC en profite pour rappeler que les messages Hello ne sont pas protégés cryptographiquement, et peuvent donc être modifiés (le message Finished résume les décisions prises et peut donc protéger contre ce genre d'attaques).

Autrement, parmi les autres nouvelles extensions :

  • Le petit gâteau (cookie), pour tester la joignabilité,
  • Les données précoces (early data), extension qui permet d'envoyer des données dès le premier message (« O-RTT »), réduisant ainsi la latence, un peu comme le fait le TCP Fast Open du RFC 7413,
  • Liste des AC (certificate authorities), qui, en indiquant la liste des AC connues du client, peut aider le serveur à choisir un certificat qui sera validé (par exemple en n'envoyant le certificat CAcert que si le client connait cette AC).

La section 5 décrit le protocole des enregistrements (record protocol). C'est ce sous-protocole qui va prendre un flux d'octets, le découper en enregistrements, les protéger par le chiffrement puis, à l'autre bout, déchiffrer et reconstituer le flux… Notez que « protégé » signifie à la fois confidentialité et intégrité puisque TLS 1.3, contrairement à ses prédécesseurs, impose AEAD (RFC 5116).

Les enregistrements sont typés et marqués handshake (la salutation, vue dans la section précédente), change cipher spec, alert (pour signaler un problème) et application data (les données elle-mêmes) :

enum {
          invalid(0),
          change_cipher_spec(20),
          alert(21),
          handshake(22),
          application_data(23),
          (255)
      } ContentType;
    
Le contenu des données est évidemment incompréhensible, en raison du chiffrement (voici un enregistrement de type 23, données, vu par tshark) :
    TLSv1.3 Record Layer: Application Data Protocol: http-over-tls
        Opaque Type: Application Data (23)
        Version: TLS 1.2 (0x0303)
        Length: 6316
        Encrypted Application Data: eb0e21f124f82eee0b7a37a1d6d866b075d0476e6f00cae7...
    
Et décrite par la norme dans son langage formel :
struct {
          ContentType opaque_type = application_data; /* 23 */
          ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
          uint16 length;
          opaque encrypted_record[TLSCiphertext.length];
      } TLSCiphertext;
    
(Oui, le numéro de version reste à TLS 1.2 pour éviter d'énerver les stupides middleboxes.) Notez que des extensions à TLS peuvent introduire d'autres types d'enregistrements.

Une faiblesse classique de TLS est que la taille des données chiffrées n'est pas dissimulée. Si on veut savoir à quelle page d'un site Web un client HTTP a accédé, on peut parfois le déduire de l'observation de cette taille. D'où la possibilité de faire du remplissage pour dissimuler cette taille (section 5.4 du RFC). Notez que le RFC ne suggère pas de politique de remplissage spécifique (ajouter un nombre aléatoire ? Tout remplir jusqu'à la taille maximale ?), c'est un choix compliqué. Il note aussi que certaines applications font leur propre remplissage, et qu'il n'est alors pas nécessaire que TLS le fasse.

La section 6 du RFC est dédiée au cas des alertes. C'est un des types d'enregistrements possibles, et, comme les autres, il est chiffré, et les alertes sont donc confidentielles. Une alerte a un niveau et une description :

 struct {
          AlertLevel level;
          AlertDescription description;
      } Alert;
    
Le niveau indiquait si l'alerte est fatale mais n'est plus utilisé en TLS 1.2, où il faut se fier uniquement à la description, une énumération des problèmes possibles (message de type inconnu, mauvais certificat, enregistrement non décodable - rappelez-vous que TLS 1.3 n'utilise que du chiffrement intègre, problème interne au client ou au serveur, extension non acceptée, etc). La section 6.2 donne une liste des erreurs fatales, qui doivent mener à terminer immédiatement la session TLS.

La section 8 du RFC est entièrement consacrée à une nouveauté délicate, le « 0-RTT ». Ce terme désigne la possibilité d'envoyer des données dès le premier paquet, sans les nombreux échanges de paquets qui sont normalement nécessaires pour établir une session TLS. C'est très bien du point de vue des performances, mais pas forcément du point de vue de la sécurité puisque, sans échanges, on ne peut plus vérifier à qui on parle. Un attaquant peut réaliser une attaque par rejeu en envoyant à nouveau un paquet qu'il a intercepté. Un serveur doit donc se défendre en se souvenant des données déjà envoyées et en ne les acceptant pas deux fois. (Ce qui peut être plus facile à dire qu'à faire ; le RFC contient une bonne discussion très détaillée des techniques possibles, et de leurs limites. Il y en a des subtiles, comme d'utiliser des systèmes de mémorisation ayant des faux positifs, comme les filtres de Bloom, parce qu'ils ne produiraient pas d'erreurs, ils rejetteraient juste certains essais 0-RTT légitimes, cela ne serait donc qu'une légère perte de performance.)

La section 9 de notre RFC se penche sur un problème difficile, la conformité des mises en œuvres de TLS. D'abord, les algorithmes obligatoires. Afin de permettre l'interopérabilité, toute mise en œuvre de TLS doit avoir la suite de chiffrement TLS_AES_128_GCM_SHA256 (AES en mode GCM avec SHA-256). D'autres suites sont recommandées (cf. annexe B.4). Pour l'authentification, RSA avec SHA-256 et ECDSA sont obligatoires. Ainsi, deux programmes différents sont sûrs de pouvoir trouver des algorithmes communs. La possibilité d'authentification par certificats PGP du RFC 6091 a été retirée.

De plus, certaines extensions à TLS sont obligatoires, un pair TLS 1.3 ne peut pas les refuser :

  • supported_versions, nécessaire pour annoncer TLS 1.3,
  • cookie,
  • signature_algorithms, signature_algorithms_cert, supported_groups et key_share,
  • server_name, c'est à dire SNI (Server Name Indication), souvent nécessaire pour pouvoir choisir le bon certificat (cf. section 3 du RFC 6066).

La section 9 précise aussi le comportement attendu des équipements intermédiaires. Ces dispositifs (pare-feux, par exemple, mais pas uniquement) ont toujours été une plaie pour TLS. Alors que TLS vise à fournir une communication sûre, à l'abri des équipements intermédiaires, ceux-ci passent leur temps à essayer de s'insérer dans la communication, et souvent la cassent. Normalement, TLS 1.3 est conçu pour que ces interférences ne puissent pas mener à un repli (le repli est l'utilisation de paramètres moins sûrs que ce que les deux machines auraient choisi en l'absence d'interférence).

Il y a deux grandes catégories d'intermédiaires, ceux qui tripotent la session TLS sans être le client ou le serveur, et ceux qui terminent la session TLS de leur côté. Attention, dans ce contexte, « terminer » ne veut pas dire « y mettre fin », mais « la sécurité TLS se termine ici, de manière à ce que l'intermédiaire puisse accéder au contenu de la communication ». Typiquement, une middlebox qui « termine » une session TLS va être serveur TLS pour le client et client TLS pour le serveur, s'insérant complètement dans la conversation. Normalement, l'authentification vise à empêcher ce genre de pratiques, et l'intermédiaire ne sera donc accepté que s'il a un certificat valable. C'est pour cela qu'en entreprise, les machines officielles sont souvent installées avec une AC contrôlée par le vendeur du boitier intermédiaire, de manière à permettre l'interception.

Le RFC ne se penche pas sur la légitimité de ces pratiques, uniquement sur leurs caractéristiques techniques. (Les boitiers intermédiaires sont souvent programmés avec les pieds, et ouvrent de nombreuses failles.) Le RFC rappelle notamment que l'intermédiaire qui termine une session doit suivre le RFC à la lettre (ce qui devrait aller sans dire…)

Depuis le RFC 4346, il existe plusieurs registres IANA pour TLS, décrits en section 11, avec leurs nouveautés. En effet, plusieurs choix pour TLS ne sont pas « câblés en dur » dans le RFC mais peuvent évoluer indépendamment. Par exemple, le registre de suites cryptographiques a une politique d'enregistrement « spécification nécessaire » (cf. RFC 8126, sur les politiques d'enregistrement). La cryptographie fait régulièrement des progrès, et il faut donc pouvoir modifier la liste des suites acceptées (par exemple lorsqu'il faudra y ajouter les algorithmes post-quantiques) sans avoir à toucher au RFC (l'annexe B.4 donne la liste actuelle). Le registre des types de contenu, lui, a une politique d'enregistrement bien plus stricte, « action de normalisation ». On crée moins souvent des types que des suites cryptographiques. Même chose pour le registre des alertes ou pour celui des salutations.

L'annexe C du RFC plaira aux programmeurs, elle donne plusieurs conseils pour une mise en œuvre correcte de TLS 1.3 (ce n'est pas tout d'avoir un protocole correct, il faut encore qu'il soit programmé correctement). Pour aider les développeurs à déterminer s'ils ont correctement fait le travail, un futur RFC fournira des vecteurs de test.

Un des conseils les plus importants est évidemment de faire attention au générateur de nombres aléatoires, source de tant de failles de sécurité en cryptographie. TLS utilise des nombres qui doivent être imprévisibles à un attaquant pour générer des clés de session. Si ces nombres sont prévisibles, toute la cryptographie s'effondre. Le RFC conseille fortement d'utiliser un générateur existant (comme /dev/urandom sur les systèmes Unix) plutôt que d'écrire le sien, ce qui est bien plus difficile qu'il ne semble. (Si on tient quand même à le faire, le RFC 4086 est une lecture indispensable.)

Le RFC conseille également de vérifier le certificat du partenaire par défaut (quitte à fournir un moyen de débrayer cette vérification). Si ce n'est pas le cas, beaucoup d'utilisateurs du programme ou de la bibliothèque oublieront de le faire. Il suggère aussi de ne pas accepter certains certificats trop faibles (clé RSA de seulement 1 024 bits, par exemple).

Il existe plusieurs moyens avec TLS de ne pas avoir d'authentification du serveur : les clés brutes du RFC 7250 (à la place des certificats), ou bien les certificats auto-signés. Dans ces conditions, une attaque de l'homme du milieu est parfaitement possibe, et il faut donc prendre des précautions supplémentaires (par exemple DANE, normalisé dans le RFC 6698, que le RFC oublie malheureusement de citer).

Autre bon conseil de cryptographie, se méfier des attaques fondées sur la mesure du temps de calcul, et prendre des mesures appropriées (par exemple en vérifiant que le temps de calcul est le même pour des données correctes et incorrectes).

Il n'y a aucune bonne raison d'utiliser certains algorithmes faibles (comme RC4, abandonné depuis le RFC 7465), et le RFC demande que le code pour ces algorithmes ne soit pas présent, afin d'éviter une attaque par repli (annexes C.3 et D.5 du RFC). De la même façon, il demande de ne jamais accepter SSL v3 (RFC 7568).

L'expérience a prouvé que beaucoup de mises en œuvre de TLS ne réagissaient pas correctement à des options inattendues, et le RFC rappelle donc qu'il faut ignorer les suites cryptographiques inconnues (autrement, on ne pourrait jamais introduire une nouvelle suite, puisqu'elle casserait les programmes), et ignorer les extensions inconnues (pour la même raison).

L'annexe D, elle, est consacrée au problème de la communication avec un vieux partenaire, qui ne connait pas TLS 1.3. Le mécanisme de négociation de la version du protocole à utiliser a complètement changé en 1.3. Dans la 1.3, le champ version du ClientHello contient 1.2, la vraie version étant dans l'extension supported_versions. Si un client 1.3 parle avec un serveur <= 1.2, le serveur ne connaitra pas cette extension et répondra sans l'extension, avertissant ainsi le client qu'il faudra parler en 1.2 (ou plus vieux). Ça, c'est si le serveur est correct. S'il ne l'est pas ou, plus vraisemblablement, s'il est derrière une middlebox boguée, on verra des problèmes comme par exemple le refus de répondre aux clients utilisant des extensions inconnues (ce qui sera le cas pour supported_versions), soit en rejettant ouvertement la demande soit, encore pire, en l'ignorant. Arriver à gérer des serveurs/middleboxes incorrects est un problème complexe. Le client peut être tenté de re-essayer avec d'autres options (par exemple tenter du 1.2, sans l'extension supported_versions). Cette méthode n'est pas conseillée. Non seulement elle peut prendre du temps (attendre l'expiration du délai de garde, re-essayer…) mais surtout, elle ouvre la voie à des attaques par repli : l'attaquant bloque les ClientHello 1.3 et le client, croyant bien faire, se replie sur une version plus ancienne et sans doute moins sûre de TLS.

En parlant de compatibilité, le « 0-RTT » n'est évidemment pas compatible avec les vieilles versions. Le client qui envoie du « 0-RTT » (des données dans le ClientHello) doit donc savoir que, si la réponse est d'un serveur <= 1.2, la session ne pourra pas être établie, et il faudra donc réessayer sans 0-RTT.

Naturellement, les plus gros problèmes ne surviennent pas avec les clients et les serveurs mais avec les middleboxes. Plusieurs études ont montré leur caractère néfaste (cf. présentation à l'IETF 100, mesures avec Chrome (qui indique également que certains serveurs TLS sont gravement en tort, comme celui installé dans les imprimantes Canon), mesures avec Firefox, et encore d'autres mesures). Le RFC suggère qu'on limite les risques en essayant d'imiter le plus possible une salutation de TLS 1.2, par exemple en envoyant des messages change_cipher_spec, qui ne sont plus utilisés en TLS 1.3, mais qui peuvent rassurer la middlebox (annexe D.4).

Enfin, le RFC se termine par l'annexe E, qui énumère les propriétés de sécurité de TLS 1.3 : même face à un attaquant actif (RFC 3552), le protocole de salutation de TLS garantit des clés de session communes et secrètes, une authentification du serveur (et du client si on veut), et une sécurité persistante, même en cas de compromission ultérieure des clés (sauf en cas de 0-RTT, un autre des inconvénients sérieux de ce service, avec le risque de rejeu). De nombreuses analyses détaillées de la sécurité de TLS sont listées dans l'annexe E.1.6. À lire si vous voulez travailler ce sujet.

Quant au protocole des enregistrements, celui de TLS 1.3 garantit confidentialité et intégrité (RFC 5116).

TLS 1.3 a fait l'objet de nombreuses analyses de sécurité par des chercheurs, avant même sa normalisation, ce qui est une bonne chose (et qui explique en partie les retards). Notre annexe E pointe également les limites restantes de TLS :

  • Il est vulnérable à l'analyse de trafic. TLS n'essaie pas de cacher la taille des paquets, ni l'intervalle de temps entre eux. Ainsi, si un client accède en HTTPS à un site Web servant quelques dizaines de pages aux tailles bien différentes, il est facile de savoir quelle page a été demandée, juste en observant les tailles. (Voir « I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis », de Miller, B., Huang, L., Joseph, A., et J. Tygar et « HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting », de Husak, M., Čermak, M., Jirsik, T., et P. Čeleda). TLS fournit un mécanisme de remplissage avec des données bidon, permettant aux applications de brouiller les pistes. Certaines applications utilisant TLS ont également leur propre remplissage (par exemple, pour le DNS, c'est le RFC 7858). De même, une mise en œuvre de TLS peut retarder les paquets pour rendre l'analyse des intervalles plus difficile. On voit que dans les deux cas, taille des paquets et intervalle entre eux, résoudre le problème fait perdre en performance (c'est pour cela que ce n'est pas intégré par défaut).
  • TLS peut être également vulnérable à des attaques par canal auxiliaire. Par exemple, la durée des opérations cryptographiques peut être observée, ce qui peut donner des informations sur les clés. TLS fournit quand même quelques défenses : l'AEAD facilite la mise en œuvre de calculs en temps constant, et format uniforme pour toutes les erreurs, empêchant un attaquant de trouver quelle erreur a été déclenchée.

Le 0-RTT introduit un nouveau risque, celui de rejeu. (Et 0-RTT a sérieusement contribué aux délais qu'à connu le projet TLS 1.3, plusieurs participants à l'IETF protestant contre cette introduction risquée.) Si l'application est idempotente, ce n'est pas très grave. Si, par contre, les effets d'une requête précédentes peuvent être rejoués, c'est plus embêtant (imaginez un transfert d'argent répété…) TLS ne promet rien en ce domaine, c'est à chaque serveur de se défendre contre le rejeu (la section 8 donne des idées à ce sujet). Voilà pourquoi le RFC demande que les requêtes 0-RTT ne soient pas activées par défaut, mais uniquement quand l'application au-dessus de TLS le demande. (Cloudflare, par exemple, n'active pas le 0-RTT par défaut.)

Voilà, vous avez maintenant fait un tour complet du RFC, mais vous savez que la cryptographie est une chose difficile, et pas seulement dans les algorithmes cryptographiques (TLS n'en invente aucun, il réutilise des algorithmes existants comme AES ou ECDSA), mais aussi dans les protocoles cryptographiques, un art complexe. N'hésitez donc pas à lire le RFC en détail, et à vous méfier des résumés forcément toujours sommaires, comme cet article.

À part le 0-RTT, le plus gros débat lors de la création de TLS 1.3 avait été autour du concept que ses partisans nomment « visibilité » et ses adversaires « surveillance ». C'est l'idée qu'il serait bien pratique si on (on : le patron, la police, le FAI…) pouvait accéder au contenu des communications TLS. « Le chiffrement, c'est bien, à condition que je puisse lire les données quand même » est l'avis des partisans de la visibilité. Cela avait été proposé dans les Internet-Drafts draft-green-tls-static-dh-in-tls13 et draft-rhrd-tls-tls13-visibility. Je ne vais pas ici pouvoir capturer la totalité du débat, juste noter quelques points qui sont parfois oubliés dans la discussion. Côté partisans de la visibilité :

  • Dans une entreprise capitaliste, il n'y pas de citoyens, juste un patron et des employés. Les ordinateurs appartiennent au patron, et les employés n'ont pas leur mot à dire. Le patron peut donc décider d'accéder au contenu des communications chiffrées.
  • Il existe des règles (par exemple PCI-DSS dans le secteur financier ou HIPAA dans celui de la santé) qui requièrent de certaines entreprises qu'elles sachent en détail tout ce qui circule sur le réseau. Le moyen le plus simple de le faire est de surveiller le contenu des communications, même chiffrées. (Je ne dis pas que ces règles sont intelligentes, juste qu'elles existent. Notons par exemple que les mêmes règles imposent d'utiliser du chiffrement fort, sans faille connue, ce qui est contradictoire.)
  • Enregistrer le trafic depuis les terminaux est compliqué en pratique : applications qui n'ont pas de mécanisme de journalisation du trafic, systèmes d'exploitation fermés, boîtes noires…
  • TLS 1.3 risque de ne pas être déployé dans les entreprises qui tiennent à surveiller le trafic, et pourrait même être interdit dans certains pays, où la surveillance passe avant les droits humains.
Et du côté des adversaires de la surveillance :
  • La cryptographie, c'est compliqué et risqué. TLS 1.3 est déjà assez compliqué comme cela. Lui ajouter des fonctions (surtout des fonctions délibérement conçues pour affaiblir ses propriétés de sécurité) risque fort d'ajouter des failles de sécurité. D'autant plus que TLS 1.3 a fait l'objet de nombreuses analyses de sécurité avant son déploiement, et qu'il faudrait tout recommencer.
  • Contrairement à ce que semblent croire les partisans de la « visibilité », il n'y a pas que HTTPS qui utilise TLS. Ils ne décrivent jamais comment leur proposition marcherait avec des protocoles autres que HTTPS.
  • Pour HTTPS, et pour certains autres protocoles, une solution simple, si on tient absolument à intercepter tout le trafic, est d'avoir un relais explicite, configuré dans les applications, et combiné avec un blocage dans le pare-feu des connexions TLS directes. Les partisans de la visibilté ne sont en général pas enthousiastes pour cette solution car ils voudraient faire de la surveillance furtive, sans qu'elle se voit dans les applications utilisées par les employés ou les citoyens.
  • Les partisans de la « visibilité » disent en général que l'interception TLS serait uniquement à l'intérieur de l'entreprise, pas pour l'Internet public. Mais, dans ce cas, tous les terminaux sont propriété de l'entreprise et contrôlés par elle, donc elle peut les configurer pour copier tous les messages échangés. Et, si certains de ces terminaux sont des boîtes noires, non configurables et dont on ne sait pas bien ce qu'ils font, eh bien, dans ce cas, on se demande pourquoi des gens qui insistent sur leurs obligations de surveillance mettent sur leur réseau des machines aussi incontrôlables.
  • Dans ce dernier cas (surveillance uniquement au sein d'une entreprise), le problème est interne à l'entreprise, et ce n'est donc pas à l'IETF, organisme qui fait des normes pour l'Internet, de le résoudre. Après tout, rien n'empêche ces entreprises de garder TLS 1.2.

Revenons maintenant aux choses sérieuses, avec les mises en œuvre de TLS 1.3. Il y en existe au moins une dizaine à l'heure actuelle mais, en général, pas dans les versions officiellement publiées des logiciels. Notons quand même que Firefox 61 sait faire du TLS 1.3. Les autres mises en œuvre sont prêtes, même si pas forcément publiées. Prenons l'exemple de la bibliothèque GnuTLS. Elle dispose de TLS 1.3 depuis la version 3.6.3. Pour l'instant, il faut compiler cette version avec l'option ./configure --enable-tls13-support, qui n'est pas encore activée par défaut. Un bon article du mainteneur de GnuTLS explique bien les nouveautés de TLS 1.3.

Une fois GnuTLS correctement compilé, on peut utiliser le programme en ligne de commande gnutls-cli avec un serveur qui accepte TLS 1.3 :

% gnutls-cli  gmail.com 
...
- Description: (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: X25519
 - Curve size: 256 bits
- Version: TLS1.3
- Key Exchange: ECDHE-RSA
- Server Signature: RSA-PSS-RSAE-SHA256
- Cipher: AES-256-GCM
- MAC: AEAD
...
Et ça marche, on fait du TLS 1.3. Si vous préférez écrire le programme vous-même, regardez ce petit programme. Si GnuTLS est en /local, il se compilera avec cc -I/local/include -Wall -Wextra -o test-tls13 test-tls13.c -L/local/lib -lgnutls et s'utilisera avec :
% ./test-tls13 www.ietf.org      
TLS connection using "TLS1.3 AES-256-GCM"

%  ./test-tls13 gmail.com  
TLS connection using "TLS1.3 AES-256-GCM"

%  ./test-tls13 mastodon.gougere.fr
TLS connection using "TLS1.2 AES-256-GCM"

% ./test-tls13 www.bortzmeyer.org
TLS connection using "TLS1.2 AES-256-GCM"

% ./test-tls13 blog.cloudflare.com
TLS connection using "TLS1.3 AES-256-GCM"
  
Cela vous donne une petite idée des serveurs qui acceptent TLS 1.3.

Un pcap d'une session TLS 1.3 est disponible en tls13.pcap. Notez que le numéro de version n'est pas encore celui du RFC (0x304). Ici, 0x7f1c désigne l'Internet-Draft numéro 28. Voici la session vue par tshark :

    1   0.000000 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 94 36866 → https(443) [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=3528788861 TSecr=0 WS=128
    2   0.003052 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 86 https(443) → 36866 [SYN, ACK] Seq=0 Ack=1 Win=24400 Len=0 MSS=1220 SACK_PERM=1 WS=1024
    3   0.003070 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [ACK] Seq=1 Ack=1 Win=28800 Len=0
    4   0.003354 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TLSv1 403 Client Hello
    5   0.006777 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 74 https(443) → 36866 [ACK] Seq=1 Ack=330 Win=25600 Len=0
    6   0.011393 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TLSv1.3 6496 Server Hello, Change Cipher Spec, Application Data
    7   0.011413 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [ACK] Seq=330 Ack=6423 Win=41728 Len=0
    8   0.011650 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TLSv1.3 80 Change Cipher Spec
    9   0.012685 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TLSv1.3 148 Application Data
   10   0.015693 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 74 https(443) → 36866 [ACK] Seq=6423 Ack=411 Win=25600 Len=0
   11   0.015742 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TLSv1.3 524 Application Data
   12   0.015770 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [RST] Seq=411 Win=0 Len=0
   13   0.015788 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 74 https(443) → 36866 [FIN, ACK] Seq=6873 Ack=411 Win=25600 Len=0
   14   0.015793 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [RST] Seq=411 Win=0 Len=0
Et, complètement décodée par tshark :
Secure Sockets Layer [sic]
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Version: TLS 1.2 (0x0303)
...
            Extension: supported_versions (len=9)
                Type: supported_versions (43)
                Length: 9
                Supported Versions length: 8
                Supported Version: Unknown (0x7f1c)
                Supported Version: TLS 1.2 (0x0303)
                Supported Version: TLS 1.1 (0x0302)
                Supported Version: TLS 1.0 (0x0301)
Le texte complet est en tls13.txt. Notez bien que la négociation est en clair.

Quelques autres articles à lire :

2018-08-10

☕︎ Tout en noir

De la même manière que les individus « prosociaux » ne sont pas des malades mentaux à soigner mais des personnes saines d’esprit prises au piège dans une culture humaine profondément cinglée, les individus que l’on qualifie parfois de « catastrophistes » ne sont pas des dérangés qui verraient « tout en noir ». Le monde entier gagnerait à ce que les euphémistes invétérés et autres optimistes par déni le reconnaissent, et à ce qu’ils utilisent leur énergie pour lutter contre les désastres socio-écologiques en cours qui rendent la vie insupportable tout en la détruisant, plutôt que contre ceux qui les exposent et contre le sentiment de malaise que cela suscite chez eux.

Voyons-nous « les choses en noir » ou sont-ils incapables de regarder l’horreur en face ? (cache)

Nicolas Casaux écrit des textes radicaux qui résonnent particulièrement en moi actuellement, voir aussi ceux sur la civilisation (cache), la collapsologie (cache) et sa suite (cache). Ces pensées se rapprochent de mes propres réflexions : l’Anthropocène est l’histoire d’une extinction, celle de l’espèce humaine. Une espèce qui s’est auto-sélectionnée pour ne garder que les expansionnistes et les explorateurs destructeurs au détriment des reproducteurs et des gestionnaires sensés qui avaient conscience de la finitude du monde.

La question n’est plus pour moi de savoir si tout va s’effondrer mais jusqu’à quand en quelque sorte. Et du rôle que je m’autorise à avoir là-dedans… si tant est que je puisse faire ce choix.

2018-08-09

☕︎ Read/write Web

Triggered by some of the previous postings on RSS, I started thinking about what my ideal set-up for RSS reading would be. Because maybe there’s a way to create that for myself.

My Ideal RSS Reader (cache)

Really interesting ideas here. I’m still thinking about an evolution of both my reading and publishing tools. My ideal setup would be like a browser for RSS/uncluttered contents that I can annotate then optionally publish as a new feed, a webpage and/or as a mailing list (because (cache)).

It looks pretty basic and still I can’t find a self-hosted service doing that. So maybe it’s time to “create that for myself”. I already have the first 80% with my custom made tool for publishing/caching here. It remains the last 80% though :-).

When Google got out of the RSS game, those of us who remained realized that yes, we can survive without them. Five years later, RSS is still the best, most unfiltered way to get content you want. There’s a greater diversity of choices and no one company dominates everything. So let’s stop hoping Facebook or Twitter or someone else will do our job for us. Let’s stop waiting for someone to tell us what we want to read. Let’s stop publishing what they want us to publish. We can do better without them.

Thanks, Google! (cache)

2018-08-08

☕︎ Subordination forte

Comment nommer l’interlocuteur du mentor ?

[…]

Je veux aussi absolument éviter les termes qui induisent une relation de subordination forte.

[Vocabulaire] le mentor et le … (cache)

Cette question m’a fait pas mal cogité cette dernière semaine et j’ai bien peur qu’il n’y ait pas de réponse possible. Il faut choisir un terme plus neutre si on veut garder l’horizontalité, mes propositions seraient :

  • pair que j’aime beaucoup mais qui pose deux soucis ; au féminin ça passe mal et il y a le problème en français de l’homonyme pair/père qui peut être la base de pas mal de quiproquo à l’oral.
  • binôme qui reste mon choix préféré compte tenu des contraintes énoncées par Éric, là c’est clair et ça montre bien l’apprentissage en commun, potentiellement à des niveaux différents. Il y a l’idée du faire ensemble même si le faire reste assez théorique.

Le parallèle sportif qui me vient en tête est celui de l’escalade en corde tendue mais j’ai bien peur que l’expression premier/second de cordée ait prise une mauvaise connotation en France ces derniers temps…

2018-08-07

☕︎ Aveuglé

Me montre une feuille constellée de points.
— De la pluie ?
— C’est un alphabet en braille papa…

😳

RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier

Ce RFC décrit les algorithmes cryptographiques à base de courbes elliptiques utilisés dans TLS. Il remplace le RFC 4492.

Plus exactement, il normalise les algorithmes utilisés dans les versions de TLS allant jusqu'à 1.2 incluse. L'utilisation des courbes elliptiques par TLS 1.3 est décrite dans le RFC sur TLS 1.3, le RFC 8446. Les deux points importants de ce nouveau RFC sont :

  • L'utilisation de courbes elliptiques pour un échange Diffie-Hellman de la clé de session TLS (ce qu'on nomme ECDHE),
  • Les algorithmes de signature à courbes elliptiques ECDSA et EdDSA pour authentifier le pair TLS.

Commençons par l'échange de clés de session (section 2). TLS nécessite que les deux pairs se mettent d'accord sur une clé de chiffrement symétrique qui sera ensuite utilisée pendant toute la session, avec des algorithmes comme AES. Une des façons de synchroniser cette clé de session est qu'un des pairs la génère aléatoirement, puis la chiffre avec la clé publique (chiffrement asymétrique) de son pair avant de lui transmettre (cela marche avec RSA mais je n'ai pas l'impression qu'il y ait un moyen normalisé de faire cela avec les courbes elliptiques). Une autre façon est d'utiliser un échange Diffie-Hellman. Contrairement à l'échange Diffie-Hellman originel, celui présenté dans ce RFC, ECDHE, utilise la cryptographie sur courbes elliptiques. (J'ai simplifié pas mal : par exemple, l'échange ECDHE ne donnera pas directement la clé de session, celle-ci sera en fait dérivée de la clé obtenue en ECDHE.) Le principal avantage de Diffie-Hellman est de fournir de la sécurité même en cas de compromission ultérieure de la clé privée.

Notre RFC présente trois variantes d'ECDHE, selon la manière dont l'échange est authentifié, l'une utilisant ECDSA ou EdDSA, l'autre utilisant le traditionnel RSA, et la troisième n'authentifiant pas du tout, et étant donc vulnérable aux attaques de l'Homme du Milieu, sauf si une authentification a lieu en dehors de TLS. (Attention, dans le cas de ECDHE_RSA, RSA n'est utilisé que pour authentifier l'échange, la génération de la clé se fait bien en utilisant les courbes elliptiques.)

Lorsque l'échange est authentifié (ECDHE_ECDSA - qui, en dépit de son nom, inclut EdDSA - ou bien ECDHE_RSA), les paramètres ECDH (Diffie-Hellman avec courbes elliptiques) sont signés par la clé privée (ECDSA, EdDSA ou RSA). S'il n'est pas authentifié (ECDH_anon, mais notez que le nom est trompeur, bien que le E final - ephemeral - manque, la clé est éphémère), on n'envoie évidemment pas de certificat, ou de demande de certificat.

Voilà, avec cette section 2, on a pu générer une clé de session avec Diffie-Hellman, tout en authentifiant le serveur avec des courbes elliptiques. Et pour l'authentification du client ? C'est la section 3 de notre RFC. Elle décrit un mécanisme ECDSA_sign (là encore, en dépit du nom du mécanisme, il fonctionne aussi bien pour EdDSA), où le client s'authentifie en signant ses messages avec un algorithme à courbes elliptiques.

Les courbes elliptiques ont quelques particularités qui justifient deux extensions à TLS que présente la section 4 du RFC. Il y a Supported Elliptic Curves Extension et Supported Point Formats Extension, qui permettent de décrire les caractéristiques de la courbe elliptique utilisée (on verra plus loin que la deuxième extension ne sert plus guère). Voici, vue par tshark, l'utilisation de ces extensions dans un ClientHello TLS envoyé par OpenSSL :

Extension: elliptic_curves
                Type: elliptic_curves (0x000a)
                Length: 28
                Elliptic Curves Length: 26
                Elliptic curves (13 curves)
                    Elliptic curve: secp256r1 (0x0017)
                    Elliptic curve: secp521r1 (0x0019)
                    Elliptic curve: brainpoolP512r1 (0x001c)
                    Elliptic curve: brainpoolP384r1 (0x001b)
                    Elliptic curve: secp384r1 (0x0018)
                    Elliptic curve: brainpoolP256r1 (0x001a)
                    Elliptic curve: secp256k1 (0x0016)
...
Extension: ec_point_formats
                Type: ec_point_formats (0x000b)
                Length: 4
                EC point formats Length: 3
                Elliptic curves point formats (3)
                    EC point format: uncompressed (0)
                    EC point format: ansiX962_compressed_prime (1)
                    EC point format: ansiX962_compressed_char2 (2)

La section 5 du RFC donne les détails concrets. Par exemple, les deux extensions citées plus haut s'écrivent, dans le langage de TLS (cf. section 4 du RFC 5246) :

enum {
          elliptic_curves(10),
          ec_point_formats(11)
} ExtensionType;
La première extension permet d'indiquer les courbes utilisées. Avec celles du RFC 7748, cela donne, comme possibilités :
enum {
               deprecated(1..22),
               secp256r1 (23), secp384r1 (24), secp521r1 (25),
               x25519(29), x448(30),
               reserved (0xFE00..0xFEFF),
               deprecated(0xFF01..0xFF02),
               (0xFFFF)
} NamedCurve;  
secp256r1 est la courbe P-256 du NIST, x25519 est la Curve-25519 de Bernstein. Notez que beaucoup des courbes de l'ancien RFC 4492, jamais très utilisées, ont été abandonnées. (Les courbes se trouvent dans un registre IANA.)

Normalement, dans TLS, on peut choisir séparément l'algorithme de signature et celui de condensation (cf. section 7.4.1.4.1 du RFC 5246). Avec certains algorithmes comme EdDSA dans sa forme « pure », il n'y a pas de condensation séparée et un « algorithme » bidon, Intrinsic (valeur 8) a été créé pour mettre dans le champ « algorithme de condensation » de l'extension signature_algorithms.

Voici une négociation TLS complète, vue par curl :

%  curl -v https://www.nextinpact.com
...
* Connected to www.nextinpact.com (2400:cb00:2048:1::6819:f815) port 443 (#0)
...
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
...
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=nextinpact.com
...
> GET / HTTP/1.1
> Host: www.nextinpact.com
> User-Agent: curl/7.52.1
> Accept: */*
On voit que l'algorithme utilisé par TLS est ECDHE-ECDSA-AES128-GCM-SHA256, ce qui indique ECDHE avec ECDSA. Le certificat du serveur doit donc inclure une clé « courbe elliptique ». Regardons ledit certificat :
% openssl s_client -connect www.nextinpact.com:443 -showcerts | openssl x509 -text
Certificate:
...
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO ECC Domain Validation Secure Server CA 2
...
        Subject: OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = ssl378410.cloudflaressl.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
...
                ASN1 OID: prime256v1
                NIST CURVE: P-256
...
            X509v3 Subject Alternative Name: 
                DNS:ssl378410.cloudflaressl.com, DNS:*.baseballwarehouse.com, DNS:*.campusgroups.com, DNS:*.cretedoc.gr, DNS:*.groupment.com, DNS:*.icstage.com, DNS:*.ideacouture.com, DNS:*.industrialtour-deloitte.com, DNS:*.jonessnowboards.com, DNS:*.nextinpact.com, DNS:*.pcinpact.com, DNS:*.pinkapple.com, DNS:*.softballrampage.com, DNS:*.undercovercondoms.co.uk, DNS:baseballwarehouse.com, DNS:campusgroups.com, DNS:cretedoc.gr, DNS:groupment.com, DNS:icstage.com, DNS:ideacouture.com, DNS:industrialtour-deloitte.com, DNS:jonessnowboards.com, DNS:nextinpact.com, DNS:pcinpact.com, DNS:pinkapple.com, DNS:softballrampage.com, DNS:undercovercondoms.co.uk
    Signature Algorithm: ecdsa-with-SHA256
On a bien une clé sur la courbe P-256.

Quel est l'état des mises en œuvre de ces algorithmes dans les bibliothèques TLS existantes ? ECDHE et ECDSA avec les courbes NIST sont très répandus. ECDHE avec la courbe Curve25519 est également dans plusieurs bibliothèques TLS. Par contre, EdDSA, ou ECDHE avec la courbe Curve448, sont certes implémentés mais pas encore largement déployés.

Les changements depuis le RFC 4492 sont résumés dans l'annexe B. Souvent, une norme récente ajoute beaucoup de choses par rapport à l'ancienne mais, ici, pas mal de chose ont au contraire été retirées :

  • Plusieurs courbes peu utilisées disparaissent,
  • Il n'y a plus qu'un seul format de point accepté (uncompressed),
  • Des algorithmes comme toute la famille ECDH_ECDSA (ECDH et pas ECDHE, donc ceux dont la clé n'est pas éphémère) sont retirés.
Parmi les ajouts, le plus important est évidemment l'intégration des « courbes Bernstein », Curve25519 et Curve448, introduites par le RFC 7748. Et il y avait également plusieurs erreurs techniques dans le RFC 4492, qui sont corrigées par notre nouveau RFC.

Et, pendant que j'y suis, si vous voulez générer un certificat avec les courbes elliptiques, voici comment faire avec OpenSSL :

% openssl ecparam -out ec_key.pem -name prime256v1 -genkey
% openssl req -new -key ec_key.pem  -nodes -days 1000 -out cert.csr
  
J'ai utilisé ici la courbe P-256 (prime256v1 est encore un autre identificateur pour la courbe NIST P-256, chaque organisme qui normalise dans ce domaine ayant ses propres identificateurs). Si vous voulez la liste des courbes que connait OpenSSL :
% openssl ecparam -list_curves 

Ce blog est accessible en TLS mais pas avec des courbes elliptiques. En effet, l'AC que j'utilise, CAcert, ne les accepte hélas pas (« The keys you supplied use an unrecognized algorithm. For security reasons these keys can not be signed by CAcert. ») Il y a des raisons pour cela mais c'est quand même déplorable. (Enfin, j'accepte quand même ECDHE.)

Enfin, un échange TLS complet vu par tshark est visible ici.

Merci à Manuel Pégourié-Gonnard pour sa relecture vigilante.

2018-08-06

☕︎ Multipotentialite

A multipotentialite is someone with many interests and creative pursuits.

Multipotentialites have no “one true calling” the way specialists do. Being a multipotentialite is our destiny. We have many paths and we pursue all of them, either sequentially or simultaneously (or both).

Multipotentialites thrive on learning, exploring, and mastering new skills. We are excellent at bringing disparate ideas together in creative ways. This makes us incredible innovators and problem solvers.

When it comes to new interests that emerge, our insatiable curiosity leads us to absorb everything we can get our hands on. As a result, we pick up new skills fast and tend to be a wealth of information.

Emilie Wapnick, Puttylike (cache)

🐙

2018-08-05

☕︎ Listening to my body

How do you train for these ultras?

Just however I feel. I don’t have a plan. Sometimes when I leave my house I don’t even know if I’m going to go out for 45 minutes or for 4 hours. Basically I’m just listening to my body and relying on the fact that I feel like I can read the signs my body is giving me pretty well and just going with it, otherwise not getting too caught up on what I do every day to train but trying to just keep getting in good, solid miles and keep figuring out how to do it all better.

There’s No Stopping Ultrarunner Courtney Dauwalter (cache)

🏃‍♀️

2018-08-04

☕︎ Ruissèlement de la domination

Notre insécurité dans les rues, le métro, le bureau et même dans nos maisons n’est pas une fatalité, une malédiction, c’est un fait social construit par des siècles d’exclusion et de persécution contre la classe d’exploitation de base du capitalisme moderne : les femmes. Et les hommes continuent à participer activement à cette persécution, parce que c’est d’elle qu’en grande partie naissent leurs nombreuses prérogatives et privilèges, même chez les hommes les plus dominés parmi les hommes : le dernier des grouillots sait à quel point il est bon de pouvoir se défouler régulièrement sur plus dominé⋅e que soi. Et c’est de ce seul ruissèlement réellement efficace du système capitalisme (le ruissèlement de la domination), que naissent ces cavaliers de l’apocalypse humaine que sont les dominations discriminantes : racisme, sexisme, classisme, validisme, homophobie, grossophobie, etc. comme autant de comportements qui rassurent chacun sur sa place réelle et concrète dans la hiérarchie de fer du capitalisme, lequel se repait concrètement de toutes les inégalités.

Dernières de cordée, Agnès Maillard (cache)

🧗‍♀️

2018-08-03

☕︎ Removing tracking

In truth, Google Analytics has always been a bit of a childish self-validation crutch. “Look how many visits I’m getting ma!” It doesn’t really serve a purpose for me. I design my site for everybody, so I don’t need to track where people are coming from. I design my site for every device, so I don’t need to track OS and Browser. I have zero interest in the awfully revealing demographic data that GA exposes. I really have no need to see real-time data on visitors. It’s all really for nothing.

Removing Site Tracking (cache)

🙌

2018-08-02

☕︎ Slow trail

C’est que le natif du Colorado rétif à parler de son palmarès de coureur, hormis ses deux deuxièmes places au Mad Marathon, son épreuve fétiche à travers les collines verdoyantes du Vermont, incarne une tendance de fond. Comme de plus en plus de runners lassés par les compétitions, Rickey veut tracer sa route, en solo, sans chrono. Ou s’offrir des parcours off sur le tracé d’une course mythique, sans rubalises et meute titubant dans des lacets pour s’afficher en finisher. « Cela fait 20 ans que je fais ça. Ca ne m’intéresse plus, faire des zig-zags dans les montagnes » Dans cette forme assumée de slow trail, on prend le temps de la discussion, du détour, le sac à dos est délesté du superflu, concentré sur l’essentiel.

On a retrouvé Forrest Gump, Patricia Oudit (cache)

🤩

2018-08-01

☕︎ Documentation of my research

OK let me start by saying that I could be wrong. I know that the Codepen folks may want something completely different, or think of something completely different. So this article is not meant to redesign the Codepen switch button, but rather serve as a documentation of my research and train of thought while working on creating my own switch button for my talk. I’ll need to do even more research when it’s time to continue working on my new workshop, and things may change, and I know I’ll learn and know more by the time I create my next switch. But, until then, I know I’ve got this blog post to reference for some of the thoughts and ideas that crossed my mind when I took the first step into this.

On Designing and Building Toggle Switches, Sara Soueidan (cache)

👌

2018-07-31

☕︎ Lâcher prise

Collaborer c’est bien, mais voir un travail de design critiqué par des personnes qui ne s’y connaissent pas et font une platrée de retours non pertinents, c’est vraiment très agaçant (en plus de faire perdre beaucoup de temps à tout le monde). Ce n’est pas qu’on tienne à faire les divas mais si vous faites appel à quelqu’un dont c’est le métier, c’est important de lâcher prise et de lui faire confiance, et non pas de vous permettre de critiquer sous prétexte que “Tout le monde a des yeux donc tout le monde peut juger de la qualité du design”

Designers & Logiciels libres : et si on collaborait ?, Maïtané Lenoir (cache)

🤔

2018-07-30

☕︎ Harcèlement ordinaire

Nul doute que la visibilité aussi soudaine qu’écrasante que m’a apportée la conférence sur le design de soi que j’ai donnée à Paris Web en octobre 2015 (cache) y a été pour beaucoup.

Du jour au lendemain, le nombre de mes followers sur Twitter a explosé. Le nombre des personnes me détestant juste parce que mes billets et ma conférence étaient très partagés, aussi.

La violence verbale et symbolique à l’œuvre sur les réseaux sociaux, dont j’étais témoin depuis des années, était en train de me prendre pour cible.

Deux ans plus tard, Marie Guillaumet (cache)

😢

RFC 8399: Internationalization Updates to RFC 5280

Ce court RFC ajoute aux certificats PKIX du RFC 5280 la possibilité de contenir des adresses de courrier électronique dont la partie locale est en Unicode. Et il modifie légèrement les règles pour les noms de domaine en Unicode dans les certificats.

Les certificats sur l'Internet sont normalisés dans le RFC 5280, qui décrit un profil de X.509 nommé PKIX (définir un profil était nécessaire car la norme X.509 est bien trop riche et complexe). Ce RFC 5280 permettait des noms de domaine en Unicode (sections 4.2.1.10 et 7 du RFC 5280) mais il suivait l'ancienne norme IDN, celle des RFC 3490 et suivants. Depuis, les IDN sont normalisés dans le RFC 5890 et suivants, et notre nouveau RFC 8399 modifie très légèrement le RFC 5280 pour s'adapter à cette nouvelle norme de noms de domaines en Unicode. Les noms de domaine dans un certificat peuvent être présents dans les champs Sujet (titulaire du certificat) et Émetteur (AC ayant signé le certificat) mais aussi dans les contraintes sur le nom (une autorité de certification peut être limitée à des noms se terminant en example.com, par exemple).

Notez que, comme avant, ces noms sont exprimés dans le certificat en Punycode (RFC 3492, xn--caf-dma.fr au lieu de café.fr). C'est un bon exemple du fait que les limites qui rendaient difficiles d'utiliser des noms de domaine en Unicode n'avaient rien à voir avec le DNS (qui n'a jamais été limité à ASCII, contrairement à ce qu'affirme une légende courante). En fait, le problème venait des applications (comme PKIX), qui ne s'attendaient pas à des noms en Unicode. Un logiciel qui traite des certificats aurait été bien étonné de voir des noms de domaines non-ASCII, et aurait peut-être planté. D'où ce choix du Punycode.

Nouveauté plus importante de notre RFC 8399, les adresses de courrier électronique en Unicode. Elles étaient déjà permises par la section 7.5 du RFC 5280, mais seulement pour la partie domaine (à droite du @). Désormais, elles sont également possibles dans la partie locale (à gauche du @). Le RFC 8398 donne tous les détails sur ce sujet.

Reste à savoir quelles AC vont accepter Unicode. J'ai testé avec Let's encrypt (avec le client Dehydrated, en mettant le Punycode dans domains.txt) et ça marche, regardez le certificat de https://www.potamochère.fr/. Le voici, affiché par GnuTLS :

% gnutls-cli www.potamochère.fr
...
- subject `CN=www.xn--potamochre-66a.fr', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x03ed9617bb88bab3ad5b236675d1dd6e5d27, ...
    
D'autres AC acceptent ces noms en Unicode : Gandi le fait aussi, regardez le certificat de https://réussir-en.fr. On notera que le célèbre service de test de la qualité des configurations TLS, SSLlabs, gère bien les IDN :

2018-07-29

☕︎ Worthwhile to say

Part of this is convincing myself that I have something worthwhile to say again. That sharing something cool or posting the odd thought doesn’t mean I’m arrogant and think the world needs to hear me. I’m just craving connection over shared experiences.

Insecure, Laura Kalbag (cache)

💪

SÉLECTION

Cette planète rassemble les principaux carnets web d'auteurs francophones traitant de XML. Ces blogs sont souvent bilingues français/anglais et éclectiques. Cette page rassemble l'ensemble de leurs billets et vous permet de sélectionner ceux que vous voulez voir.


Lien permanent pour cette sélection :
feed /actualites/planete/xmlfr/fr/
Les documents publiés sur ce site le sont sous licence " Open Content".

Valid XHTML 1.0 Transitional

logo DYOMEDEA
Conception, réalisation et hébergement

Questions ou commentaires
redacteurs@xmlfr.org