Exemple avec CloudFlare

Mis à part quelques cyber-ermites dans les marges, tout le monde s'est rendu compte d'une panne chez Cloudflare hier (18 novembre). Ils s'en sont expliqué dans leur retour d'expérience¹ et, comme toujours après coup, ça paraît si simple…

1. Pour améliorer leur sécurité, ils ont revu les permissions dans leur base de donnée. Les requêtes ne sont plus faites par un compte partagé mais pas un compte utilisateur dédié à chaque système. Détails d'importance, ces comptes utilisateurs ont implicitement accès à la table r0.
2. Le système de génération des règles de détection des robots a une de ses requêtes qui récupère des données depuis la table default, mais sans la nommer en partant du principe que c'est la seule table à laquelle il a accès. Sauf qu'après la modification, il a aussi récupéré des données de r0.
3. Ces données surnuméraires ont généré de très nombreux doublons qui n'ont pas été écartés dans les règles de détection et leur nombre a explosé (il est passé d'une soixantaine à plus de 200). Le nouveau fichier de configuration contenant toutes ces lignes a ensuite été envoyé aux systèmes de détection de robots.
4. Par soucis d'optimisation, ces systèmes allouent une zone de mémoire fixe pour lire cette configuration. Trop gros pour y entrer, le système n'a pas pu charger le fichier. L'erreur générée n'a pas été attrapée par le code qui a tenté de convertir l'erreur en lignes de configuration… et s'est donc planté.
5. Sur les anciens proxy de Cloudflare, le plantage a généré un score de robot systématiquement nul. Les clients n'utilisant pas ce score n'y ont donc pas vu de problème mais pour les autres… le système anti robot a alors tout bloqué. Sur les nouveaux proxeies, le plantage a été détecté comme une erreur interne et un code 5xx a été retourné aux visiteurs, bloquant le trafic correspondant.
6. Tous les services de Cloudflare sont hébergés derrière leur propre proxy et ont donc cessé de fonctionner aussi.

Il a fallu 20 minutes pour que la mise à jour de la base de donnée fasse planter les premiers flux. Cloudflare a mis deux heures pour déterminer que le blocage était du au détecteur de robots, et une heure de plus pour remonter au fichier de configuration et commencer à déployer un ancien fichier. Deux heures et demi plus tard, les systèmes sont revenus à la normale. Très franchement, on peut saluer leur performance (et les remercier pour leur retour d'expérience).

Le premier enseignement c'est qu'en informatique, c'est comme en aéronautique. Lorsqu'un système se plante, c'est rarement à cause d'une seule erreur mais plus souvent d'une cascade de petites erreurs individuelles. Elles peuvent toutes sembler minimes voir être justifiées individuellement, mais mises bout à bout, la cascade fait déborder le vase.

L'autre enseignement, c'est qu'à force de vouloir ajouter de la sécurité qui bloque, on fini par obtenir ce pourquoi on a payé : les accès sont bloqués. D'une certaine manière, le système s'est comporté exactement tel qu'il devait le faire. Face à chacune des erreurs, le système a pris la voie la plus sécurisée : aucun robot n'a pu passer les barrières.

Karpman a encore frappé

Si on prend du recul, on peut y voir un problème de géométrie... Les sites web sont des victimes, Cloudflare est le sauveur. Sauf que le sauveur peut faire des boulettes, et dans ce cas là, il se transforme (malgré lui) en agresseur. Pour sortir du triangle et éviter ce genre de problème, il serait plus résilient que chacun s'occupe de sa propre sécurité.

La majorité des sites n'ont pas besoin de ces CDN. Tous ces contenus stockés en cache... c'est bien beau le cache, mais si on y réfléchit, ce ne sont que des sites statiques qu'on met devant d'autres sites statiques… Sauf qu'il faut aussi y mettre devant d'autres proxys, répartiteurs de charge et autres détecteurs divers qui ralentissent l'ensemble².

On peut alors se poser la question légitime...

Quel intérêt ?

La Question Légitime

Pour Cloudflare, au-delà des revenus tirés de la facturation du service, on peut remarquer qu’ils sont la terminaison TLS de tous les flux qu’on leur a confié. Dit autrement, la cryptographie s’arrête à leur porte ; ils voient donc les flux en clair³.

Gérer soi-même

Comme l'a écrit Lord, toute cette couche peut dédouaner les salariés de leurs responsabilités. Mais pour le reste, pourquoi aurions nous besoin de tout ça ?

Chez les arsouyes, on n'a qu'un site statique ne contenant que des informations publiques. Aucun contrôle d'accès, aucune interprétation de code, aucune vulnérabilité à masquer d'un Waf⁴, aucun cache pour ralentir la transmission des fichiers.

Surtout que, comme Lord l'écrit, si on veut gérer la disponibilité, on pourrait le faire nous même. Redonder les serveurs DNS puis redonder les serveurs web et répartir la charge via les enregistrement DNS. Et pourquoi pas aller plus loin et échanger cette redondance entre amis : chacun redonde les autres.

On pourrait aller plus loin. Puisque nos sites ne sont que des contenus statiques, n'importe qui pourrait aspirer le contenu et produire un clone sur son serveur. La redondance apportée serait une preuve qu'on soutient l'auteur du site original. Une preuve bien plus concrète (et impactante) qu'un pseudo like sur un réseau pseudo social.

Mettons de côté l'idée que l'auteur n'a pas demandé l'assistance d'un sauveur venu lui redonder son site pour lui et poursuivons quand même cette idée pour voir où elle peut mener…

Pourquoi ne pas tout automatiser ? Et si on pouvait épingler les sites qu'on aime et ainsi servir de miroir automatiquement. On pourrait aller jusqu'à ajouter une petite couche de cryptographie à clé publique pour authentifier les contenus et éviter qu'un anmaerdeux nous usurpe. Et pourquoi pas gérer aussi l'adressage et se passer du DNS ?

Et boum, vous avez IPFS et les autres protocoles du genre...

Pourquoi redonder ?

Mais la question qui m'intéresse, ce n'est pas tant comment résoudre techniquement le problème (on vient de voir que IPFS propose une solution) mais plutôt « pourquoi aurions nous besoin de le faire ? »

Je veux dire, admettons que le datacenter qui héberge les arsouyes brûle⁵, ça ne prendra pas plus d'une journée de tout remonter (le temps le plus long sera la propagation des DNS). Imaginons pire, que le site soit injoignable pendant un mois. Mettons même deux mois pour faire bonne mesure. Le monde va sombrer dans le chaos parce que vous n'avez plus accès à nos textes ?

Puisque ce n’est pas un problème de disponibilité, c’est peut être un problème de conservation du patrimoine culturel de l’Humanité. L'idée que la disparition soit définitive vous inquiéterait et justifierait de mettre en œuvre des méthodes de sauvegarde pérenne…

L’œuvre est un legs aux générations futures.

Je ne suis pas sûr que tous nos articles méritent vraiment d'être sauvegardés à ce point. Je veux dire, on a régulièrement fait le ménage et personne n'est jamais venu nous demander ce qu'était devenu tel article disparu. Inversement, devons nous vraiment faire peser sur l'humanité la charge de sauvegarder nos propres textes ?

C’est pourtant la mission que s’est donné Wayback Machine. Comme vous vous en doutez, on est dessus mais toutes nos pages n’ont pas été sauvegardées. Je ne m’en plaint pas, si je voulais une archive de mon propre site, j’en aurais fait une. Et si je ne l’ai pas fait, c’est que ce problème ne m’inquiète pas.

Pour aller au bout de la réflexion, je ne trouve pas les sites webs adaptés pour une transmission aux générations futures. Au delà des problèmes techniques de rétro-compatibilité, nos sites sont en constante mutation et contiennent de nombreux liens vers d’autres sites, eux aussi en mutation permanente. Pour les sauvegarder dans leur environnement il faudrait faire une capture du web complet à chacune de ses modifications…

Et les livres dans tout ça ?

Contrairement au web où il est très facile de publier, les livres imposent un rythme beaucoup plus lent. Entre l’idée et sa publication, les livres nécessitent des étapes intermédiaires qui n’existent pas pour le web (e.g. impression sur papier et reliure), ou qui existent mais sont plus coûteuses et/ou plus longues.

Paradoxalement, je trouve que cette lourdeur est leur force. Si on veut léguer quelque chose aux générations futures, avec humilité⁶ et sincérité⁷, le livre est bourré d’opportunités⁸.

La consistance. Nos billets font 1700 mots en moyenne⁹. Pour un petit livre de 100 pages il faut compter entre 20 000 et 30 000 mots. Soit de 12 à 18 billets de taille moyenne. Si vous visez 400 pages, il faut l’équivalent de 47 à 70 billets.

Au risque de produire du vide ou un recueil sans cohérence, le sujet du livre doit être conséquent pour remplir toutes ces pages à lui seul.

La maturité. Pour traiter un sujet sur la distance d’un livre, il faut le maîtriser en profondeur. Si ce n’est pas toujours le cas au début du projet, ça finira par le devenir. Mais attention, il ne suffit pas d’accumuler du contenu pour remplir des pages. Il faut être capable de l’organiser pour lui donner un sens. Et ça implique aussi de choisir ce qui ne sera pas dans le livre.

La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer.

Antoine de Saint-Exupéry

Écrire un livre, ce n’est pas tracer une carte exhaustive sur le sujet. C’est bien plus que ça. C’est raconter les voyages qui donnent du sens à la carte.

La qualité. Avant de publier un livre qu’on veut léguer à l’Humanité, on se doit de le vérifier à tous les niveaux. Il y a le texte ; et son orthographe, son choix de mots, de formulations, et de transitions. Il y a aussi le para-texte ; avec les notes en bas de page, les références, les citations, les codes sources¹⁰, les illustrations et les schémas.

Il y a aussi la forme. Avec tous ses choix typographiques et de mise en page. Faire attention à ce que le para-texte soit sur la même double page que le texte qui y fait référence¹¹ pour que le lecteur n’aie pas à tourner les pages en aller/retours, ou que les codes sources ne soient pas divisés par un saut de page.

Et lorsqu’on pense avoir atteint l’objectif : imprimer le livre pour le lire et le faire lire à des bêta-testeurs. Attendre leur retour et se rendre compte des erreurs qui sont passées entre les mailles de nos filets et se remettre à l’ouvrage. Encore. Parce que s’il est facile de corriger un billet de blog après coup, c’est bien plus difficile une fois les livres imprimés et partis chez leurs lecteurs.

L’intérêt. Vu les écueils à traverser, seules les idées qui motivent assez l’auteur pour poursuivre l’aventure survivront au processus. Une sorte de sélection naturelle qui écarte les idées en l’air pour ne garder que celles qui font sens¹².

Et après ?

Une fois rendus à la fin du chemin, on a la satisfaction d’avoir produit un objet qui en vaut la peine. Et en tant qu’objet matériel, le livre a de nouveau avantages.

Tout d’abord, c’est un médium profondément humain. Contrairement à un ebook ou un site web, vous ne dépendez pas de l’informatique ; tant que vous savez lire, vous pouvez profiter du livre. Inversement, les robots d’IA n’ont accès qu’aux œuvres numériques et tant que personne ne numérise le livre, ces machines à plagiat n’y auront pas accès¹³.

Ensuite, c’est un médium profondément libre. Même si le livre dans sa réalisation matérielle est couvert par le droit d’auteur, son contenu est libre. Même s’il n’est pas sous licence Créative Commons, vous pouvez l’utiliser librement au sens de la Free Software Foundation :

0. Vous pouvez utiliser le livre dans n’importe quel but (y compris pour caler un meuble),
1. Vous pouvez l’analyser autant que vous voulez pour le comprendre,
2. Vous pouvez le prêter à qui vous voulez pour qu’il en profite (y compris pour caler ses meubles),
3. Vous pouvez écrire vos propres livres avec vos propres réflexions et adaptations des livres que vous avez lu.

Enfin, c’est un médium profondément résilient. Chacun des exemplaires en circulation est une sauvegarde autonome. Pas besoin d'internet, pas besoin d'équipement de lecture, tant que vous en avez un sur votre étagère, vous pouvez le lire. Tant qu'il reste un livre en circulation, son contenu reste disponible pour l'Humanité (et il y en a deux à la BNF).