Réflexion issue d’une discussion sur le Discord de Cuistops concernant le fait que Talos pourrait ne pas être le meilleur point de départ pour s’attaquer à cette technologie d’infrastructure qui a balayé le monde de l’orchestration de containers en une petite dizaine d’années. Pour illustrer pourquoi il n’y a pas de réponse absolue à cette question, je me suis dit que vous décrire mon parcours concernant l’univers des containers et Kubernetes en particulier (aussi bien au niveau perso que pro) serait éclairant sur certains points.

Aux origines : Docker

Le moins qu’on puisse dire, c’est que mon entrée dans l’univers des containers, en particulier via docker, n’était pas brillante. Je conserve avec malice le premier billet que j’ai consacré à ce sujet en 2016 pour illustrer à quel point je me trompais sur la technologie, que je n’avais jusque là pas vraiment vu, encore moins au niveau professionnel. J’ai heureusement rattrapé cette erreur depuis, aussi bien à la faveur de formations au travail (merci Thomas Perelle ) qu’au niveau perso, où mes propres expérimentations m’ont conduit à partager ma découverte et mon utilisation de Docker Swarm. J’ai bien rattrapé le coup, hein ?

D’ailleurs, Swarm a été pour moi la découverte de la notion d’orchestration. Que j’ai pu creuser cette fois au niveau pro en 2018 après un premier tout petit pas vers l’univers Kubernetes par la porte OpenShift à la faveur d’un workshop de deux jours par un collègue qui sera réellement un mentor pour les années suivantes, Julien Francoz. Je n’ai malheureusement pas gardé grand chose de ce workshop, étant donné que je n’avais aucune plateforme de ce type dans mon pôle client, encore moins de Kubernetes. Tout juste on commençait à avoir des clients qui cherchaient à déployer leurs applis en mode container sur des serveurs classiques, avec Docker. Sans pratique, la théorie s’efface vite, d’autant qu’en 2018, les usages « domestiques » n’étaient pas légion, donc les articles de blog non plus, encore moins autour d’Openshift. C’est en 2019 que tout change.

2019 : La découverte de Kube, de la containerisation d’applications, d’Azure, de terraform (tout en même temps)

Je vous passe le contexte de comment j’en suis arrivé à cette situation intense qui aura duré 5 mois, mais oui, j’ai découvert Kubernetes d’une façon un peu particulière : service cloud managé, sur Azure, el famoso « AKS« , à devoir migrer des applications précédemment hébergées sur des serveurs virtuels Debian dépassés, avec un cluster déployé manuellement qu’on a tenté de « terraformer » après-coup, avec toute la « qualité » de l’API d’Azure d’alors. Et je remercie encore Julien d’avoir pris autant de temps à me soutenir dans cet apprentissage express (la notion de mentor n’était pas galvaudée, clairement).

Service cloud Managé veut dire qu’on ne gère pas certains aspects importants de la vie d’un cluster : tout le control plane est masqué, vous ne voyez que les nœuds, vous ne vous occupez pas trop de certains aspects comme la rotation des certificats, les mises à jour sont automatisées (vous indiquez une version cible, le service s’occupe de la montée de version du control plane, puis des nœuds un par un), et vous bénéficiez d’intégrations avec le reste de l’infra du fournisseur, au niveau du réseau, du stockage, des capacités comme l’autoscaling (vous augmentez et réduisez automatiquement le nombre de nœuds en fonction de la charge ou des réservations de ressources des pods à déployer). L’installation se fait en trois/quatre clics via l’interface web, une ligne de commande avec l’utilitaire maison, ou un peu plus de lignes de code si on le fait via un outil d’infrastructure as code.

Bref, c’est cool, ça permet de se concentrer sur les aspects opérationnels des applications déployées, mais même comme ça, je vous avoue que AKS tel que Microsoft le proposait n’était pas toujours une sinécure. Azure lui-même était pénible, avec des VMs qui mettaient plusieurs minutes à démarrer (quand les concurrents tournaient autour de la minute). Et comme on ne gère pas le control plane, on rate tout un pan de l’architecture et de la gestion de Kubernetes et de ses composants sous-jacents. En plus à l’époque, l’image de l’OS utilisé pour les nœuds était basée sur Ubuntu, pas le plus léger et le « gaspillage » de ressources était réel, au-delà de Kubernetes lui-même.

J’aurais l’occasion de passer encore quelques années, pratiquement trois, à déployer d’autres projets AKS pour d’autres clients, ce qui m’a permis de constater, il faut savoir aussi le reconnaitre, comment Microsoft a cravaché pour amener un niveau de qualité sur le service bien plus en phase avec ce qu’on attend d’un tel fournisseur. Rotation automatique des certificats via les mises à jour (c’était pas le cas, la commande de rotation était à lancer à la main), amélioration générale d’Azure sur les temps de démarrage des nœuds, efficacité des mises à jour, intégrations avancées au niveau réseau (Calico, Istio, etc)… Ce qui n’empêche pas certains pains avec entre autres une API qui accepte certaines valeurs pourtant non supportées et qui m’ont forcé à redéployer des clusters from scratch parce que la communication entre les nœuds étaient devenue impossible (réponse du support : « on va mettre à jour la doc pour indiquer les valeurs supportées »; bravo…). Par la suite, j’ai découvert et encore plus adoré exploiter et déployer du GKE, le service équivalent de Google Cloud; il m’aura permis au passage d’apprendre comment fonctionnait ce fournisseur et tout ce qu’il fait de mieux que Microsoft (et parfois d’AWS). Au point de passer la certification « Professional Architect » au bout de 4 mois seulement de pratiques.

Kube à la maison

Cette expérience en particulier avec Azure ne m’aura pas empêché pas de tomber amoureux de la technologie, au point de remiser Docker Swarm, et de migrer sur K3S. Là aussi un choix particulier, conçu pour les machines très légères, puisque ciblant les Raspberry Pi, j’ai malgré tout fait le déploiement du flemmard, même si j’ai privilégié un déploiement semi-automatisé avec un playbook/role Ansible, et un seul nœud comme control plane (qui était le seul mode de déploiement supporté alors).

Particularité de k3s, regrouper tous les composants « core » de Kubernetes dans un seul binaire, une petite prouesse à la base de son empreinte mémoire réduite, mais pas que : un des éléments les plus critiques d’un cluster, la base de données ETCD, la « mémoire » du cluster, est remplacée par SQlite, bien plus léger, mais évidemment limité à une seul nœud, et moins enclin aux problèmes des bases de données plus complexe. Bien que le mode « multi-master » ait été implémenté par la suite, au passage à mes Raspberry Pi 4, j’ai quand même conservé le même mode de fonctionnement. J’ai eu l’occasion de détailler pas mal de choses concernant K3S sur ce blog, je ne vais donc pas m’étendre beaucoup plus.

Reste qu’à l’occasion d’une volonté de refonte, accélérée par la mort successive des cartes SD des Raspi après 4 ans de bons et loyaux services, j’ai décidé de revenir à un Kubernetes un peu moins simplifié, en partant sur un autre choix particulier, Talos Linux, qui aura fini en machine virtuelle suite à une déconvenue de matériel et de limitations électriques, que je me suis pris en pleine poire en plein live Twitch. Talos propose un déploiement Kubernetes beaucoup plus standardisé dans ses composants de base, mais dont la gestion des nœuds est très particulière : pas d’OS à proprement parler, juste le noyau et une API qui permet de pratiquer toutes les opérations sur la gestion de ces nœuds : pas de SSH, pas de CLI directe, l’utilitaire talosctl est là pour configurer les nœuds à l’envi, permettant de les ajouter/retirer d’un cluster en un clin d’œil, un aspect très important dans une gestion d’infrastructure au sens large (comprendre, en entreprise). Toute la configuration de base se fait au travers de fichiers de configuration YAML, à l’instar de Kubernetes lui-même, permettant une approche « intégration continue » et un versionnement via git.

Actuellement, je me débats avec certains paramétrages par défaut orientés sécurité entre autres qui peuvent limiter/bloquer certains usages sans attention particulière. Il est vrai que par défaut, Kubernetes est une plateforme particulièrement ouverte avec peu de gardes-fous, et c’est à chacun d’adapter cet aspect en fonction de son propre contexte, ce qui amène à devoir exploiter nombre d’extensions et contrôleurs additionnels pour y parvenir. Et comme souvent, la sécurité à un prix…

Et la question de départ ?

On le voit, au final je n’ai que peu choisi comment j’ai découvert et abordé la technologie et son déploiement « dans le monde réel », et j’ai démarré par certaines abstractions qui font que si je m’étais retrouvé face à un cluster « vanilla » (kubeadm, kubespray), et un problème lié au control plane, j’aurais été plus en peine que quelqu’un ayant directement attaqué « the hard way » (z’avez la ref ?). Et d’un certain côté c’est certainement encore le cas encore aujourd’hui, ce qui me vaudrait d’être recalé au recrutement chez Lucca ou Enix. Le livre à venir teasé par Denis Germain (qui ne s’appellera pas 50 Nuances de Kubernetes, ce qui aurait été bien trop cool comme titre) montre bien la diversité d’approches qui ont chacune leurs spécificités, avec la plupart des services dit « managés » abstrayant une bonne partie des composants et concepts de bas-niveau pour vous concentrer sur vos applications ou celles de vos clients.

Est-ce que l’une d’elles est meilleure qu’une autre ? Je considère toujours que la théorie est importante, jusqu’à un certain point, dans la mesure où si on n’a pas de le contrôle sur les éléments, ne pas savoir comment ils fonctionnent de manière sous-jacente n’est pas toujours une grosse tare : ce n’est pas de notre ressort que d’y mettre les mains. Imaginez une corruption de base ETCD sur un service managé. Ma seule préoccupation sera d’être capable éventuellement de restaurer tout ce que j’y ai mis au départ – mes déploiements d’applications, mes secrets, mes CRDs, etc- , là où la préoccupation du provider, sera de réparer cette corruption; dans le pire des cas, s’il n’aura pas été capable de restaurer le service avec un minimum de pertes, il s’agira de restaurer tout ça sur un nouveau cluster.

Nous vivons également dans un monde connecté à la plus grande base de connaissances du monde : Le Web. Je n’ai pas besoin de connaitre l’intégralité des arcanes du moindre bout de logiciel, quelque soit son niveau dans l’environnement où j’évolue, pour être capable de l’exploiter au quotidien, voire de le réparer. Les connaissances déjà acquises sont évidemment importantes, parce qu’elles permettent de définir un état d’esprit, un mode de réflexion, qui est la plupart du temps applicable aux autres technologies que vous rencontrerez. Mais si je rencontre un problème que je n’ai pas déjà vu par le passé, une recherche sur le web m’amène généralement soit à la solution, soit à une piste à creuser pour déterminer la cause. Dès lors, il n’y a pas de réponses simples à apporter à la question « par où démarrer », parce qu’elle peut dépendre aussi de la « fin ».

Faire un cluster à la mano avec tous les composants en mode « the hard way » ne sert pratiquement à rien si après on évolue dans un contexte de service managé. À l’inverse, un service managé est intéressant en ce sens qu’il permet de gérer les interactions avec d’autres services du fournisseur, et donc le mode de fonctionnement de celui-ci. Sur Kube lui-même vous manquez des choses, mais vous avez quand même pas mal de concepts à intégrer. Est-ce moins pertinent ? Pas forcément si c’est ce que vous manipulez tous les jours. Dans le même esprit, « the hard way » est probablement la pire méthode pour gérer le quotidien sur de l’infra qu’on gère, même si pour le coup on a toutes les tripes du cluster sur la table. On privilégiera donc très vite d’autres outils plus automatisés pour la gestion habituelle. N’est-ce pas tout aussi pertinent de démarrer directement avec ces solutions pour intégrer plus rapidement leurs concepts ?

Par où commencer Kubernetes ? J’ai envie de dire, par la solution qui vous rendra curieux. C’est tout le sel de l’apprentissage, comme de la recherche scientifique, où chaque réponse qu’on trouve amène d’autres questions, tout aussi passionnantes. D’autant plus que quand on démarre, on est amené à faire, défaire, refaire, à comparer. Notre univers informatique au sens large bouge tout le temps, la « galaxie » Kubernetes n’est pas en reste, il y a toujours des dizaines d’angles d’attaque possible, et à de très rares exceptions près, il n’y en a pas nécessairement une qui est plus mauvaise qu’une autre. Et d’autres apparaitront régulièrement, ce qui représente de nouvelles réponses possibles à cette question. Il ne faut pas avoir peur de se faire plaisir de différentes manières

Le temps que je cherche une solution pérenne, je coupe les commentaires, pour expliquer pourquoi, voilà un petit aperçu de la raison :

Ça, c’est le spam sur ces deux derniers jours. Et c’est pas le pire que j’ai reçu déjà. J’adore toujours recevoir des commentaires, mais avec un tous les quatre mois, on peut pas dire que ça se bouscule non plus, donc dans l’immédiat, ça ne devrait pas déranger tant de monde que ça.

Ça fait beaucoup trop longtemps que je n’ai pas parlé de Firefox ici (que je n’ai pas parlé du tout, d’ailleurs, si on considère la fréquence de publication, même si j’ai récemment sorti des trucs). Pourtant, un des rares navigateurs web qui devraient avoir votre attention en dehors de la galaxie Chromium (Chrome, Edge, Opera, etc) n’a pas cessé d’avancer, même si on va le voir, la fondation qui est derrière continue de prendre des décisions compliquées…

LE gros plus : continue de supporter uBlock Origin (et d’autres dans le genre)

Sans trop rentrer dans les détails techniques, Google a décidé, pour protéger ses revenus avant de protéger les utilisateurs, de faire évoluer Chromium, et donc tous les acteurs qui en dépendent, pour réduire l’efficacité des outils de blocage de contenus – en tête, les contenus publicitaires et attentatoires à la « vie privée » (même si j’aime moyen le terme en français) – afin de continuer de pister les utilisateurs en ligne. Ça se traduit par une nouvelle version du cadre pour les extensions, Manifest v3. Mozilla a de son côté, certes accepté de prendre en charge les autres évolutions liées à ce changement, mais aussi de garder la compatibilité avec la version actuelle, aka Manifest v2, pour conserver l’efficacité des extensions existantes en matière de contrôle de l’expérience UTILISATEUR.

Bref, quand Google vous dit clairement « on va continuer de faire des saloperies en vous suivant à chaque coin de clic », Mozilla vous dit « on va continuer à vous aider à empêcher de vous suivre à chaque coin de clic ». Et vu l’état du web aujourd’hui, aussi bien pour le confort que pour votre sécurité, ça devrait être LE critère. D’autant que c’est dispo partout, Windows, Mac, Linux, Android ! (reste l’iPhone, mais quand on choisit délibérément la prison dorée, on peut rien pour vous, même si ça pourrait bouger avec les décisions européennes récentes).

L’interface, ça bouge enfin !

Il aura fallu plus de deux ans et plusieurs forks qui commencent à faire du bruit (coucou Zen) pour qu’enfin, Mozilla se bouge le cul sur la gestion des onglets dans une barre latérale VERTICALE. Pendant des années, et pire après la refonte Quantum, les extensions permettant entre autres de déporter la barre d’onglets du haut de la page vers la gauche (ou la droite si c’est votre kiff, ou que votre langue natale se lit de droite à gauche) avaient toutes la même limitation, à savoir ne pas pouvoir cacher l’originale du haut de l’écran, ça faisait donc doublon et une sacrée pertes de pixels à l’écran. J’en ai été l’amer témoin après deux ans d’utilisation de Tree Style Tab, et je ne considère pas les gros hacks dans les fichiers de configuration (chrome.css) comme quelque chose de potable pour le conseiller à d’autres personnes.

Autre gros changement, indépendant mais qui arrive avec très peu de décalage au final, et là aussi réclamé très fort depuis des années, le groupement d’onglets. On ne parle pas ici des contextes/containers, qui permet l’isolation des cookies entre autres, mais plus simplement du fait de regrouper visuellement les onglets dans des « groupes » pour pouvoir les classer, sans tout refermer et sans se reposer juste sur les marque-pages ou des fenêtres différentes, ce qui permet de garder la barre d’onglets claire tout en gardant un œil et pouvant basculer sur plusieurs activités différentes nécessitant plusieurs onglets. Cette fonctionnalité a été déployée en plusieurs fois, donc au début il fallait passer par about:config, mais désormais, pour autant que j’ai pu en juger, c’est actif par défaut.

Concernant ces groupements d’onglets, ils commencent aussi à introduire une recommandation de groupes via une mini-IA locale (cherchez pas, j’ai pas creusé je sais pas dans quelle mesure c’est du bullshit marketing, mais c’est là), histoire de faciliter la vie si vous avez beaucoup d’onglets.

Autre sujet problématique depuis très longtemps sur Firefox: la gestion des profils. Oui, au-delà de la séparation des cookies via les onglets contextuels (les fameux « containers »), il est possible d’aller beaucoup plus loin, avec un profil complet. Ça veut dire, une gestion distincte des extensions, de l’historique, des marque-pages, du stockage éventuel de mots de passe, de la synchronisation de tout ou partie de tout ça avec un compte Firefox différent, bref, comme si vous aviez deux installations de Firefox indépendantes ou presque, tout ça sur le même compte utilisateur du même PC. Mais historiquement, pour accéder à ça, il fallait passer par la ligne de commande, ce qui fait que même la plupart des utilisateurs avancés de Firefox n’ont peut-être même pas connaissance de la fonction. Ça progresse doucement, mais il y a enfin une manière de gérer « nativement » (comprendre sans démarrer Firefox depuis ladite ligne de commande) les différents profils. Et si vous ne voyez pas à quoi ça peut servir (après tout, si vous avez plusieurs utilisateurs sur un PC, chacun aura son propre profil aussi), voici un petit exemple: Vous devez travailler avec deux identités Microsoft 365 différentes, pour accéder en parallèle à deux documents différents sur deux « tenants » différents, des permissions différentes, etc. Pour éviter de croiser les flux, Isoler les deux comptes/identités dans des containers, c’est bien, mais isoler dans des profils, c’est encore mieux, parce qu’on isole aussi l’historique, et donc on évite, via la barre d’adresses et l’historique, de tenter d’ouvrir malencontreusement le lien d’un document en utilisant la mauvaise identité. Au mieux on se prend une erreur, au pire ça remonte une alerte de tentative d’accès non-autorisée à un document relativement confidentiel par une personne extérieure. Dans un contexte un peu moins professionnel, si vous gérez deux comptes de réseaux sociaux, un pour vous, un pour votre chat, vous pouvez utiliser les profils pour vraiment garantir que vous ne posterez pas avec le mauvais compte.

Du rattrapage sur certains standards et pratiques

Il y a aussi des choses un peu moins visibles ou triviales, mais qui auraient du là aussi être prises en compte depuis longtemps. Comme des fonctionnalités liées à WebRTC par exemple (vous savez, le protocole que tout le monde à découvert en 2020 avec le confinement lié au COVID19), avec plusieurs années de retard et qui ont empêché l’utilisation de Jitsi Meet et Firefox à grande échelle et qui ont du coup poussé des utilisateurs vers d’autres navigateurs qui eux fonctionnaient parfaitement (et d’autres solutions de visioconférences moins respectueuses et sécurisées)… Quand Mozilla se plaignait déjà de perdre des utilisateurs au profit de Chrome, c’est con hein ?

Il y a aussi le support intégré d’H265 – plus pour de sombres histoires de brevets qu’autre chose, évidemment, quand on aimerait que tout le monde se tourne définitivement vers AV1, qui n’a pas ces problèmes de brevets, lui. D’autant que les services vidéo qui utilisent encore H265 ne sont pas légion, Twitch reste encore majoritairement cantonné à H264, et Youtube pousse VP9 et AV1 dès qu’il peut, Netflix présente l’AV1 dès que c’est possible pour économiser en bande passante… pour ne parler que de certains des plus gros.

Pour les trois linuxiens qui restent et dont je fais partie, l’accélération vidéo qui décolle enfin avec autre chose que du GPU Intel, comme quoi il n’y a pas qu’avec la 3D que notre environnement polaire pose problème. Notez bien que du côté de Chrome, sous Linux ça s’en contrefout royalement et ça ne supporte pas l’accélération, donc ça tabasse du CPU comme il faut (enfin presque : ça arrive via VA-API… sous Wayland, wouhou).

Plus subtil, pas du tout grand public, et je ne l’ai découvert qu’il y a moins d’un an, l’arrivée ENFIN pour les développeurs d’une interface commune entre Firefox et Chrome pour les tests automatisés de leurs applications, Webdriver BiDi. Si vous cherchiez une des raisons qui poussent certains développeurs « flemmards » à vous dire « on a testé que sur Chrome » c’est probablement pour cette raison, et c’est l’un des points les plus ahurissants à mon sens quand on regarde deux secondes la quantité d’outils de frameworks de tests automatisés qui supportent juste Chrome avec CDP, et même la différence de fonctionnalités entre les deux interfaces historiques avant qu’un standard commun soit trouvé/mis en place; et même là il y a encore quelques limitations, mais beaucoup moins qu’avant !.

Aussi, et ça m’a été confirmé récemment par Christophe Villeneuve à LeHACK, Mozilla commence à modifier ses priorités de développement en fonction de certaines idées remontées via leur plateforme dédiée à cet effet, Mozilla Connect. Bref, si vous avez des idées d’options, de fonctionnalités, de traductions, etc… que vous voulez voir implémentés, vous pouvez vérifier si la proposition a déjà été faite, pour la soutenir, ou faire la proposition vous-même si c’est tout neuf. Plutôt cool non ?

Et pourtant toujours des dissonances plus ou moins compréhensibles

Je ne vais pas trop me prononcer sur toutes les initiatives qu’ils peuvent avoir sur les sensibilisations à la vie privée, au contrôle de l’expérience en ligne etc, vu qu’ils ne font pas ça en France (ou alors tellement peu que ça passe complètement sous le radar), mais oui, Firefox se targue d’être LE navigateur qui respecte votre vie privée, qui vous permet de la faire respecter sur les sites web que vous visitez. Et pour une grande part, c’est tout à fait vrai, les options intégrées sont quand même particulièrement poussées quand on compare à la concurrence.

À côté de ça, ils continuent d’utiliser Google Analytics pour leurs propres services, le catalogue d’extensions en tête, alors que sur le papier, c’est illégal en Europe depuis 2020 parce que par nature on ne peut pas respecter le RGPD avec. La dépendance à Google ne s’arrête pas là vu que la majorité des revenus vient toujours de l’accord avec celui-ci pour proposer Google Search en moteur de recherche web par défaut. On y reviendra d’ailleurs à ce Google…

Côté maitrise des données, cela fait des années qu’ils ne se sont toujours pas réveillés et que PERSONNE ne sait héberger sa propre infrastructure de compte Firefox pour se séparer de celle de Mozilla, quand bien même on peut paramétrer la source du compte dans les options avancées de Firefox (idem pour la synchronisation), et pire, que le code source est publié mais qu’il n’a pas évolué ou presque. Problème, Mozilla étant sur le sol américain, là encore ils sont soumis aux lois locales et donc nos données ne sont pas spécialement plus à l’abri. Donc vie privée oui, mais quand même un peu en mode « aie confiance, crois en moi » qui gratte un peu dans le dos.

Ils aiment l’open-source, mais le service Pocket, racheté il y a longtemps et qui permet de « mettre de côté » des articles à lire plus tard, n’a été mis en open-source que très très récemment (et j’étais passé complètement à côté de cette info, vu qu’une des premières choses que je fais en démarrant un nouveau profil Firefox est d’aller dans about:config pour désactiver Pocket). Il y a semble-t-il un petit marché pour en faire une source de revenu, mais c’est un très petit marché (ça fait vivre wallabag.it par exemple, mais c’est un solo dev). Tellement petit qu’ils viennent de fermer le service d’ailleurs. Également sur l’aspect open-source, il y a eu pendant très longtemps le gros problème de la « gestion de la marque » qui a empêché l’utilisation de Firefox et de son logo directement dans plusieurs distributions Linux comme Debian. Ça a donné Iceweasel, Firefox mais sans la marque Firefox, avant qu’ils se décident à lâcher du lest de ce côté-là (choix incompréhensible notamment pour Debian qui est un projet non-commercial, quand Ubuntu a eu le droit dès le départ…).

Aussi, alors même qu’ils ont été à l’origine de Rust, que ça a été un gros sujet d’augmentation des performances, au final Rust est devenu indépendant (c’était plutôt logique), mais pourquoi avoir abandonné Servo, une refonte from scratch du moteur écrit justement en Rust avec la promesse de performances de haut-vol en garantissant une grosse base de sécurité par dessus le marché ? Servo a fini par renaitre sous la houlette de volontaires, mais accumule du coup un retard conséquent pour en faire quelque chose d’exploitable en alternative à Chrome. Et ça disperse les ressources qui auraient pu bosser sur Firefox…

Et puis même si j’ai été moins impacté, j’ai difficilement digéré l’abandon de FirefoxOS qui aurait pu, avec la force de frappe que pouvait avoir Firefox à l’époque, être une réelle alternative quand on voit ce que devient Android aujourd’hui et comment Google est en train, sournoisement, de refermer son emprise dessus. 99% des besoins des utilisateurs ne nécessitent pas de les enfermer dans des applications, sauf à les abuser de publicités ciblées (là encore…). Les initiatives alternatives à Android sont toujours très compliquées aujourd’hui, parce qu’avec toujours très peu de ressources, sans parler des fabricants très peu respectueux sur l’ouverture d’une partie des pilotes (et on va mettre de côté le problème des « firmwares » aujourd’hui, hein), voire carrément du bootloader qui permettrait de prolonger la durée de vie des appareils (coucou Samsung).

Firefox en danger ?

Contrairement à Julien qui évoque le fait que les forks de Firefox pourraient prendre le relai, vu l’ampleur du projet, je suis moins optimiste si Mozilla se retrouve sans sa perfusion. J’avais dit qu’on reviendrait dessus, si ça n’est pas arrivé jusqu’à vous, il faut savoir qu’actuellement, Google est sous le coup de deux procès différents qui viennent d’aboutir à des décisions d’abus de position dominantes, l’un sur la publicité en ligne (70+% des revenus de Google), l’autre sur la recherche en ligne, avec pour cible dans ce deuxième contexte les accords conclus pour proposer/embarquer Google en moteur de recherche par défaut dans des produits/services tiers; c’est valable chez Mozilla, mais aussi chez Apple, qui est pourtant concurrent de Google sur la partie mobile, et d’autres acteurs moins forcément parlants pour nous. Si ces accords venaient à être interdits, Mozilla se verrait privé de 80% de ses revenus, on imagine l’impact catastrophique que ça aurait sur eux et donc sur Firefox, mais pas seulement (Apple s’en remettrait facilement, ce n’est « que » 20 milliards de dollars, même s’ils chouinent aussi logiquement).

Malgré les problèmes passés et les polémiques notamment sur le salaire de l’ancien responsable de la Fondation, sans la manne financière, le développement de Firefox sera littéralement à l’arrêt s’ils ne peuvent pas financer l’infrastructure et les développeurs qui sont loin d’être tous bénévoles. En face, Chromium est alimenté par les développeurs de toutes les grosses boites qui se basent dessus : Google avec Chrome, Microsoft avec Edge, rien que pour ne citer que ces deux-là… Faire un navigateur web embarquant tous les standards et permettant d’exploiter tout ce que les participants existants supportent actuellement est un travail de titan qui ne se fera pas sur le temps libre de quelques valeureux et talentueux volontaires. Et la fondation Linux ne peut pas voler au secours de tous les projets open-source en danger du monde (et ça se multiplie ces dernières années à un rythme inquiétant). Bref, ça se complique un peu ces derniers temps, et si Google pourrait se voir obligé de vendre Chrome (sans surprise ils refusent), les vautours se pressent déjà autour du potentiel cadavre, Firefox est toujours plus isolé, alors même qu’il est plus que nécessaire dans un paysage particulièrement morose. D’ailleurs entre le début de l’écriture de ce billet sa sortie, on a deux acteurs de l’IA générative qui veulent leur propre navigateur, et sans surprise, ce n’est pas pour le respect des utilisateurs… et c’est basé sur Chromium.

Bref, utilisez Firefox pour que le Web ne devienne pas une immense prison dorée pour entreprises américaines, (ce qui est déjà pratiquement le cas, on laisse crever les moteurs de recherches pour utiliser des IA qui sont toutes américaines…) c’est même un des derniers qui vous permette de réellement vous protéger face aux abus quant à votre vie privée, et surtout qui vous laisse le contrôle à ce sujet. De mon côté, comme j’ai prévu de revoir mes contributions aux associations, Mozilla va peut-être de nouveau profiter d’un peu de mon argent, et si vous pouvez vous le permettre, je ne peux que vous inviter à en faire de même. Ils ne sont pas parfaits, certes, mais c’est toujours moins pire que Google et Microsoft, non ?

Les courbes elliptiques, c’est la promesse de la robustesse des communications chiffrées de TLS sans la lourdeur des tailles de clés utilisées avec l’algorithme RSA. Il ne sera pas question de mathématiques aujourd’hui (je suis trop mauvais pour ça, vous avez qu’à voir Wikipedia pour ça), juste de quelques notes sur leur utilisation, pour du certificat autosigné, de la vérification, et un micro rappel de Let’s Encrypt.

Faites une petite recherche rapide, et 99,9% des tutos pour générer un certificat, que ça soit pour de l’auto-signé, ou dans le cadre de la commande chez une autorité « classique », et vous aurez du RSA avec un panel de 2048 à 4096 bits de taille de clé. Sans faire de benchmark, je peux vous assurer que si 2048bits est assez classique, 4096 ça commence à être assez lourd à gérer. Les courbes elliptiques sont des objets mathématiques qui promettent de garder la complexité mathématique, clé de la robustesse en matière de cryptographie, mais avec une taille de clé beaucoup plus réduite, ce qui permet d’améliorer la consommation de ressources et la performance du chiffrement des communications, parce que c’est le contexte dans lequel elles ont été envisagées et déployées.

Le certificat auto-signé

Typiquement, pour déployer un virtualhost « par défaut » sur mon serveur web Nginx, j’ai voulu générer un certificat auto-signé certes, mais avec les courbes elliptiques comme base cryptographique. C’est plutôt simple au final, ça se joue en à peine plus de temps, ça repose sur l’incontournable OpenSSL, malgré les problèmes qu’il pose ces dernières années, surtout en tant que bibliothèque applicative. On commence par lister les courbes disponibles :

openssl ecparam -list_curves

Vous choisissez ce que vous voulez, pour des raisons de compatibilité, j’ai sélectionné secp384r1 qui est la plus utilisée derrière sa petite sœur en 256bits et qui est nommée prime256v1 (parce que nique la cohérence, hein). C’est au passage celle que j’utilise sur le blog

Ensuite, on fait les étapes classiques pour un autosigné :

openssl ecparam -genkey -name secp384r1 -out key.pem
openssl req -new -sha256 -key key.pem -out csr.csr
openssl req -x509 -sha256 -days 365 -in csr.csr -out certificate.pem

Pendant la phase de création du CSR, vous répondez comme vous le souhaitez aux questions, comme on est sur de l’autosigné vous pouvez être créatif si ça vous chante

Et voilà, vous n’avez plus qu’à renseigner la clé et le certificat dans votre Virtualhost par défaut, comme ça, si vous interrogez l’IP de votre serveur web, c’est ce certificat « placeholder » qui apparaitra (autosigné certes, mais certificat quand même) et ça masquera le reste de vos virtualhosts, parce que sinon le serveur web présente le premier chargé dans les configurations incluses (je me demande si j’en ferai pas une démo en live tiens…).

Vérifier la correspondance clé/certificat

Oui je sais ça parait con, mais ça m’est déjà arrivé une quantité beaucoup trop importante de fois de ne pas être certain qu’un nouveau certificat à installer correspond encore à la clé qui est déjà déployée, ou si une nouvelle clé à été générée pour l’occasion. La joie de l’infogérance et des tickets traités par plusieurs admins successivement.

Idem, quand on cherche les manipulations à effectuer, on trouve quasi systématiquement la méthode basée sur le modulus. Sauf que cette méthode est propre à l’algorithme RSA, et n’est donc pas applicable pour des courbes elliptiques. Malgré tout, on peut s’en sortir. L’astuce consiste cette fois à comparer la clé publique entre la clé et le certificat. D’abord pour la clé :

openssl ec -in key.pem -pubout |openssl md5

openssl x509 -in certificate.pem -noout -pubkey |openssl md5

Si les deux résultats sont identiques, vous pouvez les charger dans le serveur web (ou dans l’interface de votre fournisseur d’infrastructure, si vous êtes dans le claude).

La génération pour Let’s Encrypt via acme.sh

Let’s Encrypt (et certainement d’autres fournisseurs) supporte les courbes elliptiques depuis un moment déjà. Personnellement, je préfère utiliser le léger acme.sh plutôt que l’officiel certbot, que je trouve particulièrement lourd. La génération est plutôt simple :

acme.sh --issue --ecc -k ec-384 -d www.domain.tld -w /var/www/ --debug

Évidemment c’est à adapter au domaine, et au dossier par lequel il va bosser le challenge. Perso je préfère ensuite faire une installation dans un dossier dédié pour inclure la commande de rechargement du serveur web derrière :

acme.sh --install-cert -d domain.tld --fullchain-file /etc/nginx/ssl/domain.tld.crt --key-file /etc/nginx/ssl/domain.tld.key --reloadcmd "systemctl reload nginx"

---

Voilà, comme on le voit, il ne faut pas grand chose pour passer à cette méthode cryptographique, et investiguer à son sujet est à peu près aussi simple qu’avant. Juste je trouve qu’il y a vraiment peu d’articles qui incluent les courbes dans les manipulations. Bon ben voilà