Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.
Fiche de lecture : Obfuscation; A User's Guide for Privacy and Protest
Auteur(s) du livre : Finn Brunton, Helen
Nissenbaum
Éditeur : MIT Press
978-0-262-02973-5
Publié en 2015
Première rédaction de cet article le 17 mai 2020
Beaucoup d'efforts sont aujourd'hui dépensés pour protéger la vie privée sur l'Internet. En effet, le déploiement des réseaux informatiques a permis une extension considérable de la surveillance, privée comme étatique. Il est donc logique que des informaticiens cherchent à développer des moyens techniques pour gêner cette surveillance, moyens dont le plus connu est le chiffrement. Mais aucun moyen technique ne résout tous les problèmes à lui seul. Il faut donc développer une boîte à outils de techniques pour limiter la surveillance. Ce court livre est consacré à un de ces outils : le brouillage (obfuscation en anglais). Le principe est simple : le meilleur endroit pour cacher un arbre est au milieu d'une forêt.
Le principe du brouillage est en effet simple : introduire de fausses informations parmi lesquelles les vraies seront difficiles à trouver. Cette technique est surtout intéresssante quand on ne peut pas se dissimuler complètement. Par exemple, le logiciel TrackMeNot (dont une des développeuses est une des auteures du livre) envoie des recherches aléatoires aux moteurs de recherche. On ne peut pas empêcher ces moteurs de recherche de connaître nos centres d'intérêt, puisqu'il faut bien leur envoyer la question. Le chiffrement n'aide pas ici, puisque, s'il peut protéger la question sur le trajet, il s'arrête au serveur à l'autre extrémité. Mais on peut noyer ces serveurs sous d'autres requêtes, qu'ils ne pourront pas distinguer des vraies, brouillant ainsi l'image qu'ils se font de l'utilisateur.
À ma connaissance, il n'existe pas de traduction idéale du terme anglais obfuscation, qui est le titre de ce livre. Wikipédia propose offuscation, ce qui me fait plutôt penser à « s'offusquer ». À propos de français, notez qu'il existe une traduction de ce livre, « Obfuscation ; La vie privée, mode d'emploi » (avec préface de Laurent Chemla), chez C&F Éditions, mais je n'ai personnellement lu que la version originale.
Les techniciens ont facilement tendance à considérer comme
technique de protection de la vie privée le seul
chiffrement. Celui-ci est évidemment
indispensable mais il ne protège pas dans tous les cas. Deux
exemples où le chiffrement ne suffit pas sont l'analyse de trafic,
et le cas des GAFA. D'abord, l'analyse de
trafic. C'est une technique couramment utilisée par les
surveillants lorsqu'ils n'ont pas accès au contenu des
communications mais seulement aux
métadonnées. Par exemple, si on sait que A
appelle B, et que, dès que ça s'est produit, B appelle C, D et E, on
a identifié un réseau de personnes, même si on ne sait pas ce
qu'elles racontent. Et un autre cas est celui des
GAFA. Si la communication avec, par exemple,
Gmail, est chiffrée (le
https:// dans l'URL, qui indique que tout se passe en
HTTPS, donc chiffré), cela ne protège que contre
un tiers qui essaierait d'écouter la communication, mais pas contre
Google lui-même, qui voit évidemment tout en clair. Bref, le
chiffrement n'est pas une solution miracle. Dans ce second cas, une
autre solution pourrait être de dire « n'utilisez pas ces outils du
capitalisme de surveillance, n'utilisez que des services libres et
sans captation des données personnelles ». À long terme, c'est en
effet l'objectif. Mais à court terme, les auteurs du livre estiment
(et je suis d'accord avec eux) qu'il n'est pas réaliste de demander
cette « déGAFAisation
individuelle ». Comme le notent les auteurs p. 59
« Martyrdom is rarely a productive choice in a political
calculus ».
Le livre contient plein d'exemples de brouillage, car la technique est ancienne. Quand on ne peut pas cacher, on brouille. Des paillettes qui font croire à la défense anti-aérienne qu'il y a plein d'avions supplémentaires, au génial film de Spike Lee, Inside Man (non, je ne vais pas divulgâcher, regardez le film), les exemples ne manquent pas. Cette technique a été largement utilisée en informatique, et le livre comprend une passionnante description de l'opération Vula, où il ne fallait pas simplement dissimuler le contenu de la communication, mais également le fait qu'elle avait lieu, ce qui est bien plus difficile. Et les auteurs savent de quoi il parle puisqu'Helen Nissenbaum a également travaillé sur Ad Nauseam, un logiciel qui clique sur toutes les publicités, pour empêcher la surveillance (dont la publicité est à la fois l'un des moteurs importants et l'une des armes favorites) de savoir si les publicités sont efficaces ou pas.
Outre cette très intéressante partie sur les exemples réels (dans le monde de l'informatique, et en dehors), l'intéret du livre est une discussion détaillée de la légitimité du brouillage. Est-ce bien ou mal de « cliquer » sur les publicités, privant ainsi une profession honorable des informations sur la vie privée des utilisateurs (pardon, les pubards les appellent les « cibles ») ? Les auteurs insistent que le brouillage est l'arme du faible. Les riches et les puissants peuvent se cacher, ou échapper à la surveillance, le brouillage est pour ceux et celles qui ne peuvent pas se cacher. C'est cette asymétrie qui est le principal argument en faveur de la légitimité du brouillage (p. 78).
Et le problème écologique ? Le brouillage consomme davantage de ressources, c'est sûr. La question est suffisamment sérieuse pour faire l'objet d'un traitement en détail dans le livre (p. 65), je vous laisse découvrir la discussion dans le livre.
Ceci dit, de même que le chiffrement n'est pas la seule technique à utiliser dans la lutte pour préserver sa vie privée (p. 62), de la même façon, il ne faut pas penser qu'aux solutions techniques. Ne pourrait-on pas compter sur la bonne volonté des entreprises privées, pour qu'elles arrêtent la surveillance ? (p. 60, les auteurs expliquent pourquoi ils n'y croient pas.) Et, sinon, sur les États pour arrêter cette surveillance par la loi ? (p. 61, les auteurs sont pessimistes à ce sujet.)
Enfin, le livre compte aussi d'autres discussions passionnantes, mais je vous laisse les découvrir. Bonne lecture ! (Et, après, il y a une grosse bibliographie, si vous voulez approfondir.)
L'article seul
Supervision répartie sur plusieurs sites avec Icinga
Première rédaction de cet article le 16 mai 2020
De nos jours, quand on est un ou une ingénieur système responsable d'un service Internet un peu sérieux, on a une supervision automatique du service, pour être prévenu des pannes avant de se faire engueuler sur Twitter. C'est classique et cela va se soi, d'autant plus qu'il existe de très nombreux logiciels libres pour cette tâche (j'utilise Icinga). Mais, souvent, les tests sont faits depuis un seul point, en général dans les locaux de l'organisation qui gère le service. C'est insuffisant car, l'Internet étant ce qu'il est, les problèmes peuvent dépendre du point de mesure. Il existe plusieurs solutions pour faire de la supervision répartie sur plusieurs points, je vais parler ici du système maîtres/satellites/agents d'Icinga.
Pour illustrer cette histoire de supervision depuis plusieurs points, je prendrai comme exemple le système de répartition d'Icinga. Ce système est souvent présenté uniquement comme un moyen de répartir la charge entre plusieurs machines. Mais il a une bien plus grande utilité : permettre de voir la connectivité ou les données depuis plusieurs points de l'Internet. En effet, bien des choses dépendent d'où on est dans l'Internet. Un problème de routage ne va frapper que certains AS. Un « trou noir » annoncé à tort ne va capter qu'une partie du trafic. L'anycast va vous diriger vers un serveur différent (et potentiellement à problèmes) selon votre point de départ. Pour toutes ces raisons, il est crucial aujourd'hui d'avoir une supervision largement répartie. (Une autre utilité est la possibilité de superviser des choses purement locales à la machine, comme l'occupation de l'espace disque, comme on faisait autrefois avec NRPE.)
Commençons par la documentation d'Icinga, très détaillée. Elle n'est pas d'un abord facile, car il existe plusieurs façons de configurer sa supervision répartie. Personnellement, j'ai choisi un mode simple, avec une seule machine maîtresse (Master), plusieurs machines agentes (Agent), et pas de satellite. J'ai configuré de façon à ce que ce soit toujours le maître qui contacte les agents (ce qui simplifie les configurations des pare-feux), mais Icinga permet également la connexion en sens opposé (ce qui peut être utile si c'est le maître qui est un serveur public, et l'agent qui est coincé derrière du NAT), voire dans les deux sens. Et j'ai choisi de centraliser la configuration sur le maître, les agents n'ont aucune initiative, ils ne font qu'exécuter ce qu'a décidé le maitre. (Mais rappelez-vous qu'Icinga offre de nombreuses autres possibilités, et c'est une des raisons pour lesquelles la documentation est assez touffue.)
Il faut installer Icinga sur chaque machine, maître ou agent. Il n'y a pas de logiciels séparés pour les deux rôles (contrairement avec ce qui se fait chez, par exemple, Zabbix), c'est le même Icinga.
La configuration initiale peut se faire très simplement avec le Icinga 2 Setup Wizard (je donne un exemple plus loin) mais je vais d'abord montrer comment le faire à la main. Un petit mot sur la sécurité, d'abord : la communication entre les machines Icinga est protégée par TLS et il nous faut donc un certificat valable sur chaque machine. Comme certaines ne sont pas visibles depuis l'Internet, utiliser Let's Encrypt n'aurait pas forcément été pratique (oui, il y a des solutions, je sais, mais que je trouvais compliquées, dans mon cas). J'ai donc choisi de faire gérer tous les certificats par CAcert. Comme il ne s'agit que de machines que je contrôle, l'obligation d'ajouter le certificat de CAcert au magasin d'AC n'est pas un problème.
Une note sur le nom des fichiers de configuration. Icinga permet
d'inclure depuis le fichier de configuration principal d'autres
fichiers, et cela peut même être récursif
(include_recursive "conf.d"). Vous pouvez donc
choisir l'organisation que vous voulez pour vos fichiers de
configuration. Ici, j'ai choisi celle qu'a par défaut le
paquetage
Debian. Quant aux noms de domaine, j'ai tout mis sous
foobar.example, la zone du maître étant
icinga-master.foobar.example.
Bon, d'abord la configuration du maître. Il faut un fichier de
configuration zones.conf où on déclare les
agents à contacter (rappelez-vous que j'ai choisi une configuration
où c'est toujours le maître qui contacte l'agent) :
const NodeName = "icinga-master.foobar.example"
const ZoneName = "icinga-master.foobar.example"
// Dans le cas le plus simple, il y a une zone par machine.
object Zone ZoneName {
endpoints = [ NodeName ]
}
// La machine maîtresse
object Endpoint NodeName {
}
// Un des agents
object Endpoint "bellovese.foobar.example" {
host = "bellovese.foobar.example" // Nécessaire pour pouvoir le
// contacter, ça pourrait être une adresse IP.
}
// L'agent fait confiance à la machine maîtresse (la directive "parent")
object Zone "bellovese.foobar.example" {
endpoints = [ "bellovese.foobar.example" ]
parent = ZoneName
}
// La configuration qui sera poussée vers les agents
object Zone "global-templates" {
global = true
}
On crée ensuite un répertoire zones.d où on va
placer ce qui concerne la configuration des agents. Il y aura les
gabarits communs à tous les agents. Ici, la partie qui permettra de
faire des ping à distance :
% cat zones.d/global-templates/templates.conf
template Host "remote-host" {
vars.ping_wrta = 300
vars.ping_crta = 600
...
}
...
Avec cette configuration, qui sera poussée vers les agents, tous testeront avec les mêmes paramètres. Autre cas dans ce fichier des gabarits communs, la supervision du démon OpenDNSSEC, qui n'est pas accessible de l'extérieur :
% cat zones.d/global-templates/templates.conf
...
object CheckCommand "opendnssec" {
command = [ PluginContribDir + "/check_opendnssec" ]
arguments = {
"-e" = "$opendnssec_enforcer_expect$",
"-s" = "$opendnssec_signer_expect$"
}
}
apply Service "remote-opendnssec" {
import "generic-service"
check_command = "opendnssec"
assign where host.vars.opendnssec
}
Avec cela, toute machine où la variable
opendnssec a été définie sera testée (on va vérifier
que le démon tourne bien).
Ça, c'était la configuration globale, commune à tous les
agents. Ensuite, pour chaque agent, on va mettre une configuration
spécifique, sous, par exemple,
zones.d/nom-de-l-agent.conf, avec des choses
comme :
object Host "test-bellovese" {
import "remote-host"
address = "bellovese.foobar.example"
address6 = "bellovese.foobar.example"
}
qui fera que l'agent testera la machine
bellovese.foobar.example avec le gabarit
remote-host commun.
Il reste à créer un certificat :
[Choisir éventuellement des options OpenSSL] % openssl req -new -nodes [Répondre aux questions d'OpenSSL, notamment :] Server name []:icinga-master.foobar.example
et à le faire signer par l'AC. Puis on concatène les deux certificats de l'AC :
# cat /usr/share/ca-certificates/CAcert/root.crt /usr/share/ca-certificates/CAcert/class3.crt > /var/lib/icinga2/certs/ca.crt
Et on
met les certificats en
/var/lib/icinga2/certs, aussi bien celui de la
machine maître que celui de l'AC (ici,
CAcert) ;
# ls -l /var/lib/icinga2/certs total 16 -rw-rw---- 1 nagios nagios 5179 Jun 7 2018 ca.crt -rw-rw---- 1 nagios nagios 1875 Jan 7 09:44 icinga-master.foobar.example.crt -rw-rw---- 1 nagios nagios 1704 Jun 7 2018 icinga-master.foobar.example.key
On peut maintenant tester la configuration, avant de redémarrer Icinga :
# icinga2 daemon -C ... [2020-05-15 12:49:18 +0000] information/cli: Finished validating the configuration file(s).
C'est parfait, on redémarre le maître avec sa nouvelle configuration :
# systemctl restart icinga2
Mais les agents, eux, ne sont pas encore configurés et ne vont pas répondre aux demandes du maître. Configurons donc le premier agent. D'abord, activer l'API (on ne le fait pas sur le maître puisqu'on a choisi une configuration où c'est toujours le maître qui se connecte aux agents, jamais le contraire) :
# icinga2 feature enable api
Et n'oublions pas d'ajouter dans
features-available/api.conf :
object ApiListener "api" {
...
accept_config = true
accept_commands = true
Et dans le zones.conf de l'agent, on va
indiquer qui est le maître et donc à qui faire confiance
(l'authentification sera faite via les certificats, dans la session TLS) :
// Moi (l'agent)
object Endpoint NodeName {
host = NodeName
}
object Zone ZoneName {
endpoints = [ NodeName ]
parent = "icinga-master.foobar.example"
}
// Mon maître
object Endpoint "icinga-master.foobar.example" {
}
object Zone "icinga-master.foobar.example" {
endpoints = [ "icinga-master.foobar.example" ]
}
object Zone "global-templates" {
global = true
}
Ensuite, on crée des certificats pour l'agent, on les fait signer par l'AC CAcert et on les installe.
Comme avec le maître, on teste la configuration avec
icinga2 daemon -C et on redémarre Icinga. Comme
l'API a été activée, on doit voir Icinga écouter sur le réseau :
# lsof -i:5665 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME icinga2 21041 nagios 14u IPv4 261751305 0t0 TCP *:5665 (LISTEN)
Pour tester qu'Icinga écoute bien, et en TLS, essayons depuis le maître :
% gnutls-cli bellovese.foobar.example:5665 ... - Server has requested a certificate. ... - Certificate[0] info: - subject `CN=bellovese.foobar.example', issuer `CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc.', serial 0x52cf13, RSA key 2048 bits, signed using RSA-SHA512, activated `2020-02-12 14:00:50 UTC', expires `2022-02-11 14:00:50 UTC', pin-sha256="sAA...=" ... - Status: The certificate is trusted. - Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
Si cette connexion TCP plus TLS ne fonctionne pas, c'est peut-être un problème de réseau et/ou de pare-feu. À vous de déboguer !
Maintenant que l'agent fonctionne, on dit au maitre de s'y
connecter. Dans le zones.conf du maître :
object Zone "bellovese.foobar.example" {
endpoints = [ "bellovese.foobar.example" ]
parent = ZoneName
}
Et, toujours sur le maître, dans le fichier qui sert à configurer ce qu'on supervise sur cette machine :
object Host "bellovese" {
...
vars.client_endpoint = "bellovese.foobar.example"
zone = "icinga-master.foobar.example"
Et on crée sur le maitre un fichier
zones.d/bellovese.conf pour indiquer
ce qu'on veut faire faire à l'agent. Par exemple :
object Host "test-segovese" {
vars.outside = true
import "remote-host"
address = "segovese.foobar.example"
address6 = "segovese.foobar.example"
}
object Host "bellovese-opendnssec" {
import "generic-host"
check_command = "remote_always_true"
vars.opendnssec = true
vars.opendnssec_signer_expect="There are 7 zones configured"
vars.opendnssec_enforcer_expect="bortzmeyer\\.org"
}
La première directive object Host dit à l'agent
de tester la machine segovese.foobar.example (ce qui
donnera un point de vue différent du maître, si l'agent est situé
dans un autre réseau). La deuxième directive dit
que bellovese est un site
OpenDNSSEC et qu'on veut donc surveiller que
les deux démons OpenDNSSEC tournent bien (ils
ne sont pas accessibles de l'extérieur, il faut donc un agent Icinga
sur cette machine).
Maintenant que maître et agent sont prêts, la connexion devrait se faire, ce qu'on peut voir dans le journal, ici celui du maître :
May 15 13:52:48 ambigat icinga2[31436]: [2020-05-15 13:52:48 +0000] information/ApiListener: Finished syncing runtime objects to endpoint 'bellovese.foobar.example'.
On aurait aussi pu faire la configuration avec le wizard. Voici un exemple où on configure le maître :
# icinga2 node wizard
Welcome to the Icinga 2 Setup Wizard!
...
Please specify if this is a satellite setup ('n' installs a master setup) [Y/n]: n
Starting the Master setup routine...
Please specify the common name (CN) [ambigat]: icinga-master.foobar.example
...
information/cli: Dumping config items to file '/etc/icinga2/zones.conf'.
...
information/cli: Updating constants.conf.
...
Done.
Now restart your Icinga 2 daemon to finish the installation!
Et pour configurer un agent :
# icinga2 node wizard
Welcome to the Icinga 2 Setup Wizard!
...
Please specify if this is a satellite setup ('n' installs a master setup) [Y/n]: y
Starting the Node setup routine...
Please specify the common name (CN) [sumarios]: sumarios.foobar.example
Please specify the master endpoint(s) this node should connect to:
Master Common Name (CN from your master setup): icinga-master.foobar.example
Do you want to establish a connection to the master from this node? [Y/n]: n
...
Connection setup skipped. Please configure your master to connect to this node.
...
Bon, si tout va bien, les tests sont maintenant exécutés par
les agents et vous pouvez voir les résultats dans l'interface Web
ou en ligne de commande via l'API. Mais si
ça ne marche pas ? On a vu que la configuration d'Icinga était
complexe, et la documentation pas toujours d'un abord
facile. Alors, voyons maintenant le déboguage des
problèmes. D'abord, et avant tout, si ça ne marche pas, il faut
évidemment regarder le journal
(journalctl -t icinga2 -f -n avec systemd). Par
exemple, ici, on voit que le maître ne peut pas se connecter à
l'agent, car le certificat de ce dernier a expiré :
Feb 12 14:00:41 ambigat icinga2[31333]: [2020-02-12 14:00:41 +0000] warning/ApiListener: Certificate validation failed for endpoint 'comrunos.foobar.example': code 10: certificate has expired
De la même façon, si vous voyez des tests qui restent
désespérément affichés dans l'état pending sur
le maître, le journal de l'agent pourra vous renseigner sur ce
qui se passe. Il peut, par exemple, manquer une commande externe (execvpe(/usr/local/lib/nagios/plugins/check_whichasn) failed: No such file or directory).
La panne peut être aussi due à une mauvaise configuration dans le
zones.conf de l'agent, par exemple l'oubli de
la directive parent. Autre cas, si vous
trouvez des messages comme :
warning/ApiListener: Ignoring config update. 'api' does not accept config.
c'est que vous avez oublié accept_config =
true dans
features-available/api.conf.
Si le journal par défaut n'est pas suffisant, vous pouvez
aussi rendre Icinga bien plus bavard. Vérifiez que
debuglog est bien activé :
# icinga2 feature list
Disabled features: compatlog elasticsearch gelf graphite icingastatus influxdb livestatus opentsdb perfdata statusdata syslog
Enabled features: api checker command debuglog ido-pgsql mainlog notification
Ou, s'il ne l'est pas, activez-le avec icinga2 feature
enable debuglog et configurez dans
features-available/debuglog.conf. Par
exemple, cette configuration :
object FileLogger "debug-file" {
severity = "debug"
path = LogDir + "/debug.log"
}
Va vous produire un debug.log très bavard.
L'article seul
StopCovid : une « éthique de la responsabilité ? »
Première rédaction de cet article le 12 mai 2020
Dans le dernier numéro du magazine « La Recherche », Jean-Gabriel Ganascia, président du comité d'éthique du CNRS, parle des applications de suivi de contacts en estimant que « la surveillance de la pandémie demande une éthique de responsabilité ».
Dans chaque numéro de ce mensuel, Jean-Gabriel Ganascia tient une chronique sur l'éthique. Dans le numéro 559 de mai 2020, il parle des applications de suivi de contacts comme l'hypothétique StopCovid, qui a suscité pas mal de discussions, sur divers points. Ici, un seul point est discuté : les risques que fait peser StopCovid sur la vie privée. (Sur le même thème, il a également donné un interview à France Info. Notez que StopCovid pose bien d'autres questions que la vie privée.)
L'argument principal de Jean-Gabriel Ganascia est présenté sous un angle philosophique. Il rappelle qu'il y a deux grands courants en éthique, qu'il nomme « éthique de conviction » et « éthique de responsabilité ». L'éthique de conviction fait passer le respect des principes avant tout. Mentir, c'est mal, donc on ne ment pas, même pour, par exemple, sauver une vie. L'éthique de responsabilité, également appelée « conséquentialisme », s'attache surtout aux conséquences des actes, pour juger s'ils étaient éthiques ou pas. Envahir un pays pour en chasser un dictateur brutal peut être considéré comme éthique, même si on juge la guerre mauvaise. Évidemment, ces deux courants sont ici présentés sous leur forme extrême. On pourrait les caricaturer (par exemple en disant que l'éthique de responsabilité mène au « qui veut la fin veut les moyens ») mais, en pratique, la plupart des gens sont situés quelque part entre les deux. Ici, Jean-Gabriel Ganascia présente les gens qui s'opposent à StopCovid au nom de la défense de la vie privée comme partisans d'une éthique de conviction extrême (« dogmatique »), et il les accuse de « [risquer] une nouvelle flambée de l'épidémie qui causerait des dizaines, voire des centaines de milliers de morts ». Il prône donc une éthique de la responsabilité, qui ferait passer la vie privée après, au nom des conséquences positives du suivi des contacts. (« Ces craintes [...] doivent, dans la période actuelle, être mises en regard des autres enjeux ».)
Le principal problème que je vois avec cette prise de position n'est pas sur le principe : je ne suis pas un moraliste pur, qui voudrait que les principes comme la défense de la vie privée aient le pas sur tout (il parait que Kant, lui, était comme ça). Il est sur le fait que, curieusement, Jean-Gabriel Ganascia défend le conséquentialisme en oubliant un de ses principes de base : l'efficacité. Si on défend des mesures mauvaises au nom de leurs résultats positifs, c'est la moindre des choses que d'évaluer quelle chance on a d'atteindre ces résultats. Or, il n'y a rien de tel dans l'article :
- Aucun mot sur les tests, actuellement en nombre très insuffisant alors que, justement, une application de suivi de contacts n'a de sens que si on teste les personnes, pour pouvoir ensuite prévenir leurs contacts qu'ils se sont approchés d'une personne contaminée.
- Aucune estimation de l'efficacité de l'application prévue. Jean-Gabriel Ganascia dit simplement qu'iil faut faire quelque chose donc que StopCovid est une bonne solution, sans étudier ses forces et ses faiblesses, qui ont pourtant été largement discutées publiquement.
Bref, il n'est pas un conséquentaliste conséquent. Il défend les applications de suivi de contacts au nom de l'éthique de responsabilité. Si on le suit, cela veut dire que ces applications peuvent être éthiques, même si elles violent la vie privée. (Notez que d'autres défenseurs de ces applications ont un autre angle d'attaque, affirmant bien haut qu'elles ne violent en rien la vie privée. La communication autour de StopCovid a changé dans le temps.) Mais cela n'implique pas forcément que ces applications soient éthiques, il leur reste encore à prouver leur efficacité. La fin justifie les moyens, peut-être mais des moyens non éthiques et qui ne permettent pas d'atteindre la fin auraient quelle légitimité ?
L'article seul
Résolveur DNS : définition
Première rédaction de cet article le 11 mai 2020
Ce court article explique ce qu'est un résolveur DNS. Il existe plein de ressources en ligne sur le DNS mais très peu expliquent la différence cruciale entre un résolveur et un serveur faisant autorité.
Il y a en effet deux catégories de serveurs DNS. Ils sont tellement différents que c'est en général une mauvaise idée de dire « serveur DNS » tout court. Le résolveur est le serveur qu'interrogent directement les machines terminales (comme celle que vous touchez en ce moment, lorsque vous consultez cet article). Ces machines terminales ne parlent jamais directement aux serveurs faisant autorité, l'autre catégorie de serveurs DNS.
Comme c'est le serveur contacté pour toute résolution DNS, il est absolument critique : s'il tombe en panne, ce sera, pour la très grande majorité des activités, comme si on n'avait plus d'Internet du tout. S'il ment, il pourra emmener l'utilisateur où il veut. Et s'il capture des données, il peut avoir accès à énormément d'informations sur votre activité (cf. RFC 7626).
Notez que le résolveur est parfois appelé « serveur récursif » ou « serveur cache ».
Des exemples de résolveurs :
- Le cas le plus courant est celui où vous utilisez le résolveur fourni par votre FAI ou par le service informatique qui gère votre réseau d'accès à l'Internet.
- Mais il existe aussi des résolveurs DNS publics, dont les plus célèbres sont ceux des GAFA Google et Cloudflare. Les utiliser n'est pas forcément une bonne idée.
- Vous pouvez parfaitement avoir votre propre résolveur DNS, pour un maximum de contrôle ; c'est ce qui arrive avec le Pi-hole mais cela peut se faire avec beaucoup d'autres logiciels libres comme Unbound ou Knot. Notez toutefois qu'aucune solution n'est parfaite.
Comment la machine terminale connait le résolveur à utiliser ?
L'adresse IP du résolveur
est apprise via des protocoles comme DHCP, mais peut aussi avoir été
configurée statiquement, dans une base comme le fichier de
configuration /etc/resolv.conf sur
Unix. En pratique, ce n'est pas toujours trivial.
Le résolveur ne connait quasiment aucune donnée au démarrage, il apprend petit à petit en contactant les serveurs faisant autorité.
Le résolveur, au milieu de la résolution DNS :
Notez que certains logiciels DNS permettent d'assurer les fonctions de résolveur et de serveur faisant autorité dans le même serveur. C'est en général une mauvaise idée.
Et si vous êtes branché·e technique, et que vous voulez interroger un
résolveur directement, pour voir ce qu'il raconte ? Sur
Unix, le logiciel dig permet de le faire. Si on
n'indique pas explicitement un serveur, il interroge le résolveur
par défaut de la machine, ici il a l'adresse IP
::1 (la ligne SERVER) :
% dig AAAA cyberstructure.fr ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50365 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ... ;; ANSWER SECTION: cyberstructure.fr. 82347 IN AAAA 2001:4b98:dc0:41:216:3eff:fe27:3d3f ... ;; Query time: 137 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri May 08 17:23:54 CEST 2020 ;; MSG SIZE rcvd: 251
On voit qu'on parle à un résolveur, et non pas à un serveur faisant autorité à deux détails :
- Dans les flags, il y a le bit RA (Recursion Available), qui serait absent sur un serveur faisant autorité, qui aurait plutôt le bit AA.
- Le TTL n'est pas un chiffre rond, ce qui arrive lorsque la donnée était déjà dans la mémoire du résolveur.
Notez que la motivation originelle pour cet article était le désir de pouvoir parler de « résolveur » dans les articles de ce blog sans devoir l'expliquer à chaque fois, uniquement en mettant un lien. D'habitude, je résous le problème en mettant un lien vers Wikipédia mais, ici, il n'existe pas de bon article Wikipédia sur la question. Je n'ai pas le courage de l'écrire, et surtout de le gérer par la suite, surtout face aux « corrections » erronnées. Mais, ce blog étant sous une licence libre, et compatible avec celle de Wikipédia, si vous souhaitez le faire, n'hésitez pas à copier/coller du texte.
L'article seul
Serveur DNS faisant autorité : définition
Première rédaction de cet article le 11 mai 2020
Ce court article explique ce qu'est un serveur DNS faisant autorité. Il existe plein de ressources en ligne sur le DNS mais très peu expliquent la différence cruciale entre un résolveur et un serveur faisant autorité.
Il y a en effet deux catégories de serveurs DNS. Ils sont tellement différents que c'est en général une mauvaise idée de dire « serveur DNS » tout court. Le serveur faisant autorité est le serveur qui stocke les données, qui seront récupérées via le protocole DNS. C'est pour cela qu'on dit qu'il « fait autorité » : par définition, ce qu'il dit est la vérité. Il n'est jamais interrogé par les machines des utilisateurs, mais il est questionné indirectement, par les serveurs de l'autre catégorie, les résolveurs.
Les serveurs faisant autorité, et leur rôle dans la résolution
DNS :
Un serveur faisant autorité ne fait pas autorité pour tous les noms de domaine, puisque le DNS est décentralisé. Il fait autorité pour une partie de l'arbre des noms de domaine. Par exemple :
- Les serveurs de l'AFNIC,
l'organisation qui gère le TLD
.frfont autorité pour.fr. - Les serveurs faisant autorité pour les domaines du CNAM sont gérés par le service informatique du CNAM.
- Je gère moi-même la plupart des serveurs qui font autorité
pour le domaine de ce blog,
bortzmeyer.org. - Les serveurs faisant autorité pour le Ministère des Armées français sont sous-traités à la société Orange (via la marque Oleane).
À noter qu'un serveur faisant autorité se dit en anglais authoritative server, ce qu'on voit parfois bêtement traduit par « serveur autoritaire ». Non. Un adjudant est autoritaire, un serveur DNS fait autorité.
Si un serveur DNS faisant autorité est en panne, les autres serveurs faisant autorité pour la même zone (sous-arbre de l'arbre des noms de domaine) restent disponibles. Pour qu'une zone ne marche plus, il faut une panne de tous les serveurs faisant autorité (cf. la fameuse attaque contre Dyn, ou bien cette panne chez Microsoft). Mais cela n'affectera que les domaines hébergés sur ces serveurs, pas le reste du DNS.
Si vous êtes informaticien ou simplement intéressé par l'informatique, et que vous voulez monter des serveurs faisant autorité, il existe de nombreux logiciels libres pour cela, comme NSD ou Knot.
Notez que certains logiciels DNS permettent d'assurer les fonctions de résolveur et de serveur faisant autorité dans le même serveur. C'est en général une mauvaise idée.
Où les serveurs faisant autorité trouvent-ils leurs données, celles qu'ils vont servir à tout les résolveurs de la planète ? Cela dépend du serveur, c'est une décision locale. Il est courant de stocker les données dans un fichier de zone, dont la syntaxe absconse et pleine de pièges a souvent créé des problèmes :
$TTL 86400
@ IN SOA ns4.bortzmeyer.org. hostmaster.bortzmeyer.org. (
2020043001
7200
3600
604800
43200 )
IN NS ns4.bortzmeyer.org.
IN NS ns1.bortzmeyer.org.
...
IN MX 0 mail.bortzmeyer.org.
IN TXT "v=spf1 mx ?all"
IN TXT "My personal domain - Domaine personnel"
IN CAA 0 issue "cacert.org"
IN CAA 0 issuewild ";"
IN CAA 0 issue "letsencrypt.org"
www IN AAAA 2001:4b98:dc0:41:216:3eff:fe27:3d3f
www IN AAAA 2605:4500:2:245b::42
mercredifiction IN CNAME ayla
_443._tcp.mercredifiction IN TLSA 1 1 1 928dde55df4cd94cdcf998c55085fbb5228b561cc237a122d950260029c5b8c9
...
Mais d'autres méthodes existent, par exemple l'utilisation d'un SGBD.
Et si on veut continuer dans la technique et regarder les données
d'un serveur faisant autorité ? Normalement, ils ne sont pas
interrogés directement mais via les résolveurs. Ceci dit, les
serveurs faisant autorité sont publics, et on peut, sur
Unix, utiliser dig pour les interroger, en
mettant le nom ou l'adresse IP du serveur après le signe @. Ici, on
interroge un serveur de l'AFNIC sur le
domaine sante.gouv.fr :
% dig @d.nic.fr A sante.gouv.fr ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38097 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6 ;; WARNING: recursion requested but not available ... ;; AUTHORITY SECTION: sante.gouv.fr. 172800 IN NS ns3.nameshield.net. sante.gouv.fr. 172800 IN NS ns2.observatoiredesmarques.fr. sante.gouv.fr. 172800 IN NS ns1.travail.gouv.fr. sante.gouv.fr. 172800 IN NS ns1.sante.gouv.fr. sante.gouv.fr. 172800 IN NS ns2.sante.gouv.fr. sante.gouv.fr. 172800 IN NS a.ns.developpement-durable.gouv.fr. ... ;; Query time: 3 msec ;; SERVER: 2001:678:c::1#53(2001:678:c::1) ;; WHEN: Fri May 08 17:25:44 CEST 2020 ;; MSG SIZE rcvd: 326
La question posée au serveur d.nic.fr, qui fait
autorité pour .fr était « quelle est l'adresse
IPv4 de
sante.gouv.fr ? » Nous n'avons pas eu de
réponse directe, car d.nic.fr fait autorité
pour .fr mais pas pour
sante.gouv.fr (rappelez-vous que le DNS est
décentralisé). On a donc une délégation,
d.nic.fr nous renvoie à six serveurs qui font
autorité pour sante.gouv.fr. L'avertissement
« recursion requested but not available » est
normal, s'agissant d'un serveur faisant autorité, pas d'un résolveur
(les résolveurs sont également appelés serveurs récursifs).
Au passage, cela me permet d'expliquer comment on trouve les
serveurs faisant autorité pour une zone donnée : le DNS utilise le
DNS pour son propre fonctionnement. Une requête de type NS
(Name Servers) permet de trouver les serveurs,
ici, ceux faisant autorité pour
.fi (j'ai pensé à ce
TLD car je
venais de lire des récits
de randonnée en Finlande) :
% dig NS fi ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7282 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1 ... ;; ANSWER SECTION: fi. 86400 IN NS e.fi. fi. 86400 IN NS b.fi. fi. 86400 IN NS a.fi. fi. 86400 IN NS h.fi. fi. 86400 IN NS i.fi. fi. 86400 IN NS f.fi. fi. 86400 IN NS d.fi. fi. 86400 IN NS g.fi. fi. 86400 IN NS c.fi. ;; Query time: 176 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri May 08 18:42:25 CEST 2020 ;; MSG SIZE rcvd: 175
On a vu plus haut que demander des informations sur
sante.gouv.fr à un serveur qui fait autorité
pour .fr renvoie une délégation. Si on suit
cette délégation et qu'on pose la même question à un serveur qui
fait autorité pour sante.gouv.fr, on a notre réponse :
% dig @a.ns.developpement-durable.gouv.fr. A sante.gouv.fr ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15886 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 5 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;sante.gouv.fr. IN A ;; ANSWER SECTION: sante.gouv.fr. 600 IN A 213.162.60.164 ... ;; Query time: 25 msec ;; SERVER: 194.5.172.19#53(194.5.172.19) ;; WHEN: Fri May 08 17:26:21 CEST 2020 ;; MSG SIZE rcvd: 298
On voit qu'on parle à un serveur faisant autorité, et non pas à un résolveur, à deux détails :
- Dans les flags, il y a le bit AA (Authoritative Answer), qui serait absent sur un résolveur, qui aurait plutôt le bit RA.
- Le TTL est un chiffre rond.
Notez que la motivation originelle pour cet article était le désir de pouvoir parler de « serveur faisant autorité » dans les articles de ce blog sans devoir l'expliquer à chaque fois, uniquement en mettant un lien. D'habitude, je résous le problème en mettant un lien vers Wikipédia mais, ici, il n'existe pas de bon article Wikipédia sur la question. Je n'ai pas le courage de l'écrire, et surtout de le gérer par la suite, surtout face aux « corrections » erronnées. Mais, ce blog étant sous une licence libre, et compatible avec celle de Wikipédia, si vous souhaitez le faire, n'hésitez pas à copier/coller du texte.
L'article seul
Qui contrôle votre ordiphone et qui devrait avoir ce pouvoir ?
Première rédaction de cet article le 10 mai 2020
Le débat sur le contrôle des ordiphones est ancien mais a récemment repris de l'importance en France lors de la discussion sur une éventuelle application de suivi des contacts pour l'épidémie de COVID-19. En effet, les systèmes d'exploitation les plus répandus sur ordiphone ne permettent pas certaines fonctions qu'un projet d'application voulait utiliser. D'où la discussion « qui doit décider d'autoriser ou pas telle fonction de l'appareil ? »
Dans ce cas précis, le problème portait sur le Bluetooth et plus précisément sur son activation permanente par une application, même quand elle est en arrière-plan sur l'ordiphone. Le système d'exploitation d'Apple, iOS (mais, apparemment, également son concurrent Android) ne permet pas cela. Bluetooth est en effet très dangereux pour la sécurité, permettant à tout appareil proche de parler avec le vôtre, et surtout pour la vie privée. Compte tenu de l'attitude des commerçants vis-à-vis de la vie privée, des scénarios de type « Black Mirror » seraient possibles, si les applications pouvaient laisser le Bluetooth fonctionner discrètement, par exemple de la surveillance de clients dans un magasin, pour identifier les acheteurs potentiels. Il est donc tout à fait normal qu'iOS ne permette pas cela. C'est aussi pour cela que l'ANSSI recommande, à juste titre, « Les interfaces sans-fil (Bluetooth et WiFi) ou sans contact (NFC par exemple) doivent être désactivées lorsqu’elles ne sont pas utilisées ».
OK, dans ce cas bien précis, Apple a raison. Mais généralisons un peu le problème : qu'ils aient raison ou pas, est-ce normal qu'une entreprise privée étatsunienne prenne ce genre de décisions ? Et, si ce n'est pas Apple ou Google (qui gère Android), alors qui ?
La question est importante : la technique n'est pas neutre, les auteurs de logiciel (ici, Google et Apple) ont un pouvoir. En effet, une très grande partie des activités humaines passe par des équipements informatiques. Ces équipements déterminent ce qu'on peut faire ou ne pas faire, particulièrement sur les ordiphones, des engins beaucoup plus fermés et contrôlés par les auteurs de logiciel que les traditionnels ordinateurs. Même quand le logiciel n'impose pas et n'interdit pas, il facilite, ou au contraire il décourage telle ou telle utilisation, exerçant ainsi un réel pouvoir, même s'il n'est pas toujours très apparent. Mais, justement, dans le cas de l'application de suivi de contacts, ce pouvoir se manifeste plus nettement. On peut taper du poing sur la table, crier que c'est intolérable, si Apple et Google ne bougent pas, on ne peut rien faire. Notez que c'est une simple constatation que je fais ici : Apple et Google ont du pouvoir, indépendamment de si on pense qu'ils exercent ce pouvoir correctement ou pas. (Ici, j'ai déjà dit qu'Apple avait tout à fait raison et que leur demander de diminuer la sécurité de leur système - déjà basse - était une mauvaise idée.) Je ne vais pas développer davantage cette question de la neutralité de la technique, et du pouvoir des auteurs du logiciel, j'en ai déjà parlé dans mon livre (p. 148 et 97 de l'édition papier, respectivement).
Le problème du pouvoir d'Apple et Google sur ces machines, je l'ai dit au début, est perçu depuis un certain temps. L'ARCEP en a fait le thème d'une campagne sur la nécessaire « neutralité des terminaux », terme malheureux car un logiciel n'est jamais neutre, il fait des choix (ou, plus exactement, l'organisation qui écrit le logiciel fait des choix). L'ARCEP semble d'ailleurs depuis préférer une meilleure terminologie, parlant par exemple d'ouverture des terminaux. Une autre raison qui fait que le concept de « neutralité des terminaux » est contestable est qu'il est un peu trop évident qu'il s'agit de faire référence à la neutralité de l'Internet, une question assez différente. En effet, il est normalement bien plus facile de changer de machine et de logiciel que de FAI. Vraiment ? C'est que d'un autre côté, le choix est parfois plus théorique que réel. Ainsi, pour les ordiphones, le matériel impose souvent le choix d'un et d'un seul système d'exploitation, avec différents moyens techniques de rendre difficile le changement de ce système, ce qui est une entrave anormale à la liberté de l'utilisateur. J'y reviendrai.
Mais, d'abord, revenons à la souveraineté. Faut-il une solution « souveraine », par exemple un système d'exploitation français sur ces ordiphones, qui suivrait alors les ordres du gouvernement français ? Avant de considérer si ce serait une bonne idée ou pas, est-ce réaliste ? Clairement non, mais j'ai déjà détaillé cette question dans mon article sur le défunt projet « OS souverain ». À défaut de développer un système souverain, serait-il possible, en remuant suffisamment d'air, de contraindre Google et Apple à obtempérer ? Ces entreprises n'ont pas de morale, leur but est de gagner de l'argent et leur décision finale dépendrait simplement de si elles estiment préférable, pour leur cours en Bourse, d'obéir ou au contraire de jouer les vertueux résistants. Disons que cela va dépendre de l'importance du gouvernement qui demande…
Mais, outre, cette question de réalisme, il y a un problème politique bien plus fondamental : la souveraineté de qui ? La souveraineté n'est pas un but en soi, c'est normalement le moyen de prendre des décisions qui correspondent à nos intérêts et pas à ceux de Google et d'Apple. Mais qui est le « nous » ? L'État ? Le citoyen ? (Notez au passage que tous les citoyens ne sont pas d'accord entre eux…) L'entreprise nationale ? Un système d'exploitation contrôlé par Orange et Thales serait-il meilleur que s'il était contrôlé par Google et Apple ? J'en doute. Et c'est pour cela que je ne suis pas très enthousiaste en lisant les discours souverainistes, qui ne parlent en général jamais des décisions qui seront prises, uniquement du fait qu'elles seront « souveraines ».
Bon, maintenant, assez râlé, qu'est-ce que je propose ? Certainement pas de lancer le Nième grand projet national de développement d'un système souverain, projet qui finira soit en échec gaspilleur soit, pire, en un autre système fermé ne laissant aucune souveraineté aux citoyens et citoyennes. L'important est au contraire d'ouvrir le choix. Il ne s'agit pas de n'avoir le choix qu'entre deux systèmes privateurs mais au contraire de faire en sorte que les utilisateurs et utilisatrices d'ordiphones (et d'ordinateurs tout court, d'ailleurs) aient accès à plusieurs choix possibles. Un monopole de Capgemini ne serait pas meilleur qu'un monopole de Google ! Le pluralisme est en effet la meilleure garantie contre les abus du pouvoir. Si les auteurs d'un système d'exploitation tentent d'abuser de leur pouvoir, on peut espérer que les autres suivront un chemin différent. Notez que le fait d'avoir des systèmes d'exploitation différents est une condition nécessaire mais pas suffisante. Il faut aussi :
- Que les systèmes offrent un réel choix. Actuellement, le duopole Apple+Google leur permet trop facilement de s'entendre sur tel ou tel choix.
- Que le matériel permette de changer réellement de système d'exploitation, au contraire de la plupart des ordiphones d'aujourd'hui, verrouillés contre toute installation d'un système alternatif. Le problème n'est pas seulement Apple+Google : les fabricants de matériel, ainsi que les opérateurs téléphoniques qui distribuent des ordiphones, ont également une part de responsabilité.
- Que les systèmes d'exploitation en question soient du logiciel libre, autrement, l'utilisateur n'aurait pas davantage de souveraineté qu'aujourd'hui, quelle que soit l'organisation qui a développé ce système.
Sinon, d'autre(s) article(s) sur le même sujet :
- L'article « Souveraineté numérique » d'Elisabeth.
- Le dossier de l'ARCEP sur « les terminaux ». Il fait plusieurs propositions concrètes, assez modestes, mais qui vont dans le bon sens. Par exemple, le rapport demande « de permettre aux utilisateurs de supprimer des applications préinstallées » mais ne parle pas de leur permettre d'installer un système d'exploitation alternatif.
- L'étude sous l'angle juridique de la fermeture des ordiphones et de leurs systèmes d'exploitation, par Emmanuel Netter.
L'article seul
Afficher une page de ce blog prise au hasard
Première rédaction de cet article le 9 mai 2020
Sur une suggestion d'un fidèle lecteur, j'ai installé un p'tit script qui permet de voir une page au hasard de ce blog.
Quel intérêt ? Pas beaucoup, c'est surtout amusant, et cela peut
permettre de découvrir des articles peu lus sur ce
blog. L'URL
est https://www.bortzmeyer.org/apps/random
Notez que cela peut faire ressortir de vieux articles, pas du tout à jour. En effet, je ne m'engage pas à ce que tous les articles soient maintenus, cela ne me laisserait plus le temps d'en faire de nouveaux. Au moins, je mets systématiquement la date, ce qui permet de vérifier si l'article est récent ou pas.
Les amateurs de programmation noteront que le code source de ce service, en Python, est très simple :
def randomfile(start_response, environ):
global generator
files = glob.glob("%s/*.xml" % path)
file = re.sub(path, '', re.sub('\.xml$', '.html', generator.choice(files)))
url = "%s%s" % (prefix, file)
status = '307 Redirect'
output = """
<html><head><title>Redirect at random</title></head>
<body>
<h1>Redirect at random</h1>
<p>Go <a href="%s">to this article</a>.</p>
</body>
</html>""" % url
response_headers = [('Location', url),
('Content-type', 'text/html'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output.encode()]
L'article seul
Fiche de lecture : The island of lost maps
Auteur(s) du livre : Miles Harvey
Éditeur : Broadway Books
0-7679-0826-0
Publié en 2000
Première rédaction de cet article le 7 mai 2020
Ce n'est pas un roman : ce livre raconte la triste histoire d'un salaud, Gilbert Bland, qui a écumé les bibliothèques des États-Unis pendant des années, découpant des livres anciens pour voler des cartes et les revendre. L'auteur raconte l'histoire de ces vols, les réactions des bibliothèques (souvent trop pauvres pour pouvoir protéger efficacement les trésors qu'elles contiennent) et le discret monde des vendeurs d'antiquités, où l'éthique est assez basse, et où d'autres salauds achètent sans discuter des œuvres manifestement volées.
L'enquête est très approfondie mais cela n'a pas été facile. Les bibliothèques ont pendant longtemps préféré se taire, en partie pour ne pas attirer l'attention sur la quantité d'objets précieux qu'elles stockent, en partie parce que les universités aux États-Unis dépendent beaucoup du financement privé et qu'il ne faut pas effrayer les riches donateurs. Le monde du commerce d'antiquités est discret, d'autant plus qu'ils savent bien qu'une bonne partie des transactions est fondé sur le vol. Mais Miles Harvey y a passé du temps, et a été le premier à exposer le business de Bland, dans une série d'articles dont il a ensuite tiré ce livre, plein de personnages mystérieux, de rendez-vous dans des lieux luxueux, de trésors antiques en péril.
Bland n'était pas le premier voleur de cartes, bien sûr. Le livre refait vivre une bonne partie de l'histoire de la cartographie ; les cartes sont précieuses, parfois secrètes, et dans de nombreux cas, des espions étaient prêts à prendre des risques énormes pour arriver à mettre la main sur les cartes utilisées pour les voyages lointains. Ce livre passionnant ne se limite pas aux actions d'un minable voleur du XXe siècle, il parle aussi de voyages, de comment on fait les cartes, comment on répare les vieux livres et de plein d'autres sujets qui font rêver.
L'article seul
Fiche de lecture : Super-héros ; une histoire politique
Auteur(s) du livre : William Blanc
Éditeur : Libertalia
978-2377-290444
Publié en 2018
Première rédaction de cet article le 5 mai 2020
Les super-héros étatsuniens ne sont pas juste une bande de types bizarres en collants colorés et qui chassent des méchants en sautant d'un immeuble à l'autre. Ils résument et illustrent des valeurs et des opinions, ils sont donc politiques, comme les autres personnages de fiction. Dans cet excellent livre, William Blanc analyse cette politique des super-héros, depuis les débuts jusqu'à aujourd'hui, et comment ils reflètent les mythes, les espoirs et les préjugés de chaque époque.
Depuis toujours, il y a des histoires avec des héros. Mais quand on parle spécifiquement des « super-héros », on fait allusion à un courant purement étatsunien (et qui, logiquement dans ce pays, est une marque déposée). Ce courant est né en 1938, date de la parution du premier Superman. Le caractère bon marché des comics, et leur immense succès populaire ont paradoxalement retardé le moment où les thèmes politiques sous-jacents ont été sérieusement étudiés. Mais cette époque-là est révolue et, désormais, on ne compte plus les travaux érudits analysant les X-Men, Batman ou les Avengers. Ces super-héros sont-ils de gauche ou de droite ? Orientés vers le progrès ou vers le retour au passé ? Cela dépend du personnage et des époques. Les super-héros, qui semblent dotés d'une force invincible sont en fait très vulnérables à l'air du temps, et évoluent régulièrement en fonction des attentes du marché, pardon, de la société. Et comme la demande est vaste, l'offre s'adapte. Les super-héros sont trop machos ? On crée Wonder Woman, car il y a suffisamment de lectrices (ou de lecteurs intéressés par un personnage féminin fort) pour que ça se vende. Les Noirs revendiquent leurs droits ? Black Panther apparait (il y a aussi le moins connu Power Man, que j'ai découvert dans ce livre). Les super-héros ont ainsi épousé tous les changements de la société étatsunienne au cours du XXe siècle.
Si certains des super-héros ont des opinions politiques explicites, comme Green Arrow, d'autres sont plus difficiles à décoder. C'est ainsi que le chapitre sur le Punisher, personnage favori de l'extrême-droite, ne tranche pas complètement : ce super-héros est plus complexe que ce que croient ses supporters habituels.
Ah, et l'étude très fouillée des super-héros va jusqu'à étudier leurs pratiques sportives. Je vous laisse deviner quel est le sport le plus pratiqué par les super-héros.
Note personnelle : je n'aime pas les comics traditionnels, et j'absorbe avec modération les films modernes de super-héros. Donc, je ne suis peut-être pas le cœur du cible idéal pour ce livre. L'auteur, William Blanc, a écrit sur d'autres mythes qui me touchent plus, comme le roi Arthur ou comme Charles Martel (oui, c'est un personnage historique, mais on sait peu de choses sur lui, et c'est surtout le mythe qu'analyse l'auteur dans son livre).
L'article seul
RFC 8752: Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)
Date de publication du RFC : Mars 2020
Auteur(s) du RFC : M. Thomson, M. Nottingham
Pour information
Première rédaction de cet article le 1 mai 2020
Ce RFC est le compte-rendu d'un atelier de l'IAB qui s'est tenu en juillet 2019 au sujet du Web Packaging, une proposition technique permettant de regrouper un ensemble de pages Web en un seul fichier, pouvant être distribué par des moyens non-Web, tout en étant authentifié. Web Packaging (ou WebPackage) est un concentré de pas mal d'enjeux technico-politiques actuels.
Pour en savoir plus sur ce projet, vous pouvez consulter l'actuel dépôt du projet, géré par le WICG. (Il y avait un projet W3C à un moment mais qui a été abandonné). Vous pouvez commencer par ce document. (Il y a aussi un brouillon à l'IETF, et un nouveau groupe de travail, wpack.) Le projet avait été lancé à l'origine par Google.
La proposition a suscité pas mal de discussions, voire de contestations. N'est-ce pas encore un plan diabolique de Google pour entuber les webmestres ? L'IAB a donc organisé un atelier, joliment nommé ESCAPE (Exploring Synergy between Content Aggregation and the Publisher Ecosystem) au sujet du Web Packaging. Cela permettait notamment de faire venir des gens qui sont plutôt du côté « création de contenus » (entreprises de presse, par exemple), et qui viennent rarement au W3C et jamais à l'IETF. Cet atelier s'est tenu à Herndon en juillet 2019. Il n'avait pas pour but de prendre des décisions, juste de discuter. Vous pouvez trouver les documents soumis par les participants sur la page de l'atelier. Je vous recommande la lecture de ces soumissions.
Le principe de base de Web Packaging est de séparer l'écriture du contenu et sa distribution, tout en permettant de valider l'origine du contenu (l'annexe B du RFC décrit Web Packaging plus en détail). Ainsi, un des scénarios d'usage (section 2 du RFC) serait que le crawler de Google ramasse un paquetage de pages et de ressources sur un site Web, l'indexe, et puisse ensuite servir directement ce paquetage de pages et autres ressources au client qui a utilisé le moteur de recherche, sans renvoyer au site original. Et tout cela avec des garanties d'origine et d'authenticité, et en faisant afficher par le navigateur dans sa barre d'adresses l'URL original. Un autre usage possible serait la distribution de sites Web censurés, par des techniques pair-à-pair, tout en ayant des garanties sur l'origine (sur ce point particulier, voir aussi la section 3.3 du RFC). Notez que ces techniques font que le site original ne connait pas les téléchargements, ce qui peut être vu comme une bonne chose (vie privée) ou une mauvaise (statistiques pour le marketing). Et puis les inquiétudes vis-à-vis de Web Packaging ne viennent pas uniquement des problèmes pour avoir des statistiques. Des éditeurs ont dit lors de l'atelier qu'il étaient tout simplement inquiets des « copies incontrôlées ». En outre, l'argument de vie privée est à double tranchant : le site d'origine du contenu ne voit pas les téléchargements, mais un autre acteur, celui qui envoie le Web Packaging le voit.
Séparer création de contenu et distribution permet également la consultation hors-ligne, puisque un paquetage Web Packaging peut être auto-suffisant. Cela serait très pratique, par exemple pour Wikipédia. Actuellement, il existe des trucs plus ou moins pratiques (HTTrack…) mais le Web Packaging rendrait cette activité plus agréable. Notez que les participants à l'atelier ne se sont pas mis d'accord sur le caractère indispensable ou pas de la signature dans ce cas.
Potentiellement, un système comme Web Packaging pourrait également changer le monde du livre électronique : tout site Web pourrait être facilement « ebookisé ». Une amusante discussion à l'atelier a eu lieu sur l'intérêt des signatures. Comme souvent en cryptographie, les signatures ont une durée de validité limitée. Sept jours est proposé, par défaut, mais Moby Dick a été écrit il y a 61 000 jours.
Dernier scénario d'usage envisagé, l'archivage du Web. Ce n'est pas trivial, car il ne suffit pas de copier la page HTML, il faut garder toutes les ressources auxiliaires, d'où l'intérêt de Web Packaging. Et la signature serait utile là aussi, pour vérifier que l'archive est sincère. (Voir aussi le RFC 7089).
La section 3 du RFC discute ensuite la difficile question de la relation entre les producteurs de contenu et les intermédiaires comme Google. Par exemple, si un producteur de contenu sous-traite la distribution du contenu à un CDN, il doit lui faire confiance pour ne pas modifier le contenu. Web Packaging, avec son système de signature, résoudrait le problème. D'un autre côté, ça fait encore un format de plus dans lequel il faut distribuer le contenu, un coût pas forcément négligeable, et qui frappera de manière disproportionnée les petits producteurs, ou les moins pointus techniquement. Certains participants en ont profité pour râler contre AMP.
Comme toute nouvelle technique, Web Packaging pourrait mener à des déplacements de pouvoir dans l'écosystème du Web. Mais il est très difficile de prévoir ces effets (cf. RFC 5218). Est-ce que Web Packaging va favoriser les producteurs de contenu, les intermédiaires, les utilisateurs ? La section 4 du RFC explore la question. Par exemple, un des risques est la consolidation du pouvoir des gros intermédiaires. Si Facebook peut directement servir des paquetages Web, sans passer par le site original, les performances seront bien meilleures pour les paquetages déjà chargés par Facebook, qui gagnera donc en pouvoir. D'un autre côté, Web Packaging pourrait mener au résultat inverse : l'authentification des paquetages rendrait la confiance en l'intermédiaire inutile. (Personnellement, j'apprécie dans l'idée de Web Packaging que cela pourrait encourager le pair-à-pair, dont le RFC ne parle quasiment pas, en supprimant l'inquiétude quant à l'authenticité du contenu.)
La section 4 couvre d'autres questions soulevées par le concept de Web Packaging. Par exemple, il ne permet pas facilement d'adapter le contenu à l'utilisateur puisque, au moment de fabriquer le paquetage, on ne sait pas qui le lira. Une solution possible serait, pour un même site Web, de produire plusieurs paquetages et de laisser l'utilisateur choisir, mais elle complexifie encore le travail des producteurs. (Personnellement, je pense que beaucoup de ces adaptations sont mauvaises, par exemple l'adaptation au navigateur Web dans l'espoir de contrôler plus étroitement l'apparence, et cela ne me chagrine donc pas trop si elles seraient plus difficiles.)
Et la sécurité ? Un mécanisme de distribution par paquetages Web signés envoyés par divers moyens serait un changement profond du mécanisme de sécurité du Web. Actuellement, ce mécanisme repose essentiellement sur TLS, via HTTPS (RFC 2818). Mais c'est très insuffisant ; TLS ne protège que le canal, pas les données. Si un site Web a des miroirs, HTTPS ne va pas protéger contre des miroirs malveillants ou piratés. Et, comme noté plus haut, si un contenu Web est archivé, et distribué, par exemple, par Internet Archive, comment s'assurer de son authenticité ? L'absence d'un mécanisme d'authentification des données (Object-based security) est une des plus grosses faiblesses du Web (malgré des essais anciens mais jamais déployés comme celui du RFC 2660), et Web Packaging, qui sépare la validation du contenu de sa distribution, pourrait contribuer à traiter le problème. Ceci dit, l'expérience de la sécurité sur l'Internet montre aussi que tout nouveau système amène de nouvelles vulnérabilités et il faudra donc être prudent.
Et la vie privée ? De toute façon, quand on récupère un contenu, qu'il soit sous forme de paquetages ou de pages Web classiques, on donne au serveur des informations (et HTTP est terriblement bavard, il n'y a pas que l'adresse IP qui est transmise). Il semble qu'au moins, Web Packaging n'aggrave pas les nombreux problèmes du Web. (Personnellement, je pense qu'il pourrait même les limiter mais l'analyse exacte est compliquée. À l'heure actuelle, si vous suivez un lien depuis Facebook, le site Web d'origine et Facebook sont au courant. Avec Web Packaging seul Facebook le saurait. Est-ce un progrès ?)
La technologie AMP, très controversée a souvent été mentionnée pendant l'atelier. Elle n'a pas de rapport direct avec Web Packaging mais elle sort de la même société, et est souvent présentée comme faisant partie d'un même groupe de technologies modernes. La section 5 du RFC discute donc des problèmes spécifiques à AMP.
Je n'ai pas regardé les outils existants pour faire du Web Packaging donc ce site n'est pas encore sous forme de paquetage.
L'article seul
Fiche de lecture : À l'école du partage
Auteur(s) du livre : Marion Carbillet, Hélène
Mulot
Éditeur : C&F Éditions
978-2-915825-93-0
Publié en 2019
Première rédaction de cet article le 30 avril 2020
Ce livre rassemble l'expérience de deux enseignantes sur l'utilisation de ressources libres à l'école. Au lieu de n'enseigner qu'avec des documents fermés et réservés, utilisons les Communs à l'école !
Chaque chapitre contient un recueil d'expérience (les auteures sont professeures documentalistes) et des idées pour un aspect particulier du monde numérique ; l'utilisation du Web pour la recherche d'information, la question de la copie et du partage des documents numériques, le travail en commun… Aux débuts du déploiement de l'Internet en France, le système scolaire avait globalement mal réagi, rejettant ce qui était nouveau, et créant un grand fossé entre les pratiques des élèves, qui étaient diabolisées (« n'utilisez pas Wikipédia, c'est gratuit, donc ça ne vaut rien ») et celles de l'Éducation Nationale. Heureusement, les choses changent.
Parmi les ressources en commun utilisables, les auteures citent évidemment Wikimedia Commons, mais aussi (page 110) les archives municipales de Toulouse, qui ont été les premières en France à mettre leur fond à la libre disposition du public (cf. l'excellent exposé de Vincent Privat au Capitole du Libre 2018). Les auteures citent de nombreux projets réalisés avec les élèves (par exemple p. 147), les sensibilisant à la fois à l'importance du partage, et à la nécessité de faire attention aux licences et aux conditions de réutilisation.
Bref, un livre qui, je crois, sera utile aux enseignants et enseignantes qui se demandent comment former les élèves à l'utilisation des Communs numériques. Notez que Stéphanie de Vanssay a fait un article plus détaillé sur ce livre.
Notez enfin que le site officiel du livre contient également des articles récents sur les mêmes sujets, par exemple « En période de confinement, quelles activités proposer aux élèves ? ».
L'article seul
RFC 8758: Deprecating RC4 in Secure Shell (SSH)
Date de publication du RFC : Avril 2020
Auteur(s) du RFC : L. Camara, L. Velvindron (cyberstorm.mu)
Réalisé dans le cadre du groupe de travail IETF curdle
Première rédaction de cet article le 29 avril 2020
L'algorithme de chiffrement symétrique RC4, trop fragile, est abandonné depuis longtemps. Ce nouveau RFC le retire officiellement de SSH. Notre RFC remplace donc le RFC 4345, dont le statut devient « Intérêt historique seulement ».
L'utilisation de RC4 dans SSH avait été enregistrée dans le RFC 4253, et précisée dans ce RFC 4345, désormais abandonné. Les faiblesses de RC4 sont connues depuis longtemps, et ont été documentées dans le RFC 7465. Résultat, RC4 est retiré peu à peu des protocoles Internet (cf. par exemple le RFC 8429.) Désormais, RC4 disparait également de SSH, et le registre IANA des algorithmes a été mis à jour en ce sens.
OpenSSH a retiré RC4 il y a longtemps :
% ssh -V OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 % ssh -Q cipher 3des-cbc aes128-cbc aes192-cbc aes256-cbc rijndael-cbc@lysator.liu.se aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com aes256-gcm@openssh.com chacha20-poly1305@openssh.com
(RC4 apparaissait comme arcfour, pour des
raisons légales.)
L'article seul
RFC 8781: Discovering PREF64 in Router Advertisements
Date de publication du RFC : Avril 2020
Auteur(s) du RFC : L. Colitti, J. Linkova (Google)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF 6man
Première rédaction de cet article le 25 avril 2020
Lors qu'on utilise le système NAT64, pour permettre à des machines situées sur un réseau purement IPv6 de parler avec des machines restées en seulement IPv4, il faut utiliser un résolveur DNS spécial ou bien connaitre le préfixe utilisé pour la synthèse des adresses IPv6. Ce nouveau RFC décrit une option RA (Router Advertisement) pour informer les machines du préfixe en question.
NAT64 est normalisé dans le RFC 6146 et son copain DNS64 dans le RFC 6147. Il permet à des machines situées dans un
réseau n'ayant qu'IPv6 de parler à des
machines restées uniquement sur le protocole du siècle dernier,
IPv4. Le principe est que, pour parler à la
machine d'adresse 192.0.2.1, la machine
purement IPv6 va écrire à 64:ff9b::192.0.2.1
(soit 64:ff9b::c000:201.) C'est le routeur
NAT64 qui changera ensuite le paquet IPv6 allant vers
64:ff9b::192.0.2.1 en un paquet IPv4 allant
vers 192.0.2.1. NAT64 est, par exemple,
largement utilisé dans les grandes réunions internationales comme
l'IETF
ou le FOSDEM, où le réseau WiFi par
défaut est souvent purement IPv6. Mais pour que la machine émettrice
pense à écrire à 64:ff9b::192.0.2.1, il faut
qu'elle connaisse le préfixe à mettre devant les adresses IPv4
(64:ff9b::/96 n'est que le préfixe par défaut.)
La solution la plus courante, DNS64, est que le résolveur DNS mente, en fabriquant des
adresses IPv6 pour les machines n'en ayant pas, dispensant ainsi les
machines du réseau local IPv6 de tout effort. Mais si l'émetteur
veut faire sa résolution DNS lui-même, ou bien utiliser un autre
résolveur, qui ne fabrique pas les adresses v6 ? Une alternative est
donc que cet émetteur fasse lui-même la synthèse. Pour cela, il faut
lui fournir le préfixe IPv6 du routeur NAT64.
Cela résoudra le problème de la machine qui ne veut pas utiliser le résolveur DNS64 :
- Car elle veut faire la validation DNSSEC toute seule comme une grande,
- ou car elle veut se servir d'un résolveur extérieur, accessible via DoT (RFC 7858) ou DoH (RFC 8484),
- ou bien que l'administrateur du réseau local ne fournit tout simplement pas de résolveur DNS64,
- ou encore car elle veut pouvoir utiliser des adresses IPv4
littérales, par exemple parce qu'on lui a passé
l'URL
http://192.0.2.13/, dans lequel il n'y a pas de nom à résoudre, - ou enfin parce qu'elle utilise 464XLAT (RFC 6877) pour lequel la connaissance du préfixe IPv6 est nécessaire.
Pourquoi envoyer cette information avec les RA (Router Advertisements) du RFC 4861 plutôt que par un autre mécanisme ? La section 3 du RFC explique que c'est pour être sûr que le sort est partagé ; si le routeur qui émet les RA tombe en panne, on ne recevra plus l'information, ce qui est cohérent, alors qu'avec un protocole séparé (par exemple le PCP du RFC 7225), on risquait de continuer à annoncer un préfixe NAT64 désormais inutilisable. En outre, cela diminue le nombre de paquets à envoyer (l'information sur le préfixe NAT64 peut être une option d'un paquet RA qu'on aurait envoyé de toute façon.) Et, en cas de changement du préfixe, le protocole du RFC 4861 permet de mettre à jour toutes les machines facilement, en envoyant un RA non sollicité.
Enfin, l'utilisation des RA simplifie le déploiement, puisque toute machine IPv6 sait déjà traiter les RA.
L'option elle-même est spécifiée dans la section 4 du RFC. Outre les classiques champs Type (valeur 38) et Longueur (16 octets), elle comporte une indication de la durée de validité du préfixe, un code qui indique la longueur du préfixe (le mécanisme classique préfixe/longueur n'est pas utilisé, car toutes les longueurs ne sont pas acceptables), et le préfixe lui-même.
La section 5 explique comment les machines doivent utiliser cette option. Elle s'applique à tous les préfixes IPv4 connus. Si on veut router certains préfixes IPv4 vers un routeur NAT64 et d'autres préfixes vers un autre routeur, il faut quand même que les adresses IPv6 soient dans le même préfixe, et router ensuite sur les sous-préfixes de ce préfixe. Un autre problème découlant de ce choix d'avoir un préfixe IPv6 unique pour tout est celui des préfixes IPv4 qu'on ne veut pas traduire, par exemple des préfixes IPv4 purement internes. Il n'y a pas à l'heure actuelle de solution. De toute façon, l'option décrite dans notre RFC est surtout conçu pour des réseaux purement IPv6, et qui n'auront donc pas ce problème.
Attention, le préfixe IPv6 reçu est spécifique à une interface réseau. La machine réceptrice devrait donc le limiter à cette interface. Si elle a plusieurs interfaces (pensez par exemple à un ordiphone avec WiFi et 4G), elle peut recevoir plusieurs préfixes pour le NAT64, chacun ne devant être utilisé que sur l'interface où il a été reçu (cf. RFC 7556.)
Un petit mot sur la sécurité pour terminer. Comme toutes les annonces RA, celle du préfixe NAT64 peut être mensongère (cf. le RFC 6104 au sujet de ces « RAcailles ».) La solution est la même qu'avec les autres options RA, utiliser des techniques « RA guard » (RFC 6105.)
À noter qu'une annonce mensongère d'un préfixe IPv6 prévue pour le NAT64 affectera évidemment les adresses IPv4 qu'on tente de joindre (parfois au point de les rendre injoignables) mais pas les adresses IPv6, qui ne sont pas traduites et donc non touchées par cet éventuel RA tricheur. Comme une machine qui arrive à émettre et à faire accepter des RAcailles peut déjà facilement réaliser un déni de service, on voit que l'option de ce nouveau RFC n'aggrave pas les choses, en pratique.
Le RFC conclut que la procédure de validation des préfixes de la section 3.1 du RFC 7050 n'est pas nécessaire, si on a ce RA Guard.
À l'heure actuelle, il ne semble pas que cette option soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les récepteurs. Mais Wireshark sait déjà le décoder.
L'article seul
Deux ou trois choses sur les applications de suivi de contacts pendant l'épidémie
Première rédaction de cet article le 19 avril 2020
Deux ou trois personnes m'ayant demandé si j'avais une opinion sur les applications de suivi de contacts, dans le contexte de l'épidémie de COVID-19, je publie ici quelques notes, et pas mal d'hyperliens, pour vous donner de la lecture pendant le confinement.
D'abord, des avertissements :
- Je ne suis pas épidémiologiste. Même si je l'étais, il y a encore beaucoup de choses que la science ignore au sujet des infections par le SARS-CoV2, comme les durées exactes des phases où on est contagieux.
- Je ne suis pas non plus un spécialiste de la conception et de l'analyse de protocoles de suivi de contacts. Mais ce n'est pas très grave, pour les raisons que j'exposerai rapidement par la suite.
- Vous ne trouverez pas ici d'analyse de l'application annoncée par le gouvernement français, StopCovid, pour la bonne et simple raison qu'elle n'existe pas. Il y a eu des promesses sous la forme de quelques mots (« anonyme », « sur la base du volontariat ») mais aucun détail technique n'a été publié. À l'heure actuelle, il n'est donc pas possible de dire quoi que ce soit de sérieux sur cette application spécifique.
- D'une manière générale, la situation évolue vite, et il est très possible que, dans une ou deux semaines, cet article ne vale plus rien.
Maintenant, rentrons dans le vif du sujet. Dans la description et l'analyse des protocoles comme PACT, DP3T ou ROBERT ? Non, car, pour moi, c'est une question très secondaire. Voyons les problèmes par ordre décroissant d'importance.
D'abord, il faut se demander si une telle application de suivi des contacts est utile et, surtout, si elle justifie les efforts qu'on y consacre, par rapport à des sujets moins high-tech, moins prestigieux, moins startup-nation, qui motivent moins les informaticiens mais qui ont plus d'importance pour la santé publique, comme la production et la distribution de masques, ou comme la revalorisation des rémunérations et des conditions de travail du personnel de santé. Je ne vais pas insister sur ce point, c'est certes le plus important mais la Quadrature du Net en a déjà parlé, et mieux que moi.
Bref, ce projet d'application de suivi des contacts semble davantage motivé par le désir d'agir, de faire quelque chose, même inutile, désir qui est commun en temps de crise, plutôt que par un vrai problème à résoudre. (C'est ce que les anglophones nomment la maladie du do-something-itis.) Il y a également des enjeux commerciaux, qui expliquent que certaines entreprises se font de la publicité en affirmant travailler sur le sujet (sans tenir compte des travaux existants).
Mais surtout, une application n'a de sens que si on teste les gens, pour savoir qui est contaminé. Comme on peut apparemment être contagieux et pourtant asymptomatique (pas de maladie visible), il faut tester ces personnes asymptomatiques (qui sont sans doute celles qui risquent de contaminer le plus de gens puisque, ignorantes de leur état, elles sortent). Or, Macron a bien précisé dans son discours du 13 avril qu'on ne testerait pas les personnes asymptomatiques (probablement car il n'y a pas de tests disponibles). Cela suffit à rendre inutile toute application, indépendamment des techniques astucieuses qu'elle utilise, car l'application elle-même ne peut pas déterminer qui est malade ou contagieux.
Ensuite, le protocole est une chose, la mise en œuvre dans une application réelle en est une autre. Le diable est dans les détails. Comme indiqué plus haut, on ne sait encore rien sur l'application officielle, à part son nom, StopCovid. Pour formuler un avis intelligent, il ne faudra pas se contenter de généralités, il faudra regarder son code, les détails, les traqueurs embarqués (une plaie classique des applications sur ordiphone, cf. le projet ExodusPrivacy et également leur article sur le COVID-19), etc. Il faudra aussi se pencher sur le rôle du système d'exploitation (surtout s'il y a utilisation de l'API proposée par Google et Apple). Le fait que l'application soit en logiciel libre est évidemment un impératif, mais ce n'est pas suffisant.
Si vous n'êtes pas informaticienne ou informaticien, mais que vous voulez vous renseigner sur les applications de suivi de contacts et ce qu'il y a derrière, souvenez-vous qu'il y a plusieurs composants, chacun devant être étudié :
- L'application elle-même, celle que vous téléchargez sur le magasin, qui est la partie visible (mais pas forcément la plus importante).
- Le protocole qui est l'ensemble des règles que suit l'application, notamment dans la communication avec le reste du monde (autres ordiphones, serveur central…). Avec le même protocole, on peut créer plusieurs applications assez différentes.
- Le système d'exploitation qui, après tout, a un complet contrôle de la machine et peut passer outre les décisions des applications. C'est un sujet d'autant plus sensible que, sur les ordiphones, ce système est étroitement contrôlé par deux entreprises à but lucratif, Apple et Google.
- Le serveur central (la grande majorité des protocoles proposés nécessite un tel serveur) qui peut être piraté ou, tout simplement, géré par des gens qui ne tiennent pas leurs promesses.
Parmi les bonnes lectures accessible à un large public :
- L'excellente bande dessinée de Gee.
- Un article de Martin Untersinger.
- Le texte de Paula Forteza et Elliot Alderson.
- Le message de Pierre-Yves Gosset (Framasoft).
- En anglais, Privacy International a une analyse très détaillée.
Voilà, on peut maintenant passer aux questions qui passionnent mes lecteurs et lectrices passionnés d'informatique, les protocoles eux-mêmes. Il en existe de nombreux. J'ai une préférence pour PACT, dont je vous recommande la lecture de la spécification, très claire. La proposition DP3T est très proche (lisez donc son livre blanc).
Ces deux propositions sont très proches : l'ordiphone émet en Bluetooth des identifiants temporaires, générés aléatoirement et non reliables entre eux. Les autres ordiphones proches les captent et les stockent. Ces identifiants se nomment chirps dans PACT (qu'on pourrait traduire par « cui-cui ») et EphID (pour Ephemeral ID) dans DP3T. Lorsqu'on est testé (rappel : il n'y a pas assez de tests en France, on ne peut même pas tester tous les malades, ce qui est un problème bien plus grave que le fait d'utiliser tel algorithme ou pas), et détecté contaminé, on envoie les données à un serveur central, qui distribue la liste. En téléchargeant et en examinant cette liste, on peut savoir si on a été proche de gens contaminés.
C'est évidemment une présentation très sommaire, il y a plein de détails à traiter, et je vous recommande de ne pas vous lancer dans de longues discussions sur Twitter au sujet de ces protocoles, avant d'avoir lu les spécifications complètes. Les deux propositions ont été soigneusement pensées par des gens compétents et le Café du Commerce devrait lire avant de commenter.
PACT et DP3T ont assez peu de différences. Les principales portent sur le mécanisme de génération des identifiants, PACT déduit une série d'identifiants d'une graine renouvellée aléatoirement (on stocke les graines, pas réellement les identifiants), alors que DP3T déduit chaque graine de la précédente, des choses comme ça.
La proposition ROBERT est assez différente. La liste des identifiants des contaminés n'est plus publique, elle est gardée par le serveur central, que les applications doivent interroger. Globalement, le serveur central a bien plus de pouvoir et de connaissances, dans ROBERT. La question est souvent discutée de manière binaire, avec centralisé vs. décentralisé mais le choix est en fait plus compliqué que cela. (Paradoxalement, un protocole complètement décentralisé pourrait être moins bon pour la vie privée.) Au passage, j'ai déjà discuté de cette utilisation très chargée de termes comme « centralisé » dans un article à JRES. Autre avantage de ROBERT, la discussion sur le protocole se déroule au grand jour, via les tickets de GitHub (cf. leur liste mais lisez bien la spécification avant de commenter, pas juste les images). Par contre, son analyse de sécurité est très insuffisante, comme le balayage de tous les problèmes liés au serveur central en affirmant qu'il sera « honnête et sécurisé ». Et puis la communication autour de cette proposition est parfois scientiste (« Ce sont des analyses scientifiques qui permettent de le démontrer, pas des considérations idéologiques [comme si c'était mal d'avoir des idées, et des idées différentes des autres] ou des a priori sémantiques. ») et il y a une tendance à l'exagération dans les promesses.
Enfin, un peu en vrac :
- Le Wikipédia anglophone a un bon guide des applications de suivi.
- La proposition Apple/Google, détaillé ici ainsi que sur cette page. Il ne s'agit à proprement parler pas d'un protocole de suivi de contacts mais d'un ensemble de services dans les systèmes d'exploitation (iOS pour Apple et Android pour Google), pour aider les applications de suivi.
- Une critique détaillée du protocole ROBERT.
- Je n'ai pas cité les autres protocoles, NTK et TCN.
- La question de la protection de la vie privée, avec de telles applications, a suscité bien des discussions (et à juste titre). L'Union européenne a produit une série de recommandations à ce sujet, et le CCC une autre série d'exigences à satisfaire.
- L'avis du Conseil National du Numérique est une lecture intéressante.
- Une analyse par divers chercheurs montre bien en quoi suivi et anonymat sont deux notions difficilement conciliables, quelles que soient les promesses officielles.
- La mise en correspondance de deux ensembles de données (les identifiants des gens avec qui il y a eu contact, et les identifiants des gens contaminés) est un problème très difficile à résoudre si on veut respecter un peu la vie privée. Mais il n'est pas insoluble, voir par exemple la solution de Signal.
- Un bon article de Ross Anderson, qui prend de la hauteur sur le sujet.
L'article seul
RFC 8761: Video Codec Requirements and Evaluation Methodology
Date de publication du RFC : Avril 2020
Auteur(s) du RFC : A. Filippov (Huawei), A. Norkin (Netflix), J.R. Alvarez (Huawei)
Pour information
Réalisé dans le cadre du groupe de travail IETF netvc
Première rédaction de cet article le 17 avril 2020
Si vous passez toutes vos soirées avachi·e devant un écran à regarder des séries sur Netflix, ce RFC est pour vous. Il est le cahier des charges d'un futur codec vidéo libre pour l'Internet. Ce codec devra gérer beaucoup de cas d'usage différents.
Concevoir un codec vidéo n'est jamais facile. Il y a beaucoup d'exigences contradictoires, par exemple minimiser le débit en comprimant, tout en n'exigeant pas de la part du processeur trop de calculs. Ce RFC, le premier du groupe de travail netvc de l'IETF, se limite au cas d'un codec utilisé au-dessus de l'Internet, mais cela fait encore plein d'usages différents, du streaming à la vidéoconférence en passant par la vidéosurveillance (celle que les politiciens hypocrites appellent la vidéoprotection, mais le RFC est plus sincère et utilise le bon terme.)
Le problème est d'autant plus difficile que plein de choses peuvent aller mal sur l'Internet, les paquets peuvent être perdus, les bits modifiés en route, etc. En pratique, tous ces incidents n'ont pas la même probabilité : les pertes sont bien plus fréquentes que les corruptions, par exemple. Si on n'est pas trop pressés (cas du téléchargement), TCP ou d'autres protocoles de transport similaires fournissent une bonne solution. Si on a des exigences temporelles plus fortes (diffusion en direct, « temps réel »), il faut parfois renoncer à TCP et, soit utiliser des réseaux idéaux (managed networks, dit le RFC, qui reprend le terme marketing de certains opérateurs qui tentent de nous faire croire qu'il existerait des réseaux sans pertes), soit trouver d'autres moyens de rattraper les pertes et les erreurs.
Depuis qu'on fait de la vidéo sur l'Internet, c'est-à-dire depuis très longtemps (malgré les prédictions des opérateurs de télécommunications traditionnels qui étaient unanimes, dans les années 1990, pour dire que cela ne serait jamais possible), toute une terminologie a été développée pour communiquer sur ce sujet. La section 2 de notre RFC rappelle les sigles importants, et quelques termes à garder en tête. Ainsi, la « compression visuellement sans perte » désigne les méthodes de compression avec perte, mais dont on ne voit pas d'effet secondaire à l'œil nu.
La section 3 de notre RFC fait ensuite le tour des applications de la vidéo sur l'Internet, pour cerner de plus près leurs caractéristiques et leurs exigences propres. (Le cahier des charges proprement dit sera en section 4.) Chaque cas d'usage est accompagné d'un tableau indiquant la résolution et la fréquence des trames souhaitées. On commence évidemment par le streaming (un des auteurs du RFC travaille chez Netflix.) Pouvoir regarder Le Messie via l'Internet est un objectif crucial. Comme les clients sont variés, et que les conditions de leur accès Internet varient en permanence (surtout s'il y a des liens radio), le codec doit tout le temps s'adapter, et pour cela tenir compte des caractéristiques de la perception humaine. L'encodage est typiquement fait une fois et une seule, lorsque la vidéo est chargée sur les serveurs. Pour cet usage :
- On peut accepter un encodeur complexe et coûteux en ressources, puisque l'encodage sera fait sur de grosses machines, et une seule fois,
- Le décodeur, par contre, doit être simple, car beaucoup de monde devra faire le décodage, et pas forcément sur des machines performantes,
- En entrée, il faut pouvoir accepter beaucoup de formats, et de types de contenus, parfois avec des particularités (le grain d'un film peut être délibéré, l'encodage ne doit pas le supprimer).
Proche du streaming mais quand même différent, il y a le partage de vidéos, usage popularisé par YouTube mais également accessible en utilisant du logiciel libre et décentralisé, comme PeerTube. C'est le monde de l'UGC : M. Michu filme des violences policières avec son petit ordiphone (ou avec sa GoPro), et les diffuse au monde entier grâce aux services de partage de vidéos.
Après le streaming et le partage de vidéos, la télévision sur IP. Il s'agit de distribuer de la télévision traditionnelle sur IP, pour permettre de se réduire le cerveau en regardant Hanouna. Cet usage se décompose en deux groupes : l'unicast, où on envoie l'émission à un seul destinataire, c'est la VoD, et le multicast où on diffuse à un grand nombre d'utilisateurs simultanément. Ce dernier est sans doute de moins en moins utilisé, à part pour les événements sportifs et les cérémonies. Le RFC se concentre sur la distribution de télévision au-desus d'un réseau « géré » (comme si les autres ne l'étaient pas…) où on peut garantir une certaine QoS. C'est par exemple le cas d'un FAI qui envoie les chaînes de télévision aux boxes des abonnés. Si on diffuse un match de foot, on souhaite que le but qui décide du sort du match atteigne les ordinateurs sans trop de retard sur les hurlements bestiaux de supporters utilisant la diffusion hertzienne, hurlements qu'on entendra dehors. Pour compliquer un peu les choses, on souhaite que l'utilisateur puisse mettre en pause, reprendre, etc.
Et la vidéoconférence ? Là aussi, le délai d'acheminement est crucial, pour qu'on n'ait pas l'impression de parler avec un astronaute perdu sur Mars. (Le RFC suggère 320 millisecondes au grand maximum, et de préférence moins de 100 ms.)
Il y a aussi le partage d'écran, où on choisit de partager l'écran de son ordinateur avec une autre personne. Comme pour la vidéoconférence, il faut du temps réel, encoder au fur et à mesure avec le plus petit retard possible.
Et les jeux vidéo, alors ? Les jeux ont souvent un contenu riche (beaucoup de vidéos). Dans certains cas, le moteur de jeu est quelque part sur l'Internet et, à partir d'un modèle 3D, génère des vidéos qu'il faut envoyer aux joueurs. Là encore, il faut être rapide : si un joueur flingue un zombie, les autres participants au jeu doivent le voir « tout de suite ». (Nombreux détails et exemples, comme GeForce Grid ou Twitch, dans le document N36771 « Game streaming requirement for Future Video Coding », de l'ISO/IEC JTC 1/SC 29/WG 11.)
Enfin, le RFC termine la liste des applications avec la vidéosurveillance. Dans le roman « 1984 », George Orwell ne donne aucun détail technique sur le fonctionnement du télécran, et notamment sur la connexion qui permet au Parti de savoir ce qui se passe chez Winston. Ici, l'idée est de connecter les caméras de vidéosurveillance à l'Internet et de faire remonter les flux vidéo à un central où on les regarde et où on les analyse. Comme l'État peut souhaiter disposer de très nombreuses caméras, le coût matériel est un critère important.
Après cet examen des cas d'usage possibles, la section 4 du RFC est le cahier des charges à proprement parler. D'abord, les exigences générales, qui concernent toutes les applications. Évidemment, le futur codec vidéo de l'Internet doit encoder efficacement, donc, dit le RFC, mieux que les codecs existants, H.265 ou VP9. Évidemment encore, l'interopérabilité entre les différentes mises en œuvre du codec est cruciale, et cela dépend en partie de l'IETF, qui devra écrire une norme claire et cohérente. Cette norme se déclinera en profils, qui limiteront certains aspects du codec, pour des cas d'usages spécifiques.
Le RFC exige également qu'il soit possible de gérer des extensions au format, pour les questions futures, tout en maintenant la compatibilité (un nouveau décodeur doit pouvoir décoder les vieilles vidéos). Le format doit permettre huit bits de couleur (par couleur) au minimum, et de préférence douze, gérer le YCbCr, permettre des résolutions quelconques, autoriser l'accès direct à un point donné de la vidéo, et bien d'autres choses encore. Et le tout doit pouvoir marcher en temps réel (aussi bien l'encodage que le décodage.) Par contre, pour l'encodage de haute qualité, le RFC autorise les encodeurs à être jusqu'à dix fois plus complexes que pour les formats existants : les ressources des ordinateurs croissent plus vite que la capacité des réseaux, et il est donc raisonnable de faire davantage d'efforts pour encoder.
Les réseaux sont imparfaits, et il faut donc gérer les erreurs. Outre les mécanismes présents dans la couche transport, le RFC demande que des mécanismes spécifiques à la vidéo soient également inclus dans le format. En parlant de couche transport, comme le but est de faire un codec vidéo pour l'Internet, le RFC rappelle l'importance de prévoir comment encapsuler le futur format dans les protocoles de transport existants.
Les exigences ci-dessus étaient impératives. Il y en a également des facultatives, par exemple un nombre de bits pour coder chaque couleur allant jusqu'à 16, la gestion du RGB, celle du transparence… Toujours dans les demandes facultatives, le RFC note qu'il serait bon que le format choisi n'empêche pas le parallélisme dans le traitement des vidéos, ce qui implique, par exemple, qu'on ne soit pas obligé de traiter toutes les images précédant une image pour encoder celle-ci. Et qu'on puisse utiliser des algorithmes qui soient acceptables pour les SIMD/GPU.
Ce n'est pas tout de faire une liste au Père Noël avec toutes les jolies choses qu'on voudrait voir dans le nouveau format, encore faut-il une bonne méthodologie pour évaluer les futures propositions. La section 5 décrit les tests à effectuer, avec plusieurs débits différents. Ces tests seront ensuite faits en comparant un codec de référence (HEVC ou VP9) aux codecs candidats pour répondre à ce cahier des charges. Comme le codec utilisera certainement des techniques dépendant de la perception humaine, ces tests « objectifs » ne suffisent pas forcément, et le RFC prévoit également des tests subjectifs, avec la procédure MOS (cf. le document ISO/IEC « PDTR 29170-1 », première partie.)
Et un petit point de sécurité pour finir : le RFC rappelle qu'encodeur et surtout décodeur doivent être paranoïaques, afin d'éviter qu'une vidéo un peu inhabituelle ne mène à des consommations de ressources déraisonnables, voire épuisant la machine.
Pour l'instant, le candidat sérieux pour répondre à ce cahier des charges est le codec AV1, notamment poussé par l'Alliance for Open Media. Mais il ne semble pas tellement se rapprocher de la normalisation formelle. Le groupe de travail ne semble plus très actif.
L'article seul
RFC 8763: Deployment Considerations for Information-Centric Networking (ICN)
Date de publication du RFC : Avril 2020
Auteur(s) du RFC : A. Rahman (InterDigital Communications), D. Trossen (InterDigital Europe), D. Kutscher (University of Applied Sciences Emden/Leer), R. Ravindran (Futurewei)
Pour information
Réalisé dans le cadre du groupe de recherche IRTF icnrg
Première rédaction de cet article le 17 avril 2020
Ce nouveau RFC annonce [mais c'est très prématuré] que l'ICN est désormais une technologie mûre et qu'il est temps de se pencher sur les problèmes pratiques de déploiement. Il documente ces problèmes, et des solutions possibles. Il décrit aussi des expériences de déploiement (très limitées et qui ont souvent disparu.)
Il y a plusieurs façons (section 4 du RFC) d'envisager le déploiement des techniques « fondées sur le contenu » (ICN) :
- Une table rase, où on remplace complètement l'Internet existant par une solution à base d'ICN. Cela implique que les actuels routeurs soient tous changés, pour des machines faisant tourner un logiciel comme NFD. (Inutile de dire que c'est complètement irréaliste.)
- Un déploiement de l'ICN comme réseau de base, avec une couche TCP/IP au-dessus, pour continuer à faire tourner l'Internet classique. Cela pose les mêmes problèmes que la table rase.
- Un déploiement de l'ICN au-dessus de l'Internet existant, un réseau virtuel, quoi, comme on faisait pour IPv6 au début. C'est le seul déploiement effectif qu'ait connu l'ICN pour l'instant, avec des idées comme CCNx sur UDP. Cela permet l'expérimentation et le déploiement progressif.
- De l'ICN « sur les côtés » du réseau. On peut envisager une
épine dorsale qui reste en TCP/IP, avec des réseaux extérieurs en
ICN, et des passerelles entre les deux. Ces réseaux extérieurs en
ICN pourraient concerner, par exemple,
l'IoT (cf.
draft-irtf-icnrg-icniot), et les passerelles transformeraient du CoAP (RFC 7252) en ICN et réciproquement. - Les technologies qui permettent de découper un réseau physique en plusieurs tranches, chacune abritant un réseau virtuel, comme la 5G, pourraient permettre de faire cohabiter harmonieusement ICN et TCP/IP sur la même infrastructure physique.
- Enfin, on peut imaginer, tant qu'on y est, des déploiements mixtes, mêlant les différentes approches citées ci-dessus.
La section 5 du RFC décrit de manière plus détaillées des chemins de migration possibles. Et la section 6 décrit quelques expériences qui ont effectivement eu lieu (on peut aussi lire le RFC 7945) :
- Le projet FP7 PURSUIT (documenté dans un article IEEE non public) se positionnait comme une approche de table rase mais, en pratique, a été déployé par dessus l'Internet existant. Il a compté jusqu'à 70 nœuds. Comme tous les projets ICN, il a été abandonné à la fin des subventions. (Pour s'amuser, regardez ce qu'est devenu le site Web du projet.)
- Le projet NDN de la NSF a également effectué un déploiement (environ 100 nœuds) sur l'Internet existant.
- Le projet ICN 2020 a produit des rapports sur ses réalisations au-dessus de TCP/IP, avec 37 nœuds ICN.
- Le projet UMOBILE a été déployé entre autre sur le réseau communautaire Guifi, avec dix Raspberry Pi. C'est raconté dans « Information-Centric Multi-Access Edge Computing Platform for Community Mesh Networks ».
Ces projets tournaient sur l'Internet d'aujourd'hui. Mais il y avait aussi d'autres projets qui se situaient plus bas dans le modèle en couches :
- POINT et RIPE ont également utilisé Guifi mais cette fois en étant directement sur le WiFi, avec TCP/IP par dessus. l'ICN.
- Un autre projet concret a connecté 60 nœuds en 6LoWPAN, en utilisant RIOT, et est documenté dans « Information Centric Networking in the IoT: Experiments with NDN in the Wild ».
- Signalons enfin (mais le RFC en liste d'autres) le projet Doctor, sur lequel a été testé le transport de trafic HTTP réel.
Le RFC note qu'aucun de ces déploiements n'a dépassé mille utilisateurs. Pour moi, il s'agissait clairement d'expérimentation et appeler ça « déploiement » est trompeur.
La section 7 du RFC discute des points qui manquent pour des déploiements significatifs, notamment question normalisation. La liste est longue. Le RFC note entre autres :
- Le problème des applications ; un navigateur Web existant n'a aucun moyen de savoir s'il doit récupérer un contenu en ICN ou par des moyens classiques. Aucune API ne permet au programmeur de contrôler ce choix. De même, aucune API vaguement standard n'existe pour utiliser les capacités de l'ICN.
- Le nommage des objets dans l'ICN n'est pas normalisé, quoique il existe des tentatives comme celle du RFC 6920 (voir aussi les RFC 8569 et RFC 8609.)
- Et il y a tous les autres problèmes pratiques, comme l'OAM…
- La sécurité a droit à sa propre section, la 10. (Voir aussi le RFC 7945.) Elle n'a guère été testée en vrai pour l'instant, à part peut-être dans le projet Doctor (voir « Content Poisoning in Named Data Networking: Comprehensive Characterization of real Deployment », une étude détaillée de l'attaque par empoisonnement du contenu, où un méchant producteur essaie d'envoyer du contenu malveillant aux clients, ou bien « A Security Monitoring Plane for Named Data Networking Deployment », les deux articles se sont spécialement concentrés sur NFD.) Compte-tenu de l'expérience de l'Internet, cela sera pourtant un point crucial.
L'article seul
RFC 8753: Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions
Date de publication du RFC : Avril 2020
Auteur(s) du RFC : J. Klensin, P. Faltstrom (Netnod)
Chemin des normes
Première rédaction de cet article le 16 avril 2020
La norme IDN, qui permet depuis 2003 les noms de domaine en Unicode était autrefois liée à une version particulière d'Unicode. La révision de cette norme en 2010 a libérédélivré IDN d'une version spécifique. La liste des caractères autorisés n'est plus statique, elle est obtenue par l'application d'un algorithme sur les tables Unicode. Tout va donc bien, et, à chaque nouvelle version d'Unicode, il suffit de refaire tourner l'algorithme ? Hélas non. Car, parfois, un caractère Unicode change d'une manière qui casse la compatibilité d'IDN et qui, par exemple, rend invalide un nom qui était valide auparavant. La norme IDN prévoit donc un examen manuel de chaque nouvelle version d'Unicode pour repérer ces problèmes, et décider de comment les traiter, en ajoutant une exception spécifique, pour continuer à utiliser ce caractère, ou au contraire en décidant d'accepter l'incompatibilité. Ce nouveau RFC ne change pas ce principe, mais il en clarifie l'application, ce qui est d'autant plus nécessaire que les examens prévus n'ont pas toujours été faits, et ont pris anormalement longtemps, entre autre en raison de l'absence de consensus sur la question.
Le RFC à lire avant celui-ci, pour réviser, est le RFC 5892. Il définit l'algorithme qui va décider, pour chaque caractère Unicode, s'il est autorisé dans les noms de domaine ou pas. À chaque version d'Unicode (la dernière est la 13.0), on refait tourner l'algorithme. Bien qu'Unicode soit très stable, cela peut faire changer un caractère de statut. Si un caractère auparavant interdit devient autorisé, ce n'est pas grave. Mais si l'inverse survient ? Des noms qui étaient légaux cessent de l'être, ne laissant le choix qu'entre deux solutions insatisfaisantes, supprimer le nom, ou bien ajouter une exception manuelle (procédure qui n'est pas parfaitement définie dans le RFC 5892, qui sera faite, si tout va bien, par de nouveaux RFC.)
[Notez que ce RFC affirme que les registres sont responsables des noms qu'ils autorisent, point de vue politique et non technique, contestable et d'ailleurs contesté.]
En quoi consiste donc le nouveau modèle d'examen qui accompagne la sortie d'une nouvelle version d'Unicode ? La section 3 du RFC l'expose. D'abord faire tourner l'algorithme du RFC 5892, puis noter les caractères qui ont changé de statut. Cela doit être fait par un expert nommé par l'IESG (DE, pour Designated Expert, actuellement Patrik Fältström, un des auteurs du RFC.) Puis réunir un groupe d'experts (il faut un groupe car personne n'est compétent dans tous les aspects d'IDN à la fois, ni dans toutes les écritures normalisées, cf. annexe B ; si l'IETF n'a pas de problèmes à trouver des experts en routage, elle doit par contre ramer pour avoir des experts en écritures humaines.) La recommandation pour ce groupe est d'essayer de préserver le statut des caractères et donc, si nécessaire, de les ajouter à une table d'exceptions (le RFC 6452 avait pris la décision opposée.) Le fait d'avoir des experts explicitement nommés va peut-être permettre d'éviter le syndrome du « il faudrait que quelqu'un s'en occupe » qui avait prévalu jusqu'à présent.
La promesse de publier les tables résultant de l'algorithme du
RFC 5892 n'ayant pas été tenue (ce qui a
fait râler), le RFC espère que cette fois, le travail sera
fait. Pour l'instant, l'état actuel de la révision est dans
l'Internet-Draft
draft-faltstrom-unicode12-00.
L'annexe A résume les changements depuis le RFC 5892 (qui n'est pas remplacé, juste modifié légèrement) :
- Séparer explicitement l'examen des nouvelles versions d'Unicode en deux, la partie algorithmique et la partie plus politique,
- Désigner un groupe d'experts pour cette deuxième partie,
- Et quelques autres détails pratico-bureaucratiques sur l'organisation du travail.
La section 2 du RFC rappelle l'histoire d'IDN. La norme originale, le RFC 3490 définissait l'acceptabilité de chaque caractère dans un nom de domaine. Lorsqu'une nouvelle version d'Unicode sortait, il n'y avait pas de mécanisme pour décider d'accepter ou non les nouveaux caractères. Il aurait fallu refaire un nouveau RFC pour chaque version d'Unicode (il y en a environ une par an.) La version 2 d'IDN, dans le RFC 5890, a changé cela, en décidant de normaliser l'algorithme et non plus la liste des caractères. L'algorithme, décrit en détail dans le RFC 5892, utilise les propriétés indiquées dans la base de données Unicode (cf. la norme, sections 4 et 3.5) pour décider du sort de chaque caractère. Dans un monde idéal, ce sort ne change pas d'une version d'Unicode à l'autre. Si les propriétés Unicode des caractères sont stables, le statut (accepté ou refusé) restera le même, l'algorithme ne servant vraiment que pour les nouveaux caractères introduits par la nouvelle version d'Unicode. Mais, bien qu'Unicode fasse certaines promesses de stabilité, elles ne sont pas totales : un caractère peut donc se retrouver accepté une fois, puis refusé. Le RFC 5892 prévoyait donc, à juste titre, un examen manuel, et le RFC 5892 décrivait une table d'exceptions permettant de maintenir la compatibilité (section 2.7). Cette table aurait pu être remplie au fur et à mesure, pour conserver une certaine stabilité. Mais un tel examen n'a été fait qu'une fois, pour Unicode 6, dans le RFC 6452, suite à quoi il a été décidé de ne pas ajouter d'exceptions (et donc de laisser des noms devenir invalides.) En 2015, l'IAB avait demandé que les mises à jour soient suspendues, suite au « problème » (dont tout le monde n'est pas convaincu) du caractère arabe bāʾ avec hamza (ࢡ, U+08A1). Puis, en 2018, avait insisté sur l'importance de terminer ce travail. Deux ans après, ce n'est toujours pas fait. Donc, en pratique, IDNA version 2 n'a pas encore tenu sa promesse de pouvoir être mis à jour « presque » automatiquement.
À noter un autre problème avec la nouvelle version d'IDN : le fait qu'un caractère soit autorisé ou pas dépend d'un algorithme, et non plus d'une table statique. Mais, pour faciliter la vie des utilisateurs, l'IANA avait produit des tables en appliquant l'algorithme aux données Unicode. Il a toujours été prévu que ces tables soient juste une aide, qu'elles ne fassent pas autorité mais, malheureusement, certaines personnes les ont compris comme étant la référence, ce qui n'était pas prévu. Comme ces tables IANA n'ont pas été mises à jour au fur et à mesure des versions d'Unicode, le problème devient sérieux. Le RFC demande à l'IANA de modifier la description des tables pour insister sur leur caractère non-normatif (« It should be stressed that these are not normative in that, in principle, an application can do its own calculations and these tables can change as IETF understanding evolves. ».)
J'ai écrit que tout le monde n'était pas convaincu de la nature du problème. Il y a en effet un désaccord de fond au sujet d'Unicode, entre ceux qui considèrent que toutes les lettres se valent, que toutes les écritures doivent avoir le même statut et, ceux, souvent des utilisateurs de l'alphabet latin, que la diversité dérange et qui voudraient mieux contrôler les caractères « dangereux », en utilisant des arguments de sécurité contestables. La question est d'autant plus sérieuse que les retards de mise à jour d'IDN (qui est toujours en version 6 alors qu'Unicode est en version 13) handicape surtout les utilisateurs des écritures les plus récemment ajoutées dans Unicode, en général des peuples minoritaires et peu présents dans le business international. Le retard n'est donc pas forcément gênant de la même manière pour tout le monde…
L'article seul
RFC 8724: SCHC: Generic Framework for Static Context Header Compression and Fragmentation
Date de publication du RFC : Avril 2020
Auteur(s) du RFC : A. Minaburo (Acklio), L. Toutain (IMT-Atlantique), C. Gomez (Universitat Politecnica de Catalunya), D. Barthel (Orange Labs), JC. Zuniga (SIGFOX)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF lpwan
Première rédaction de cet article le 16 avril 2020
Ce nouveau RFC décrit un mécanisme de compression des données, et de fragmentation des paquets, optimisé pour le cas des réseaux à longue distance lents connectant des objets contraints en ressources, ce qu'on nomme les LPWAN (Low-Power Wide Area Network, par exemple LoRaWAN.) L'un des buts est de permettre l'utilisation des protocoles Internet normaux (UDP et IPv6) sur ces LPWAN. SCHC utilise un contexte de compression et décompression statique : il n'évolue pas en fonction des données envoyées.
Le LPWAN (RFC 8376) pose en effet des défis particuliers. Il a une faible capacité, donc chaque bit compte. Il relie des objets ayant peu de ressources matérielles (par exemple un processeur très lent). Et la batterie n'a jamais assez de réserves, et émettre sur un lien radio coûte cher en énergie (1 bit reçu ou transmis = 1-1000 microjoules, alors qu'exécuter une instruction dans le processeur = 1-100 nanojoules.) . Le but de l'IETF est de pouvoir utiliser IPv6 sur ces LPWAN et la seule taille de l'en-tête IPv6 est un problème : 40 octets, dont plusieurs champs « inutiles » ou redondants, et qui auraient donc tout intérêt à être comprimés.
Trois choses importantes à retenir sur SCHC (Static Context Header Compression) :
- N'essayez pas de prononcer le sigle « èsse cé hache cé » : on dit « chic » en français, et « sheek » en anglais.
- Comme tout algorithme de compression, SCHC repose sur un contexte commun au compresseur et au décompresseur, contexte qui regroupe l'ensemble des règles suivies pour la compression et la décompression. Mais, contrairement aux mécanismes où le contexte est dynamiquement modifié en fonction des données transmises, ici le contexte est statique ; il n'évolue pas avec les données. Cela élimine notamment tout risque de désynchronisation entre émetteur et récepteur. (Contrairement à des protocoles comme ROHC, décrit dans le RFC 5795.)
- SCHC n'est pas un protocole précis, c'est un cadre générique, qui devra être incarné dans un protocole pour chaque type de LPWAN. Cela nous promet de nouveaux RFC dans le futur. L'annexe D liste les informations qu'il faudra spécifier dans ces RFC.
Si les LPWAN posent des problèmes particuliers, vu le manque de ressources disponibles, ils ont en revanche deux propriétés qui facilitent les choses :
- Topologie simple, avec garantie que les paquets passent au même endroit à l'aller et au retour,
- Jeu d'applications limité, et connu à l'avance, contrairement à ce qui arrive, par exemple, avec un ordiphone.
La section 5 de notre RFC expose le fonctionnement général de SCHC. SCHC est situé entre la couche 3 (qui sera typiquement IPv6) et la couche 2, qui sera une technologie LPWAN particulière, par exemple LoRaWAN (pour qui SCHC a déjà été mis en œuvre). Après compression, le paquet SCHC sera composé de l'identificateur de la règle (RuleID), du résultat de la compression de l'en-tête, puis de la charge utile du paquet. Compresseur et décompresseur doivent partager le même ensemble de règles, le contexte. Le contexte est défini de chaque côté (émetteur et récepteur) par des mécanismes non spécifiés, par exemple manuellement, ou bien par un protocole d'avitaillement privé. Chaque règle est identifiée par son RuleID (section 6 du RFC), identificateur dont la syntaxe exacte dépend d'un profil de SCHC donc en pratique du type de LPWAN. (Rappelez-vous que SCHC est un mécanisme générique, les détails concrets de syntaxe sont spécifiés dans le profil, pas dans SCHC lui-même.)
Les règles sont expliquées dans la section 7. Chaque règle comporte plusieurs descriptions. Chaque description comprend notamment :
- L'identificateur du champ concerné (SCHC ne traite pas l'en-tête globalement, mais champ par champ), par exemple « port de destination UDP ».
- Longueur et position du champ.
- Valeur cible (TV, Target Value), qui est la valeur à laquelle on va comparer le champ.
- Opérateur de comparaison (MO, pour Matching Operator), l'égalité complète, par exemple, ou bien l'égalité de seulement les N bits de plus fort poids.
- Action (CDA, Compression Decompression Action), qui indique quoi faire si le contenu du champ correspond à la valeur cible. Par exemple, ne pas transmettre le champ (si sa valeur est une valeur connue), ou bien (pour le décompresseur) recalculer la valeur à partir des données. La liste des actions possibles figure dans un tableau en section 7.4. (Elle est fixée une fois pour toutes, il n'est pas prévu de procédure d'enregistrement de nouvelles possibilités.)
L'algorithme est donc : pour chaque description dans une règle, voir si elle correspond au champ visé, en utilisant l'opérateur de comparaison et la valeur cible. Si toutes les descriptions collent, appliquer les actions, et envoyer les données comprimées, précédées de l'identificateur de la règle. Un RuleID spécial est utilisé pour attraper tout le reste, les paquets qui ne seront pas comprimés car aucune règle ne correspondait.
Prenons un exemple : la règle de RuleID 1 a
deux descriptions, qui disent
que les champs X et Y de l'en-tête ont une valeur connue (indiquée
dans la valeur cible), mettons respectivement 42 et « foobar ». Dans
ce cas, les actions de compression (CDA, Compression
Decompression Action) peuvent être simplement « omets ces
champs » (not-sent). Le décompresseur, à
l'autre bout, a la même règle (rappelez-vous que le contexte,
l'ensemble des règles, est statique). Lorsque qu'il voit passer un
paquet comprimé avec la règle 1, il crée simplement les deux champs,
avec les valeurs définies dans la règle (valeurs TV, Target
Value.)
Un exemple figure en section 10 du RFC, avec des règles pour
comprimer et décomprimer les en-têtes IPv6 et UDP. Ainsi, le champ
Version d'IPv6 vaut forcément 6. On met donc la valeur cible (TV) à
6, l'opérateur de comparaison (MO) à « ignorer » (on ne teste pas
l'égalité, on est sûr d'avoir 6, si le paquet est correct), et
l'action (CDA) à not-sent (ne pas envoyer). Le
champ Longueur, par contre, n'a pas de valeur cible, l'opérateur de
comparaison est « ignorer », et l'action est
compute (recalculer à partir des données).
Pour UDP, on peut également omettre les ports source et destination si, connaissant l'application, on sait qu'ils sont fixes et connus, et on peut également recalculer le champ Longueur, ce qui évite de le transmettre. La somme de contrôle est un peu plus compliquée. IPv6 en impose une (RFC 8200, section 8.1) mais autorise des exceptions. Ne pas l'envoyer peut exposer à des risques de corruption de données, donc il faut bien lire le RFC 6936 et le RFC 6282 avant de décider d'ignorer la somme de contrôle. Les règles complètes pour UDP et IPv6 sont rassemblées dans l'annexe A du RFC.
Outre la compression, SCHC permet également la fragmentation (section 8 du RFC). La norme IPv6 (RFC 8200) dit que tout lien qui fait passer de l'IPv6 doit pouvoir transmettre 1 280 octets. C'est énorme pour du LPWAN, où la MTU n'est parfois que de quelques dizaines d'octets. Il faut donc effectuer fragmentation et réassemblage dans la couche 2, ce que fait SCHC (mais, désolé, je n'ai pas creusé cette partie, pourtant certainement intéressante .)
La section 12 de notre RFC décrit les conséquences de SCHC sur la sécurité. Par exemple, un attaquant peut envoyer un paquet avec des données incorrectes, dans l'espoir de tromper le décompresseur, et, par exemple, de lui faire faire de longs calculs, ou bien de générer des paquets de grande taille, pour une attaque avec amplification. Comme toujours, le décompresseur doit donc se méfier et, entre autres, ne pas générer de paquets plus grands qu'une certaine taille. Question sécurité, on peut aussi noter que SCHC n'est pas vulnérable aux attaques comme CRIME ou BREACH, car il traite les différents champs de l'en-tête séparément.
La fragmentation et le réassemblage amènent leurs propres risques, qui sont bien connus sur l'Internet (d'innombrables failles ont déjà été trouvées dans les codes de réassemblage de paquets fragmentés.) Par exemple, une attaque par déni de service est possible en envoyant plein de fragments, sans jamais en envoyer la totalité, forçant le récepteur à consommer de la mémoire pour stocker les fragments en attente de réassemblage. Là encore, le récepteur doit être prudent, voire paranoïaque, dans son code. Par contre, les attaques utilisant la fragmentation pour se dissimuler d'un IDS ne marcheront sans doute pas, puisque SCHC n'est utilisé qu'entre machines directement connectées, avec probablement aucun IDS sur le lien.
Merci à Laurent Toutain pour avoir attrapé une sérieuse erreur dans cet article et à Dominique Barthel pour sa relecture très attentive.
L'article seul
RFC 8770: Host Router Support for OSPFv2
Date de publication du RFC : Avril 2020
Auteur(s) du RFC : K. Patel (Arrcus), P. Pillay-Esnault
(PPE
Consulting), M. Bhardwaj, S. Bayraktar
(Cisco)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ospf
Première rédaction de cet article le 13 avril 2020
Le protocole de routage OSPF, dans sa version 2, a une particularité amusante : dès qu'une machine participe au protocole, et échange des messages avec les autres, elle va être considérée comme un routeur, à qui on peut envoyer du trafic à faire suivre. Or, on peut souhaiter observer le routage sans être soi-même routeur. D'où ce RFC, qui prévoit un moyen de mettre dans les messages : « je suis juste un observateur, ne m'envoie pas de paquets à router ».
Dans quels cas trouve-t-on ces machines qui participent à un protocole de routage mais ne veulent pas transmettre les paquets des autres ? La section 1 du RFC cite plusieurs cas, dont :
- Un routeur en train de redémarrer et qui n'est pas encore prêt à transmettre des paquets,
- Un routeur surchargé de travail et qui souhaite demander qu'on arrête de l'utiliser (mais qui a besoin de continuer à connaitre les routes existantes),
- Des réflecteurs de route.
La solution proposée dans ce RFC est d'ajouter aux messages OSPF un bit, le bit H (Host bit). Lors du calcul des routes avec SPF (section 16.1 du RFC 2328, qui normalise OSPF version 2), les routeurs ayant le bit H seront exclus. Ce bit utilise un des bits inutilisés du LSA (Link State Advertisement) de routeur (RFC 2328, section A.4.2), et il est enregistré à l'IANA.
Difficulté classique quand on modifie un protocole, surtout ancien et très répandu, comme OSPF, la cohabitation entre anciens et récents logiciels. Que se passe-t-il si un réseau mêle des routeurs qui envoient le bit H et d'autres qui ne connaissent pas ce bit ? La section 5 explique la solution : en utilisant les extensions du RFC 7770, un LSA Router Information est envoyé, indiquant qu'on sait gérer le bit H (capacité Host Router, cf. le registre IANA.) Les routeurs connaissant notre RFC ne tiendront compte du bit H que si tous les routeurs de la zone OSPF ont annoncé cette capacité.
L'article seul
Fiche de lecture : Les furtifs
Auteur(s) du livre : Alain Damasio
Éditeur : La volte
978-2370-490742
Publié en 2019
Première rédaction de cet article le 7 avril 2020
J'ai aimé le dernier roman d'Alain Damasio, « Les furtifs », autant que « La horde du contrevent », ce qui n'est pas peu dire.
Mais, cette fois, le roman ne se passe plus dans une planète lointaine et bizarre mais chez nous. Enfin, un peu dans le futur, quand même. Il s'agit d'une dystopie où le pays est contrôlé par un gouvernement autoritaire, où tout est privatisé et ne fonctionne que pour le profit, et où les inégalités entre « premiers de cordée » et la masse sont ouvertement assumées ; par exemple, certaines rues de la ville sont réservées aux citoyens favorisés (il n'y a de toute façon plus guère d'espace public). Les activités non lucratives sont réprimées (l'un des personnages est « proferrante », ce qui veut dire qu'elle donne des cours clandestins, enfreignant le monopole des compagnies privées.)
Tout cela est évidemment compliqué à gérer mais, cette fois, il y a le numérique : tout est surveillé et fiché, et le citoyen sait exactement où il a le droit d'aller, et les systèmes de surveillance et de répression savent où est chacun. Comme toutes les dystopies, c'est exagéré mais… pas si exagéré que cela. On se dit qu'il ne manque pas grand'chose aux sociétés modernes pour arriver à ce stade. Pas une dictature totale et brutale comme dans « 1984 », non, simplement un monde bien contrôlé, une smart city totale.
Bien sûr, tout le monde n'est pas d'accord. Dans les interstices du système, il y a des protestations, des tentatives d'élargir les rares espaces de liberté, voire des franches rébellions. Et puis il y a des choses (choses ?) mystérieuses, les Furtifs, dont on ne sait pas grand'chose mais que l'armée traque, dans le doute. Et c'est au sein même de l'unité d'élite anti-Furtifs que vont naître les questions.
Je ne vais pas essayer de résumer le reste du livre, d'abord pour vous laisser le plaisir de la découverte et ensuite parce que le livre est riche, très riche, et part dans tous les sens. Il faut du temps pour y entrer et pour l'explorer dans tous les sens.
Comme dans « La horde du contrevent », le récit est fait par plusieurs des personnages, avec des jolis signes typographiques pour indiquer qui parle. Ne perdez donc pas de vue le rabat qui les résume.
L'article seul
Articles des différentes années : 2020 2019 2018 2017 2016 2015 2014 Précédentes années
Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.
