Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.


Fiche de lecture : Le libre pensée dans le monde arabo-musulman

Auteur(s) du livre : Ouvrage collectif
Éditeur : Fédération de la Libre Pensée
978-2-916801-23-0
Publié en 2023
Première rédaction de cet article le 22 février 2024


En France en 2024, le discours politique sur le monde arabo-musulman est souvent fondé sur une assignation identitaire, qui suppose que toute personne élevée dans un milieu musulman est forcément croyante, voire bigote, ou même islamiste. La réalité est différente et le monde arabo-musulman a lui aussi ses libres penseurs qui n'acceptent pas aveuglément les dogmes religieux, et encore moins les humains qui les utilisent pour assoir leur pouvoir. Cet ouvrage rassemble un certain nombre de contributions, très diverses, sur des libres penseurs dans l'histoire du monde arabo-musulman.

Tout le monde a entendu parler d'Omar Khayyam, bien sûr. Mais la plupart des autres libres penseurs décrits dans l'ouvrage sont nettement moins connus en Occident. Ils ne forment pas un groupe homogène : certains sont athées, d'autres simplement méfiants vis-à-vis de la religion organisée. Il faut aussi noter que le livre couvre treize siècles d'histoire et une aire géographique très étendue ; il n'est pas étonnant que la diversité de ces libres penseurs soit grande. Le livre contient aussi des textes qui remettent en perspective ces penseurs, par exemple en détaillant le mouvement de la Nahda ou bien en critiquant le mythe de la tolérance religieuse qui aurait régné en al-Andalus.

Le livre est assez décousu, vu la variété des contributeurs. On va de textes plutôt universitaires à des articles davantage militants (et certains sont assez mal écrits, je trouve, et auraient bénéficié d'une meilleure relecture). Mais tous ont le même mérite : tirer de l'oubli des libres penseurs souvent invisibilisés comme Tahar Haddad ou Ibn al-Rawandi. Et vous apprendrez de toute façon plein de choses (je ne connaissais pas le mutazilisme).


L'article seul

Fiche de lecture : Atlas du numérique

Auteur(s) du livre : Ouvrage collectif
Éditeur : Les presses de SciencesPo
978-2-7246-4150-9
Publié en 2023
Première rédaction de cet article le 21 février 2024


Cet atlas illustre (au sens propre) un certain nombre d'aspects du monde numérique (plutôt axé sur l'Internet). Beaucoup de données et d'infographies sous les angles économiques, sociaux et politiques.

L'ouvrage est très graphique, et riche. Tout le monde y trouvera des choses qui l'intéressent comme le spectaculaire tableau des systèmes d'exploitation p. 18 ou bien la représentation astucieuse de l'alternance des modes en IA p. 33 ou encore la visualisation de la censure en Russie p. 104 (tirée des travaux de Resistic). Les résultats ne sont pas forcément surprenants (p. 61, les youtubeurs les plus populaires sur les sujets de la voiture ou de la science sont des hommes, sur les sujet animaux, style et vie quotidienne, ce sont des femmes). Mais plusieurs articles mettent aussi en cause certaines analyses traditionnelles comme p. 82 celui qui dégonfle le mythe « fake news » (ou plus exactement leur instrumentalisation par les détenteurs de la parole officielle).

Les utilisations de l'Internet (en pratique, surtout les réseaux sociaux centralisés) sont très détaillées, par contre l'infrastructure logicielle est absente (la matérielle est présente via des cartes de câbles sous-marins et des articles sur l'empreinte environnementale).

Les infographies sont magnifiques mais souvent difficiles à lire, en raison de leur petite taille (sur la version papier de l'ouvrage) et du fait que chacune est le résultat de choix de présentation différents. D'autre part, les couleurs sont parfois difficiles à distinguer (p. 31 par exemple). Et l'axe des X ou celui des Y manque parfois, comme dans l'article sur la viralité p. 56 qui n'a pas d'ordonnées. Il faut dire que certaines réalités sont très difficiles à capturer comme la gouvernance de l'Internet p. 101, sujet tellement complexe qu'il n'est pas sûr qu'il aurait été possible de faire mieux.

Plus gênantes sont les bogues comme p. 31 la Quadrature du Net et FFDN classées dans « Secteur économique et start-ups ». Ou bien p. 37 LREM considéré comme plus à gauche que le PS


L'article seul

Fiche de lecture : The Wager

Auteur(s) du livre : David Grann
Éditeur : Simon & Schuster
976-1-47118367-6
Publié en 2023
Première rédaction de cet article le 20 février 2024


Si vous aimez les histoires de bateau à voile, avec naufrages, mutineries, iles désertes et tout ça, ce roman vous emballera. Sauf que ce n'est pas un roman, le navire « The Wager » a vraiment existé et vraiment fait vivre toutes ces aventures à son équipage.

Le livre a été écrit par David Grann, connu comme l'auteur de « Killers of the flower moon ». En attendant que Scorsese en fasse un film, comme il l'a fait de « Killers of the flower moon », je recommande fortement la lecture du livre. « The Wager », navire de guerre anglais, n'a eu que des malheurs pendant la guerre de l’oreille de Jenkins. Départ retardé, épidémies à bord alors même qu'il était encore à quai, problèmes divers en route, une bonne partie de l'équipage mort alors même que le Wager n'a pas échangé un seul coup de canon avec les Espagnols. Le bateau finit par faire naufrage en Patagonie. À cette époque, sans radio, sans GPS, sans même de mesure de longitude correcte, de tels naufrages n'étaient pas rares. (Le livre parle aussi d'une escadre espagnole qui a tenté d'intercepter celle où se trouvait le Wager, et n'a pas été plus heureuse.)

Ce qui est plus original dans le cas du Wager est que des survivants sont rentrés séparement en Angleterre et qu'ils ont raconté des histoires très différentes sur le naufrage et la mutinerie qui a suivi. Chacun (en tout cas ceux qui savaient écrire ou bien trouvaient quelqu'un pour le faire pour eux) a publié sa version et l'auteur de ce livre essaie de rendre compte des différents points de vue.

Donc, pas un roman mais autant de rebondissements que dans un roman. Vous feriez comment, vous, pour rentrer en Angleterre si vous étiez coincé sur une des iles les plus inhospitalières d'une des régions les plus inhospitalières du monde ? Le plus extraordinaire est que plusieurs groupes de survivants y sont arrivés, par des moyens différents.

Sinon, les informaticien·nes noteront que l'arrière-grand-père d'Ada Lovelace était à bord (il fait partie de ceux qui ont écrit un livre sur le voyage du Wager). Les fans de Patricio Guzmán verront que cela se passe au même endroit que son film « Le bouton de nacre » (et on croise dans le livre les mêmes Kawésqars).


L'article seul

Fiche de lecture : Penser la transition numérique

Auteur(s) du livre : Ouvrage collectif
Éditeur : Les éditions de l'atelier
978-2-7082-5410-7
Publié en 2023
Première rédaction de cet article le 19 février 2024


Comme les lecteurices de ce blog le savent sûrement, je pense que la place prise par le numérique dans nos vies justifie qu'on réfléchisse sérieusement à cette transition que nous vivons. Donc, ce livre est une bonne idée. Mais, comme beaucoup d'ouvrages collectifs, il souffre d'un manque évident de coordination entre les auteurices, dont les différentes contributions sont de niveaux très inégaux.

On y croise ainsi des baratineurs classiques comme Luc Ferry, personnage qu'on aurait pu penser définitivement démonétisé. Sans surprise, il parle d'un sujet cliché, le transhumanisme (le mannequin de paille classique de beaucoup d'« intellectuels » français). Sans aller aussi loin dans la vacuité, on trouve aussi dans ce livre des articles par des auteurs dont on peut se demander s'ils maitrisent leur sujet. Ainsi une auteure présentée comme spécialiste des questions bancaires déplore que l'IA a des biais quand elle décide d'accorder un prêt ou pas (un exemple, typique de la sur-utilisation de la notion de biais ; évidemment qu'un outil d'aide à la décision en matière de prêts va être mal disposé envers les gens ayant des revenus faibles et irréguliers). Le texte de présentation de chaque contribution a aussi sa part de responsabilité, comme celui de l'article sur la chaine de blocs qui dit que les données sont cryptées (et, non, le problème n'est pas l'utilisation de cet terme, « chiffrées » n'aurait pas été mieux). Enfin lisant un livre qui se veut de réflexion sur le numérique, je vois la phrase « les technologies digitales sont des technologies qui sont faciles à prendre en main », et je me demande si l'auteur l'a fait exprès.

Bon, assez critiqué, il y a aussi des analyses intéressantes (j'ai dit intéressantes, pas forcément que j'étais 100 % d'accord) : Pauline Türk réfléchit sur l'utilisation du numérique pour améliorer le processus démocratique, Ophélie Coelho traite de géopolitique et détaille les risques liés à la dépendance vis-à-vis d'entreprises ou d'États, Lionel Maurel plaide pour l'ouverture des résultats des recherches scientifiques, mais aussi (avec nuances) pour l'ouverture des données de recherche, Philippe Bihouix explique concrètement comment réduire l'empreinte environnementale, Jessica Eynard questionne l'identité numérique (même si je la trouve bien trop optimiste sur le projet d'identité numérique étatique au niveau de l'UE), Amine Smihi décrit la vidéosurveillance vue de son rôle d'élu local, etc.

Bref, un tour d'horizon de beaucoup de questions que pose la place du numérique dans notre société.


L'article seul

Panne du domaine national russe

Première rédaction de cet article le 30 janvier 2024
Dernière mise à jour le 8 février 2024


Aujourd'hui, une panne a affecté le domaine de premier niveau russe, .ru. Que sait-on ? (Quand cet article a été initialement publié, on ne savait pas exactement ce qui s'était passé. Voir à la fin pour des explications vraisemblables.)

La panne a duré à peu près de 15:20 UTC à 19:00 UTC (avec une réparation partielle à 17:50 UTC). Pour l'instant, il semble certain que le problème était lié à DNSSEC et qu'il s'agissait probablement d'une panne, pas d'une action volontaire de la Russie ou de ses ennemis (hypothèse parfois citée, vu le contexte de guerre). Un petit rappel : DNSSEC est une technique de sécurité visant à garantir l'intégrité des noms de domaine. DNSSEC, comme toutes les techniques de sécurité, peut, en cas de fausse manœuvre, aboutir à un déni de service ; si vous perdez les clés de votre maison, vous ne pourrez plus rentrer chez vous. Ici, les signatures des domaines de .ru étaient invalides, menant les résolveurs DNS à les rejeter et donc à ne pas réussir à résoudre les noms de domaine sous .ru. Deux points sont notamment à noter :

  • Du fait du caractère arborescent du DNS, une panne de .ru affecte tous les noms situés sous .ru. La gestion d'un TLD est quelque chose de critique ! Il est donc faux de dire que tel ou tel site Web russe était en panne ; en fait, son nom de domaine ne fonctionnait plus.
  • Comme tous les résolveurs DNS ne valident pas les signatures DNSSEC, la résolution marchait encore pour certains.

Compte-tenu des observations faites sur le moment, il semble bien que le communiqué du ministère russe était correct (à un point près, détaillé plus loin). Le problème était bien dans le registre du .ru et était sans doute le résultat d'une erreur de leur côté. La traduction du communiqué par DeepL : « Ministère russe de la numérisation \ L'accès aux sites de la zone .RU sera bientôt rétabli \ La zone .RU a été affectée par un problème technique lié à l'infrastructure DNSSEC* mondiale. Des spécialistes du Centre technique de l'internet et de MSC-IX travaillent à son élimination. \ Actuellement, le problème a été résolu pour les abonnés du système national de noms de domaine. Les travaux de restauration sont en cours. Nous vous tiendrons au courant de l'évolution de la situation. \ *DNSSEC est un ensemble d'extensions du protocole DNS, grâce auxquelles l'intégrité et la fiabilité des données sont garanties. » Et le communiqué original sur Telegram : telegram-min-russe-dnssec.png

Notons que les TLD .su et .рф ne semblent pas avoir été affectés, alors qu'ils sont gérés par le même registre.

Un peu plus de technique, maintenant. Avec dig, voyons la résolution DNS, via un résolveur validant :


% date -u ; dig ru. NS
Tue 30 Jan 17:12:05 UTC 2024

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> ru. NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32950
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 6 (DNSSEC Bogus): (NXJA)
;; QUESTION SECTION:
;ru.			IN NS

;; Query time: 2384 msec
;; SERVER: 192.168.2.254#53(192.168.2.254) (UDP)
;; WHEN: Tue Jan 30 18:12:07 CET 2024
;; MSG SIZE  rcvd: 41

  

Le SERVFAIL indique un échec. Notez l'EDE (Extended DNS Error, RFC 8914), qui indique que l'échec est lié à DNSSEC.

Ensuite, vérifions que tout marchait, à part DNSSEC. En coupant la validation DNSSEC (option +cd, Checking Disabled), on avait bien une réponse :


% date -u ; dig +cd ru. NS
Tue 30 Jan 17:15:06 UTC 2024

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> +cd ru. NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5673
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;ru.			IN NS

;; ANSWER SECTION:
ru.			344162 IN NS b.dns.ripn.net.
ru.			344162 IN NS d.dns.ripn.net.
ru.			344162 IN NS e.dns.ripn.net.
ru.			344162 IN NS f.dns.ripn.net.
ru.			344162 IN NS a.dns.ripn.net.
ru.			344162 IN RRSIG	NS 8 1 345600 (
				20240305102631 20240130141847 52263 ru.
				kw9oqgvi/l0MZp/6FY0Ha+VZDWRR3+iDUCYqAY5W7D2w
				CfIXXdOOvdd58nNY7z/3b4fRK6tlTF3wQpCDSpeKrmkW
				mric4kcUptaj1rp71lC0GHXHmGwDsx8Zi/lvo6sJEk0g
				uBbJYBJkzKqeseD4u1Pw29jkRHhQEJKk2seP+Zk= )

;; Query time: 8 msec
;; SERVER: 192.168.2.254#53(192.168.2.254) (UDP)
;; WHEN: Tue Jan 30 18:15:06 CET 2024
;; MSG SIZE  rcvd: 285

Les serveurs de nom faisant autorité répondaient bien :


% dig @b.dns.ripn.net. ru NS

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> @b.dns.ripn.net. ru NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37230
;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 11
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ru.			IN NS

;; ANSWER SECTION:
RU.			345600 IN NS a.dns.ripn.net.
RU.			345600 IN NS e.dns.ripn.net.
RU.			345600 IN NS b.dns.ripn.net.
RU.			345600 IN NS f.dns.ripn.net.
RU.			345600 IN NS d.dns.ripn.net.
ru.			345600 IN RRSIG	NS 8 1 345600 (
				20240305102631 20240130141847 52263 ru.
				kw9oqgvi/l0MZp/6FY0Ha+VZDWRR3+iDUCYqAY5W7D2w
				CfIXXdOOvdd58nNY7z/3b4fRK6tlTF3wQpCDSpeKrmkW
				mric4kcUptaj1rp71lC0GHXHmGwDsx8Zi/lvo6sJEk0g
				uBbJYBJkzKqeseD4u1Pw29jkRHhQEJKk2seP+Zk= )

;; ADDITIONAL SECTION:
a.dns.RIPN.net.		1800 IN	AAAA 2001:678:17:0:193:232:128:6
b.dns.RIPN.net.		1800 IN	AAAA 2001:678:16:0:194:85:252:62
d.dns.RIPN.net.		1800 IN	AAAA 2001:678:18:0:194:190:124:17
e.dns.RIPN.net.		1800 IN	AAAA 2001:678:15:0:193:232:142:17
f.dns.RIPN.net.		1800 IN	AAAA 2001:678:14:0:193:232:156:17
a.dns.RIPN.net.		1800 IN	A 193.232.128.6
b.dns.RIPN.net.		1800 IN	A 194.85.252.62
d.dns.RIPN.net.		1800 IN	A 194.190.124.17
e.dns.RIPN.net.		1800 IN	A 193.232.142.17
f.dns.RIPN.net.		1800 IN	A 193.232.156.17

;; Query time: 268 msec
;; SERVER: 2001:678:16:0:194:85:252:62#53(b.dns.ripn.net.) (UDP)
;; WHEN: Tue Jan 30 17:56:45 CET 2024
;; MSG SIZE  rcvd: 526

Et DNSviz confirme le diagnostic : dnsviz-russia.png

Comme le note DNSviz, les signatures étaient invalides : dnsviz-russia-sig.png

Il ne s'agissait pas de problèmes locaux. En demandant aux sondes RIPE Atlas, on voit beaucoup d'échecs de résolution (SERVFAIL, SERVer FAILure) :

% blaeu-resolve -r 200 --type NS ru
[ERROR: SERVFAIL] : 79 occurrences 
[a.dns.ripn.net. b.dns.ripn.net. d.dns.ripn.net. e.dns.ripn.net. f.dns.ripn.net.] : 66 occurrences 
[ERROR: NXDOMAIN] : 13 occurrences 
Test #66905129 done at 2024-01-30T16:59:57Z

(Notez les NXDOMAIN - No Such Domain, qui sont des mensonges de résolveurs qui censurent la Russie, en raison de son agression de l'Ukraine.)

Une fois que tout était réparé, la validation se passait bien :

% blaeu-resolve -r 200 --type DNSKEY --displayvalidation --ednssize 1450 ru
…
[ERROR: NXDOMAIN] : 19 occurrences 
[ (Authentic Data flag)  256 3 8 awea…] : 93 occurrences 
[256 3 8 aweaa…] : 64 occurrences 
[ERROR: SERVFAIL] : 9 occurrences 
[] : 1 occurrences 
[ (TRUNCATED - EDNS buffer size was 1450 ) ] : 1 occurrences 
Test #66910201 done at 2024-01-30T18:20:56Z

Notez que la phrase du ministre « le problème a été résolu pour les abonnés du système national de noms de domaine » était fausse. Le problème a été résolu pour tout le monde (ce « système national de noms de domaine » est l'objet de beaucoup de propagande et de fantasme et il n'est pas du tout sûr qu'il ait une existence réelle). La situation actuelle :


% dig ru DNSKEY   

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> ru DNSKEY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6401
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;ru.			IN DNSKEY

;; ANSWER SECTION:
ru.			39023 IN DNSKEY	256 3 8 (
				AwEAAcBtr/w2hP6OQjiCacPFzK6xh0pR7QsHV9lxprIX
				G9WBoBB5XWPVc5q17F3yt3wpJ7xmedt80gxVMaicPYNY
				Aa8YUFyMxTGVBDVQlz5gCmXQKlr0yImI78sdwzWNmgKH
				ap0BLypTBVxAKxpcvuwTmqXQUSONkjq9werHvogrvkUb
				) ; ZSK; alg = RSASHA256 ; key id = 44301
ru.			39023 IN DNSKEY	257 3 8 (
				AwEAAfcMZekGvFYkmt18Q8KIS+XX/7UBbpmIJ4hK3FNz
				ErkJmiNPxq+sbM00NYJwY725QxoDwHPeK0JIybKW6s+U
				2+I7aBGJus/bvDklw0CMTDsG7HoJG+4sjq/jRPUQNwkO
				A/cNoiYjroqw7/GnB8DEAGE03gyxdZcxxU3BJKPZfds8
				DJYPBaDUO35g9I6+dLPXxHK6LFUFprkBtpqj13tJ/ptL
				yMSaivvi3xrvJMqu/FWN6piMzu7uYmrSdv6s01y+0x62
				29sZ7ufSQ6E66gdTmXebDx8S8q70B4BmMZosrsHlf3uX
				VMMY72LnrQzbere2ecd95q+1VDMDXcXB/pT1/C0=
				) ; KSK; alg = RSASHA256 ; key id = 43786
ru.			39023 IN DNSKEY	256 3 8 (
				AwEAAbjj3GP0TUwaNI7BIIw/fvwKTmdR+oZsEPk64pl8
				VYn4dfdbGHWpYIooxcgEbuBEYrnC/oqnKhad38nTxrZ9
				SAK3qV5qShntFdgozS5IKs5m1ebNmg2sotlhXRhJ4vqg
				H+BQh/lw6T4vdB8FE5tHGE1vwPs9Vhj0vLTBhX8TwB6/
				) ; ZSK; alg = RSASHA256 ; key id = 52263
ru.			39023 IN RRSIG DNSKEY 8 1 345600 (
				20240213000000 20240124000000 43786 ru.
				rgqGAFvlWoGzSGrKaaMUqpNkOGyKQS+MOwvrwy3+A4nh
				FiioZ610H9GlN/fh3kUjiFrRJ7T1sKiW9AVekkpdZk/Q
				T5vRGqWi+PLyuRtfL7ZtJKVgUPV+jGVOc0A9AZA0dVgx
				qX54L+mbMY6OGCcMeTHwUpg6J2UR0MmB3TCyHPhg0Z/L
				VHWf/E9hHO4dqdePwKvlVeA7txcXemiJE6C1/mgFvtQl
				uQsot9eDOqKZt9oUpqzi63gsw835+h6fiKNbMJf4SEPw
				5enbdQqcubSWwwY/SbeoW74qgPgPgJrmiP8UxT6DEAZc
				W5UO9CsMcyfgifsL0zy5SMba4kS0izp4rQ== )

;; Query time: 4 msec
;; SERVER: 192.168.2.254#53(192.168.2.254) (UDP)
;; WHEN: Tue Jan 30 21:04:05 CET 2024
;; MSG SIZE  rcvd: 893

Plusieurs personnes ont noté une lenteur, ou même parfois une absence de réponse, de la part de certains des serveurs faisant autorité pour .ru. Il s'agit probablement d'un effet dû aux efforts des résolveurs DNS qui, recevant des signatures invalides, réessayaient (éventuellement vers d'autres serveurs faisant autorité) dans l'espoir de récupérer enfin des signatures correctes. En tout cas, rien n'indique qu'il y ait eu une attaque externe contre .ru.

Mais peut-on savoir ce qui s'est passé ? Pas exactement, mais on peut toujours poursuivre l'analyse. DNSviz nous donne également accès aux numéros de série, stockés dans l'enregistrement SOA de la zone .ru. On peut donc reconstituer une chronologie (elle a été faite par Phil Kulin et vérifiée par moi) :

  • 2024-01-30 12:29:44 UTC : dernier test où tout était correct. Le numéro de série était 4058855, la clé signant les enregistrements (ZSK, Zone Signing Key) était la 44301, la ZSK 52263 était déjà publiée (remplacement de ZSK en cours).
  • 2024-01-30 15:27:27 UTC : premier test avec la panne, qui a donc dû commencer quelques minutes plus tôt (en cas de problème DNSSEC, il y a toujours quelqu'un qui se précipite pour faire un test DNSviz). Le numéro de série est le 4058857. La clé signante est désormais la 52263, et les signatures sont invalides.
  • Il y aura une zone de numéro 4058858, mais le problème continue.
  • 2024-01-30 17:59:46 UTC : la réparation commence. L'ancienne zone de numéro 4058856 est republiée, signée par l'ancienne clé 44301. Notez que, pendant plus d'une heure, plusieurs versions de la zone coexisteront (avec trois numéros de série différents, 4058856, 4058857 et 4058858).
  • 2024-01-30 19:07:29 UTC : réparation terminée, on est revenu à la situation d'avant la panne.
  • À un moment dans la journée du 31 janvier : la zone bouge à nouveau (le numéro de série augmente, la zone est signée par la clé 52263).

Enfin, on notera que le numéro de série ne bougeait plus (il changeait toutes les deux heures environ auparavant), ce qui fait penser que le problème n'était pas tant dans la clé 52263 que dans un système de signature désormais cassé.


% dig ru SOA

; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> ru SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44285
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ru.			IN SOA

;; ANSWER SECTION:
ru.			86400 IN SOA a.dns.ripn.net. hostmaster.ripn.net. (
				4058856    ; serial
				86400      ; refresh (1 day)
				14400      ; retry (4 hours)
				2592000    ; expire (4 weeks 2 days)
				3600       ; minimum (1 hour)
				)
ru.			86400 IN RRSIG SOA 8 1 345600 (
				20240313163045 20240130121923 44301 ru.
				dAGkfXQSmGCwwUuzxIfNeIgd+/BbAYt0whh3JcqvKi6x
				z6N8a7KGBHkfBCbg19xzx6b+LQBJgK4yVtvTQLqLNo8P
				fxg5J8S/JUw2EHgPUMJw0CjsrqH85biJqkv+5TVoN9dG
				PFnFIjaTPLP0DRscR3ps5NP8lJstDwBYQmg/i68= )

;; AUTHORITY SECTION:
ru.			86400 IN NS e.dns.ripn.net.
ru.			86400 IN NS d.dns.ripn.net.
ru.			86400 IN NS a.dns.ripn.net.
ru.			86400 IN NS f.dns.ripn.net.
ru.			86400 IN NS b.dns.ripn.net.
ru.			86400 IN RRSIG NS 8 1 345600 (
				20240304113906 20240126101933 44301 ru.
				KthCG9ahQ3UyFl1aakpJRiXI0GXH6TNB6i+uY+920a93
				DQgCgkokpsYAHCCzqJl0VXiAmcaEK1yLFHxfJzDbjsel
				0xz8IJi3CIuzEtBfBbedXUfBzE/64HmJ9xHVgc5fdLDA
				6AfIAmw0oeHCgssUTdZ67IlZO90nzeEHu6PHj2k= )

;; Query time: 32 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Jan 31 10:45:15 CET 2024
;; MSG SIZE  rcvd: 580

  

Il n'a repris sa progression que dans la journée du 31 janvier, et la clé 52263 était à nouveau utilisée :

    
% dig ru SOA

; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> ru SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37102
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ru.			IN SOA

;; ANSWER SECTION:
ru.			86397 IN SOA a.dns.ripn.net. hostmaster.ripn.net. (
				4058871    ; serial
				86400      ; refresh (1 day)
				14400      ; retry (4 hours)
				2592000    ; expire (4 weeks 2 days)
				3600       ; minimum (1 hour)
				)
ru.			86397 IN RRSIG SOA 8 1 345600 (
				20240306211526 20240201082001 52263 ru.
				trZgMG6foXNX+ZotfA11sPGSCJwVpdSzobvrPbMfagIj
				pToI2+W9fa3HIW5L3GSliQHbWDnaTp0+dhMs/v3UFnFs
				UtCoTy00F/d1FysBtQP2uPZLwPTI3rXJSE2U5/Xxout/
				2hSCsIxQE5CxksPzb9bazp63Py0AfbWY56b1/FE= )

;; AUTHORITY SECTION:
ru.			86397 IN NS e.dns.ripn.net.
ru.			86397 IN NS f.dns.ripn.net.
ru.			86397 IN NS a.dns.ripn.net.
ru.			86397 IN NS b.dns.ripn.net.
ru.			86397 IN NS d.dns.ripn.net.
ru.			86397 IN RRSIG NS 8 1 345600 (
				20240303133621 20240131134337 52263 ru.
				MD8EOMQtjhr08qt3I890qHE+E0HBvhdbtUkasjez+1zd
				8zsxH0GCPz5zD0db/HQr9o0hDUMd3xZLHaDvlS/PjLti
				6dEVOT7SYHHC2yF7Ypu97alFpEHpGEcchEhMx3rSUBZF
				Jik3JVG9yqOxF4m0r+QgVotU4PMIejFGjPdvZ0w= )

;; Query time: 16 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Feb 01 11:27:06 CET 2024
;; MSG SIZE  rcvd: 580

  

Merci à John Shaft, et Paul Ó Duḃṫaiġ pour les analyses expertes et les discussions. J'ai fait à la réunion FOSDEM du 3 février 2024 un exposé rapide sur la question (supports et vidéo sont en ligne).

Vous pouvez lire le premier communiqué officiel du registre (dont les affirmations sont conformes aux observations). Contrairement à ce qui a été affirmé sans preuves, il n'y a aucune indication que cette panne soit liée aux projets russes de renforcement du contrôle étatique sur la partie russe de l'Internet.

L'explication technique officielle et détaillée a finalement été donnée le 7 février dans un message aux BE. Il s'agirait donc bien d'une bogue logicielle dans le système de signature, qui se déclenchait lorsque deux clés avaient le même key tag (ce qui est possible, vu la taille de ce key tag, mais n'aurait pas dû provoquer de faille.) Cette explication officielle colle très bien aux observations qui ont été faites au moment de la panne. Notez aussi que cette explication confirme bien que .рф et .su n'ont pas été affectés (conformément à ce qui a été observé, et au contraire de ce qu'ont affirmé plusieurs articles écrits sans vérifier) alors que deux TLD peu connus, .дети et .tatar l'ont été.


L'article seul

Jouons et sécurisons avec une clé FIDO2/WebAuthn

Première rédaction de cet article le 29 janvier 2024


Je viens de me lancer dans l'utilisation d'une clé de sécurité (une Nitrokey) pour les protocoles d'authentification FIDO2 et WebAuthn. Regardons cela.

Un peu de contexte d'abord. Lorsqu'on veut s'authentifier auprès d'un service en ligne (un serveur SSH, un site Web, etc), la solution la plus ancienne est le couple identificateur (login) / mot de passe. Ce système pose plusieurs problèmes :

  • La difficulté d'avoir des mots de passe à la fois solides (résistant aux attaques par force brute) et mémorisables par l'utilisateurice.
  • Le risque de hameçonnage, lorsque l'utilisateurice se laisse convaincre d'aller sur un service qui n'est pas le vrai, à qui ielle donnera le mot de passe, que le hameçonneur pourra ensuite utiliser.
  • Plus généralement, la trop grande facilité avec laquelle un mot de passe se partage, par exemple suite à de l'ingénierie sociale.

Tous ces problèmes ont des solutions. Par exemple, le premier se résout très bien par l'utilisation d'un gestionnaire de mots de passe, solution très recommandée. Mais, évidemment, aucune des solutions n'est parfaite.

On cherche donc à renforcer la sécurité, en ajoutant un deuxième facteur d'authentification, par exemple un code à usage restreint, généré sur une machine distincte, qui peut être un ordinateur (rappel : un ordiphone est un ordinateur) ou un périphérique matériel spécialisé, souvent nommé « clé ». Des protocoles normalisés existent comme HOTP (RFC 4226, le code est alors à usage unique) ou TOTP (RFC 6238, le code étant alors à usage limité dans le temps). Il existe aussi des solutions non normalisées, spécifiques à un seul vendeur, qu'il faut bien sûr fuir. Aujourd'hui, lorsqu'on veut accéder à un service sensible (l'interface de gestion de ses noms de domaine, par exemple), cette authentification à deux facteurs doit être considérée comme impérative.

Je vais essayer ici une technique qui permet, soit de remplacer le couple identificateur / mot de passe par une authentification à un seul facteur, mais plus sûre, soit d'utiliser comme deuxième facteur une méthode plus sûre que HOTP ou TOTP. Il s'agit de FIDO2/WebAuthn. C'est en fait un ensemble de plusieurs protocoles. Pour les expliquer, un peu de terminologie (tout en se rappelant qu'en français, il n'y a souvent pas de terminologie standard et répandue pour une bonne partie du vocabulaire de l'informatique). Il y a quatre entités, humaines et non-humaines, qui interviennent

  • L'utilisateurice, M. ou Mme Toutlemonde.
  • Le service auquel ielle veut se connecter (par exemple un site Web).
  • Le logiciel client de l'utilisateurice (par exemple un navigateur Web).
  • L'authentificateur, qui est un dispositif à la disposition de l'utilisateurice (par exemple une clé physique comme ma Nitrokey).

Le protocole entre l'authentificateur (relayé par le logiciel client) et le service utilise la classique cryptographie asymétrique. Le service génère des données à usage unique qu'il chiffre avec la clé publique de l'authentificateur, celui-ci les déchiffrera et les enverra, prouvant ainsi qu'il connait la clé privée. Le service n'apprend donc jamais aucun secret (contrairement à ce qui se passe avec le mot de passe), ce qui protège contre le hameçonnage. Les clés privées ne quittent pas l'authentificateur, le logiciel client ne les voit jamais. FIDO2 désigne la communication avec l'authentificateur, WebAuthn l'API JavaScript exposée aux services.

Voyons en pratique ce que cela donne, avec le service de test https://webauthn.io/. Je visite le site Web avec Firefox, j'indique mon identificateur puis je clique sur Authenticate : webauthn-io-firefox.png

Je sors ensuite ma clé, une Nitrokey 3A NFC : nitrokey-3a-nfc.jpg

Je la mets dans le port USB de la machine et j'appuie sur le bouton de la clé (une lumière sur la clé clignote pour vous le rappeler) et je suis authentifié. Ici, on n'a qu'un seul facteur (la possession de la clé). Avec la version de Firefox sur mon système, on ne peut pas ajouter de code PIN à la clé (mais ça marche avec Chrome, sur la même machine ; dans le monde FIDO2 / WebAuthn, vous rencontrerez souvent ce genre de problèmes d'interopérabilité ; sur Android, Fennec n'a tout simplement pas WebAuthn). Notez aussi que, la première fois, il faudra s'enregistrer auprès du service pour être reconnu par la suite.

La Nitrokey 3A NFC que je possède peut aussi, comme son nom l'indique, être « connectée » en NFC (testé avec succès sur mon Fairphone, bien qu'il faille un peu chercher où la placer sur l'ordiphone, et avec un Samsung, même problème). android-webauthn.png

Une fois que vous avez testé votre clé sur ce service et que tout marche, vous pouvez commencer à activer son utilisation sur divers services réels (mais lisez cet article jusqu'au bout : il y a des pièges). Ici, par exemple, sur Proton Mail : proton-2fa-fido.png

Sans la configuration d'un code PIN sur la clé, le vol de la clé permet au voleur de se faire passer pour vous. Il ne faut donc l'utiliser qu'en combinaison avec un autre facteur. Certaines clés, plus coûteuses, peuvent reconnaitre leur utilisateurice par biométrie mais ne vous fiez pas aux promesses des commerciaux : la biométrie est très loin d'être la solution miracle. Non seulement un attaquant peut reproduire des caractéristiques biométriques (vous laissez vos empreintes digitales un peu partout) mais inversement, vos propres doigts ne sont pas forcément reconnus (les empreintes s'usent avec l'âge et vous aurez de plus en plus de problèmes).

Quand à la perte de la clé, elle doit être anticipée. Sans la clé, vous ne pourrez plus vous connecter. Comme le dit la FAQ, il faut avoir un plan B. Par exemple, lorsqu'on active la sécurité FIDO2/WebAuthn sur Cloudflare, le service fournit une longue série de chiffres secrets qui permettront de récupérer son compte, et suggère très fortement de les stocker dans un endroit sécurisé (à la fois contre le vol et contre la perte). Il n'y a pas de mécanisme de sauvegarde de la clé (c'est délicat à concevoir pour un dispositif dont le but est d'empêcher les clés privées de sortir). La solution la plus simple semble être d'avoir deux clés et d'enregistrer les deux auprès des services qui le permettent.

Pour gérer ma clé, j'utilise l'utilitaire en ligne de commande nitropy. La documentation en ligne n'est pas terrible (sauf pour la partie sur l'installation sur une machine Linux, où il faut configurer udev). Mais le logiciel a une aide avec --help. Voici quelques exemples d'utilisation :

% nitropy list
Command line tool to interact with Nitrokey devices 0.4.45
:: 'Nitrokey FIDO2' keys
:: 'Nitrokey Start' keys:
:: 'Nitrokey 3' keys
/dev/hidraw3: Nitrokey 3 522A…

% nitropy nk3 status
Command line tool to interact with Nitrokey devices 0.4.45
UUID:               522A…
Firmware version:   v1.5.0
Init status:        ok
Free blocks (int):  60
Free blocks (ext):  478
Variant:            LPC55
  

Pour finir, des liens utiles :


L'article seul

Gestion de son serveur de courrier électronique

Première rédaction de cet article le 8 janvier 2024


Je gère depuis longtemps mon propre serveur de courrier électronique. Cet article va présenter quelques observations issues de cette expérience. Si vous êtes pressé·e, voici un résumé : 1) ça marche et je peux envoyer du courrier y compris aux grosses plateformes 2) c'est compliqué et ça fait du travail.

Je commence par des explications générales, si vous vous intéressez aux détails techniques, ils sont à la fin. Si vous n'êtes pas familier·ère avec le monde du courrier électronique, quelques notions. Un élément essentiel du cahier des charges du courrier est la possibilité d'envoyer des messages non sollicités, à quelqu'un avec qui on n'a jamais échangé. Les cas d'usage de cette fonction sont nombreux (candidature spontanée à une entreprise, demande d'un devis à une entreprise, remarques sur un article de blog, etc.). Cet élément est une des raisons du succès du courrier électronique, qui reste aujourd'hui le principal moyen de contact universel. Mais il y a un côté négatif, le spam, puisque les spammeurs, eux aussi, utilisent cette possibilité pour nous envoyer leurs messages sans intérêt. La lutte contre le spam est un sujet complexe mais le point qui nous intéresse ici est que, comme pour toute question de sécurité, il y a forcément des faux négatifs (des coupables qui s'en tirent) et des faux positifs (des innocents frappés à tort). Ceux qui vous diraient le contraire et prétendraient qu'on peut avoir des solutions sans faux positifs ni faux négatifs sont des menteurs ou des commerciaux.

Des organisations qui gèrent des grandes plateformes de courrier, comme Google avec gmail.com ou Microsoft avec outlook.com et hotmail.com, déploient diverses techniques pour lutter contre le spam. Un effet de bord de ces techniques, dit-on souvent, est de bloquer les petits hébergeurs ou les auto-hébergeurs, les petites structures ou les particuliers qui, comme moi, gèrent leur propre serveur. Une accusation courante est qu'il ne s'agit pas de difficultés techniques, mais d'une politique délibérée, que ces grandes entreprises essaient volontairement de tuer cet auto-hébergement. Il n'y a pourtant aucune raison technique, ni dans les normes techniques du courrier électronique (RFC 5321 et RFC 5322), ni dans des règles légales, qui impose que le courrier ne passe que par un oligopole de grandes entreprises ; une personne ou une petite organisation peut parfaitement gérer son propre serveur. Sans le spam, ce serait même plutôt simple techniquement. Mais, avec le spam et ses conséquences, les choses se compliquent.

(Point philosophico-politique au passage : la délinquance ou l'incivilité a des conséquences directes, si on vous vole votre vélo, vous n'avez plus de vélo mais aussi, et c'est trop souvent oublié, des conséquences indirectes et qui sont souvent plus coûteuses : déploiement de mesures de sécurité chères et gênantes, perte de confiance qui délite la société, etc.)

Voyons maintenant la légitimité des plateformes de courrier électronique à prendre des mesures anti-spam qui m'empêcheront parfois de joindre mon correspondant. Le gestionnaire d'un service de messagerie est maître chez lui. Il ou elle peut déployer les techniques qu'il veut, même si cela bloque certains émetteurs, de même que vous n'êtes pas obligés de prendre le tract qu'on vous tend dans une manifestation. Google n'est pas obligé d'accepter vos messages, rien ne l'y force. Toutefois, la situation n'est pas la même que celle de la personne qui ne veut pas prendre un tract. Ici, il y a un intermédiaire, qui va décider pour ses utilisateurs. Ceux-ci et celles-ci ne sont jamais informé·es de la politique de lutte anti-spam de leur hébergeur. Mieux, la propagande des grandes plateformes affirme en général que, si le message n'arrive pas, c'est de la faute de l'émetteur. Beaucoup d'utilisateurs ou d'utilisatrices croient sur parole ce discours.

J'ai ainsi été étonné de voir que des gens, ne recevant pas mes messages, ne voulaient pas se plaindre auprès de leurs fournisseurs, me demandant de le faire. Pourtant, n'étant pas client de outlook.com, j'avais certainement beaucoup moins de poids sur Microsoft que des utilisateurs de leur service.

(Si vous utilisez le fédivers comme réseau social, vous aurez noté que c'est pareil, et pour cause, le courrier électronique était un réseau social décentralisé bien avant le fédivers. C'est pareil car le gestionnaire d'une instance peut refuser qui il veut. En soi, ce n'est pas un problème, mais cela se complique quand le petit chef qui dirige une instance le fait pour le compte de ses utilisateurices.)

Donc, le petit hébergeur de courrier part avec un sérieux désavantage : Google ou Microsoft se fichent pas mal de lui, et leurs utilisateurs et utilisatrices font une confiance aveugle à ces GAFA, davantage qu'à leurs propres correspondant·es. Google, Microsoft, Orange, laposte.net, etc, se satisferaient certainement d'un oligopole où tout se passerait entre eux. Heureusement, le monde du courrier électronique n'en est pas là. On va voir qu'il n'est pas exact de dire que les gros hébergeurs bloquent déliberement les petits. D'une part, ils ne sont pas les seuls à poser problème, d'autre part, ils ne sont pas acharnés à bloquer les petits, c'est plutôt qu'ils s'en foutent.

(Au passage, les politiques anti-spam des grosses plateformes de courrier peuvent rejeter le message directement, ce qui donne à l'expéditeur un message d'erreur, ou bien escamoter le message sans avertissement, ou encore le mettre dans la boite Spam du destinataire. Je vais traiter tous ces cas ensemble.)

Parmi les problèmes que j'ai rencontrés, le fait d'être listé de temps en temps dans une liste de blocage de Spamhaus. Mon serveur n'a jamais envoyé de spam, il n'héberge même pas de liste de diffusion (héberger une liste est bien plus difficile, puisque, par construction, elles envoient en masse, ce que certains récepteurs considèrent comme du spam). La communication avec Spamhaus n'a jamais donné de résultat, notamment lorsque je leur ai demandé les spams que j'avais soi-disant envoyés, pour que je puisse les étudier et comprendre un éventuel problème (jamais de réponse). Le rejet du courrier via l'utilisation de cette liste est loin d'être spécifique aux gros méchants GAFA. Pas mal de libristes utilisent la liste de Spamhaus et se montrent assez agressifs quand on leur suggère que c'est peut-être une mauvaise idée (Spamhaus a beaucoup de fanboys).

Autre problème, avec Microsoft, qui gère des services comme outlook.com et hotmail.com. Tous les services Microsoft rejetaient mon courrier par intermittence :


<DESTINATAIRE@outlook.com>: host
    outlook-com.olc.protection.outlook.com[52.101.73.31] said: 550 5.7.1
    Unfortunately, messages from [92.243.4.211] weren't sent. Please contact
    your Internet service provider since part of their network is on our block
    list (S3150). You can also refer your provider to
    http://mail.live.com/mail/troubleshooting.aspx#errors.
    [AMS0EPF000001AE.eurprd05.prod.outlook.com 2023-10-07T10:03:08.034Z
    08DBBB93AD81129F] (in reply to MAIL FROM command)

Résoudre le problème est très chronophage. Il faut essayer un des innombrables moyens de contact avec Microsoft comme https://sender.office.com/, https://sendersupport.olc.protection.outlook.com/snds/ (le programme SNDS - Smart Network Data Services - ne fait qu'afficher, il ne modifie pas les listes de blocage) ou https://olcsupport.office.com/ (le troisième a marché, pour moi, j'ai pu parler à un humain), ce qui nécessite parfois un compte Microsoft (et une adresse Gmail pour pouvoir leur écrire…). (Rappelez-vous que les clients de Microsoft n'osent jamais rien demander à Microsoft. Ce sont des gens comme moi, qui ne sont pas clients de cette entreprise, qui doivent la contacter, ce qui est évidemment moins efficace.) Bref, après des mois de discussions kafkaïennes (Microsoft prétendant même que mon adresse IP n'était pas bloquée alors que leur propre message d'erreur, cité plus haut, dit explicitement le contraire), Microsoft a fini par corriger le problème (« Thank you for contacting the Outlook.com Deliverability Support Team. We have implemented mitigation for your IP (92.243.4.211) and this process may take 24 - 48 hours to replicate completely throughout our system. »). Je peux désormais envoyer du courrier à outlook.com et hotmail.com (pour l'instant, en tout cas). Mais on se doute bien que toustes les administrateurices de serveurs de messagerie n'ont pas envie de dépenser autant de temps et d'effort avec cette entreprise.

Concrètement, ma plateforme actuelle est composée d'un serveur de messagerie, qui est un VPS sous Debian. (Vous pouvez trouver son nom, tout est forcément public, pour que ça fonctionne, ce qui peut avoir des conséquences en terme de vie privée.) Ce serveur est situé chez Gandi. J'aurais pu l'héberger à la maison (mon FAI bloque le port 25 - celui de SMTP - par défaut mais permet de l'ouvrir gratuitement simplement en un clic sur l'interface client) mais je n'avais pas envie de gérer l'alimentation électrique permanente, certains opérateurs qui refusent le courrier provenant d'adresses IP « résidentielles », etc. Sur cette machine tournent Postfix et les autres logiciels utiles (comme OpenDKIM).

Bien sûr, j'utilise SPF (mon enregistrement), DKIM (la clé actuelle) et même DMARC (avec une politique laxiste car DMARC casse les listes de diffusion, ce que je trouve inacceptable). Et j'ai un enregistrement inverse (de l'adresse IP vers le nom) dans le DNS. J'ai testé toutes ces configurations avec divers auto-répondeurs. Et, pour me protéger moi-même contre le spam, je valide les assertions SPF, DKIM et DMARC, ce qui ajoute au courrier des informations (RFC 8601) comme :

Authentication-Results: mail.bortzmeyer.org;
        dkim=pass (2048-bit key; unprotected) header.d=mailchimpapp.net
        header.i=rayna=rs-strategy.consulting@mailchimpapp.net header.a=rsa-sha256 header.s=k2 header.b=Gr+4sGal;
        dkim-atps=neutral
Authentication-Results: mail.bortzmeyer.org; spf=pass (sender SPF authorized) smtp.mailfrom=mail198.atl221.rsgsv.net
        (client-ip=198.2.139.198; helo=mail198.atl221.rsgsv.net;
        envelope-from=bounce-mc.us5_165546418.9420482-fccde11058@mail198.atl221.rsgsv.net)
  

Comme SPF et DKIM ne font que de l'authentification (et qu'un spammeur peut lui aussi s'authentifier), j'ajoute du greylisting (RFC 6647), avec Greyfix, SpamAssassin (comme tout le monde…) et surtout bogofilter, qui est particulièrement efficace, les faux positifs sont en nombre infime.

Quelques lectures :

En conclusion, si vous m'avez écrit et que vous n'avez pas eu de réponse, c'est peut-être que votre hébergeur de courrier fait n'importe quoi et bloque mes messages. Dirigez vos reproches vers eux, pas vers moi.


L'article seul

Du nouveau dans la (l'in)sécurité de l'Internet ?

Première rédaction de cet article le 5 janvier 2024


Le 3 janvier 2024, une partie du trafic IP à destination de la filiale espagnole d'Orange n'a pas été transmis, en raison d'un problème BGP, le système dont dépend tout l'Internet. Une nouveauté, par rapport aux nombreux autres cas BGP du passé, est qu'il semble que le problème vienne du piratage d'un compte utilisé par Orange. Quelles leçons tirer de cette apparente nouveauté ?

D'abord, les faits. Le 3 janvier 2024, vers 14:30 UTC, le trafic avec l'AS 12479, celui d'Orange Espagne chute brutalement. Cela se voit par exemple sur Radar, le tableau de bord de Cloudflare, recopié ici : cloudflare-orange-espagne.png

Pourquoi ? Le problème est lié à BGP, ce qui est logique puisque ce protocole de routage est la vraie infrastructure de l'Internet. C'est BGP qui permet à tous les routeurs de savoir par où envoyer les paquets IP. On voit l'augmentation importante du trafic BGP de cet AS sur RIPE stat : ripe-orange-espagne-as.png

Mais il ne s'agit pas d'un détournement par le biais d'une annonce BGP mensongère comme on l'a vu de nombreuses fois. Ici, le problème était plus subtil. Si on regarde l'archive des annonces BGP à RouteViews, on ne trouve pas une telle annonce « pirate ». Prenons le fichier d'annonces BGP https://archive.routeviews.org/route-views3/bgpdata/2024.01/UPDATES/updates.20240103.1400.bz2 (attention, il est gros) et convertissons les données (qui étaient au format MRT du RFC 6396), avec l'outil bgpdump : on trouve des retraits massifs d'annonces des préfixes d'Orange Espagne comme :

TIME: 01/03/24 14:13:17.792524
TYPE: BGP4MP_ET/MESSAGE/Update
FROM: 208.94.118.10 AS40630
TO: 128.223.51.108 AS6447
WITHDRAW
  85.50.0.0/22
  85.51.12.0/22
  85.53.56.0/22
  85.53.100.0/22
  85.54.36.0/22
...
  

Mais pas d'annonce usurpatrice. Le problème est très différent et semble venir d'un détournement d'un mécanisme de sécurité de BGP.

En effet, BGP est, par défaut, très vulnérable. N'importe quel routeur de la DFZ peut annoncer une route vers n'importe quel préfixe et ainsi capter du trafic (un grand classique, on l'a dit). Rassurez-vous, il existe plusieurs mécanismes de sécurité pour limiter ce risque. Mais comme rien n'est parfait en ce bas monde, ces mécanismes peuvent à leur tour créer des problèmes. En l'occurrence, le problème semble avoir été avec la RPKI. Ce système, normalisé dans le RFC 6480, permet de signer les ressources Internet, notamment les préfixes d'adresses IP (comme 85.50.0.0/22 et les autres cités plus haut). Un des objets que permet la RPKI est le ROA (Route Origination Authorization, RFC 6482), qui déclare quel(s) AS peuvent être à l'origine d'une annonce d'un préfixe. Il y a normalement un ROA pour les préfixes d'Orange Espagne (il se voit, ainsi que sa validité, sur le service de Hurricane Electric, ou bien sur RIPE stat). Mais, pendant le problème, ce ROA avait disparu, remplacé par un autre qui donnait comme origine l'AS 49581 (qui, j'insiste sur ce point, est apparemment totalement innocent dans cette affaire et semble avoir été choisi au hasard). Les annonces BGP d'Orange Espagne étaient donc refusés par les routeurs validants, ce qui explique les retraits de route comme celui montré plus haut, d'où l'agitation BGP, et la chute du trafic, bien des routeurs ne sachant plus comment joindre les préfixes d'Orange Espagne.

S'agissait-il d'une erreur d'Orange ? Apparemment pas. Une personne identifiée comme « Ms_Snow_OwO » s'est vantée sur Twitter d'avoir provoqué le problème. Le message a depuis disparu mais voici une copie d'écran : twitter-orange-espagne.png

Notez aussi les copies d'écran envoyées par « Ms_Snow_OwO », montrant bien l'interface du RIPE-NCC avec les ressources (notamment les préfixes IP) d'Orange Espagne : twitter-orange-espagne-ressources.png

En Europe, la très grande majorité des opérateurs qui créent des ROA ne le font pas sur une machine à eux (ce que la RPKI permet, puisqu'elle est décentralisée) mais sous-traitent cette opération au RIR, le RIPE-NCC. L'opérateur se connecte à une interface Web, le LIR Portal, s'authentifie et indique les préfixes qu'il veut voir signés. On voit donc qu'un maillon nécessaire à la sécurité est l'authentification sur le portail qui sert aux opérateurs Internet. Le RIPE-NCC permet une authentification à deux facteurs, via le protocole TOTP (normalisé dans le RFC 6238), mais ce n'est pas obligatoire et, selon « Ms_Snow_OwO », le mot de passe était bien trop simple. L'attaquant a pu alors s'authentifier auprès du RIPE-NCC et changer le ROA, cassant ainsi le routage.

C'est un problème courant en sécurité : toute technique qui vise à empêcher l'accès aux méchants peut être détournée pour faire un déni de service. Ainsi, par exemple, si vous bloquez un compte au bout de N tentatives d'accès infructueuses (une très mauvaise idée, mais qu'on voit parfois), il est trivial pour un attaquant de bloquer le compte, juste en tapant n'importe quel mot de passe. Ici, on peut s'indigner de ce qu'une technique anti-usurpation mène à un déni de service mais c'est un problème bien plus vaste que la RPKI.

Comme des informations ont montré que le mot de passe d'Orange Espagne était bien trop faible (juste « ripeadmin »), beaucoup de gens ont ricané, parfois bêtement, sur cette faiblesse. En fait, comme l'attaquant a apparemment utilisé un logiciel malveillant installé sur l'ordinateur d'un employé d'Orange Espagne, il aurait pu avoir le meilleur mot de passe du monde (« 45cf*b2b44cfA7🦕f64ccç302617F! »), cela n'aurait rien changé. Plutôt que de se focaliser sur ce mot de passe, effectivement trop faible, il vaudrait mieux insister sur l'importance d'activer l'authentification à deux facteurs, comme le recommande le RIPE.

Quelques lectures sur cette attaque, presque toutes en anglais car je n'ai rien trouvé en français :


L'article seul

Articles des différentes années : 2024  2023  2022  2021  2020  2019  2018  Précédentes années

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

Un article de ce blog au hasard.