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.


Printing on a Xerox AltaLink from Debian

First publication of this article on 11 April 2024


This is a very short article documenting how I managed to configure a Xerox AltaLink C8130 printer on a Debian machine. No rocket science, it is just that it could have been easier so I document it for the benefits of the people finding this artcle via a search engine, and also for my own benefit if I have to do it again.

I use CUPS for printing on my Debian machine and, without anything special, it worked with the Xerox AltaLink C8130. But without any option (double-sided, stapling, etc). To have the full set of options, I deleted the printer through CUPS' Web interface (the one which is by default at http://localhost:631/) and added it from scratch (Administration → Add a printer). I then choosed "LPD/LPR printer" (I assume it should work as well with IPP but I did not try), then used socket://192.0.2.43/ as connection parameter (the IP address being of course the printer's address; the easiest way to get it is by printing a test page from the front panel of the printer).

Then, I added the PPD file. This is the important step and it is not easy to find the PPD file on Xerox Web site (a "site:support.xerox.com ppd altalink" in your favorite search engine helps, searching for "drivers" or "download" is useless). The file is labeled "Generic PPD" and its name is AltaLink_C8130-C8170_5.709.0.0_PPD.zip.

You can then upload it to CUPS through its Web interface and it's done.


L'article seul

RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)

Date de publication du RFC : Novembre 2023
Auteur(s) du RFC : B. Schwartz (Meta Platforms), M. Bishop, E. Nygren (Akamai Technologies)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 8 avril 2024


Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau avant qu'il ne tente de se connecter à un serveur. On peut envoyer ainsi des indications sur les versions des protocoles gérées, des clés cryptographiques ou des noms de serveurs supplémentaires.

Un client d'un service réseau a en effet plein de questions à se poser avant de tenter une connexion. Quelle adresse IP utiliser ? Quel port ? Chiffrement ou pas ? Les anciens mécanismes traitent la question de l'adresse IP (on la trouve par une requête DNS) et celle du port, si on se limite aux ports bien connus (comme 43 pour whois). Mais cela ne dit pas, par exemple, si le serveur HTTP distant accepte ou non HTTP/3 (RFC 9114). Par contre, cet enregistrement HTTPS de Cloudflare va bien nous dire que ce serveur accepte HTTP/2 et 3 :


% dig cloudflare.com HTTPS
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28399
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
cloudflare.com.		300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5
…
;; WHEN: Mon Apr 08 09:27:01 CEST 2024
;; MSG SIZE  rcvd: 226

  

Bon, en quoi consiste cet enregistrement SVCB ? Il a deux modes de fonctionnement, alias et service. Le premier mode sert à faire d'un nom une version canonique d'un autre, un peu comme le CNAME mais en étant utilisable à l'apex d'une zone. Le second mode sert à indiquer les paramètres techniques de la connexion. Un enregistrement SVCB (ou HTTPS) a trois champs dans ses données :

  • SvcPriority : quand il vaut zéro, il indique le mode alias. Autrement (par exemple dans le cas ci-dessus), il indique la priorité de ces paramètres.
  • TargetName : en mode alias, il indique le nom canonique, ou autrement un nom alternatif (pour un service accessible via plusieurs noms). Dans l'exemple Cloudflare ci-desssus, il valait la racine (un point) ce qui indique l'absence de nom alternatif (section 2.5).
  • SvcParams : une liste de couples {clé,valeur} pour les paramètres de connexion (uniquement en mode service). Dans le cas avec Cloudflare, c'était alpn="h3,h2" ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5. (Si vous vous intéressez aux débats à l'IETF, la question de la syntaxe de ces paramètres avait suscité une longue discussion.)

Les enregistrements SVCB ont le type 64 (enregistré à l'IANA) et les HTTPS, qui ont la même syntaxe et le même contenu, mais sont spécifiques à HTTP, ont le 65 (SVCB est générique). Les enregistrements HTTPS (et de futurs enregistrements pour d'autres protocoles) sont dits « compatibles avec SVCB » car ils ont la même syntaxe et la même sémantique.

Notre RFC définit (section 7) une liste de paramètres possibles mais d'autres peuvent être ajoutés dans un registre IANA, via la procédure « Examen par un expert » (RFC 8126). Pour l'instant, il y a, entre autres :

  • alpn : indique l'ALPN (RFC 7301).
  • ech : il servira à indiquer la clé à utiliser pour chiffrer le SNI.
  • port : comme son nom l'indique.
  • ipv4hint et ipv6hint : les adresses IP du service.

L'enregistrement peut (cela dépend des protocoles qui l'utilisent, HTTP ne le fait pas) être placé sur un sous-domaine indiquant le service, par exemple _8765._baz.api.example.com (section 10.4.5).

Idéalement, un serveur faisant autorité devrait renvoyer les SVCB et les HTTPS, s'ils sont présents, dans la section additionnelle de la réponse, lorsque le type demandé était une adresse IP. Mais ceux de Cloudflare ne semblent pas le faire actuellement. (PowerDNS le fait.)

Si vous vous intéressez aux questions opérationnelles, et que vous voulez mettre des enregistrements SVCB/HTTPS dans votre zone, la section 10 du RFC est faite pour vous. J'ai des enregistrements HTTPS pour ce blog :


# Un alias à l'apex (la priorité 0 indique le mode alias)
% dig +short +nodnssec bortzmeyer.org HTTPS
0 www.bortzmeyer.org.

# J'ai HTTP/2 (mais pas encore HTTP/3)
% dig +short +nodnssec www.bortzmeyer.org HTTPS
1 . alpn="h2"

Pour cela, j'ai mis dans le fichier de zone :

; Enregistrements SVCB (HTTPS).     

; HTTP/2 (mais pas encore - au 2024-04-08 - de HTTP/3)               
www IN HTTPS 1 . alpn="h2"

; alias                               
@ IN HTTPS 0 www.bortzmeyer.org.

Les clients HTTP récents, qui gèrent SVCB/HTTPS vont alors se connecter directement en HTTP/2 à https://www.bortzmeyer.org/ même si l'utilisateur demandait originellement http://bortzmeyer.org/ (le type d'enregistrement HTTPS, comme son nom l'indique, sert aussi à annoncer qu'on accepte HTTPS, ce qui permettra d'abandonner HSTS). Les clients HTTP plus anciens, évidemment, ne connaissent pas le système SVCB/HTTPS et il faut donc garder une configuration pour eux (par exemple des adresses IP à l'apex). Il y a aussi les autres méthodes, comme le Alt-Svc: du RFC 7838. La section 9.3 du RFC décrit le comportement attendu lorsque les différentes méthodes coexistent.

Faites attention toutefois, lorsque vous mettez ce type d'enregistrements dans votre zone, je ne connais pas encore d'outils de test permettant de vérifier la syntaxe des enregistrements, encore moins leur correspondance avec la réalité (par exemple, SSLLabs ne semble pas le faire). C'est un problème général de la signalisation sur l'Internet, quand on signale (notamment via le DNS) les capacités d'un serveur : le logiciel client doit de toute façon être prêt à tout, car il ne peut jamais être sûr que le signal est conforme aux faits.

En parlant d'anciens logiciels (clients et serveurs), vous pouvez trouver une liste de mises en œuvre de SVCB/HTTPS. Attention, elle est incomplète et pas à jour. Notez qu'il y a parfois des contraintes particulières, ainsi, il semble que Firefox ne demande des enregistrements HTTPS que s'il utilise DoH. iOS envoie des requêtes HTTPS depuis iOS 14, publié en septembre 2020, ce qui avait étonné, à l'époque.

En parlant de Firefox, s'il est assez récent, et s'il est configuré pour faire du DoH, vous pouvez tester le SVCB/HTTPS en allant dans about:networking#dnslookuptool. En entrant un nom de domaine, le champ « RR HTTP » doit renvoyer l'enregistrement HTTPS.

Avec un tcpdump récent, voici le trafic DNS utilisant le nouvel enregistrement DNS, qu'on peut observer sur un serveur faisant autorité pour bortzmeyer.org :

09:49:23.354974 IP6 2a04….31362 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 13024% [1au] HTTPS? www.bortzmeyer.org. (47)
09:52:06.094314 IP6 2a00….56551 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 40948% [1au] HTTPS? wWw.bOrTZmEyER.ORg. (62)
10:06:21.501437 IP6 2400….11624 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 59956 [1au] HTTPS? doh.bortzmeyer.fr. (46)
10:06:21.999608 IP6 2400….36887 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 17231 [1au] HTTPS? radia.bortzmeyer.org. (49)
10:25:53.947096 IP6 2001….54476 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 26123% [1au] HTTPS? www.bortzmeyer.org. (47)
  

Si votre tcpdump est plus ancien, vous verrez Type65 au lieu de HTTPS.

Sinon, si vous aimez les bricolages (et celui-ci sera de moins en moins utile avec le temps, au fur et à mesure que les serveurs géreront ce type), pour fabriquer les enregistrements, vous pouvez utiliser cet outil, qui va fabriquer la forme binaire, directement chargeable par les serveurs faisant autorité :

% perl type65_https.pl 'example.net HTTPS 1 . alpn="h3,h2" ipv4hint="192.0.2.42" ipv6hint="2001:db8::42"'
example.net. TYPE65 ( \# 41 00010000010006026833026832000400
	04c000022a0006001020010db8000000 000000000000000042 )
  

(Il faut un Net::DNS récent sinon « unknown type "HTTPS" at /usr/share/perl5/Net/DNS/RR.pm line 671. in new Net::DNS::RR( www.bortzmeyer.org HTTPS 1 . alpn="h2" ) at type65_https.pl line 30. ».)

Quelques articles pas mal :


Téléchargez le RFC 9460


L'article seul

Un résolveur DNS public en Inde

Première rédaction de cet article le 7 avril 2024


J'avais raté l'information : il y a désormais un résolveur DNS public en Inde, dns.nic.in.

Il ne semble pas y avoir eu beaucoup de communication publique sur ce service mais il fonctionne. Un résolveur DNS public est un résolveur qui est ouvert à toustes et accepte donc des requêtes DNS de n'importe quelle adresse IP. (Un résolveur ouvert fait pareil mais c'est une erreur de configuration ; un résolveur public résulte d'une action volontaire.) Les plus connus sont ceux de grosses entreprises étatsuniennes comme Google (avec son 8.8.8.8) ou Cloudflare (avec son 1.1.1.1). Si on ne veut pas, et avec raison, contribuer à nourrir ces entreprises d'encore plus de données personnelles, sans compter les risques de centralisation de la résolution DNS, on a le choix : on peut avoir son propre résolveur, ou bien utiliser d'autres résolveurs publics comme celui de Yandex (si on veut envoyer ses données personnelles au FSB plutôt qu'à la NSA), celui d'une entreprise allemande ou d'une association française. (Il y en a même un que je gère.)

Cette offre importante et variée s'est enrichie (mais je ne sais pas trop quand) d'un résolveur indien. Il est accessible en UDP et TCP avec plusieurs adresses IP. Prenons l'une des plus jolies, 2409::.


%  dig @2409:: mastodon.gougere.fr AAAA

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @2409:: mastodon.gougere.fr AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33859
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: d5d69e457527742201000000661296ca11b1e6683393ded2 (good)
;; QUESTION SECTION:
;mastodon.gougere.fr.	IN AAAA

;; ANSWER SECTION:
mastodon.gougere.fr.	900 IN AAAA 2001:bc8:1202:ce00::1
mastodon.gougere.fr.	900 IN RRSIG AAAA 13 3 900 (
				20240522050147 20240323042710 18689 gougere.fr.
				YUzJqyzLVFbndBhaFPtxcQZPoFgVynD9BpxukCuYKJzP
				PtSzNK/lY3xFvHi44Txda+/KrZiRIr7LvuU46s0RhQ== )

;; Query time: 304 msec
;; SERVER: 2409::#53(2409::) (UDP)
;; WHEN: Sun Apr 07 14:51:22 CEST 2024
;; MSG SIZE  rcvd: 210


  

OK, tout fonctionne, et on peut voir (flag AD, pour Authentic Data) que ce résolveur valide avec DNSSEC. Le temps de réponse n'est pas extraordinaire depuis ma machine en France mais il est probable que les gérants de ce serveur ont privilégié leur présence en Inde.

Testons cette hypothèe avec les sondes RIPE Atlas :

% blaeu-resolve --nameserver 2409:: --displayvalidation --displayrtt --requested 100 \
                    --country IN --old_measurement 69708749   --type AAAA geoponum.com
…
[ (Authentic Data flag)  2001:41d0:301::28] : 33 occurrences Average RTT 27 ms
[TIMEOUT] : 11 occurrences 
Test #69708785 done at 2024-04-07T13:01:15Z

% blaeu-resolve --nameserver 2409:: --displayvalidation --displayrtt --requested 100 \
                    --country JP --old_measurement 69708763     --type AAAA geoponum.com
…
[ (Authentic Data flag)  2001:41d0:301::28] : 98 occurrences Average RTT 134 ms
[2001:41d0:301::28] : 1 occurrences Average RTT 897 ms
[TIMEOUT] : 1 occurrences 
Test #69708813 done at 2024-04-07T13:03:37Z
  

(On réutilise les sondes d'une mesure précédente, pour augmenter la probabilité que tout soit dans la mémoire du résolveur.) On voit que la latence moyenne est plus basse en Inde qu'au Japon, ce qui est logique. Ce résolveur n'est donc peut-être pas la solution idéale si vous vivez en dehors de l'Inde.

Je l'ai dit, l'offre en matière de résolveurs publics est très diverse et donc les arguments des contempteurs de DoH comme quoi DoH pousserait à la centralisation sont bien à côté de la plaque. Notez aussi que, bien qu'il existe de nombreux résolveurs publics de qualité opérationnels, celui annoncé en fanfare par la Commission Européenne il y a déjà plusieurs années, DNS4EU, ne fonctionne toujours pas (Thierry Breton est plus doué pour les annonces que pour l'opérationnel, ce qui était déjà le cas lorsqu'il dirigeait Atos).

Ah, mais j'ai dit que le résolveur était accessible en UDP et en TCP. Et avec des protocoles chiffrés comme DoT (RFC 7858) ou DoH (RFC 8484) ?

% kdig +tls @2409:: geoponum.com
;; WARNING: can't connect to 2409::@853(TCP)
;; ERROR: failed to query server 2409::@853(TCP)
  

Ah, zut, pas encore de chiffrement. Mais, en fait, c'est plus compliqué que cela. Il semble que certaines instances du nuage anycast (cf. plus loin) aient du chiffrement, mais pas les autres. Donc, selon l'adresse IP de service qu'on utilise et l'endroit où on est, on verra du chiffrement ou pas :


% kdig +nsid +https=/dns-query @1.10.10.10 geoponum.com                                             
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
;; HTTP session (HTTP/2-POST)-(1.10.10.10/dns-query)-(status: 200)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 0
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; NSID: 696E2D626F6D2D7331 "in-bom-s1"

;; QUESTION SECTION:
;; geoponum.com.       		IN	A

;; ANSWER SECTION:
geoponum.com.       	3600	IN	A	51.91.236.193

;; Received 70 B
;; Time 2024-04-07 16:49:26 CEST
;; From 1.10.10.10@443(TCP) in 613.4 ms

Ici, l'instance de Bombay a bien répondu en DoH (son certificat, sans surprise, est un Let's Encrypt).

En demandant le NSID (RFC 5001, on voit que le résolveur est manifestement anycasté :

% blaeu-resolve --nameserver 2409::  --nsid --requested 200 --type AAAA geoponum.com
Nameserver 2409::
[TIMEOUT] : 12 occurrences 
[2001:41d0:301::28 NSID: in-amd-s1;] : 134 occurrences 
[2001:41d0:301::28 NSID: in-blr-s1;] : 32 occurrences 
[2001:41d0:301::28 NSID: in-maa-s1;] : 6 occurrences 
[2001:41d0:301::28 NSID: in-maa-s2;] : 3 occurrences 
[2001:41d0:301::28 NSID: in-bom-s1;] : 1 occurrences 
[2001:41d0:301::28 NSID: in-gau-s1;] : 6 occurrences 
[2001:41d0:301::28 NSID: None;] : 3 occurrences 
[2001:41d0:301::28 NSID: in-bom-s2;] : 3 occurrences 
Test #69708899 done at 2024-04-07T13:10:50Z
  

On voit au moins sept instances différentes. Le schéma de nommage semble être le classique code IATA des aéroports (AMD = Ahmedabad, BLR = Bangalore, etc).

Si on essaie d'obtenir le nom du serveur à partir de son adresse IP, on voit que la zone 0.0.0.9.0.4.2.ip6.arpa est bien cassée (regardez l'EDE - RFC 8914) :


% dig -x 2409::
…
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9388
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 7 (Signature Expired): (6GJV)
;; QUESTION SECTION:
;0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.0.4.2.ip6.arpa. IN PTR

;; Query time: 4296 msec
;; SERVER: 192.168.2.254#53(192.168.2.254) (UDP)
;; WHEN: Sun Apr 07 10:40:34 CEST 2024
;; MSG SIZE  rcvd: 111    

  

Outre les signatures DNSSEC expirées, cette zone a plein d'autres problèmes DNS.

Et les adresses IP sortantes, à partir desquelles le résolveur indien pose des questions aux serveurs faisant autorité ? Testons avec le service ip.dyn.bortzmeyer.fr, qui renvoie l'adresse IP de son client (du résolveur, donc) :

% blaeu-resolve --nameserver 2409::  --nsid --requested 200 --type TXT ip.dyn.bortzmeyer.fr 
Nameserver 2409::
["160.202.194.2" NSID: in-amd-s1;] : 140 occurrences 
[TIMEOUT] : 10 occurrences 
["160.202.198.2" NSID: in-blr-s1;] : 5 occurrences 
["2409:e:e7::3" NSID: in-maa-s2;] : 4 occurrences 
["240a:eff6::2" NSID: in-blr-s1;] : 23 occurrences 
["160.202.200.2" NSID: in-gau-s1;] : 1 occurrences 
["180.250.245.54" NSID: None;] : 1 occurrences 
["2409:e:e7::2" NSID: in-maa-s1;] : 2 occurrences 
["45.249.124.2" NSID: in-maa-s1;] : 1 occurrences 
["240a:eff8::2" NSID: in-gau-s1;] : 7 occurrences 
["2409:e:e4::2" NSID: in-bom-s1;] : 2 occurrences 
["2409:e:e4::3" NSID: in-bom-s2;] : 2 occurrences 
["99.212.0.7" NSID: None;] : 1 occurrences 
["121.46.96.2" NSID: in-bom-s1;] : 1 occurrences 
Test #69709105 done at 2024-04-07T13:26:34Z

On voit une grande variété de préfixes, tous enregistrés en Inde, à divers organismes publics.


L'article seul

RFC 9340: Architectural Principles for a Quantum Internet

Date de publication du RFC : Mars 2023
Auteur(s) du RFC : W. Kozlowski, S. Wehner (QuTech), R. Van Meter (Keio University), B. Rijsman, A. S. Cacciapuoti, M. Caleffi (University of Naples Federico II), S. Nagayama (Mercari)
Pour information
Réalisé dans le cadre du groupe de recherche IRTF qirg
Première rédaction de cet article le 3 avril 2024


Voici un RFC assez futuriste qui explore à quoi pourrait ressembler un futur « Internet » quantique. Je divulgâche tout de suite : ce ne sera pas de si tôt.

Quelques avertissements s'imposent d'abord. Avant tout, rappelez-vous que la quantique produit des résultats qui sont parfaitement cohérents théoriquement et très bien vérifiés expérimentalement mais qui sont hautement non-intuitifs. Avant d'aborder le monde merveilleux de la quantique, n'oubliez pas d'oublier tout ce que vous croyez savoir sur le monde physique. Et ne comptez pas trop sur moi comme guide, on sort nettement ici de mon domaine de compétence. Ensuite, « quantique » est un terme à très forte charge marketing (moins que « IA » mais davantage que « métavers » ou même « blockchain », qui semblent bien passés de mode). Il faut donc être prudent chaque fois qu'un commercial ou un éditorialiste va dire que « c'est quantique » ou que « la quantique va bouleverser tel ou tel domaine ». Enfin, il y a loin de la coupe aux lèvres : de même qu'on n'a pas encore d'ordinateur quantique utile, on n'a pas encore de réseau quantique. Le RFC est à juste titre prudent, pointant les différents obstacles qui restent sur le chemin de l'Internet quantique.

Bon, ces précautions étant posées, qu'est-ce qu'un réseau quantique et pourquoi y consacrer un RFC ? La section 1 du RFC le résume : un réseau quantique est un réseau qui ferait communiquer des dispositifs quantiques pour faire des choses inimaginables avec un réseau classique. Il s'appuierait sur des propriétés spécifiques au monde quantique, notamment l'intrication, propriétés qui n'ont pas d'équivalent dans le monde classique. Attention, et le RFC insiste bien là-dessus, personne n'envisage de remplacer l'Internet classique par un Internet quantique (de la même façon que les futurs ordinateurs quantiques, étant loin d'être généralistes, ne remplaceront pas les ordinateurs classiques). Au contraire, le scénario envisagé est celui d'un réseau hybride, partiellement quantique. (Une lecture recommandée par le RFC est « The quantum internet ».)

Un exemple typique qui ne serait pas possible avec un réseau classique est celui de la distribution quantique de clés (parfois appelée du terme erroné de « cryptographie quantique »), dont l'utilité pratique est douteuse mais qui est assez spectaculaire et, contrairement à d'autres applications, est assez avancée techniquement. D'autres applications sont envisageables à plus long terme. C'est le cas par exemple du blind quantum computation, qui n'a pas encore d'article Wikipédia mais est expliqué dans cet article.

En laboratoire, beaucoup de résultats ont été obtenus. Les chercheurs et chercheuses ont déjà mis au point bien des dispositifs physiques étonnants. Mais à l'échelle du réseau, il n'y a pas encore eu beaucoup de travaux. Le RFC compare cette situation à celle d'un réseau classique où on aurait des fibres optiques et des lasers pour les illuminer mais aucun protocole de transport, aucun mécanisme de routage, encore moins de moyens de gérer le réseau. Développer une application pour un réseau quantique revient à toucher directement au matériel, comme, pour un réseau classique, s'il fallait que chaque application parle aux interfaces physiques, sans avoir d'interface de plus haut niveau comme les prises.

La section 2 du RFC est un rappel sur la quantique. Comme dit plus haut, c'est un domaine riche et complexe, où l'intuition ordinaire ne sert pas à grand'chose. Donc, lire ce rappel est une bonne idée mais n'espérez pas tout comprendre si vous n'êtes pas spécialiste de la question. Cette section est conçue pour des gens qui ne connaissent rien à la physique quantique, elle recommande, pour aller plus loin, le livre de Sutor Dancing with Qubits ou bien celui de Nielsen et Chuang, Quantum Computation and Quantum Information.

Le rappel commence avec la notion d'état quantique. Vous avez sans doute déjà entendu dire qu'un bit classique peut prendre deux valeurs, 0 ou 1, alors que son équivalent quantique, le qubit, a un état qui est une superposition de valeurs possibles, avec des probabilités. Lorsqu'on le mesure, on trouve un 0 ou un 1. (Oui, comme le célèbre chat qui est à la fois vivant et mort.) Attention, ces non-certitudes ne sont pas la conséquence d'un manque d'information mais sont une propriété fondamentale du monde quantique (Alain Aspect a eu un prix Nobel pour avoir prouvé cela). Notez que les versions HTML ou PDF du RFC sont recommandées ici, car il y a quelques équations. Comme un qubit est dans un état qui superpose les deux valeurs possibles, les opérations quantiques agissent sur tout l'état, par exemple l'équivalent quantique d'une porte NOT va inverser les probabilités du 0 et du 1 mais pas transformer un 0 en 1.

Le terme « qubit » (et cette distinction revient souvent dans le RFC) peut désigner aussi bien le concept abstrait que le truc physique qui va le mettre en œuvre (il existe plusieurs techniques pour fabriquer un engin qui gérera des qubits).

On peut ensuite assembler des qubits et, très vite, le nombre de possibilités croît. Mais l'intérêt de mettre des qubits ensemble est qu'on peut les intriquer et ce concept est au cœur de beaucoup de solutions quantiques, notamment du réseau quantique. Une fois intriqués, les deux qubits verront leur sort lié. Une mesure sur l'un affectera l'autre. (Rappel : la quantique n'est pas intuitive et l'intrication n'a pas d'équivalent dans le monde non-quantique, celui sur lequel a été bâtie notre intuition.) La mesure, comme toujours en quantique, est « destructive » au sens où elle ramène à un système classique (le qubit vaut 0 ou 1 quand on le mesure, pas un mélange des deux, et le chat est vivant ou mort quand on ouvre la boite).

Cette intrication est au cœur des réseaux quantiques (section 3 du RFC). Tous les projets de réseaux quantiques utilisent cette propriété (qui, rappelons-le, n'a pas d'équivalent non-quantique). L'intrication permet de corréler deux nœuds du réseau. Par exemple, pour se mettre d'accord sur une valeur, deux machines n'ont pas besoin de faire tourner des algorithmes de consensus, elles peuvent utiliser deux qubits intriqués, chacune en gardant un. Quand une machine lira la valeur de son qubit, elle sera certaine de la valeur lue par l'autre. Et l'intrication ne peut pas être partagée : un tiers ne peut pas s'intriquer avec une intrication existante, ce qui peut avoir des applications en sécurité.

Un réseau quantique est donc défini par notre RFC comme un ensemble de nœuds qui peuvent échanger des qubits intriqués.

Bon, tout ça, c'est très joli, mais comment on le réalise, ce réseau quantique ? La section 4 se penche sur les défis :

  • Comme toute mesure détruit le caractère quantique du qubit et le transforme en un bit ordinaire, des opérations banales dans le monde classique, comme la copie d'un bit, deviennent non triviales.
  • Et copier un qubit sans le mesurer ? On ne peut pas (c'est le théorème d'impossibilité du clonage).
  • Tout cela rend très difficile la correction d'erreurs. Un réseau réel, reposant sur des objets physiques, va forcément voir des erreurs (un rayon cosmique passe et paf, un 0 est transformé en 1) et de nombreuses techniques existent pour gérer ce problème dans le monde classique. Mais elles ne peuvent en général pas s'appliquer dans le monde quantique, qui va donc avoir un problème de fidélité : la fidélité est la conformité à ce qu'on souhaitait (elle va de 0 à 1), et les applications doivent en tenir compte.

Distribuer sur le réseau des qubits quelconques n'est pas forcément facile, donc le RFC suggère de plutôt distribuer des paires de Bell. On peut alors plus facilement (tout est relatif) faire de la téléportation, c'est-à-dire « transporter » un qubit d'un point à un autre. Ce n'est pas une violation du théorème d'impossibilité du clonage puisque le qubit n'est pas copié (il disparait de son point de départ). Notez que le terme de « téléportation » est surtout marketing : vous ne pourrez pas déplacer votre chat ou vous-même de cette façon.

Dernier problème, amplifier le signal (sans le copier !) pour tenir compte de sa dégradation avec la distance. Il existe une astuce, l'échange d'intrication, que je ne vais pas essayer d'expliquer, mais qui permet des réseaux quantiques sur des distances importantes.

Revenons à la correction d'erreurs. Les réseaux quantiques ne sont pas complètement démunis, et ont des solutions possibles, comme les codes quantiques.

OK, on a vu que le monde quantique était très spécial. Donc, le réseau quantique va être bizarre aussi, aux yeux de quelqu'un qui a l'habitude des réseaux classiques (section 5 du RFC). Par exemple, il fera face à ces problèmes :

  • C'est bien joli, les paires de Bell, mais ce n'est pas l'équivalent d'un paquet portant une charge utile. Il n'y a pas l'équivalent de l'en-tête du paquet, et le réseau quantique va donc devoir utiliser un réseau classique pour l'information de contrôle. On ne fera pas un réseau purement quantique.
  • Toute action sur des qubits intriqués doit être coordonnée entre les nœuds puisque l'action sur un qubit va déterminer le résultat d'une action sur les autres (il faut donc que chaque nœud sache contacter les autres).

Répétons-le, chaque nœud du réseau quantique devra également être relié à un réseau classique. Le réseau sera donc complexe et son administration pas évidente.

Une fois qu'on a accepté cela, le réseau classique pourra s'occuper d'opérations comme la construction des tables de routage, pour laquelle les algorithmes et méthodes classiques semblent suffire. On n'aura donc peut-être qu'un seul plan de contrôle (le classique) mais deux plans de données, le classique et le quantique.

Que faut-il construire comme machines pour le plan de données quantique ? D'abord, des répéteurs quantiques qui vont pouvoir créer les intrications, les échanger et contrôler la fidélité. Ensuite :

  • Des routeurs quantiques, qui, en plus des fonctions ci-dessus, participeront au routage.
  • Les nœuds ordinaires, des répéteurs qui ne participent pas au routage.
  • Les nœuds terminaux, qui pourront émettre et recevoir des qubits mais pas faire d'échange d'intrication. C'est là que tourneront les applications.

Facile, me direz-vous ? Non, construire ces machines va nécessiter de s'attaquer à quelques problèmes physiques :

  • Stocker un qubit est un défi ! Le monde classique n'aime pas les objets quantiques et essaie régulièrement de les rappeler à ses lois. Les bruits divers de l'environnement font rapidement perdre aux qubits leurs propriétés quantiques. (C'est d'ailleurs pour cela que vous ne rencontrez pas de chats de Schrödinger dans la vraie vie.) Cela se nomme la décohérence et c'est l'un des principaux obstacles sur la route des réseaux quantiques (ou des calculateurs quantiques). Les durées de vie qu'on atteint étaient, lors de la rédaction du RFC, de l'ordre de la seconde (ou de la minute si on n'est pas connecté au réseau, source de perturbations).
  • La capacité des liens quantiques est un autre problème. Générer des qubits intriqués prend du temps. Quand on en fabrique dix par seconde, on est contents. Bien sûr, la technique progresse sans cesse (pas mal des références du RFC sont un peu datées, car il a mis du temps à sortir) mais pas assez.
  • On l'a dit, on peut réaliser des qubits intriqués par différentes méthodes physiques, avec des performances différentes selon la métrique utilisée. Mais ces méthodes ne communiquent pas entre elles, ce qui veut dire que tous les nœuds du réseau doivent utiliser la même.

Si vous n'êtes pas découragé·e (mais il ne faut pas l'être : même si les difficultés sont colossales, le chemin est rigolo), il faut maintenant, en supposant qu'on aura les composants de base d'un réseau, les assembler. (À moins que le choix décrit dans le RFC des paires de Bell et de l'échange d'intrication ne soit remis en cause par les futurs progrès…) La section 6 se penche sur la question. Elle démarre par un bel excès d'optimisme, en expliquant que, contrairement à ce qui s'est passé avec l'Internet classique, on a de l'expérience sur la construction de réseau, et qu'on pourra donc ne pas faire d'erreur comme la taille trop réduite des adresses IPv4.

Des services essentiels pour un réseau réel seront difficiles à assurer sur un réseau quantique. Par exemple, l'impossibilité du clonage interdira d'utiliser un logiciel équivalent à tcpdump (remarquez, pour la sécurité, c'est un plus). Le RFC liste les principes de base d'un réseau quantique :

  • Le service de base sera l'intrication.
  • La fidélité est aussi un service (contrairement au réseau classique où on peut espérer une fidélité parfaite).
  • Le temps va être un facteur crucial, compte tenu de la décohérence. Pas question de faire patienter des qubits trop longtemps dans une file d'attente, par exemple.
  • Il faudra être flexible, notamment parce que le matériel va continuer à évoluer.

Et le RFC se termine par une exploration d'une architecture de réseau quantique possible, inspirée de MPLS. Dans ce réseau (pour l'instant) imaginaire, tout fonctionne en mode connecté (comme MPLS) : on doit d'abord créer un circuit virtuel (car créer les paires de Bell et les utiliser va nécessiter de la coordination, donc il vaut mieux établir d'abord une connexion). Ce QVC (Quantum Virtual Circuit) a des caractéristiques comme une qualité de service choisie, qui se décline en, par exemple, une capacité mesurée en nombre de paires de Bell par seconde et bien sûr une fidélité (toutes les applications des réseaux quantiques n'ont pas les mêmes exigences en terme de fidélité). La signalisation peut être décentralisée (comme avec RSVP) ou centralisée (comme avec OpenFlow). Comme vous le verrez en lisant cette conclusion du RFC, les détails sont encore approximatifs.

Ce RFC a mis longtemps à être écrit, vous pouvez trouver une description ancienne du projet sur le blog de l'IETF. Notez que l'écriture de ce RFC a été en partie financée par la Quantum Internet Alliance européenne.

N'hésitez pas à vous plonger dans la bibliographie très détaillée de ce RFC, vous y trouverez beaucoup de lectures passionnantes. Il y a même déjà des livres entiers sur les réseaux quantiques comme celui de Van Meter.


Téléchargez le RFC 9340


L'article seul

Fiche de lecture : L'animal médiatique (Le temps des médias)

Auteur(s) du livre : Ouvrage collectif
Éditeur : Nouveau monde
978-2-38094-393-1
Publié en 2023
Première rédaction de cet article le 3 avril 2024


Ce numéro de la revue d'histoire « Le temps des médias » est consacré à la place des animaux dans les médias et il y a beaucoup à dire !

Tous les articles sont passionnants mais, parmi ceux qui m'ont particulièrement instruit :

  • L'histoire de l'« ours Martin » (qui n'était pas un ours unique, mais un nom générique) au Jardin des plantes, par Olivier Vayron. Si les médias de l'époque adoraient les récits (presque tous imaginaires) d'agressions commises par Martin sur les visiteurs, la réalité est plus glauque : ce sont les humains qui agressaient l'ours du zoo, souvent de manière lâche et ignoble.
  • L'analyse de la place de l'animal sauvage dans les récits d'aventure bon marché du XIXe siècle, par Sophie Bros. Peu de souci de véracité ou même de vraisemblance dans ces récits conçus pour de la production et de la distribution de masse. Dans le train de l'époque, tiré par une locomotive à vapeur, on avait le temps de se délecter d'histoires toutes pareilles, où le courageux explorateur européen venait à bout de toute une ménagerie de bêtes féroces et exotiques.
  • Plus actuel, un article de Félix Patiès détaille la polémique au sein de la Fédération Anarchiste sur une émission « antispéciste » de Radio Libertaire. Difficile équilibre entre un désir d'ouverture à d'autres courants (d'autant plus importante que l'ARCOM exige une production minimum de contenus originaux) et nécessité, pour une organisation politique, de ne pas accepter n'importe quoi sur son antenne, notamment lorsque cela s'oppose directement à sa ligne politique.
  • Toujours dans une actualité plus récente, une étude détaillée de Michel Dupuy sur la construction de l'image de l'oiseau mazouté, comme symbole des destructions que la société industrielle inflige à l'environnement. Ce malheureux oiseau a également été utilisé pour de la propagande de guerre pendant la guerre du Golfe.
  • Les fanas de géopolitique trouveront aussi de quoi les intéresser, avec l'article de Zhao Alexandre Huang, Mylène Hardy et Rui Wang sur l'utilisation des pandas par la propagande chinoise. Derrière la mignoncitude, Beijing tire les ficelles.
  • Et bien sûr un article sur le rôle des chats sur l'Internet et un sur celui des chiens dans les films de Disney (article que j'ai trouvé extrêmement pro-Disney…)

On peut se procurer ce numéro sous forme papier chez l'éditeur et sous forme numérique (paradoxalement bien plus chère) sur cairn.info. PS : oui, le site Web officiel de la revue n'est pas à jour et est plein de mojibake.


L'article seul

RFC 9432: DNS Catalog Zones

Date de publication du RFC : Juillet 2023
Auteur(s) du RFC : P. van Dijk (PowerDNS), L. Peltan (CZ.NI), O. Sury (Internet Systems Consortium), W. Toorop (NLnet Labs), C.R. Monshouwer, P. Thomassen (deSEC, SSE - Secure Systems Engineering), A. Sargsyan (Internet Systems Consortium)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 29 mars 2024


L'idée de base de ces « zones catalogue » est d'automatiser la configuration d'une nouvelle zone DNS sur les serveurs secondaires, en publiant dans le DNS les caractéristiques des zones qu'ils devront servir. Cela concerne donc surtout les gros hébergeurs qui ont beaucoup de zones.

Petit rappel : une zone, dans le DNS, est une partie contigüe de l'arbre des noms de domaine, gérée comme un tout (mêmes serveurs faisant autorité). Ainsi, si vous venez de louer le nom machin.example, un hébergeur DNS va configurer ses serveurs pour faire autorité pour ce nom. Par exemple, avec le logiciel NSD, sur le primaire (serveur maitre) :

zone:
        name: "machin.example"
        zonefile: "primary/machin.example"
        # Les serveurs secondaires :
        notify: 2001:db8:1::53
        provide-xfr: 2001:db8:1::53
        …

Et, sur un serveur secondaire (serveur esclave), qui transférera la zone depuis le primaire (RFC 5936) :

zone:
   name: "machin.example"
   # Le primaire :
   allow-notify: 2001:db8:cafe::1 NOKEY
   request-xfr: AXFR 2001:db8:cafe::1 NOKEY

Si on gère beaucoup de zones, avec des ajouts et des retraits tout le temps, l'avitaillement manuel est long et risqué (et si on oublie un serveur ?). Éditer ces fichiers sur tous les serveurs secondaires devient vite pénible. Et si les logiciels sur les secondaires sont différents les uns des autres (ce qui est recommandé, pour la robustesse), il faut se souvenir des différentes syntaxes. Pourquoi faire manuellement ce qu'on peut automatiser ? C'est le principe des zones catalogue.

Le principe est simple : une zone catalogue est une zone comme une autre, produite par les mêmes mécanismes (par exemple emacs) et qui sera servie par un serveur primaire à tous les secondaires, qui changeront alors automatiquement leur configuration en fonction du contenu de la zone catalogue. Chaque zone à configurer est un enregistrement de type PTR, dont la partie gauche est une étiquette interne et la partie droite indique le nom de la zone. Ici, on configure la zone rutaba.ga, l'étiquette (qui doit être unique) label1 est à usage interne (section 4.1 du RFC) :

label1.zones.catalog.example. IN PTR rutaba.ga.

Le reste est listé sous forme de propriétés (section 4.2). Une propriété évidente est l'adresse IP du primaire. Pour l'instant, elle doit être indiquée via le composant ext qui désigne les propriétés pas encore normalisées :

primaries.ext.catalog.example.    IN AAAA 2001:db8:bad:dcaf::42

La liste des propriétés figure dans un registre IANA.

À l'heure actuelle, de nombreux logiciels gèrent ces zones catalogues. Le site Web du projet (pas mis à jour depuis très longtemps) en liste plusieurs.

Voici un exemple complet de zone catalogue :

; -*- zone -*-
catalog.example.    IN SOA ns4.bortzmeyer.org. stephane.bortzmeyer.org. 2023120902 900 600 86400 1
catalog.example.    IN NS invalid.   ; Le NS est inutile mais
                         ; obligatoire et "invalid" est la valeur
                         ; recommandée (section 4).
version.catalog.example.    IN TXT "2"  ; Obligatoire, section 4.2.1

label1.zones.catalog.example. IN PTR rutaba.ga.
primaries.ext.catalog.example.    IN AAAA 2001:db8:bad:dcaf::42

La configuration de BIND pour l'utiliser :

# La zone catalogue se charge comme n'importe quelle zone. Ceci dit,
# vu le caractère critique de la zone catalogue, la section 7 du RFC
# insiste sur l'importance de sécuriser ce transfert, par exemple avec
# TSIG (RFC 8945) :
zone "catalog.example" {
        type slave;
        file "catalog.example";
        masters {
              2001:db8:666::;
        };            

};

# Et, ici, on la désigne comme spéciale :
options {
   ...      
   catalog-zones {
     zone "catalog.example"
              in-memory no;
   };
};

Naturellement, comme toujours lorsque on automatise, on risque le syndrome de l'apprenti sorcier. Attention donc en générant la zone catalogue. Comme le note le RFC (section 6) : « Great power comes with great responsibility. Catalog zones simplify zone provisioning by orchestrating zones on secondary name servers from a single data source: the catalog. Hence, the catalog producer has great power and changes must be treated carefully. For example, if the catalog is generated by some script and this script generates an empty catalog, millions of member zones may get deleted from their secondaries within seconds, and all the affected domains may be offline in a blink of an eye. »


Téléchargez le RFC 9432


L'article seul

Fiche de lecture : La baleine, une histoire culturelle

Auteur(s) du livre : Michel Pastoureau
Éditeur : Seuil
978-2-02-151688-3
Publié en 2023
Première rédaction de cet article le 29 mars 2024


Michel Pastoureau continue son exploration de l'histoire culturelle des animaux avec la baleine.

D'abord, une précision, c'est un livre d'histoire des mentalités, pas un livre de zoologie. Le terme « baleine », dans le passé, pouvait désigner beaucoup d'animaux qu'on n'appelerait pas « baleine » aujourd'hui. L'idée est de faire le tour, de l'Antiquité à nos jours, sur la vision que les humains ont de la baleine. C'est un animal qui, par sa taille, par le milieu jugé hostile où il vit et par le fait qu'il était très mal connu jusqu'au XIXe siècle, est un parfait support de fantasmes. En gros, jusqu'au XXe siècle, la baleine est monstrueuse, inquiétante, incarnation du Mal, puis elle change tout à coup ou, plutôt, la vision qu'on en a change et on se met à la considérer comme gentille, menacée, et digne d'être protégée (elle est, avec le panda, un des animaux iconiques des campagnes de protection de la nature).

Ce retournement est récent. Le christianisme voyait plutôt la baleine négativement (cf. l'aventure de Jonas, même si la Bible ne dit pas clairement si c'était une baleine, ou un très gros poisson). Les marins aimaient décrire les dangers terribles, et imaginaires, qu'elle faisait courir aux bateaux. Et bien sûr, Moby-Dick n'est pas un modèle de gentillesse, même si son chasseur ne vaut pas mieux. On l'a dit, ce livre est une histoire culturelle d'humains, donc toutes les projections n'ont pas grand'chose à voir avec les baleines réelles.

Ah, et le livre est magnifiquement illustré, les dessins médiévaux sont très bien reproduits, en grand et avec de belles couleurs (vous trouverez celui-ci p. 59). Inutile de rappeler que le réalisme n'était pas le principal souci des auteurs de ces dessins…

(Tiens, j'ai terminé ce livre juste avant de commencer la série télé danoise Trom, où la chasse à la baleine aux iles Féroé et les polémiques que cela suscite sont la toile de fond de l'intrigue policière.)


L'article seul

Fiche de lecture : ENIAC in action

Auteur(s) du livre : Thomas Haig, Mark Priestley, Crispin Rope
Éditeur : MIT Press
978-0-262-53517-5
Publié en 2016
Première rédaction de cet article le 25 mars 2024


Un passionnant livre détaillant l'histoire de l'ENIAC, l'un des premiers ordinateurs. Contrairement à beaucoup d'autres textes sur l'ENIAC, celui-ci est très détaillé techniquement et ne vous épargne pas les informations précises sur le fonctionnement de cette bête, notamment de ses débuts où la programmation se faisait en soudant et désoudant.

L'ENIAC a été largement traité dans de nombreux ouvrages et articles. De nombreux mythes et légendes ont été développés, malgré le fait qu'on dispose d'une quantité énorme d'informations de première main, accessible aux historiens (beaucoup plus que pour le Colossus, secret militaire et dont beaucoup de documents ont été détruits). Mais depuis ses débuts, l'ENIAC a été un objet médiatique, très publicisé (pendant la guerre, il n'était que confidentiel, pas secret, encore moins très secret, et il a été déclassifié tout de suite après la guerre). Résultat, tout le monde avait quelque chose à dire sur l'ENIAC.

Par exemple, alors que les premières histoires sur l'ENIAC ne mentionnaient que des hommes, on a vu plus récemment des histoires affirmer en sens inverse que tout avait été fait par des femmes, les six de l'ENIAC. Le récit désormais classique est qu'elles faisaient la programmation de l'ENIAC, les « inventeurs » classiques, Eckert et Mauchly ne s'occupant « que » du matériel. Écoutant pour la Nième fois cette affirmation lors d'un exposé au FOSDEM, je me suis demandé « mais ça voulait dire quoi, au juste, programmer sur l'ENIAC » et j'ai lu ce livre.

Plusieurs facteurs rendent compliqué de répondre à cette question : d'abord, comme le notent bien les auteurs du livre, l'ENIAC, qui a eu une durée de vie très longue (de 1945 à 1955, bien plus qu'un smartphone d'aujourd'hui), a beaucoup évolué, cet ordinateur unique, qui ne faisait pas partie d'une fabrication en série, était modifié en permanence. Ainsi, la question de savoir si l'ENIAC était une machine à programme enregistré (plutôt qu'une « simple » calculatrice où le programme était à l'extérieur) a plusieurs réponses possibles (« plutôt non » au début de sa carrière, « plutôt oui » à la fin). Et la façon de « programmer » l'ENIAC a donc beaucoup changé.

Ensuite, bien que l'ENIAC ait laissé une énorme pile de documentation (comme les journaux d'exploitation, qui étaient bien sûr entièrement papier) pour les historiens, tout n'a pas été décrit. Des interactions informelles entre les membres de l'équipe n'ont pas forcément laissé de trace. Plusieurs couples mari-femme travaillaient sur l'ENIAC (comme Adele et Herman Goldstine) et il n'est pas facile de séparer leurs contributions (à chaque époque, on a mis en valeur les contributions de l'une ou de l'autre, selon la sensibilité de l'époque).

Enfin, comme tout était nouveau dans cette machine, même les acteurs et les actrices du projet n'avaient pas toujours une vision claire. Même une distinction comme celle entre matériel et logiciel était loin d'être évidente à cette époque. Et la notion même de « programme » était floue. Les « six de l'ENIAC » avaient été embauchées comme « opératrices », plutôt à déboguer des programmes existants (la machine avait mauvais caractère et les bogues étaient souvent d'origine matérielle, un composant qui brûlait, et le déboguage nécessitait donc de fouiller dans les entrailles de la bête) avant que leur travail n'évolue vers quelque chose qui ressemblait beaucoup plus à la programmation actuelle (sans que leurs fiches de poste ne suivent cette évolution).

Et cette programmation, sur une machine qui était loin d'être bâtie sur un modèle en couches bien propre, nécessitait des compétences variées. Ainsi, à un moment, l'ENIAC a reçu des nouvelles mémoires, dites « lignes à retard », où une onde sonore était envoyée dans un tube de mercure. La lenteur des ondes sonores, comparée à la vitesse de l'électronique, faisait que cela permettait de mémoriser (mais pas pour toujours) une information. Comme la ligne à retard stockait plusieurs informations, et était strictement FIFO, l'optimisation du programme nécessitait de bien soigner l'ordre dans lequel on mettait les variables : il fallait qu'elles arrivent à la fin du tube pile au moment où le programme allait en avoir besoin. Le programmeur ou la programmeuse avait donc besoin d'une bonne connaissance du matériel et de la physique ! En lisant ce livre, on comprend mieux les exploits quotidiens que faisaient les « six de l'ENIAC » et leurs collègues.

Il y avait plein d'autres différences entre la programmation de l'époque et celle d'aujourd'hui. Par exemple, l'ENIAC manipulait des nombres décimaux (son successeur, l'EDVAC passera au binaire). Les débats étaient très vivants au sein de l'équipe sur la meilleure façon de dompter ces nouvelles machines. Ainsi, une discussion récurrente était de savoir s'il valait mieux une machine complexe sachant faire beaucoup de choses ou bien une machine simple, ne faisant que des choses triviales, mais optimisée et plus générale. La deuxième possibilité nécessitait évidemment que la complexité soit prise en charge par les programmes. Bref, un débat qui évoque beaucoup celui CISC contre RISC. Au milieu de tous ces débats, il peut être difficile de distinguer la contribution de chacun ou de chacune. Ainsi, on présente souvent von Neumann comme l'inventeur de l'ordinateur moderne à programme enregistré (et où le code est donc traité comme une donnée), dans son fameux first draft. mais d'autres témoins relativisent son rôle en estimant que le first draft ne faisait que documenter par écrit les idées qui circulaient dans l'équipe. Les auteurs du livre se gardent de trancher (la vérité peut aussi être quelque part entre les deux). Les éventuels désaccords de personnes compliquent aussi les choses, par exemple Adele Goldstine et les six de l'ENIAC n'ont pas vraiment les mêmes souvenirs sur la création de cette équipe et son rôle. (Contrairement à ce qui est parfois raconté, les six de l'ENIAC n'étaient pas des victimes passives du sexisme, et ont largement fait connaitre leurs souvenirs et leurs opinions, contrairement à ceux et celles de Bletchley Park, tenu·es à un secret militaire rigoureux, même longtemps après la guerre.)

Point amusant, l'ENIAC est entré en service à une époque où les concepts de la cybernétique étaient à la mode et cela a influencé le vocabulaire de l'informatique. Si le terme de « cerveau électronique », par lequel était souvent désigné l'ENIAC, n'est pas resté, c'est avec l'ENIAC qu'on a commencé à utiliser une autre métaphore humaine, « mémoire » pour parle des dispositifs de stockage de l'information et, là, ce terme a perduré.

Outre les passions humaines, l'histoire de l'ENIAC a aussi été brouillée par des conflits motivés par l'argent. Eckert et Mauchly avaient tenté d'obtenir un brevet sur les concepts de base de l'ENIAC et le long conflit juridique sur ce brevet (finalement refusé) a été marqué par de nombreux témoignages officiels devant les tribunaux, témoignages qui ont pu figer certains souvenirs en fonction d'intérêts financiers.

En tout cas, le débat sur le rôle des six de l'ENIAC a occulté le rôle d'une autre catégorie, bien oubliée (on ne connait même pas leurs noms), les Rosie qui ont bâti le monstre, un engin qui occupait une immense pièce et avait nécessité beaucoup de travail manuel, peu reconnu.

Les auteurs notent d'ailleurs que bien des débats en histoire ne peuvent pas avoir de réponse simple. Ainsi, la recherche effrénée du « premier » (l'ENIAC était-il le premier ordinateur ?) n'a pas forcément, notent-ils, de sens. Déjà, cela dépend de la définition qu'on donne d'« ordinateur », ensuite, certains concepts émergent petit à petit, sans qu'il y ait un « moment Eurêka » où tout se révèle d'un coup. (Pour prendre l'exemple d'une autre polémique classique dans l'histoire de l'informatique, se demander qui a inventé le datagramme n'a pas plus de sens. Le concept est apparu progressivement, sans qu'on puisse citer, par exemple, l'article ou la conférence qui l'aurait exposé en premier.)

Le livre se termine d'ailleurs par une « histoire de l'histoire » de l'ENIAC, qui montre les nombreuses évolutions qu'il y a eu, et qu'il continuera à y avoir, sur cette machine. Comme souvent l'histoire suit le présent (les motivations de son époque) plutôt que le passé.

Merci à Valérie Schafer pour le conseil de lire ce livre, tout à fait ce qu'il faut pour comprendre ce que voulait dire « programmer l'ENIAC ».


L'article seul

Fiche de lecture : Eaten by the Internet

Auteur(s) du livre : Ouvrage collectif, piloté par Corinne Cath
Éditeur : Meatspace Press
978-1-913824-04-4
Publié en 2023
Première rédaction de cet article le 22 mars 2024


Ce court livre en anglais rassemble plusieurs textes sur les questions politiques liées à l'Internet comme la défense de la vie privée, le chiffrement, la normalisation, etc.

Le livre est disponible gratuitement en ligne mais vous pouvez préférer l'édition papier, qui a une curieuse mise en page, avec une couverture qui se tourne dans un sens inhabituel et les appels des notes de bas de page joliment décorés.

Vous y trouverez de nombreux articles, tous écrits par des spécialistes de l'Internet (et j'ai bien dit l'Internet, pas les GAFA, vous n'aurez pas le Nième article sur les turpitudes de Facebook, encore moins sur les derniers exploits de l'IA). C'est très intéressant et couvre beaucoup de sujets, dont certains sont rarement traités (comme l'article de Shivan Kaul Sahib sur les conséquences politiques des CDN). Mais, vu la taille du livre et le nombre de contributions, cela reste peu approfondi, donc ce livre vise plutôt un public de débutant·es. (Si vous suivez ces questions depuis quelques années, vous avez certainement déjà rencontré ces auteur·es et leurs textes.)


L'article seul

Fiche de lecture : The Bomber Mafia

Auteur(s) du livre : Malcolm Gladwell
Éditeur : Penguin Books
978-0-141-99840-4
Publié en 2021
Première rédaction de cet article le 22 mars 2024


Le court livre « The Bomber Mafia » est l'histoire de la controverse technico-politique au sein de l'armée de l'air des USA, juste avant la Deuxième Guerre mondiale et pendant celle-ci : comment utiliser le mieux possible les bombardiers, peut-on forcer un ennemi à capituler en le bombardant et comment ?

Ce n'est pas une étude historique, plutôt un récit journalistique, centré sur deux personnes, Haywood Hansell et Curtis LeMay. Pour simplifier, le premier était un représentant d'un groupe surnommé The Bomber Mafia, qui avait une confiance illimitée dans les capacités des bombardiers à atteindre leur objectif, à le toucher avec précision, et ainsi à contraindre l'ennemi à capituler. Avant la deuxième guerre mondiale, leurs idées n'avaient pas vraiment été testées, et les adversaires de la Bomber Mafia lui reprochaient justement sa tendance à aborder les problèmes sous un angle trop théorique. LeMay, d'un autre côté, tout aussi convaincu de la puissance des bombardiers, et qui allait faire une belle carrière après la guerre, était plus pragmatique. Tous les deux s'opposaient sur la question de l'utilisation des B-17 et des B-29 mais, à ce conflit, se superposait aussi celui de tous les aviateurs (dont Hansell et LeMay) contre les autres branches de l'armée qui estimaient que ces jouets très chers ne gagneraient pas la guerre à eux seuls (« aucun soldat ne s'est jamais rendu à un avion »).

Au débat entre les « théoriciens » de la Bomber Mafia et les « praticiens », qui voyaient bien que les bombardements ne se passaient pas aussi bien que dans les théories d'avant-guerre, se superposait un débat moral, la Bomber Mafia estimant que le progrès technique permettait au bombardier de frapper avec une précision absolue, ce qui limitait les dégâts collatéraux, alors que ses adversaires, voyant bien la difficulté à mettre les bombes en plein sur l'objectif, dans un monde réel plein de nuages, d'appareils déréglés, et de vents puissants en altitude, voulaient plutôt bombarder largement, sans se soucier des conséquences, notamment sur les civils, voire en les ciblant délibérement.

Le livre détaille (c'est sa meilleure partie) le cas d'un appareil présenté comme magique, le viseur Norden, une incroyable merveille d'ingéniosité et de précision, contenant un calculateur analogique et qui devait permettre à l'homme chargé de déclencher le largage des bombes de mettre en plein dans le mille. Malgré les promesses boursouflées de l'inventeur (un classique de l'innovation technologique), malgré la fascination de beaucoup d'aviateurs pour cette très haute technologie, coûteuse et très secrète (l'équipage avait ordre de tout faire pour détruire le viseur si le bombardier tombait), le viseur Norden n'a jamais tenu ses promesses. Spectaculaire en laboratoire, il marchait nettement moins bien à plusieurs milliers de mètres d'altitude, dans le froid et la condensation, à bord d'un avion en mouvement. Son échec a beaucoup contribué à décrédibiliser la Bomber mafia et à donner raison à LeMay et à sa pratique d'un bombardement très étendu, d'autant plus que LeMay ne s'encombrait pas d'arguments moraux. Mais la Bomber Mafia n'a apparemment jamais admis que les faits étaient plus forts que sa théorie, trouvant toujours des moyens de dire que, cette fois, ça allait marcher comme ils le disaient.

L'auteur, qui a nettement tendance à présenter Hansell comme le bon et LeMay comme le méchant, alors que tous les deux étaient dans la même armée et poursuivaient le même but, estime que le temps a donné raison à la Bomber Mafia, puisque, le numérique ayant remplacé l'analogique, le drone moderne peut frapper avec une précision parfaite. Est-ce que les militaires d'aujourd'hui peuvent vraiment, en plein dans le brouillard de la guerre, frapper pile où ils veulent, sans dégâts collatéraux ?


L'article seul

La faille DNSSEC KeyTrap

Première rédaction de cet article le 19 mars 2024


Le 16 février a été publiée la faille de sécurité DNSSEC KeyTrap. Je sais, c'est un peu tard pour en parler mais c'est quand même utile, non ?

KeyTrap est une faille qui permet un déni de service contre des résolveurs DNS validants, c'est-à-dire qui vérifient les signatures cryptographiques de DNSSEC. Avec peu de messages DNS, parfois un seul, elle permet de stopper toute résolution de noms pendant des minutes, voire des heures. Comme souvent, hélas, en sécurité informatique, les découvreurs de la faille ont sérieusement abusé des grands mots dans leur communication (que les médias, comme d'habitude, ont bien relayés sans esprit critique) mais la faille est réelle et ils ont fait un bon travail pour la cerner exactement, et la reproduire afin de tester des remèdes.

Comment fonctionne KeyTrap ? Le point de départ est d'observer qu'un résolveur validant ne cherche pas à échouer dans la résolution de noms, il cherche à trouver, si nécessaire en insistant, un enregistrement correctement signé. Par exemple, si un des serveurs faisant autorité ne renvoie pas de signatures (il devrait), le résolveur va demander à un autre. Si une signature est invalide, le résolveur va en essayer d'autres. Cela part d'une bonne intention, éviter un échec des requêtes des clients. Mais cela ouvre la possibilité, pour un client malveillant, de donner beaucoup de travail au résolveur.

Le résolveur va essayer, pour chaque signature trouvée, toutes les clés cryptographiques présentes. En temps normal, il n'y a qu'une signature et une clé. Lors d'opérations comme le remplacement d'une clé, il peut y en avoir deux. Mais, et c'est le point important, ces nombres sont contrôlés par l'attaquant. S'il envoie dix clés et dix signatures, le résolveur aura cent vérifications à faire. Et si l'attaquant arrive à faire tenir cent clés et cent signatures dans le message, il faudra dix mille vérifications… Elles retiendront le résolveur pendant longtemps, l'empêchant de répondre aux autres requêtes (voire le bloquant complètement si ces vérifications ne sont pas réellement parallélisées).

Voyons maintenant quelques détails pratiques. D'abord, le résolveur ne va pas tester toutes les clés mais uniquement toutes celles qui ont l'identificateur, le keytag indiqué dans la signature. Si on trouve cette signature :


% dig +multi +dnssec brisbane.now.weather.dyn.bortzmeyer.fr TXT 
…
;; ANSWER SECTION:
brisbane.now.weather.dyn.bortzmeyer.fr.	1800 IN	TXT "Brisbane" "Partly cloudy" "27.0 C" "precipitation 0.17 mm" "wind 11.2 km/h" "cloudiness 25 %" "humidity 70 %"

brisbane.now.weather.dyn.bortzmeyer.fr.	1800 IN	RRSIG TXT 8 6 1800 (
				20240323040000 20240318154000 63937 dyn.bortzmeyer.fr.
				gUXD/SnFywfzQVRstRH9t5k6DIGXLHUeuSgM8ShNfTUx
… 
   
  

Alors, il n'est pas nécessaire d'essayer toutes les clés mais seulement celle(s) qui ont un identificateur (keytag ou key id) de 63937 (il est indiqué dans la signature, après les dates). Ce système est censé limiter le travail du résolveur. Si un attaquant envoie cent clés, une seule sera utilisée. Mais, car il y a un mais, ce keytag ne fait que deux octets (donc les collisions sont relativement fréquentes) et surtout, ce n'est pas un condensat cryptographique sûr, comme par exemple SHA-256. Il est facile pour un attaquant de générer cent clés ayant le même keytag et celui-ci ne sert alors plus à rien, le malheureux résolveur doit essayer toutes les clés.

Autre problème, pour l'attaquant (qui veut évidemment faire le plus de mal possible), la taille de la réponse. En UDP, un client DNS typique ne va pas accepter des réponses de plus de 4 096 octets, voire souvent 1 460 octets. Comme l'attaquant veut fourrer le plus grand nombre possible de clés et de signatures dans sa réponse, il a intérêt à utiliser les algorithmes à courbes elliptiques, comme ECDSA, dont les clés et les signatures sont bien plus petites qu'avec RSA.

Maintenant, quelles sont les solutions ? Le rapport sur KeyTrap est plein de phrases boursouflées comme « Solving these issues fundamentally requires to reconsider the basics of the design philosophy of the Internet. » C'est évidemment faux. Il faut simplement limiter le nombre d'opérations et/ou le temps passé. C'est une nécessité général du DNS, bien antérieure à KeyTrap. Le RFC 1035, en 1987, disait déjà « The amount of work which a resolver will do in response to a client request must be limited to guard against errors in the database, such as circular CNAME references, and operational problems, such as network partition which prevents the resolver from accessing the name servers it needs. While local limits on the number of times a resolver will retransmit a particular query to a particular name server address are essential, the resolver should have a global per-request counter to limit work on a single request. ». L'oubli de ce paragraphe a déjà mené à des possibilités d'attaque par déni de service comme l'attaque infinie, iDNS. La solution est donc évidente, limiter le nombre de vérifications. Il y a une part d'arbitraire dans cette limite (stopper au bout de trois clés ? de quatre ?) mais il est clair qu'il n'y a aucune raison légitime de vérifier cent clés. C'est la modification qui a été faite dans tous les résolveurs.

Noter que, pour l'exploitation de cette faille, il faut pouvoir parler au résolveur, pour lui demander de résoudre un nom dans le domaine contrôlé par l'attaquant, domaine qu'il aura rempli de clés et de signatures. C'est évidemment facile pour un résolveur public, et pas trop difficile pour les gros FAI, mais plus compliqué pour des petits résolveurs locaux. Donc, tout résolveur validant était plus ou moins menacé. Ceci dit, tous les logiciels ont été patchés très vite et tous les administrateurs système sérieux ont déjà appliqué les patches.

Notez que cette attaque ne remet pas en cause l'importance de DNSSEC. Toute technique de sécurité peut être (plus ou moins facilement) détournée pour en faire une attaque par déni de service.

Quelques lectures :


L'article seul

IETF 119 hackathon: compact denial of existence for DNSSEC

First publication of this article on 18 March 2024
Last update on of 22 March 2024


On March 16 and 17 was the IETF hackathon in Brisbane. I worked on a DNSSEC feature called "compact denial of existence", and implemented it successfully (which was easy).

Compact Denial of Existence (CDE) was originally called "black lies". The name was changed, probably because of some typical US issue with every adjective of color, but also because there was a risk of confusion with lying DNS resolvers, which are something quite different. What is its purpose? For DNSSEC, you have to sign your records. You can do it offline, on a primary name server (the records and the signatures are then transferred to other authoritative name servers), or online, in every authoritative name server. The first method is more secure (you don't need the private key on every authoritative name server) and uses less CPU resources but it is not usable if you have very dynamic content, generated at every request. For this kind of content, you need online signing.

Online signing of records does not raise any particular issue. The difficulty starts with denial of existence, when you want to sign a statement that a name, or a specific record type does not exist. In that case, you have no data to sign. DNSSEC has several ways to deal with that and the simplest is NSEC records. They are records created to say "there is no name between this one and that one". Let's query a root name server to see these NSEC records:

    
% dig +dnssec @d.root-servers.net doesnotexist
…
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26586
…
;; AUTHORITY SECTION:
doctor.			86400	IN	NSEC	dog. NS DS RRSIG NSEC
doctor.			86400	IN	RRSIG	NSEC 8 1 86400 20240330170000 20240317160000 30903 . hZ08T19claSr8ZkU
…

  

You get a NXDOMAIN (No Such Domain), obviously, and a NSEC record (more than one, actually, but I make things simple, but see later), which says that there is no TLD between .doctor and .dog. This NSEC record is signed, proving that .doesnotexist does not exist.

When signing a complete zone, creating the NSEC records is easy. But if we generate DNS content dynamically, it is more tricky. The DNS server, when signing, does not always know the previous name and the next name, it may not have a complete view of the zone. A trick for dynamic signing was named "white lies" and documented in RFC 4470. The idea is to generate dynamically a NSEC with a previous name and a next name both very close from the requested name. Something like (this is a real domain, you can try it yourself):


% dig +multi +dnssec +noidnout doesnotexist.dyn.bortzmeyer.fr
…
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61681
…
;; AUTHORITY SECTION:
~.doesnotexiss~.dyn.bortzmeyer.fr. 0 IN	NSEC doesnotexist!.dyn.bortzmeyer.fr. RRSIG NSEC
~.doesnotexiss~.dyn.bortzmeyer.fr. 0 IN	RRSIG NSEC 8 5 0 (
…

  

The names ~.doesnotexiss~.dyn.bortzmeyer.fr and doesnotexist!.dyn.bortzmeyer.fr were choosen to be close enough of the requested name. This is not the exact algorithm of RFC 4470 because I had problems with some resolvers but the general idea is the same. (Also, +noidnout was added because dig has some ideas about what is a displayable domain name. There are no IDN involved.) Here is how Drink, the dynamic name server used in the hackathon, written in Elixir, did the "white lies" trick:


previous = Drink.Dnssec.previous_name(domain)
nsec = %DNS.Resource{class: :in,
                     domain: to_charlist(DomainName.name(previous)), 
                     type: @nsec,
		     data: Drink.Dnssec.nsec(domain, is_base)} 

  

Now, what is the problem with this way of generating dynamic NSEC records? I said before that you actually need two (and sometimes three) NSEC records because you also need to prove that the name could not have been generated by a wildcard. Each NSEC will require computation for its signature and, since all of this is done in real-time, we wish to minimize the number of computations (and the size of the response). Hence the Compact Denial of Existence (CDE, formerly known as "black lies"). The idea is to have a NSEC record which does not go from "a name just before" to "a name just after" but from "the requested name" to "a name just after". This way, you no longer need to prove there was no wildcard since you do not claim the name does not exist. (And this could be called a lie, but, since it is done by the authoritative name server which, by definition, tells the truth, the term is better left unused.) But it has an important consequence, the response code must now be NOERROR and not NXDOMAIN, obscuring the fact that the name does not "really" exist (something that some people at the IETF did not like). Here is the result, as produced by Cloudflare name servers:


% dig +multi +dnssec @ns4.cloudflare.com doesnotexist.cloudflare.com 
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43367
…
;; AUTHORITY SECTION:
doesnotexist.cloudflare.com. 300 IN NSEC \000.doesnotexist.cloudflare.com. RRSIG NSEC TYPE65283
cloudflare.com.		300 IN RRSIG SOA 13 2 300 (
…

As you can see, the left-hand part of the record (the "owner name", doesnotexist.cloudflare.com) is now set to the requested name. And the return code is NOERROR, with no data returned in the Answer section. The response says that the name exists, but only with RRSIG, NSEC and TYPE65283 - more on this one later - records.

It should be noted that any ordinary, unmodified, validating resolver will have no problem with this response. It will be validated. CDE does not require any change to the resolver. Also, checking tools like DNSviz and Zonemaster will see no problem. CDE can be deployed unilaterally, and this is exactly what Cloudflare did.

So, as we saw, CDE is not new, even if it is not described in any RFC. It is already deployed (remember that the Internet is permissionless: you do not need a RFC to implement and deploy a technology). But what IETF is currently working one is precisely a specification of this technique. The project is currently an Internet-Draft, draft-ietf-dnsop-compact-denial-of-existence. This draft describes the basic technique for generating the unique NSEC record and adds:

  • In the list of record types that are present at the requested name (the "NSEC bitmap"), a pseudo-type NXNAME, signaling that the NOERROR return code is actually a NXDOMAIN. It is not officially allocated today and implementations use a value reserved for experimentations, 65283 (hence the TYPE65283 above). This can be used by resolvers to restore the NXDOMAIN from the response so that their clients will have a proper error code.
  • EDNS signaling that the client understands compact answers and can receive a NXDOMAIN, it won't be surprised to see the NSEC claiming that the name does not exist. This signaling is done with a bit called CO (for Compact OK).

During the IETF hackathon, two authoritative name servers were modified to generate CDE:

  • adns_server, written in Python.
  • Drink, written in Elixir. The code is currently in a separate branch, compact-denial (if you retrieved the code with git, git diff -u -r master -r compact-denial will give you the code written during the hackathon).

In both cases, the work was simple and fast: once you have dynamic signing (it was already in Drink), CDE is simpler than white lies. The two servers also implemented the NXNAME reporting and accept the signaling via the CO bit. Here is the result with Drink (this test domain was created for the hackathon, and no longer works):


% dig +dnssec +multi nonono.ietf.bortzmeyer.fr TXT
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49495
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
…
nonono.ietf.bortzmeyer.fr. 0 IN NSEC \000.nonono.ietf.bortzmeyer.fr. \
      RRSIG NSEC TYPE65283

nonono.ietf.bortzmeyer.fr. 0 IN RRSIG NSEC 8 4 0 (
                                20240321040000 20240316154000 43304
                                ietf.bortzmeyer.fr. …
…

As of today, no real resolver has been modified to implement NXDOMAIN restoration and/or EDNS wignaling with CO. This is not mandatory, but would be cool. Zonemaster was happy and so was DNSviz : dnsviz-test-cde-hackathon.png

As usual, the hackathon pinpointed some issues that were not always noticed before:

  • Since the draft says that explicit requests for a NXNAME record are forbidden, which error code should be returned and, if using EDE (Extended DNS Errors, RFC 8914), which EDE? (Actually, the problem is larger than just CDE since it seems that the replies to requests of pseudo-types - those between 128 and 255 - are underspecified. May be another work to start.)
  • When a DNS client does not set the DO bit, indicating it does not know about DNSSEC, should we return NXDOMAIN, forgetting about CDE, like most implementations do, or should we return NOERROR, as if the DO bit were set?
  • This is not only about the non-DNSSEC clients: some people are not happy that, by conflating NXDOMAIN and NOERROR, we lose information, and that will make debugging more difficult (unless you have a NXDOMAIN-restoring resolver, which does not exist today). It is important to remember that it is not because something is simple to implement and works, that it is a good idea.

Thanks to Shumon Huque for code, conversation and explanations.


L'article seul

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 (ça l'est devenu le 27 mars 2024, suite à ce problème) 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.