Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

echoping

Ève

Recherche dans ce blog :

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.


Quel nom vérifier dans un certificat X.509, si on a été redirigé ?

Première rédaction de cet article le 27 Janvier 2012


Une discussion animée vient d'avoir lieu sur la liste du groupe de travail IETF DANE, qui travaille à permettre l'utilisation de certificats dans le DNS (en simplifiant, il s'agit de remplacer X.509 par DNSSEC, voir mon exposé aux JRES). La question était « Lorsqu'il y a eu des redirections vers un autre nom de domaine, quel nom chercher dans le certificat ? Celui de départ ? Celui d'arrivée ? »

Prenons un exemple concret pour voir. Supposons un protocole nommé PDP (pour Pur Distribution Protocol) qui permettre de récupérer des contenus (musique, films, etc) qui avaient été auparavant chargés sur un serveur. Pour trouver le serveur adéquat, mettons que cet hypothétique PDP utilise les enregistrements SRV du DNS (RFC 2782), afin d'assurer la répartition de charge, et la résistance aux pannes. Mettons que le domaine microupload.example ait deux serveurs, on aurait quelque chose comme :

_pdp._tcp.microupload.example.    SRV     0 0 6642  content.example.com.
                                  SRV     1 0 6642  content.backup.example.

Vu les priorités (le premier chiffre après SRV), le second serveur ne sera utilisé qu'en cas de panne du premier. Mais, et c'est là que ça devient intéressant, on va supposer que PDP, pour échapper à des gens malintentionnés qui voudraient savoir ce qu'on télécharge, chiffre toutes ses communications avec TLS et authentifie le serveur avec X.509. Imaginons que le premier serveur soit en panne à ce moment et que le client PDP se connecte donc à content.backup.example. À quel nom doit être le certificat de ce dernier ? microupload.example parce que c'est le point de départ de la transaction ? content.backup.example parce que c'est le nom du serveur ? Prenez le temps de réflechir à cette question cinq minutes, et essayez de faire une liste des raisons en faveur du premier choix et de celles en faveur du second. Il est probable que vous en oublierez, car le problème est compliqué.

Vous y êtes ? Vous avez vraiment cherché ? Bon, alors, maintenant, des éléments de réponse. Le problème du groupe DANE avait été enregistré comme ticket #28 mais, si vous n'avez pas lu le RFC 6394, ce n'est pas trop grave, la question n'est pas du tout spécifique à DANE. Elle a même fait l'objet d'un RFC entier, le RFC 6125, que je trouve personnellement peu lisible. Son principal mérite est de montrer que la question de l'identité n'est pas triviale du tout et qu'elle peut signifier des choses différentes selon la personne.

Et la question n'est pas non plus spécifique aux enregistrements SRV comme dans l'exemple ci-dessus. On aurait la même question, par exemple avec des MX.

Alors, une liste de raisons en faveur du premier choix, utiliser le nom de départ (ici, microupload.example :

  • Le nom de départ est celui que voit l'utilisateur. C'est celui en lequel il a confiance. C'est le nom du service, pas celui du serveur du moment.
  • Si la résolution DNS n'est pas sécurisée (par exemple avec DNSSEC), rien ne prouve que le SRV obtenu est légitime. X.509 ne servirait à rien dans ce cas. (Notez que, dans le cas spécifique de DANE, DNSSEC est obligatoire donc, si on décide que le nom utilisé par DANE sera le premier, il sera sécurisé par DNSSEC de toute façon.)

Et les raisons d'utiliser au contraire le nom d'arrivée, ici content.backup.example ?

  • Dans le cas d'un serveur qui héberge des services pour des milliers de domaines différents, il faudra gérer beaucoup de certificats.
  • Il existe plusieurs méthodes pour avoir plusieurs certificats sur la même machine. Si la méthode choisie est de mettre tous les noms dans un même certificat, celui qui se connecte peut apprendre la liste de tous les clients (au sens affaires, pas au sens protocole réseau) du serveur juste en regardant le certificat.
  • Dans le cas où le serveur n'est pas géré par la même organisation que le domaine (ce qui est fréquent aujourd'hui), une stricte coordination sera nécessaire. Si le domaine acquiert un nouveau certificat, il leur faudra s'assurer qu'il est bien installé sur le serveur.

Bref, tester le domaine de départ est en général meilleur du point de vue sécurité, mais tester le domaine d'arrivée facilite en général le déploiement.

Mais, puisque le problème est connu depuis longtemps, que spécifient les différents RFC sur les protocoles qui utilisent TLS ? Eh bien, souvent, ce n'est pas clair. Essayez de lire le RFC 3207 pour voir ce que devrait faire un bon client SMTP, par exemple. Le vocabulaire peu stable du RFC ne permet guère de trancher. L'avis dominant est toutefois que SMTP doit utiliser le domaine d'arrivée. Donc, s'il y a un MX :

michu.example.     IN      MX      10 mail.provider.example

Alors, le MTA qui essaiera de transmettre du courrier en TLS à monsieur@michu.example cherchera sur l'autre MTA un certificat portant le nom de mail.provider.example.

Mais, et c'est là que cela devient amusant, d'autres protocoles ont pu faire des choix différents ! C'est ainsi que XMPP spécifie le contraire, on doit utiliser le domaine du début, avant toute redirection (RFC 6120, section 5.4.3.1). Et pour HTTP ? Ce dernier n'utilise pas d'enregistrement DNS de redirection (comme les MX ou les SRV). Il ne reste donc comme possibilité de piège, au niveau DNS, que les CNAME. Ceux-ci sont délicats car, contrairement aux SRV ou MX, la bibliothèque qui fait la résolution ne donne pas forcément à l'application (ici, le navigateur), une indication sur la présence ou nom d'un alias (un enregistrement CNAME). Le RFC 2818 n'est pas parfaitement clair mais semble de toute façon avoir choisi aussi l'approche « domaine de départ » (ici, celui qui est dans l'URI).

Et que va faire le groupe DANE ? La question n'est pas encore définitivement tranchée mais ce sera probablement « chaque protocole se débrouille » car il est trop difficile de spécifier un choix qui convienne à tous.


L'article seul

Changer une base PostgreSQL de « tablespace »

Première rédaction de cet article le 22 Janvier 2012


Un des principaux mécanismes de gestion de l'espace disque dans PostgreSQL est le tablespace. Un tablespace est un répertoire où on place des données du SGBD. Mais, si on change d'avis, comment changer une base de tablespace ?

La tablespace par défaut d'une base se déclare à la création :

% createdb --tablespace grosdisque experience

Ici, la base "experience" est créée sur le tablespace "grosdisque" (créé précédemment par CREATE TABLESPACE). On peut afficher les tablespaces par défaut des bases avec le catalogue système de PostgreSQL :

=> SELECT datname AS database, spcname AS tablespace, spclocation AS directory 
          FROM pg_database INNER JOIN pg_tablespace 
          ON pg_tablespace.oid = pg_database.dattablespace;
     database      |     tablespace     |   directory   
-------------------+--------------------+---------------
 template1         | pg_default         | 
 essais            | pg_default         | 
 experience        | grosdisque         | /some/where/big
...

Et si on s'est trompé, si on a oublié de mettre la base sur le bon tablespace, si la base a grossi au delà de ce qui était prévu ? Depuis la version 8.4 de PostgreSQL, il existe un moyen simple, la commande ALTER DATABASE :


essais=> ALTER DATABASE experience SET TABLESPACE autreendroit;
ERROR:  database "experience" is being accessed by other users
DETAIL:  There are 1 other session(s) using the database.

(Ah oui, il faut qu'aucune session n'accède à la table, ce qui peut
être contraignant.)

essais=> ALTER DATABASE experience SET TABLESPACE autreendroit;
ALTER DATABASE

Et si on gère une base dans une version antérieure de PostgreSQL, et qu'on ne peut pas migrer ? Rien n'est perdu. Il y a bien sûr la solution « bourrin » d'une commande pg_dump, d'une re-création de la base sur le nouveau tablespace, puis d'un pg_restore. C'est très lent, et cela empêche d'accéder à la base en écriture pendant ce temps.

Une solution plus astucieuse est documentée par Lode : elle utilise le fait que le tablespace n'est pas forcément par base mais peut être configuré par table et qu'il est possible, même avant la version 8.4 de PostgreSQL, de changer une table de tablespace. Le principe est donc :


essais=> ALTER DATABASE experience SET default_tablespace = autreendroit;

(Cette première commande changera le tablespace pour les *futures*
tables.)

essais=> ALTER TABLE premiere_table SET TABLESPACE autreendroit;
essais=> ALTER TABLE deuxieme_table SET TABLESPACE autreendroit;
...

Oui, il faut le faire pour toutes les tables, et pour les index également. Ce n'est pas très pratique. Lode automatisait avec PHP, je préfère le faire avec le shell :

% psql --tuples-only -c 'SELECT tablename FROM pg_tables' experience > tmp/tables
% for table in $(cat tmp/tables); do
   echo $table
   psql -c "ALTER TABLE $table SET TABLESPACE autreendroit;" experience
done

Et même chose avec les index :

% psql --tuples-only -c 'SELECT indexname FROM pg_indexes' experience >  tmp/indexes
% for idx in $(cat tmp/indexes); do
   echo $idx
   psql -c "ALTER INDEX $idx SET TABLESPACE autreendroit;" experience
done

C'est bien plus rapide que sauvegarder/restaurer. Rappelez-vous bien que cela ne change pas le tablespace de la base. Il apparaîtra toujours comme l'ancien. Mais toutes les données seront bien dans le nouveau tablespace.

Après, à vous de voir si cela ne serait pas plus simple de migrer vers un PostgreSQL >= 8.4. Mais les grosses bases de données sont souvent des choses fragiles, avec lesquelles on ne peut pas jouer comme on veut. J'ai récemment utilisé la vieille méthode pour une base qu'il aurait été risqué de migrer.


L'article seul

Panne Wi-Fi d'une Freebox v5

Première rédaction de cet article le 21 Janvier 2012
Dernière mise à jour le 23 Janvier 2012


Il m'est arrivé quelque chose de curieux avec mon ancienne Freebox, une v5. Elle servait entre autres de borne Wi-Fi. Et tout à coup, son signal Wi-Fi est devenu dix fois plus faible, non captable par beaucoup d'appareils.

Elle avait plusieurs clients différents, par exemple un smartphone HTC Desire, une tablette Packard Bell Liberty Pad, un ordinateur portable Dell, etc. Tous étaient contents et pouvaient se connecter de tout l'appartement. Et, un soir, fini. Le signal avait terriblement baissé. Le smartphone ne voyait plus rien. Plus de Wi-Fi pour lui. La tablette pouvait encore se connecter, mais uniquement lorsqu'elle était dans la même pièce que la Freebox. L'ordinateur portable avait la puce la plus sensible : il y arrivait encore de tout l'appartement, mais avec de fréquentes déconnexions.

Bien que le problème ait frappé tous mes appareils en même temps, j'ai cherché si le problème ne venaient pas d'eux (par exemple, s'il ne fallait pas que j'essaie un autre fichier binaire « radio » sur CyanogenMod pour le smartphone). J'ai aussi tenté de changer le canal Wi-Fi de la Freebox, sans résultat.

Le problème a été résolu lors du remplacement de la Freebox v5 par une v6 Révolution. Tout refonctionne comme avant. C'était donc bien un problème matériel (comme me l'avait suggéré un employé de Free, lors d'une réception officielle prestigieuse). La v5 accusait son (pourtant jeune) âge et ses circuits commençaient à casser.

De quoi philosopher sur la fragilité des engins numériques que nous accumulons chez nous.

Au fait, j'ai renvoyé l'ancienne Freebox à Free (elles ne sont pas vendues mais mises à la disposition de l'abonné). Quelqu'un sait comment prévenir Free qu'elle ne marche pas bien et ne doit donc pas être utilisée ? Sans passer par le support officiel, ses heures d'attente et ses questions débiles « avez-vous rebooté votre ordinateur ? ». Selon @LALIGNEDEFREE, les Freebox de retour sont systématiquement testées et il n'est donc pas nécessaire de signaler un problème.

J'ai obtenu de suggestions intéressantes (mais trop tard pour tester, la boîte étant repartie) :

  • De @fuktop13 et de nombreux autres : ce serait un problème d'alimentation électrique. Lorsque celle-ci faiblit, certaines fonctions de la boîte sont plus affectées que d'autres. Il faudrait alors changer ladite alimentation. Le nombre de témoignages reçus (y compris par des employés de Free) me pousse à privilégier cette théorie.
  • De @RenaudGuerin, l'idée que ce pourrait être un faux contact avec l'antenne (qui est externe, sur la Freebox v5).
  • Jean-Philippe Pick suggère un problème logiciel : le logiciel de la boîte est mis à jour automatiquement au démarrage de celle-ci (je n'ai pas fait attention si cela avait été le cas avant la panne) et une nouvelle version aurait pu avoir des problèmes avec la puce Ralink de la Wi-Fi.

L'article seul

RFC 6347: Datagram Transport Layer Security version 1.2

Date de publication du RFC : Janvier 2012
Auteur(s) du RFC : E. Rescorla (RTFM), N. Modadugu (Stanford University)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF tls
Première rédaction de cet article le 21 Janvier 2012


Le protocole de cryptographie TLS, normalisé dans le RFC 5246, ne s'appliquait traditionnellement qu'à TCP. Les applications utilisant UDP, comme le fait souvent la téléphonie sur IP, ne pouvaient pas utiliser TLS pour protéger leur trafic contre l'écoute ou la modification des données. Mais cette limitation a disparu avec DTLS, qui permet de protéger du trafic UDP. Ce RFC met à jour DTLS (initialement normalisé dans le RFC 4347) pour TLS 1.2.

TLS ne tournait que sur TCP car il avait besoin d'un transport fiable, garantissant que les données arrivent toutes, et dans l'ordre. Le grand succès de TLS (notamment utilisé pour HTTP et IMAP) vient de sa simplicité pour le programmeur : rendre une application capable de faire du TLS ne nécessite que très peu de code, exécuté juste avant l'envoi des données. Par contre, cela laissait les applications UDP comme SIP non protégées (section 1 de notre RFC). Les solutions existantes comme IPsec ne sont pas satisfaisantes (cf. RFC 5406), notamment parce qu'elles n'offrent pas la même facilité de déploiement que TLS, qui tourne typiquement dans l'application et pas dans le noyau.

DTLS a été conçu pour fournir TLS aux applications UDP. Il offre les mêmes services que TLS : garantie de l'intégrité des données et confidentialité.

La section 3 explique les principes de DTLS : protégé ou pas par DTLS, UDP a la même sémantique, celle d'un service de datagrammes non fiable. D'autre part, DTLS est une légère modification de TLS : il en garde les principales propriétés, bonnes ou mauvaises.

Mais pourquoi ne peut-on pas faire du TLS normal sur UDP ? Parce que TLS n'a pas été conçu pour tourner au dessus d'un protocole non fiable. TLS organise les données en enregistrements (records) et il ne permet pas de déchiffrer indépendamment les enregistrements. Si l'enregistrement N est perdu, le N+1 ne peut pas être déchiffré. De même, la procédure d'association initiale de TLS (handshake) ne prévoit pas de perte de messages et ne se termine pas si un message est perdu.

Le premier problème fait l'objet de la section 3.1. La dépendance des enregistrements TLS vis-à-vis de leurs prédécesseurs vient du chaînage cryptographique (le chiffrement par chaînagestream cipher - est donc supprimé en DTLS) et de fonctions anti-rejeu qui utilisent un numéro de séquence, qui est implicitement le rang de l'enregistrement. DTLS résoud le problème en indiquant explicitement le rang dans les enregistrements.

Et la question de l'association initiale est vue dans la section 3.2. Pour la perte de paquets lors de l'association, DTLS utilise un système de retransmission (section 3.2.1) et pour l'éventuelle réorganisation des paquets, DTLS introduit un numéro de séquence (section 3.2.2). En prime, DTLS doit gérer la taille importante des messages TLS (souvent plusieurs kilo-octets), qui peut être supérieure à la MTU. DTLS permet donc une fragmentation des paquets au niveau applicatif, un message pouvant être réparti dans plusieurs enregistrements (section 3.2.3).

Enfin, l'anti-rejeu a été modifié pour tenir compte du fait que la duplication de paquets, en UDP, n'est pas forcément malveillante (sections 3.3 et 4.1.2.6).

La définition formelle du nouveau protocole est en section 4. DTLS étant une légère évolution de TLS, la définition se fait uniquement en listant les différences avec TLS. Il faut donc garder le RFC 5246 sous la main.

Dans le Record Protocol de TLS, l'enregistrement spécifié dans la section 6.2.1 du RFC 5246 gagne deux champs (section 4.1) :

  struct {
         ContentType type;
         ProtocolVersion version;
         uint16 epoch;                                    // NOUVEAU
         uint48 sequence_number;                          // NOUVEAU
         uint16 length;
         opaque fragment[DTLSPlaintext.length];
       } DTLSPlaintext;

notamment le numéro de séquence sequence_number (qui était implicite dans TLS, puisque TCP garantissait l'ordre des messages). Pour éviter la fragmentation et les ennuis associés, les mises en œuvre de DTLS doivent déterminer la MTU du chemin et n'envoyer que des enregistrements plus petits que cette MTU (section 4.1.1).

Contrairement à IPsec, DTLS n'a pas la notion d'identificateur d'association. Une machine qui reçoit du TLS doit trouver l'association toute seule, typiquement en utilisant le tuple (adresse IP, port).

En toute rigueur, DTLS n'est pas spécifique à UDP, il peut marcher sur n'importe quel protocole de transport ayant une sémantique « datagrammes ». Certains de ces protocoles, comme DCCP (cf. RFC 5238), ont leur propres numéros de séquence et ils font donc double emploi avec ceux de DTLS. Petite inefficacité pas trop grave.

Au niveau du Hanshake protocol, les modifications que DTLS apporte à TLS font l'objet de la section 4.2. Les trois principales sont :

  • L'ajout d'un gâteau pour limiter les risques de DoS,
  • Modification des en-têtes pour gérer les pertes ou réordonnancements des paquets (section 4.2.2),
  • Ajouts de minuteries pour détecter les pertes de paquets (section 4.2.4).

Les gâteaux de DTLS sont analogues à ceux de Photuris ou IKE (section 4.2.1). Le message ClientHello de la section 7.4.1.2 du RFC 5246 y gagne un champ :

 opaque cookie<0..32>;         // NOUVEAU

Évidemment, ils ne protègent pas contre un attaquant qui utilise sa vraie adresse IP, puisque celui-ci pourra lire la réponse.

OpenSSL gère DTLS depuis la version 0.9.8 (on peut aussi consulter le site Web du développeur). Un exemple d'utilisation se trouve dans http://linux.softpedia.com/get/Security/DTLS-Client-Server-Example-19026.shtml. Il me reste à inclure ce protocole dans echoping. GnuTLS a un support DTLS plus récent.

Et les nouveautés de DTLS 1.2 par rapport au 1.0 du RFC 4347 ? (Il n'y a pas eu de DTLS 1.1.) Elles sont résumées dans la section 8. La principale nouveauté est que DTLS est désormais défini par rapport à TLS 1.2 et non plus 1.0. Cela a notamment permis d'inclure les numéros de séquence explicites de TLS 1.1, nécessaires contre l'attaque BEAST (section 4.1.2.1). Une autre nouveauté est la section 4.1.2.7 qui discute le traitement des paquets invalides. Contrairement à TLS, DTLS peut fonctionner en présence de tels paquets, avec une sémantique proche de celle d'UDP : les laisser tomber et attendre que l'application se débrouille (en demandant leur réémission ou bien en passant à autre chose). Enfin, d'autres clarifications ont été apportées, par exemple à la détection de la PMTU ou bien à l'enregistrement dans les registres IANA.

Une très bonne description de la conception de Datagram TLS et des choix qui ont été faits lors de sa mise au point, se trouve dans l'article The Design and Implementation of Datagram TLS, écrit par les auteurs du RFC. C'est une lecture très recommandée.


Téléchargez le RFC 6347


L'article seul

RFC 6471: Overview of Email DNS-Based List (DNSBL) Best Practice

Date de publication du RFC : Janvier 2011
Auteur(s) du RFC : C. Lewis (Nortel Networks), M. Sergeant (Symantec Corporation), J. Levine (Taughannock Networks)
Pour information
Première rédaction de cet article le 19 Janvier 2012


En raison de l'importance du problème du spam (et d'autres comportements tout aussi nuisibles), un grand nombre de sites utilisent des listes noires des gens avec qui on ne veut pas communiquer (DNSBL pour DNS-based Black List). Ces listes sont souvent distribuées via le DNS, et gérées par des organismes très divers, dont le niveau de sérieux et d'honnêteté est très variable. La question étant très polémique, documenter le comportement attendu de ces organismes n'a pas été une mince affaire. Ce RFC 6471 décrit donc ce qu'on espère d'un gérant de DNSBL.

Rien ne dit qu'il sera suivi, bien sûr. Mais l'espoir est que ce document serve à faire évoluer les choses dans le bon sens. À noter que le groupe en charge de ce RFC, l'Anti-Spam Research Group de l'IRTF, n'a pas toujours réussi à se mettre d'accord sur le comportement idéal de la DNSBL. Dans ces cas, ce RFC 6471 se contente d'indiquer des recommandations sur la forme (« le gérant de DNSBL devrait documenter ce qu'il fait » si le RFC ne peut pas dire ce qui devrait être fait). La section 1.4 rappelle d'ailleurs que les règles de l'IRTF n'imposent pas de consensus au sein du groupe avant publication. À noter que ce RFC ne parle pas de protocole, les questions purement techniques étant traitées dans le RFC 5782.

Le sujet est tellement polémique que je ne vais pas forcément me contenter d'un compte-rendu neutre, objectif et ennuyeux de ce RFC et que je risque de glisser quelques opinions personnelles, pour lesquelles je demande l'indulgence de mes lecteurs. C'est que les DNSBL sont un marécage de gens bizarres, de racketteurs (« pour être retiré de notre liste, il faut payer »), d'éradicateurs (« nous avons mis les trois-quarts de l'Afrique en liste noire ») et de quelques personnes sérieuses. Le groupe ASRG représente plutôt le point de vue des éradicateurs (« dans le doute, on filtre »).

La section 1 du RFC rappelle ce qu'est une DNSBL et comment elle fonctionne. Les détails techniques du fonctionnement de ce service sont exposés dans le RFC 5782. L'idée est de publier dans le DNS les noms de domaine des méchants, ou bien les adresses IP de leurs serveurs de messagerie. Le serveur qui reçoit du courrier peut alors, en consultant le DNS (ce qui est simple et rapide), prendre connaissance de la « note » attribuée au domaine ou à l'adresse IP par le gérant de la DNSBL. Sur la base de cette note, il peut alors décider de filtrer, de contrôler plus étroitement, etc. Rappelons-bien que c'est le destinataire qui décide quoi faire du courrier, pas le gérant de la DNSBL, qui se contente de publier une information. Au bout du compte, c'est le gérant du serveur de messagerie de destination qui est responsable de l'usage qu'il fait de cette information. Beaucoup sont irresponsables, et filtrent aveuglément sur la base de listes noires sur lesquelles ils n'ont même pas pris la peine de se renseigner.

Comme le DNS est une technique éprouvée, très fiable et rapide, cet usage original des DNSBL s'est étendu. On voit aujourd'hui des DNSWL (listes blanches, désignant ceux qui ont droit à un traitement de faveur), listes d'URI dont la présence dans un courrier indique un spam, etc. On voit aussi des changements dans l'usage de ces listes. Très binaire autrefois (l'adresse IP est présente dans la liste noire => on rejette le message), il est devenu plus souple, les résultats d'une recherche dans la liste noire étant souvent un facteur de décision parmi d'autres (SpamAssassin fonctionne ainsi). Poursuivant cette idée d'utiliser le DNS pour récupérer de l'information, on voit aussi des services de géolocalisation utilisant le DNS et d'autres encore plus techniques (je me sers beaucoup du domaine aspath.routeviews.org de Route Views, qui permet de récupérer les informations de routage d'une adresse). Enfin, les listes distribuées par le DNS sont désormais utilisées pour bien d'autres choses que le courrier, par exemple pour du contrôle d'accès à des serveurs IRC ou des formulaires Web. Bref, on peut tout faire avec le DNS, qui a cessé il y bien longtemps d'être uniquement un service qui « traduit des noms de domaine en adresses IP ».

Quelles sont les DNSBL aujourd'hui ? Il y a de tout, certaines sont privées, gérées par une organisation pour son besoin propre, d'autres publiques et gratuites, d'autres payantes (beaucoup de DNSBL sont gratuites en dessous d'un certain seuil d'utilisation et payantes ensuite). On estime qu'il existe plus de 700 listes publiques, la plus ancienne ayant été créée en 1997. À cette époque, les spammeurs utilisaient leurs propres machines et c'est en grande partie en raison des DNSBL, qui distribuaient rapidement les adresses de ces machines, que les spammeurs sont passés à d'autres tactiques (comme les relais de courrier ouverts), tactiques à lesquelles les DNSBL ont dû s'adapter.

Il n'y a pas que le statut juridique et administratif qui différencient les DNSBL actuelles. Elles se différencient également par leurs politiques (comment une entrée est-elle ajoutée à la base et, plus important, comment elle est retirée) et, comme le note pudiquement le RFC, les DNSBL se différencient aussi par le niveau d'honnêteté de leurs responsables.

Justement, cette politique (qui va être mis dans la liste noire, sur quels critères ?) est un point de controverse permanent. Des cow-boys qui vous blacklistent un /20 entier parce qu'une adresse a envoyé un spam, aux gens sérieux qui prennent beaucoup de temps et d'effort avant d'ajouter une adresse à la base, il y a un large spectre d'opinions. Ce RFC 6471 n'essaie pas de trancher entre ces opinions. Il ne dit pas quelle est la bonne politique, simplement que le gérant de la DNSBL doit documenter ses critères d'inclusion et d'exclusion, et faire ensuite réellement ce qu'il annonce (ce qui est très loin d'être le cas). C'est ensuite à l'utilisateur de la DNSBL (l'administrateur d'un serveur de messagerie qui décide d'interroger cette base avant d'accepter un message) de s'informer et de s'assurer que la politique de la DNSBL lui convient.

La section 1.2 fournit une bonne check-list pour ledit utilisateur, sous forme d'une série de questions à se poser avant d'utiliser une DNSBL. Par exemple (entre parenthèses, une étude de l'application de cette check-list à Spamhaus, pour sa liste SBL) :

  • Est-ce que les politiques d'inclusion et d'exclusion suivies par la liste sont nettement marquées sur son site Web ? Sont-elles claires ? (Pour la SBL, la réponse est oui, pour l'inclusion et l'exclusion.)
  • Existe-t-il une évaluation indépendante de cette liste, permettant de comparer la théorie et la pratique ? (Je n'en sais rien, pour la SBL.)
  • Qu'en pensent vos pairs, les collègues qui travaillent dans des conditions analogues aux vôtres ? Comme le note justement le RFC, les DNSBL baignent souvent dans un climat de rude controverse. Il faut bien vérifier que les opinions sur une liste sont formulées par des gens qui s'y connaissent, et pas par Jean-Kevin Boulet qui crie bien fort « Ouais, cette liste est super, marche trop bien ». (La SBL est une des listes les plus utilisées et Spamhaus une organisation ancienne et appréciée.)

Il faut en outre réviser ces questions de temps en temps, les listes évoluent et plus d'une a cessé tout fonctionnement.

Le RFC enfonce le clou à plusieurs reprises : c'est l'utilisateur qui est responsable, au final, pas la DNSBL. Certes, c'est un plaidoyer pour les gérants de DNSBL (« ce n'est pas nous qui filtrons », remarque courante des DNSBL face aux contestations) mais cela reflète la réalité. Filtrer avec une DNSBL, c'est sous-traiter une partie de sa sécurité, c'est confier les décisions à d'autres (la section 4 revient sur ce point et rappelle que des DNSBL ont déjà listé 0/0 c'est-à-dire tout l'Internet). Il est donc crucial d'évaluer les sous-traitants. Le postmaster responsable comprend ce point : la DNSBL exprime une opinion, mais c'est lui qui décide d'agir sur la base de cette opinion.

Bref, quels sont les conseils effectifs de ce RFC 6471 ? Ils commencent en section 2. D'abord, la transparence de l'offre. La DNSBL doit écrire noir sur blanc quels sont les critères pour être mis dans la liste noire et quels sont ceux pour être enlevés. Par exemple, une liste qui s'appuie sur un pot de miel peut avoir comme critère d'ajout « On ajoute toute adresse IP qui a envoyé au moins trois messages dans une semaine aux adresses du pot de miel » et comme critère de retrait « On retire toute adresse qui n'a rien écrit au pot de miel depuis deux mois ». Cette politique doit ensuite être suivie rigoureusement et honnêtement. Dans la jungle des DNSBL, on a déjà vu des gérants de liste qui ajoutaient à la liste noire les adresses IP des gens qui les critiquaient (spite listing)... Il y a des tas de politiques raisonnables, l'important est de se tenir à celle publiée. Si on prétend gérer une liste de relais de courrier ouverts, on ne doit pas y mettre des adresses IP pour une autre raison, même en rapport avec le spam.

La transparence n'empêche pas des politiques dingues, mais ouvertement assumées par le gérant de la liste. Un bel exemple est chez UCEprotect, qui menace directement les critiques « Should you want to contact us, you should keep this in mind and behave rationally and calmly in order not to aggravate your situation. [...] Applying legal action or other pressure against us will result in your IP address and/or your network range being listed in our database. ».

À noter que cette règle de transparence n'impose pas de donner tous les détails. Par exemple, l'opérateur de la liste ne va évidemment pas publier les adresses du pot de miel, cela détruirait complètement son efficacité.

Ensuite, la traçabilité. La DNSBL devrait maintenir un historique des ajouts et retraits, avec les raisons, et publier cet historique. Là encore, l'historique publié peut être expurgé mais il doit contenir suffisamment d'informations pour qu'un utilisateur (ou l'administrateur d'une machine listée dans la liste noire) puisse comprendre pourquoi. Si on prend (un peu au hasard), la liste CBL, on trouve juste : « IP Address X.Y.Z.170 is listed in the CBL. It appears to be infected with a spam sending trojan or proxy. It was last detected at 2011-12-17 12:00 GMT (+/- 30 minutes), approximately 4 hours ago. », ce qui est un peu court.

Beaucoup de gérants de DNSBL sont du genre « éradicateur » et n'hésitent pas devant les dommages collatéraux. Le RFC dit d'ailleurs franchement qu'on ne fait pas d'omelette sans casser d'œufs. Ainsi, il arrive que des listes répondent pour des adresses qui n'ont pas eu de comportement malveillant mais font partie du même préfixe (mettre dans la liste tout un /28 lorsqu'une seule adresse IPv4 de ce /28 a mal agi, par exemple). Le RFC recommande que cette pratique d'élargissement soit clairement documentée.

L'entrée dans la liste est une chose. Mais, avec la plupart des DNSBL, les problèmes sont encore pires pour sortir de la liste. Même quand l'entrée est correctement faite, et à juste titre, on peut avoir des difficultés incroyables pour se faire rayer de la liste. Par exemple, une machine Windows devient un zombie, crache du spam à tout va, et se retrouve « noirlistée », ce qui est normal. Ensuite, l'administrateur système prend les choses en main, reformate le disque, installe NetBSD à la place, et va tenter de « délister » la machine, désormais propre. Avec la plupart des DNSBL, il aura un mal fou. Être enregistré dans une liste est facile, la quitter est très très dur. C'est le même problème lorsqu'une organisation disparait et que ses adresses IP sont récupérées par une autre, qui va s'apercevoir, mais trop tard, que le RIR lui a passé des adresses plombées par une mauvaise réputation.

Le RFC demande donc que les gérants de liste changent de perspective. Au lieu de considérer le retrait comme une opération en soi, toute la liste devrait être considérée comme temporaire et la sortie devrait être automatique au bout d'un moment.

Quelle durée avant cette expiration automatique ? Cela dépend de comment est constituée la liste. Si elle est faite manuellement, sur la base d'informations relativement statiques, comme les allocations de préfixes IP, alors les durées de vie peuvent être longues. Si la détection est automatique (par exemple une liste noire de relais HTTP ouverts), alors une durée de vie très courte est plus raisonnable. Ainsi, la machine dont la configuration a été corrigée disparaîtra vite de la liste et la machine qui rechute sera vite réadmise dans la liste. Dans tous les cas, le RFC demande que la politique d'expiration soit elle aussi publiée. Des informations comme « dernière vérification le tant » sont très précieuses pour évaluer la qualité d'une entrée de la base.

Autre bonne pratique, la fourniture d'un canal privé pour demander le retrait d'une entrée dans la base. Il est nécessaire qu'un tel canal soit disponible. Cela peut être aussi simple qu'une adresse de courrier ou qu'un formulaire Web. Mais, en tout cas, une DNSBL ne devrait pas exiger de discussion publique de la demande de retrait. (Oui, certaines le font, comme forme de punition des administrateurs systèmes qui ont fait preuve de négligence, et laissé leur machine être utilisée pour le spam.)

Et, bien sûr, la DNSBL doit fournir un canal de communication qui ne soit pas lui-même bloqué par la DNSBL... Si l'administrateur de 192.0.2.25 veut demander le retrait de cette adresse de la liste, et que le canal des demandes de retrait est une adresse de courrier, sur un serveur qui utilise la DNSBL, on se retrouverait dans une situation très kafkaïenne. Bien sûr, ces adresses de demande de retrait reçoivent beaucoup de spam mais le filtrage qui les protège devrait être très prudent, pour ne pas rejeter des demandes légitimes.

Les réponses à ces demandes de retrait devraient être raisonnablement rapides. Le RFC suggère deux jours (et sept au grand maximum).

Certaines DNSBL n'acceptent de demandes de retrait de la liste noire que lorsqu'il y a eu une forme d'authentification que le demandeur est bien en charge de l'adresse en question (vérification de l'adresse de courrier dans les bases des RIR, par exemple). Cette pratique est déconseillée car une telle authentification est souvent très difficile à fournir dans l'Internet d'aujourd'hui.

Le RFC recommande même de sérieusement envisager la possibilité de retirer automatiquement les adresses incriminées, sur simple requête (politique dite « pas de question » car on ne demande rien au demandeur). Si l'inscription dans la liste est le résultat d'un test automatique, l'adresse IP « coupable » sera très vite remise, de toute façon. Si on craint une guerre d'ajout/retrait dans la base, il suffit de mettre une limitation au rythme des requêtes (par exemple, deux retraits maximum en vingt-quatre heures) ou de détecter ces guerres et de verrouiller alors l'adresse dans la base. Une telle politique « pas de question » permet de corriger très vite les erreurs dans la base, et ne diminue pas sensiblement l'efficacité globale de la DNSBL (qui ne dépend pas de quelques adresses). Enfin, cette politique permet de désamorcer les (nombreux) conflits entre les gérants de la DNSBL et les responsables des adresses noirlistées.

On l'a vu, ce RFC ne veut pas trancher la question de savoir si une politique d'ajout dans la liste est correcte ou pas. Par contre, la liste des bonnes pratiques demande qu'il y ait symétrie entre la politique d'ajout et celle de retrait. Normalement, si une adresse est ajoutée pour une raison X, et que X cesse d'être vrai, l'adresse devrait être retirée. Par exemple, si une DNSBL stocke les adresses IP des relais de courrier ouverts, elle devrait retirer les adresses qui ne sont plus de tels relais (parce que l'administrateur a réparé la configuration). Cette recommandation du RFC va à l'encontre de la pratique de certaines DNSBL de punir les gérants des machines en question, en demandant une autocritique publique, voire carrément de l'argent, pour être délisté.

Enfin, dernière bonne pratique dans la section 2, cette question du paiement. Le RFC explique qu'il est normal qu'une DNSBL fasse payer ses clients pour y accéder (la définition d'une DNSBL commerciale, après tout). Mais faire payer les administrateurs système, responsables des adresses listées, est, comme le dit le RFC avec euphémisme « proche du racket ». Pour convaincre les administrateurs de listes noires que cette pratique devrait être abandonnée, le RFC note que, même lorsqu'elle est faite avec les meilleures intentions du monde, elle est susceptible de déclencher des réactions négatives, et de mettre en péril le principe même des DNSBL.

Les points traités dans la section 2 étaients de nature plutôt politique. La section 3 touche plutôt aux questions techniques. Quelles sont les bonnes pratiques opérationnelles ? Il y en a plusieurs, par exemple l'importance de disposer d'un ensemble de serveurs de noms suffisant pour faire face à la charge. Il s'agit non seulement de la charge normale, mais également de celle, bien plus élevée, qui surviendra lors d'une dDoS (les spammeurs n'ont pas le sens de l'humour et les attaques par déni de service contre les listes noires ne sont pas rares). Pour être sûr que le nom de domaine « principal » de l'opérateur (mettons spamhaus.org) soit à l'écart des problèmes, le RFC conseille que la DNSBL soit dans un sous-domaine délégué, avec ses propres serveurs de noms :


% dig NS sbl-xbl.spamhaus.org

; <<>> DiG 9.7.3 <<>> NS sbl-xbl.spamhaus.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16914
;; flags: qr rd ra; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sbl-xbl.spamhaus.org.		IN	NS

;; ANSWER SECTION:
sbl-xbl.spamhaus.org.	86400	IN	NS	b.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	5.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	0.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	k.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	d.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	o.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	x.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	h.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	l.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	2.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	4.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	i.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	3.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	r.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	f.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	g.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	t.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	8.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	q.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	1.ns.spamhaus.org.
sbl-xbl.spamhaus.org.	86400	IN	NS	c.ns.spamhaus.org.

;; Query time: 341 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Dec 17 17:40:40 2011
;; MSG SIZE  rcvd: 388

Un des problèmes récurrents avec les DNSBL est que la plupart des administrateurs système ne testent jamais si leur configuration est toujours bonne, et lorsqu'une DNSBL cesse son activité, elle continue à être interrogée. Pour éviter cela, certaines DNSBL en fin de vie ont choisi la solution radicale de lister la totalité de l'Internet. À chaque adresse, elles répondaient qu'elle était listée. Pour détecter rapidement ce genre de problèmes, le RFC rappelle qu'on peut tester 127.0.0.1. Cette adresse ne devrait jamais apparaître dans une DNSBL. Si elle le fait, c'est que la liste a un gros problème et ne devrait plus être utilisée. Si la liste comprend des noms de domaines et pas des adresses IP, c'est le domaine invalid qui joue ce rôle. (Le RFC 5782 donne des détails sur ces conventions. D'autres domaines réservés par le RFC 2606 peuvent être utiles comme test.)

Néanmoins, la première responsabilité est celle du gérant de la liste : s'il arrête le service, il doit le faire proprement (prévenir sur son site Web au moins un mois à l'avance, etc) et surtout pas en se mettant soudain à lister tout l'Internet dans sa base. Il est important de garder le nom de domaine actif : si celui-ci était libéré, un méchant pourrait l'enregistrer et monter une fausse liste noire, qui serait utilisée par tous les clients distraits qui ont oublié de changer leur configuration.

Du point de vue technique, la méthode recommandée est de changer les serveurs de noms de la zone où se trouve la liste pour des adresses IP qui ne peuvent pas exister, par exemple celles réservées pour la documentation (RFC 5735). Ainsi, on est sûr que le domaine ne marchera pas et qu'aucun enregistrement ne sera retourné, montrant bien aux clients que la liste n'est plus en service. Par exemple, avec la syntaxe standard des fichiers de zone DNS :

dnsbl.example.com.  604800  IN  NS  u1.example.com.
                    604800  IN  NS  u2.example.com.
   
u1.example.com.     604800  IN  A   192.0.2.1
u2.example.com.     604800  IN  A   192.0.2.2

Le RFC a aussi des recommandations opérationnelles à faire pour le cas spécifiques des DNSBL qui listent les adresses IP de machines présentant une certaine vulnérabilité (relais SMTP ou HTTP ouverts, par exemple), détectée par un programme. D'abord, le programme ne devrait pas tester des machines préventivement (la question est controversée : certains défendent la légitimité de balayages systématiques de tout l'Internet, d'autres ne sont pas d'accord). Il ne devrait le faire que si quelque chose (un rapport d'envoi de spam, par exemple) attire l'attention sur des machines spécifiques.

Ensuite, une fois une adresse listée, les tests périodiques qui visent à évaluer si la machine est toujours vulnérable devraient être relativement espacés (pas plus d'une fois par jour). Et, bien sûr, le test ne doit pas avoir d'effet négatif (pas d'envoi de grandes quantités de données, par exemple).

Les logiciels qui sont derrière la DNSBL, comme tous les logiciels, ont des bogues. Et les utilisateurs d'une DNSBL peuvent faire des erreurs de configuration. Il est donc important que tout soit vérifié et testé et que des procédures soient en place pour faire face aux problèmes (par exemple, le gérant de la DNSBL doit être prêt à vider manuellement la base ou une partie de celle-ci, si une erreur entraîne le listage erronée d'adresses IP).

À noter que le Wikipédia anglophone a un intéressant tableau de comparaison des DNSBL.

Pour résumer, on a vu que ce RFC résultait d'un compromis entre ceux qui voulaient des listes noires opérant comme elles le voulaient et ceux qui souhaitaient les rendre un peu plus responsables. Le compromis a été de donner peu de recommandations concrètes excepté de documenter les choix effectués. À l'heure actuelle, le moins qu'on puisse dire est que la plupart des listes noires ne font même pas ce minimum...


Téléchargez le RFC 6471


L'article seul

RFC 6462: Report from the Internet Privacy Workshop

Date de publication du RFC : Janvier 2012
Auteur(s) du RFC : A. Cooper (Center for Democracy and Technology)
Pour information
Première rédaction de cet article le 17 Janvier 2012


Après une très longue période d'ignorance quasi-complète des problèmes de protection de la vie privée, l'IETF a évolué et on n'entend plus gère ses participants écarter d'un revers de main ces questions, en disant « Nous, on fait juste de la technique, tout ça, c'est de la politique, ça ne nous concerne pas. » De nos jours, au contraire, la prise de conscience est nette et l'IETF a désormais une activité structurée autour de la notion de vie privée, activité qui se traduit par un programme dédié et une liste de diffusion. Faut-il aller plus loin ? C'était une des questions posées lors de l'Atelier « Internet Privacy Workshop 2010 », atelier qui s'est tenu du 8 au 9 décembre 2010 à Cambridge et dont ce RFC est le compte-rendu. (L'auteure travaille pour une ONG qui lutte pour les libertés sur l'Internet.)

Pas de décisions à attendre tout de suite, donc. On en est à un stade d'exploration. L'atelier de Cambridge était coorganisé par l'IETF, le MIT et le W3C pour voir ce que les SDO pouvaient faire en terme de protection de la vie privée. On est loin d'un accord unanime (et le résumé du RFC dit bien qu'aucun des organismes présents n'a de position officielle sur ces questions) mais au moins quelques pistes de travail émergent. L'IETF étant chargé de produire des spécifications concrètes, une bonne partie de l'atelier a porté, non pas sur des discours généraux sur la vie privée, mais sur les tâches envisageables.

La question de la protection de la vie privée sur l'Internet est immense et couvre beaucoup de domaines très différents. Certains problèmes apparaissent de manière récurrente, le fingerprinting (la détermination d'une identité à partir de traces numériques qui n'étaient a priori pas conçues pour cela), la fuite d'informations, la difficulté à distinguer les partenaires primaires (à qui on a donné directement de l'information) des tiers (qui ont eu de l'information sans qu'on interagisse explicitement avec eux), le manque d'informations des utilisateurs sur les avantages et inconvénients d'une meilleure protection, etc. (Notons que le RFC mentionne les faiblesses des utilisateurs, mais pas l'aggressivité avec laquelle les capitalistes collectent et revendent de l'information privée.) Le RFC note que la vie privée n'est pas un absolu et que, par exemple, la protéger peut influer négativement sur l'utilisabilité d'un service. Bref, il y a pour l'instant davantage de défis que de solutions (section 1).

Plus précisement, de quoi a-t-on parlé pendant l'atelier (les supports présentés sont disponibles en ligne) ? La section 2 résume tout cela. D'abord, une discussion technique (section 2.1). Commençons par l'adresse IP. Elle donne souvent bien trop d'informations (il est trivial de remonter d'une adresse IP à un utilisateur, ce qui explique pourquoi elle est considérée comme une donnée personnelle). Certains protocoles offrent des risques particuliers comme certaines techniques de mobilité, qui permettent de suivre un utilisateur à la trace.

C'est d'ailleurs dans le cas de l'adresse IP qu'on trouve un des rares exemples d'une technologie IETF spécialement développée pour répondre à des craintes concernant la vie privée : les adresses IP temporaires du RFC 4941, qui sont partiellement aléatoires, et regénérées de temps en temps, pour éviter le suivi de l'utilisateur.

Autre mécanisme bien connu pour empêcher le suivi par l'adresse IP : le routage en oignon, surtout connu grâce à Tor. Ce service route les paquets à travers plusieurs nœuds distincts, chiffrant leur contenu à chaque fois. Seuls les premiers et derniers nœuds voient le message en clair. Observer le trafic ne permet de trouver, au pire, que l'origine (si on espionne au début), ou bien que la destination (si on espionne à la fin).

Mais Tor n'est pas parfait : le contenu des messages peut donner des indications sur l'origine (cookies, par exemple, pour une requête HTTP). Si on veut vraiment être anonyme, utiliser Tor ne suffit pas : il faut aussi couper bien des choses sur son navigateur, à commencer par Flash et JavaScript, et certains peuvent considérer cela comme un problème. Comme souvent en sécurité, rien n'est gratuit. Protéger sa vie privée peut nécessiter des sacrifices.

Les participants à l'atelier ont également planché sur le mode private browsing qu'offrent certains navigateurs. C'est un mode dans lequel le navigateur ne stocke pas localement les identifiants de session (comme les cookies). Son but n'est pas de protéger contre un suivi de l'utilisateur par le serveur mais de protéger contre d'autres utilisateurs du même poste client. L'expérience indique que beaucoup d'utilisateurs ne comprennent pas la différence et croient que le private browsing leur procure une navigation sans flicage. C'est un exemple d'un autre problème courant en sécurité : les utilisateurs ne comprennent pas les risques.

Enfin, dernière discussion technique, sur les propositions Do Not Track, qui permettent à un utilisateur d'indiquer clairement aux sites Web qu'il ne veut pas être suivi à la trace. Pour l'instant, ce ne sont que des propositions, sans accord technique ou politique.

Après ces discussions techniques, l'atelier s'est demandé quel pouvait être le rôle des SDO dans cette histoire. Dans le passé, il n'y a pas eu d'appproche systématique de la vie privée dans les protocoles IETF. Cela ne veut pas dire que rien n'a été fait : certains RFC ont été entièrement conçus pour résoudre un problème de vie privée (comme le RFC 4941 pour IPv6 ou le RFC 3323 pour SIP). Certains services particulièrement sensibles ont bénéficié de davantage d'efforts, par exemple l'indication de présence (RFC 2778) ou bien sûr la géolocalisation (RFC 3693). Un protocole comme ALTO (RFC 5693) a également vu ses problèmes de vie privée étudiés dès le début. Le cas d'ALTO est difficile car le protocole est d'autant plus efficace que l'utilisateur révèle beaucoup de choses sur lui (en demandant à l'oracle « Je veux télécharger le fichier Serge Reggiani - Les Loups Sont Entrés Dans Paris.mp3 de taille 4732679 octets et de MD5 2d79e0d7e25c8c10c9879cefcef4102a et voici la liste complète des pairs BitTorrent qui l'ont » par rapport au plus discret mais moins efficace « je voudrais savoir si le pair 2001:db8:1::1 est plus ou moins rapide que le 2001:db8:67e::34a:1ff3 »).

La protection de la vie privée a pas mal de rapports avec la sécurité (la section 8 discute du rapprochement de ces deux concepts) et la sécurité est un bon exemple d'une préoccupation transverse (elle affecte tous les protocoles) qui était largement ignorée au début de l'IETF et a vu son rôle de plus en plus pris en compte. L'IETF a ainsi bâti une culture de la sécurité. Ainsi, depuis le RFC 1543, tous les RFC doivent inclure une section Security Considerations pour exposer l'analyse sécurité du protocole. Elle peut être vide mais elle doit être présente avec une mention expliquant pourquoi les auteurs du RFC ont consciemment laissé la section vide. Cette obligation bureaucratique n'est évidemment pas suffisante et l'IETF a ajouté une direction de la sécurité, un RFC dédié pour guider les auteurs de RFC (RFC 3552), de nombreux tutoriels pour auteurs de RFC aux réunions physiques, etc. La même méthode peut-elle être appliquée à la vie privée ? (Le RFC 2828, qui rassemble la terminologie IETF sur la sécurité, contient des termes liés à la protection de la vie privée.)

Le W3C a également procédé à un effort semblable. Un de ses premiers grands efforts a été P3P, un mécanisme pour permettre aux sites Web d'exprimer de manière formelle leur politique de gestion des données personnelles. P3P est un langage riche, qui permet d'indiquer des politiques complexes. Mais il a été très peu adopté en pratique. Opinion personnelle : comme pour la neutralité du réseau, tout le monde prétend que l'information du consommateur résoud tous les problèmes, qu'il suffit d'annoncer sa politique et que le marché choisira. Mais personne ne veut le faire réellement. P3P permettait d'exprimer les politiques de protection des données personnelles en des termes simples et non ambigus et c'était évidemment intolérable pour les e-commerçants, qui préfèrent infliger à l'utilisateur des privacy policies de vingt pages écrites en langage légal.

Après ce tour d'horizon du travail effectué et des acteurs en place, l'atelier s'est attaqué aux défis (section 3). Quels sont les grands problèmes à résoudre ?

D'abord, la trop grande facilité à identifier un utilisateur donné par les informations que donne le logiciel qu'il utilise : adresse IP, champs de la requête HTTP comme User-Agent: ou Accept-Language:, cookies (RFC 6265), et plein d'autres paramètres font qu'on peut identifier un utilisateur ou une machine bien trop souvent. C'est ce qu'on nomme le fingerprinting et c'est bien démontré par le Panopticlick.

Comme dans toute réunion de geeks, les participants à l'atelier ont évidemment pris plaisir à explorer en détail des techniques de fingerprinting particulièrement rigolotes comme d'envoyer du code JavaScript qui va transmettre au serveur la liste des polices installées dans le navigateur (elle est souvent unique).

Capturés par un simple script WSGI sur le serveur (testez-le en http://www.bortzmeyer.org/apps/env ; les variables d'environnement dont le nom commence par HTTP_ sont les en-têtes de la requête HTTP), voici une partie de ce qu'envoie un Firefox typique, depuis une machine Ubuntu :

HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7
HTTP_USER_AGENT: Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0
HTTP_ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
HTTP_ACCEPT_LANGUAGE: en-us,en;q=0.5
HTTP_ACCEPT_ENCODING: gzip, deflate

Cette combinaison d'options et de numéros de version est probablement unique, ou en tout cas rare sur le Web, et identifie donc assez bien une machine (sans même avoir besoin de cookie). Une telle combinaison a par exemple déjà été utilisée pour confondre un agresseur agissant pour le compte de l'industrie du divertissement.

Ces informations n'étaient pas prévues pour cet usage (par exemple, les adresses IP étaient prévues pour router les paquets, pas pour identifier une machine ou une personne). Mais remplacer ces informations par des mécanismes qui empêchent ou limitent le fingerprinting ne sera pas trivial. D'autant plus que pas mal de gens se sont habitués à les utiliser dans ce but et qu'il sera de plus en plus difficile de revenir en arrière. Ainsi, le fingerprinting est souvent utilisé pour détecter des fraudes, ou pour fournir du contenu adapté (et le RFC, qui est gentil et évite les sujets qui fâchent, ne cite pas les applications répressives du fingerprinting, pour identifier l'auteur d'un délit abominable, comme de partager des œuvres d'art). Il y aura probablement beaucoup de désaccords sur le compromis entre vie privée et service « amélioré » grâce au fingerprinting.

Au minimum, l'IETF et le W3C vont essayer de documenter les points qui, dans les protocoles courants (TCP, HTTP, SIP), facilitent le fingerprinting.

Un problème proche est celui de la fuite d'informations (section 3.2) : des mécanismes conçus pour des motifs tout à fait honorables transmettent néanmoins plus d'information qu'ils ne le devraient. Ainsi, le champ Referer: dans une requête HTTP permet de savoir d'où vient un visiteur Web (ce qui est utile) mais révèle également des choses comme les ID de session (lorsqu'ils sont mis dans l'URL), les termes de recherche utilisés, etc. Voici un exemple vu dans le journal de mon blog (les informations trop sensibles ont été modifiées). On voit les termes de recherche utilisés dans Google :

192.0.2.70 - - [16/Dec/2011:17:08:53 +0000] "GET /1383.html HTTP/1.0" 200 3291 "http://www.google.fr/url?sa=t&rct=j&q=aide+rfc+dns...

Le contrôle sur les données privées repose normalement sur la possibilité de distinguer les récepteurs primaires des données des tiers (section 3.3). Ainsi, si je me connecte sur SeenThis, ce site est récepteur primaire de mes données et je ne suis pas surpris qu'il récolte des informations sur moi. Il s'agissait d'un choix conscient et informé de ma part. Mais l'examen du code source de ce site montre qu'il fait appel au service Google Analytics et donc, sans l'avoir demandé, sans même le savoir, je transmets également des données à Google, un tiers qui peut alors récolter des données sans que je l'ai choisi.

Le cas ci-dessus est relativement simple. Mais dans le Web d'aujourd'hui, on trouve d'autres cas où la distinction entre destinataire primaire et tiers est moins évidente. Un utilisateur qui met un widget amusant sur une page peut le considérer comme primaire alors que le navigateur (par exemple pour retourner les cookies) le traitera comme un tiers, et l'inverse existe également.

Enfin, le dernier grand défi est celui de l'information de l'utilisateur (section 3.4). La plupart du temps, le flicage de ce dernier se fait discrètement, sans qu'il se rende compte de l'immense quantité de données qui est collectée à son insu. La seule information disponible est composée de « policy statements » écrits dans un jargon juridique délibérement confus, conçu pour protéger le patron de l'entreprise et pas pour informer l'utilisateur. Le RFC note que des informations cruciales (comme la durée de conservation des données) en sont souvent absentes. Opinion personnelle : c'est pour cela que les mécanismes du marché - l'entreprise publie sa politique et le consommateur est libre de continuer ou pas - ne fonctionnent pas et qu'il faut des lois comme la loi I&L. Le marche suppose une information parfaite et des acteurs symétriques, ce qui n'est pas du tout le cas ici.

Le problème est d'autant plus sérieux que, si le technicien se doute bien de tout ce que le site Web peut apprendre sur son visiteur, l'utilisateur ordinaire n'a souvent pas pas idée de la quantité de traces numériques qu'il laisse.

Il est donc nécessaire de travailler à une meilleure information. P3P était un bon effort dans ce sens. Mais comme c'était un langage riche, il était difficile de traduire une politique P3P de manière claire pour l'utilisateur. Les efforts actuels portent plutôt sur un nombre limité d'icônes qui pourraient devenir largement connues (un panneau « danger, ici votre vie privée est menacée »...)

La section 4 étudie ensuite les défis liés au déploiement des bonnes pratiques. D'abord (section 4.1), le problème que les mesures techniques sont génériques, alors que les menaces effectives sont souvent spécifiques à un contexte donné. La vie privée n'est pas un concept binaire. Il y a d'autres stades que « complètement privé » et « public ». Mais il est très difficile de traiter cette complexité par des mesures techniques.

Par exemple, les solutions situées en couche 3 comme les adresses IP temporaires du RFC 4941 résolvent certes certains problèmes (le serveur qui reconnaît un visiteur récurrent uniquement sur son adresse) mais ne protège pas du tout contre un FAI ou un État qui essaie d'associer une adresse à un utilisateur. Selon la menace envisagée, ces adresses temporaires sont donc efficaces... ou pas du tout.

Il ne faut donc pas évaluer les solutions techniques en leur demandant de résoudre tous les problèmes possibles. Il ne serait pas raisonnable pour l'IETF d'exiger de ses protocoles qu'ils empêchent complètement toute atteinte à la vie privée. Il faut plutôt dire clairement quels sont les risques et qui (le programmeur, l'utilisateur, la loi) est chargé de les traiter.

Autre problème délicat de déploiement de solutions de protection de la vie privée : la tension entre l'utilisabilité et la protection (section 4.2). Comme souvent en matière de sécurité, il va falloir faire des choix douloureux. Les tenants du Roi Marché ont beau jeu de faire remarquer que les utilisateurs, lorsqu'ils ont le choix, vont vers les services qui violent le plus leur vie privée (Facebook, Google, etc) en échange d'applications sympas et qui brillent. La principale faiblesse de cet argument est qu'il suppose que l'utilisateur est parfaitement conscient des risques, et de ce qui peut lui arriver, ce qui est très optimiste.

Un bon exemple de ce compromis est donné par Tor. Celui-ci fournit une bonne protection mais complique et ralentit (en raison du nombre d'étapes de routage) la navigation. Résultat, il reste peu utilisé, en bonne partie parce que les utilisateurs font un calcul coût/bénéfice (peu informé, d'ailleurs) et décident que leur vie privée n'est pas assez importante pour justifier ce coût.

Avec Tor, le coût de la protection est élevé. Mais même des mesures bien plus légères ont des coûts. Supprimer l'en-tête Referer: des requêtes HTTP améliore certainement la protection. Mais certains sites Web proposent une vue différente selon la valeur de ce champ et, en le supprimant, on se prive de ce service. Reste à savoir qui va décider du compromis, et sur quelles informations : comment exposer ce choix (« Do not send Referer headers ») dans une interface utilisateur, de manière qui permette un choix raisonné ? Alors même que l'effet de ce choix va dépendre des sites (dans la plupart des cas, le Referer: est inutile au client Web.)

Ces problèmes d'utilisabilité sont cruciaux. Le RFC cite l'exemple de SIP, où un mécanisme normalisé de protection des requêtes contre l'écoute existe (RFC 3261, section 23) mais il n'est pas utilisé en pratique car trop contraignant.

Dernier obstacle au déploiement de techniques respectant davantage la vie privée, la difficulté à trouver les bonnes motivations (section 4.3). Les différents acteurs impliqués ne feront pas d'effort s'ils n'ont pas une motivation pour cela. Cela peut être la crainte du gendarme, la conviction que cela leur apportera plus de clients ou simplement le souci d'utiliser les meilleures techniques (ces trois motivations sont rarement présentes en même temps). La crainte du gendarme est discutée en section 4.3.1. Traditionnellement, beaucoup de services proposés sur l'Internet sont gratuits et la possibilité de vendre les données personnelles des utilisateurs est l'une des voies les plus évidentes pour gagner de l'argent. Comme l'illustre un dessin célèbre, « soit l'utilisateur est le client, soit il est la marchandise ». Dans un tel contexte, il n'y a pas de motivation économique à respecter la vie privée, bien au contraire. Les diverses autorités de régulation ont fini par froncer les sourcils, ce qui a mené les fournisseurs de ces services à publier de longues politiques d'utilisation des données sur leur site. Comme le note le RFC, ces politiques, écrites sans effort pédagogique, visent plutôt à protéger le fournisseur du service qu'à informer correctement et complètement l'utilisateur. Le RFC note à juste titre que ces problèmes ne se corrigeront pas tout seuls et qu'une approche régulatrice est nécessaire (cf. le rapport de la FTC de 2010 sur l'importance d'avoir des politiques publiques mieux écrites).

Le RFC soutient que cette tendance doit continuer : sans forte pression des régulateurs, de la loi, le patronat Internet va toujours essayer de concéder le moins de vie privée possible aux utilisateurs. Un exemple d'une telle pression est la directive européenne qui parle des cookies, indiquant qu'ils ne doivent pas être utilisés sans le consentement des utilisateurs.

Le cas de P3P, déjà cité, est un bon exemple de ce problème des motivations (section 4.3.2). L'idée de base était que les logiciels du côté du client allaient pouvoir lire et comprendre les politiques de protection de la vie privée et automatiquement réagir (par exemple en n'envoyant pas de cookies aux sites dont la politique était trop peu protectrice de la vie privée). C'est une idée très états-unienne : les acteurs libres s'informent mutuellement de leurs pratiques et décident ensuite librement, en adultes majeurs, informés et consentants, de poursuivre ou pas la relation. Si on croit qu'il y a égalité (d'information, de moyens de traitement, de pouvoir) entre le patron de Facebook et M. Michu, utilisateur de Facebook, cela peut marcher. Sinon, on préfère l'approche européenne où certaines pratiques sont interdites, qu'il y ait ou pas consentement de la marchandise, pardon, de l'utilisateur.

Donc, P3P permettait d'automatiser ce processus d'information et de décision. Microsoft a pris une décision importante en choisissant, dans Internet Explorer 6, de n'envoyer des cookies aux tiers que si ceux-ci avaient une politique P3P. Comme n'importe quelle politique, même outrageusement prédatrice, était acceptée par Internet Explorer, la plupart des sites Web se sont pliés à cette décision et ont copié/collé la première politique P3P qu'ils trouvaient (souvent l'exemple pris sur le site du W3C). Cette expérience menée grâce à Internet Explorer (les autres auteurs de navigateurs n'ont fait aucun effort et n'ont jamais intégré P3P) a permis de mettre en évidence une limite de P3P : le site qui publie sa politique peut mentir (« Nous ne vendons pas vos données personnelles »). Aucun mécanisme légal ou autre ne l'en empêche. (Voir par exemple l'article « Token Attempt: The Misrepresentation of Website Privacy Policies through the Misuse of P3P Compact Policy Tokens ».)

Le cas illustre bien la question des motivations : pour qu'ils reçoivent des cookies d'Internet Explorer, les sites devaient publier du P3P. Alors, ils l'ont fait (motivation technique). Il n'y avait pas de pression légale ou régulatrice pour dire la vérité dans ces politiques P3P, alors ils ne l'ont pas fait (pas de motivation légale). Les clients (en partie à cause de l'absence de gestion de P3P par les navigateurs) ne donnaient pas la préférence aux sites publiant du bon P3P, alors les sites n'ont pas cherché à l'améliorer (pas de motivation commerciale).

Il sera intéressant de voir si cela marche mieux en sens inverse : pour la géolocalisation, le RFC 4119 et le RFC 6280 fonctionnent de manière opposée à P3P, en permettant aux utilisateurs d'indiquer leurs choix en matière de protection des données personnelles. Ils sont normalement plus motivés que les entreprises capitalistes pour cela.

Bien sûr, on est ici très loin des questions techniques que se posent normalement les SDO. Mais la compréhension de ces enjeux économiques et légaux est nécessaire, si on veut que les futures techniques de protection de la vie privée aient plus de succès que P3P.

Conclusion, en section 5, quel est le plan d'action pour les SDO ? Pour l'IETF, la synthèse est que cela va être compliqué. L'IETF normalise des protocoles dans les couches basses, sans présupposer d'un usage particulier, alors que les menaces pour la vie privée sont très dépendantes du contexte. Il va donc être difficile de trouver des réponses générales, dans les protocoles IETF. Cela ne veut pas dire qu'il ne faut rien faire. Le travail a déjà commencé autour d'une série de recommandations pour les auteurs de RFC (rassemblées dans ce qui est aujourd'hui un Internet-Draft, draft-morris-privacy-considerations).

Les participants à l'atelier étaient tous d'accord sur la nécessité de poursuivre également le travail technique, par exemple sur les leçons apprises de Tor, ainsi que sur les capacités (plus fortes que prévues) de fingerprinting des protocoles existants.

Et le W3C ? Il est probablement mieux placé pour améliorer la protection de la vie privée, puisque les normes du W3C sont plus proches de l'utilisateur, et utilisées dans un contexte plus spécifique. Contrairement à l'IETF, le W3C peut se restreindre au Web.

L'annexe A résume quels sont les documents bruts disponibles pour ceux qui veulent approfondir leur connaissance des travaux de cet atelier :


Téléchargez le RFC 6462


L'article seul

RFC 6522: The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages

Date de publication du RFC : Janvier 2012
Auteur(s) du RFC : M. Kucherawy (Cloudmark)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF appsawg
Première rédaction de cet article le 17 Janvier 2012


Un court RFC pour un format simple : le type MIME multipart/report permet d'envoyer des rapports structurés au sujet d'un message. Ce RFC est la dernière version de la norme sur multipart/report, marquée par un léger allègement des règles d'utilisation.

Pas de grands changements, sinon. L'idée de base de multipart/report est de pouvoir faire des messages à propos des messages. Par exemple, un avis de non-remise (RFC 3461) est un message disant qu'un message n'a pu être remis, et intégrant le message originel. Un rapport ARF (RFC 5965) est un message disant qu'un message est abusif (spam, par exemple) et intégrant également le message originel. D'où l'idée d'avoir un type commun pour tous ces « messages sur les messages », et c'est multipart/report, normalisé dans notre RFC 6522, qui succède au RFC 3462 (qui succédait lui-même au RFC 1892). Ce type multipart/report est très largement utilisé depuis longtemps, et par de nombreux logiciels.

La présentation détaillée du type « rapport » figure en section 3. Voici d'abord un exemple d'un tel message, ici pour indiquer une non-délivrance, généré par un MTA Postfix :

Date: Wed, 11 Jan 2012 13:45:44 +0000 (UTC)
From: MAILER-DAEMON@bortzmeyer.org (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: bortzmeyer@nic.fr
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
        boundary="154CD3AC2C.1326289544/mail.bortzmeyer.org"
Content-Transfer-Encoding: 8bit

This is a MIME-encapsulated message.

--154CD3AC2C.1326289544/mail.bortzmeyer.org
Content-Description: Notification
Content-Type: text/plain; charset=us-ascii

[La première partie du rapport, lisible par un humain.]

This is the mail system at host mail.bortzmeyer.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

--154CD3AC2C.1326289544/mail.bortzmeyer.org
Content-Description: Delivery report
Content-Type: message/delivery-status

[La deuxième partie du rapport, conçue pour être analysée par des
programmes.]

Reporting-MTA: dns; mail.bortzmeyer.org
X-Postfix-Queue-ID: 154CD3AC2C
X-Postfix-Sender: rfc822; bortzmeyer@nic.fr
Arrival-Date: Wed, 11 Jan 2012 12:24:50 +0000 (UTC)

Final-Recipient: rfc822; nothere@nowhere.example
Action: failed
Status: 5.4.4
Diagnostic-Code: X-Postfix; Host or domain name not found. Name service error
    for name=nowhere.example type=AAAA: Host not found

--154CD3AC2C.1326289544/mail.bortzmeyer.org
Content-Description: Undelivered Message
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit

[Puis le message originel, dans la troisième partie du rapport.]

Notez le paramètre report-type, qui a ici la valeur delivery-status. (Cela serait feedback-report pour du ARF.)

Notez surtout le découpage en trois parties (la dernière est optionnelle) :

  • Une partie qui contient un message en format libre et en langue naturelle.
  • Une partie structurée (dans l'exemple ci-dessus, avec la syntaxe message/delivery-status du RFC 3464).
  • Le message originel.

Si on trouve le message originel trop gros, la troisième partie peut se composer uniquement des en-têtes du message. Elle aura alors le type message/rfc822-headers (section 4 de notre RFC).

Naturellement, les messages multipart/report ne sont pas plus authentifiés que les autres messages : il faut donc éviter d'agir automatiquement lors de leur réception (section 7).

Le seul changement de fond depuis le RFC 3462 concerne une ancienne restriction : multipart/report ne pouvait apparaître qu'au plus haut niveau du message (rappelez-vous que MIME est récursif, un message MIME peut contenir d'autres messages MIME). Cela interdisait, par exemple, de faire un multipart/report au sujet d'un multipart/report. Il semble bien que personne ne mettait en œuvre cette restriction et ce nouveau RFC 6522 l'a donc supprimé. (Voir section 1.)


Téléchargez le RFC 6522


L'article seul

Le TLD du Gabon en panne depuis quatre mois

Première rédaction de cet article le 12 Janvier 2012


Depuis septembre 2011, le TLD du Gabon, .ga est en panne quasi-complète. Quelle est la panne exacte ? Pourquoi cette panne ? Que fait le gouvernement ? Quelles sont les conséquences pour le reste du DNS ?

La panne a commencé le 13 septembre mais ses conséquences n'ont pas été visibles tout de suite. Le serveur maître à Libreville a commencé par refuser à ses esclaves les transferts de zone (RFC 5936). Le champ « expiration » dans l'enregistrement SOA de .ga étant de 42 jours, les esclaves ont fini par renoncer le 27 octobre, répondant SERVFAIL (Server Failure) :


% dig @b.hosting.nic.fr. SOA ga.
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48352
...

Cela concerne les deux esclaves extérieurs, un à l'AFNIC et un au RIPE-NCC. Et les deux serveurs situés dans le pays ? Leur comportement est plus bizarre. Souvent, ils ne répondent pas (et ce n'est pas un problème réseau, puisqu'un ping fonctionne) :


% ping -c 3 nyali.inet.ga 
PING nyali.inet.ga (217.77.71.33) 56(84) bytes of data.
64 bytes from nyali.inet.ga (217.77.71.33): icmp_req=1 ttl=241 time=366 ms
64 bytes from nyali.inet.ga (217.77.71.33): icmp_req=2 ttl=241 time=365 ms
64 bytes from nyali.inet.ga (217.77.71.33): icmp_req=3 ttl=241 time=377 ms

--- nyali.inet.ga ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 365.277/369.877/377.792/5.664 ms

% dig @nyali.inet.ga. SOA ga.       

; <<>> DiG 9.7.3 <<>> @nyali.inet.ga. SOA ga.
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Plus rigolo, la réponse peut dépendre du type de données demandé :


% dig @nyali.inet.ga. ga. SOA

; <<>> DiG 9.7.3 <<>> @nyali.inet.ga. ga. SOA
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

% dig @nyali.inet.ga. ga. NS 

; <<>> DiG 9.7.3 <<>> @nyali.inet.ga. ga. NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16007
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 6

;; QUESTION SECTION:
;ga.                            IN      NS

;; ANSWER SECTION:
ga.                     15900   IN      NS      ns-ga.ripe.net.
ga.                     15900   IN      NS      nyali.inet.ga.
ga.                     15900   IN      NS      b.hosting.nic.fr.
ga.                     15900   IN      NS      ogooue.inet.ga.
...

Lorsqu'ils répondent, le code de retour renvoyé par les serveurs est FORMERR si on a essayé avec EDNS0 (RFC 2671), ce qui est pourtant le comportement normal d'un résolveur DNS (rappelez-vous que dig, par défaut, n'avait pas le même comportement qu'un vrai résolveur, il n'activait pas EDNS0 ; ce comportement par défaut a changé récemment) :



 % dig +bufsize=1400 @nyali.inet.ga. ga. ANY 

; <<>> DiG 9.7.3 <<>> +bufsize=1400 @nyali.inet.ga. ga. ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 4032
;; flags: qr rd ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Query time: 370 msec
;; SERVER: 217.77.71.33#53(217.77.71.33)
;; WHEN: Thu Jan 12 11:13:11 2012
;; MSG SIZE  rcvd: 12

% dig @nyali.inet.ga. ga. ANY                

; <<>> DiG 9.7.3 <<>> @nyali.inet.ga. ga. ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32644
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 6

;; QUESTION SECTION:
;ga.                            IN      ANY

;; ANSWER SECTION:
ga.                     7189    IN      NS      ogooue.inet.ga.
ga.                     7189    IN      NS      ns-ga.ripe.net.
ga.                     7189    IN      NS      nyali.inet.ga.
ga.                     7189    IN      NS      b.hosting.nic.fr.
...

Comme il n'y a plus guère de logiciels serveurs qui ne gèrent pas EDNS0, douze ans après sa normalisation, le plus probable est qu'il y a devant le serveur DNS une middlebox boguée (pléonasme, vu le niveau de qualité du logiciel de la plupart de ces équipements). C'est sans doute elle qui répond aux ping, et massacre les questions et/ou les réponses DNS.

Si on ne met pas EDNS0, le serveur répond, mais sans le bit AA (Authoritative Answer), ce qui est anormal pour un serveur faisant autorité (vues les données renvoyées en réponse à une requête ANY, il est probable que ce serveur ne contienne plus les données de la zone .ga). Donc, on peut dans certains cas, certains jours, avoir une réponse des serveurs de .ga mais uniquement si on les interroge sans EDNS0. Certains résolveurs se rabattent automatiquement sur le vieux DNS, sans EDNS0, lorsqu'ils ne reçoivent pas de réponse. Pour le cas où ils reçoivent FORMERR, le RFC 2671, section 5.3 dit qu'ils doivent en effet réessayer, ce que Christophe Deleuze a testé rapidement : il semble que BIND9 répète la requête sans EDNS0, et cache l'info (n'utilise plus EDNS0 avec ce serveur dans les requêtes suivantes). Unbound répète la requête sans EDNS0 mais semble ne pas cacher l'info, car il retente avec EDNS0 à la prochaine requête.

Donc, dans beaucoup de cas, .ga est quasiment inutilisable.

Que s'est-il passé ? Sans être sur place, et sans nouvelles des gérants du TLD, on ne peut que faire des hypothèses. Le plus probable est que le vrai serveur est en panne et que la middlebox, placée devant (une mauvaise architecture, mais passons), n'assure plus qu'une partie des fonctions (je sais, cela n'explique pas tout). Le fait d'avoir plusieurs serveurs DNS faisant autorité n'aide pas lorsque le maître est panne trop longtemps (les 42 jours de grâce étant écoulés).

Pourquoi personne ne répare-t-il ? Le problème aurait dû être détecté par les administrateurs de .ga, Gabon Télécom. Sinon, il a été signalé par courrier électronique en décembre 2011 (et pas seulement à des adresses en .ga, évidemment), et par fax, pour augmenter les chances de réussite. Aucune réaction. Il faut bien se rappeler deux choses : les bases de données des administrateurs de TLD (ici, la base IANA sur .GA) sont maintenues par les administrateurs eux-mêmes. S'ils sont empêchés, ou bien irresponsables, la base va dériver petit à petit et les informations (noms, numéros, etc) devenir dépassées. Et, d'autre part, la réparation nécessite que quelqu'un agisse (les pannes ne se réparent pas seules). Le Gabon n'est pas un état de droit et une des conséquences de ce système politique est que personne ne prend d'initiatives (c'est trop risqué). Donc, tous les officiels restent les bras ballants. Le problème n'est pas d'argent (le Gabon est un pays relativement riche, grâce au pétrole), ni la compétence (des tas de gens compétents sur l'Internet sont prêts à aider leurs collègues gabonais, si ceux-ci répondaient) mais de responsabiité.

Et pour le reste de l'arbre du DNS, quelles conséquences ? À peu près aucune. La structure non-centralisée du DNS fait que la panne d'un TLD n'affecte pas les autres. Contrairement à ce que prétend l'ICANN (qui justifie ainsi les tarifs colossaux de ses nouveaux TLD), un TLD n'a rien de particulier. C'est un domaine comme un autre ; s'il est en panne, cela ne gène que ses utilisateurs.

À noter qu'un problème du même genre était survenu au Tchad.

Merci à Ed Lewis pour son premier signalement du problème, grâce à son script magique de suivi des TLD, et à Jean-Philippe Pick pour des informations supplémentaires.


L'article seul

Changer de serveur résolveur DNS facilement

Première rédaction de cet article le 8 Janvier 2012
Dernière mise à jour le 9 Janvier 2012


La sortie, le 30 décembre 2011, du décret n° 2011-2122 relatif aux modalités d'arrêt de l'accès à une activité d'offre de paris ou de jeux d'argent et de hasard en ligne non autorisée, décret qui permet à l'ARJEL de demander le blocage d'un site de paris ou de jeux en ligne, a ramené sur le devant de la scène la question du blocage via le DNS. En effet, le décret dit explicitement « Lorsque l'arrêt de l'accès à une offre de paris ou de jeux d'argent et de hasard en ligne non autorisée a été ordonné, [...] les [FAI] procèdent à cet arrêt en utilisant le protocole de blocage [sic] par nom de domaine (DNS) ». Il existe plusieurs façons de comprendre cette phrase. Si le FAI décide de mettre en œuvre cet arrêt en configurant ses résolveurs DNS pour mentir, un moyen simple de contourner cette censure sera alors pour les utilisateurs de changer de résolveur DNS. Est-ce simple ? Est-ce réaliste ? Des logiciels peuvent-ils aider ?

D'abord, un petit rappel de vocabulaire, car j'ai déjà lu pas mal d'articles sur le sujet, où l'auteur est plein de bonne volonté et veut vraiment aider les autres à contourner la censure, mais où il ne connait pas vraiment le DNS et où il utilise un vocabulaire approximatif, voire complètement faux. Il y a deux sortes de serveurs DNS : la première, ce sont les serveurs faisant autorité, qui sont ceux qui contiennent les données (par exemple, les serveurs de DENIC ont la liste de tous les noms de domaine en .de, des serveurs de la société NS14 font autorité pour le domaine shr-project.org, etc). L'ARJEL ou un autre censeur ne peut pas toujours agir sur eux car ils peuvent être situés en dehors de la juridiction française.

Et il y a les résolveurs DNS. Ils ne connaissent au démarrage aucune donnée et servent uniquement de relais et de caches (stockage temporaire de données). Ils sont typiquement gérés par votre FAI ou bien par le service informatique de votre boîte. Ce sont eux qui sont indiqués à la machine cliente (en général par le protocole DHCP), qui les utilisera à chaque fois qu'elle aura une question (c'est-à-dire pas moins d'une centaine de fois pour la seule page d'accueil de CNN).

Si on veut censurer en France l'accès à un site de jeu en ligne, par le protocole DNS, c'est un bon endroit pour attaquer. Il en existe d'autres, mais que je garde pour d'autres articles. Modifier le comportement du résolveur est facile (les logiciels ont déjà ce qu'il faut pour cela) et certains FAI le faisaient déjà pour des raisons financières.

Mais c'est aussi une technique de censure relativement facile à contourner : l'utilisateur de la machine cliente peut changer la configuration de son système pour utiliser d'autres résolveurs que ceux de son FAI, par exemple ceux de Telecomix, qui promettent de ne pas censurer. C'est cette technique qui est discutée dans cet article.

Si vous lisez les forums un peu au hasard, vous trouverez souvent des allusions à cette méthode, de la part de geeks vantards qui affirment bien haut « rien à foutre de leur censure à la con, je change mon DNS car je suis un top-eXpeRz et je surfe sans filtrage ». La réalité est plus complexe. Prenons l'exemple d'une machine Ubuntu (il y a peu près les mêmes problèmes sur Windows ou Mac OS X). La liste des résolveurs DNS utilisés figure dans le fichier /etc/resolv.conf. Suffit-il d'éditer ce fichier, comme on le lit souvent (et bien à tort) ?

  • Déjà, il faut rappeler au frimeur de forum que la grande majorité des utilisateurs de l'Internet n'ont même pas idée qu'ils peuvent choisir (et je ne parle pas seulement du résolveur DNS, mais aussi du navigateur, du système d'exploitation, etc). Si on veut que la solution soit accessible à tout le monde, pas seulement à quelques geeks auto-proclamés, elle doit être simple.
  • Même sur Ubuntu, tout le monde ne sait pas éditer un fichier système (surtout qu'il faut être root).
  • Le frimeur à grande gueule qui écrit sur forum.blaireaux.com/index.php découvrira vite, s'il essayait ce qu'il prêche, qu'éditer resolv.conf n'est pas la bonne méthode, car le client DHCP effacera ses modifications à la prochaine connexion. Il faut modifier la configuration dudit client DHCP (cela varie énormément selon le système et le logiciel installé ; sur ma Debian, en ce moment, c'est /etc/resolvconf/resolv.conf.d/head).
  • Sur certains systèmes d'exploitation, changer un réglage aussi banal est très difficile. Par exemple, sur Android (merci à Aissen pour les informations), les serveurs DNS utilisés sur le réseau mobile ne sont pas modifiables et, sur le Wi-Fi, on ne peut les changer que si on coupe DHCP. Comme la publicité fait tout son possible pour migrer les utilisateurs vers les accès Internet sur téléphone mobile, bien plus contrôlés et moins libres, l'avenir est inquiétant.
  • Une fois qu'on sait quel fichier éditer et comment, reste la question, que mettre dans ce fichier ? Il existe plusieurs résolveurs publics situés en dehors du pouvoir de l'ARJEL, et le plus souvent cité est OpenDNS. Intéressant paradoxe : pour échapper à la censure et garder sa liberté de citoyen, on utilise un résolveur menteur, qui pratique lui-même la censure (et parfois se trompe). Utiliser OpenDNS, c'est se jeter dans le lac pour éviter d'être mouillé par la pluie. Sans compter leurs autres pratiques, comme l'exploitation des données personnelles (le résolveur DNS utilisé sait tout de vous... chaque page Web visitée lui envoie au moins une requête...). À noter qu'on peut avoir aussi un résolveur local à sa machine, ce point est traité un peu plus loin.

À noter que tous les cas ne peuvent pas être couverts dans un article. Par exemple, on peut aussi envisager de changer les réglages DNS sur la box si elle sert de relais DNS pour le réseau local vers les « vrais » résolveurs.

Pour résoudre tous ces problèmes, on peut écrire des documentations (exemples à la fin de cet article). Mais la plupart des utilisateurs auront du mal à les suivre et je pense donc que la bonne solution est la disponibiité d'un logiciel qui automatise tout cela. Quel serait le cahier des charges d'un tel logiciel ?

  • Tourne sur les systèmes utilisés par M. Toutlemonde (Windows, Android, Ubuntu, etc).
  • Indépendant de l'application (le DNS ne sert pas que pour le Web) et marche donc avec tous les services (c'est pourquoi je n'ai pas discuté dans cet article des extensions Firefox comme MAFIAAFire ou DeSOPA - ce dernier ayant en outre un mode de fonctionnement très bizarre).
  • Simple à utiliser.
  • Vient avec une liste pré-définie de bons résolveurs. Je préférerais que cette liste n'inclue pas les résolveurs menteurs comme ceux d'OpenDNS. En tout cas, il est impératif qu'on puisse ajouter les résolveurs de son choix.
  • M. Toutlemonde va certainement avoir des problèmes pour décider s'il doit se servir de « Telecomix » ou « Comodo » ou « Level-3 » pour ne citer que quelque uns des résolveurs publics les plus fameux. Il faudrait donc que le logiciel teste ces résolveurs automatiquement, pour leurs performances, bien sûr (la plupart des articles trouvés sur le Web sur le thème « comment choisir son résolveur DNS ? » ne prennent en compte que leur vitesse, pas leur sincérité, contrairement à cet article) mais aussi pour leur obéissance à la censure. Le logiciel devrait venir avec une liste de domaines peut-être censurés (wikileaks.org, etc) et tester les réponses des résolveurs candidats. Ce n'est pas facile à faire car il faut aussi connaître les bonnes réponses, et elles peuvent changer. Peut-être le logiciel devrait-il interroger des résolveurs de confiance pour avoir cette information ? Le fait de tester pourrait même permettre de choisir automatiquement un résolveur, ce qui serait certainement meilleur pour M. Toutlemonde.
  • Autre cas vicieux (merci à Mathieu Goessens), celui des résolveurs DNS qui, en violation des bonnes pratiques, contiennent des données spécifiques qu'on ne trouve pas dans le DNS public. C'est le cas de pas mal de portails captifs de hotspots, par exemple. dnssec-trigger gère ce problème en ayant un mode spécial, manuellement activé, « Hotspot sign-on ». Mais il y a pire : certains FAI (notamment Orange) utilisent des données non publiques pour certains services réservés aux clients (VoIP, serveur SMTP de soumission, etc) donc une solution qui gère la connexion initiale ne suffit pas. La seule solution dans ce cas est d'avoir un mécanisme d'aiguillage qui envoie les requêtes pour certains domaines à certains résolveurs.

Un tel logiciel est vulnérable à un blocage du port 53. Si cette mesure se répand, il faudra aussi que le logiciel teste s'il peut atteindre des résolveurs publics et des serveurs faisant autorité, ou bien s'il faut passer à d'autres méthodes comme de tunneler le DNS sur TLS, port 443, comme le permet déjà Unbound, dans sa version de développement. D'autres attaques suivront alors (par exemple des FAI qui annonceront les adresses 8.8.8.8 et 8.8.4.4 sur leur propre réseau, pour se faire passer pour Google Public DNS, profitant du fait que ce service n'est pas authentifié).

Compte-tenu de ce cahier des charges, quels sont les logiciels qui conviennent aujourd'hui ? Il n'en existe aparemment qu'un seul, DNS Jumper (je ne suis pas sûr d'avoir mis un lien vers le site officiel, ce logiciel n'a pas de références bien précises et, son source n'étant pas distribué, on peut être inquiet de ce qu'il fait). DNS Jumper tourne sur Windows, assure les quatre premières fonctions de mon cahier des charges mais pas l'avant-dernière : il ne vérifie pas que le résolveur est digne de confiance. Il est décrit, par exemple, dans « Easily Switch Between 16 DNS Servers with DNS Jumper » (l'article est un peu ancien, le logiciel s'est perfectionné depuis), ou, en français, dans « DNS Jumper - Changez rapidement de serveurs DNS ».

Les autres logiciels restent à écrire (un truc comme DNS Helper ne compte pas, puisqu'il ne permet de changer... que pour les DNS de Google). Mais que les censeurs ne se réjouissent pas, les logiciels vont vite sortir, écrire un tel programme n'est pas un exploit technique, et la demande est forte, avec le décret ARJEL déja cité pour la France, SOPA pour les États-Unis, etc.

Sur le problème général de changer manuellement ses résolveurs DNS, un bon article est « How to Change DNS Server » de Remah (Windows seulement).

Quelques petits détails techniques pour finir : on peut parfaitement installer un serveur DNS résolveur sur sa propre machine (enfin, sur un ordinateur portable, pas sur un smartphone). La résolution DNS sera alors entièrement sous le contrôle d'un logiciel qu'on gère, fournissant ainsi le maximum de sécurité. Le processus n'est pas très compliqué sur Unix, ni même sur Windows (merci à Gils Gayraud et Mathieu Bouchonnet pour leur aide sur Windows). On peut le rendre encore plus simple avec des logiciels astucieux comme dnssec-trigger, qui ne teste pas la censure (son but est tout autre) mais pourrait servir de point de départ à un paquetage simple d'installation, vraiment utilisable par M. Toutlemonde (ce n'est pas encore le cas). Par contre, un tel résolveur local a des conséquences négatives sur l'infrastructure du DNS : comme il n'y a plus de cache partagé (avec le résolveur/cache du FAI, une requête pour www.bortzmeyer.org reste en mémoire et bénéficie à tous les clients du FAI), les serveurs faisant autorité verront leur charge s'accroître.

Pour éviter cet inconvénient, une des solutions serait pour le résolveur local de faire suivre les requêtes aux résolveurs du FAI (de tels résolveurs sont nommés forwarders). Mais cela implique de détecter lorsque le résolveur du FAI ment, pour le court-circuiter dans ce cas. DNSSEC fournit une piste intéressante pour cela mais, début 2012, les résolveurs ayant cette fonction forwarder (BIND et Unbound) n'ont pas de tel service de détection et de contournement.

Pire encore, on peut combiner le résolveur local (ou le remplacer) avec des fichiers statiques locaux (/etc/hosts sur Unix, C:\WINDOWS\system32\drivers\etc\hosts sur Windows) mais la maintenance de tels fichiers serait un cauchemar.

Cela ne veut pas dire que cela n'arrivera pas : dans ce maelstrom d'attaques et de contre-attaques, les solutions les plus mauvaises seront certainement déployées par certains acteurs et le futur est sombre pour le système de résolution de noms.


L'article seul

Exposé « Peut-on se passer de moteurs de recherche ? » à l'install-party du CRANS

Première rédaction de cet article le 6 Janvier 2012
Dernière mise à jour le 14 Janvier 2012


Le samedi 14 janvier, le CRANS organisait une install party à l'ENS à Cachan. J'y ai fait un exposé sur le thème « Peut-on se passer de moteurs de recherche ? ». Toutes les informations sont disponibles sur le site officiel (la vidéo devrait y apparaître un de ces jours).

L'introduction est « Aujourd'hui, beaucoup d'utilisateurs dépendent entièrement d'un moteur de recherche pour toute navigation sur l'Internet. On entend même des enseignants de collège dire aux élèves « Pour aller sur Wikipédia, tapez "wikipedia" dans Google » Pourquoi est-ce une mauvaise idée ? Quels sont les inconvénients des moteurs de recherche ? Que se passe-t-il lorsqu'une panne ou la censure modifie le résultat d'une recherche ? Quels sont les points forts des moteurs de recherche, où ils sont utiles ? À quoi sert le DNS et pourquoi est-ce important de comprendre les noms de domaine ? »

Les transparents sont disponibles :

Et, si vous n'avez pas pu venir, ce n'est pas grave, Norman a fait une excellente vidéo sur le sujet, « Maintenant, j'ai Google ».


L'article seul

Amer ou mire ?

Première rédaction de cet article le 3 Janvier 2012


Lorsqu'on effectue une mesure active sur un réseau informatique, un agent de mesure vise une cible distante connue, et le résultat de ce test nous servira à en déduire les performances du réseau. Comment nommer cette cible ? En français, les deux termes les plus courants semblent amer et mire.

Un exemple d'un tel test est l'utilisation d'une simple commande ping :

% ping -c 3 www.arcep.fr
PING www.arcep.fr (81.200.177.80) 56(84) bytes of data.
64 bytes from bastet.publicis-technology.com (81.200.177.80): icmp_req=1 ttl=51 time=74.8 ms
64 bytes from bastet.publicis-technology.com (81.200.177.80): icmp_req=2 ttl=51 time=70.3 ms
64 bytes from bastet.publicis-technology.com (81.200.177.80): icmp_req=3 ttl=51 time=73.0 ms

--- www.arcep.fr ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 70.399/72.760/74.808/1.826 ms

Ici, ma machine, l'agent de mesure local, teste le réseau avec l'amer ou mire www.arcep.fr. Un exemple plus sophistiqué ? Le protocole TWAMP du RFC 5357, et de nombreux autres.

Le premier terme, amer, vient de la navigation maritime et désigne normalement un repère fixe et connu, sur lequel l'équipage d'un bateau peut faire des tests. C'est une jolie origine et ça fait penser aux pirates, donc ça embête la HADOPI, ce qui est très bien. C'est le terme privilégié dans ce blog.

Le second mot, mire, vient de la géodésie (et n'a rien à voir avec la mire de l'ORTF). Il est utilisé par exemple par l'ARCEP (voir sa consultation publique lancée fin 2011, question n° 19).

On pourrait sans doute trouver encore d'autres candidats comme balise.

Et en anglais ? Contrairement à ce qui arrive souvent en informatique, la situation n'y est pas meilleure. On trouve parfois beacon mais qui, dans le domaine des réseaux informatiques, désigne plus souvent un système qui émet spontanément (au lieu de simplement répondre à une sollicitation), comme par exemple les beacons BGP du RIPE. Dans les RFC, on trouve souvent simplement target, que je trouve trop militaire, ou bien landmark, qui est quasiment l'équivalent d'amer.


L'article seul

L'ARJEL, ou la censure au service du fric

Première rédaction de cet article le 2 Janvier 2012


Si l'ARJEL est moins connue des internautes que l'HADOPI, les gens qui suivent de près l'actualité de l'Internet savent qu'elle est à la pointe de la censure, ayant été la première organisation en France à ordonner le bloquage de sites Web aux FAI. Mais dans quels buts ?

Après l'affaire Stan James, qui avait fait connaître l'ARJEL aux internautes, cette organisation vient de récidiver avec un décret (« n° 2011-2122 du 30 décembre 2011 relatif aux modalités d'arrêt de l'accès à une activité d'offre de paris ou de jeux d'argent et de hasard en ligne non autorisée ») qui impose aux FAI de bloquer l'accès aux sites de jeux d'argent en ligne listés par ladite ARJEL. Sur le moment, les commentateurs ont surtout noté que ce décret était le premier texte de censure à mentionner explicitement le DNS et à l'imposer comme mécanisme de blocage.

Mais cette remarque, quoique factuellement exacte, ne répond pas à la question « pourquoi faut-il bloquer l'accès à ces sites ? ». On le fait pour la pédo-pornographie (loi LOPPSI qui, en théorie, limite la censure à cette raison), ou pour défendre le modèle d'affaires des ayant-trop-de-droits (dans le contexte de la loi HADOPI, même si celle-ci ne mentionne pas explicitement de censure). La pédo-pornographie, c'est grave, aucun doute là-dessus. Même chose sur la baisse des revenus de l'industrie du divertissement. C'est très grave et il faut réprimer impitoyablement ceux qui voudraient partager la culture.

Mais l'ARJEL, qui ne s'occupe pas de pédo-pornographie ou de show business, pourquoi veut-elle censurer ? Parce que les jeux d'argent sont immoraux, avec la pression qu'ils exercent sur les plus faibles, pour les pousser à jeter leur argent en l'air dans des jeux qui ne leur rapportent rien, que des déceptions ? Mais non, voyons, ce n'est pas la raison, puisqu'il existe des jeux légaux. Prendre l'argent dans les poches des plus vulnérables a été pendant longtemps un monopole de la Française des Jeux mais, désormais, d'autres acteurs peuvent participer. À condition de verser une part des revenus de leur sale métier à l'État (pardon, on dit « payer des impôts »). Et c'est là que la censure intervient. Pour protéger le business de ceux qui paient une part à l'État, il faut interdire les autres. Le décret cité plus haut permet donc cette censure.

L'ARJEL fait valoir que les sites de jeux en ligne légaux ne sont pas uniquement légaux parce qu'ils paient mais aussi parce qu'ils respectent certaines obligations, comme d'afficher un petit avertissement « attention, le jeu est dangereux ». Mais c'est un argument très hypocrite : on sait que le jeu est dangereux, mais on gagne de l'argent avec.

À noter que cette extension des impôts via les jeux en ligne fait l'objet d'un fort consensus gauche-droite, la gauche a déjà sa place à l'ARJEL, via la responsable des questions numériques chez François Hollande, qui avait pourtant essayé de cacher son rôle à l'ARJEL (à l'ENA, personne ne l'avait prévenue qu'il était difficile en 2011 de garder secrètes ce genre d'informations ?).

Cet article a été repris par le Monde et par l'Informaticien qui l'ont tous les deux attribué, bien à tort, à mon employeur (qui n'y est pour rien). Apparemment, la même chose arrive à Tristan Nitot donc je ne me plains pas.


L'article seul

À quoi ressemblera la résolution de noms dans l'Internet de demain ?

Première rédaction de cet article le 25 Décembre 2011


Dans tout réseau, il y a besoin d'un mécanisme de résolution des noms, traduisant les noms en identificateurs de plus bas niveau, plus proches du fonctionnement technique du réseau. C'est ainsi que, de 1983 à 2011, la résolution de noms sur l'Internet a surtout été assurée par le DNS, permettant ainsi de séparer des noms stables, comme www.example.org, des identificateurs moins stables, comme 2001:db8:af::1:567. Mais est-ce que cela sera toujours le cas demain ?

Car le DNS est aujourd'hui menacé. Pas par les vagues projets de construire un système « meilleur », tâche plus compliquée qu'elle n'en a l'air. Mais par l'intérêt que portent des forces néfastes au DNS, et par les réactions que cela va entraîner. Aujourd'hui, avec le DNS, nous avons sur l'Internet un système d'une très grande fiabilité (les attaques DoS contre la racine ont toujours échoué, par exemple), largement déployé, qui permet des identificateurs stables (mon blog est resté en www.bortzmeyer.org même lorsque je suis passé de Slicehost à 6sync), et qui assure une signification unique pour les noms. Pas besoin de nuancer, de se renseigner, de demander quel réseau utilise son interlocuteur, on est sûr que tout le monde pourra utiliser www.bortzmeyer.org et avoir un résultat équivalent.

En raison de ces propriétés, le DNS est donc aujourd'hui à la base de toutes les transactions sur l'Internet, qui commencent toujours par une requête DNS (et parfois bien plus).

Ce rôle a évidemment attiré l'attention des méchants, notamment des censeurs. C'est ainsi que la loi LOPPSI en France permet d'imposer aux FAI de bloquer l'accès à certains sites, sur simple décision administrative (pour éviter que les citoyens puissent prendre connaissance de la liste des sites bloqués, et vérifier qu'ils sont bloqués pour de bonnes raisons). Un des mécanismes évidents pour mettre en œuvre ce blocage est le DNS (transformation du résolveur du FAI en DNS menteur, avec blocage du port 53). Déjà, de nombreux commerciaux font le tour des acteurs de l'Internet pour promouvoir des solutions de filtrage DNS, qui est également possible dans des logiciels comme BIND (avec la RPZ). La France dispose d'une grande avance technologique dans ce domaine, avec des entreprises comme Amesys, fournisseur de censure pour l'ex-dictature lybienne.

Les autres pays ne sont pas en reste et c'est ainsi que les États-Unis ont leur projet SOPA, équivalent de la LOPPSI, qui permet également d'obliger les FAI à bloquer l'accès à tel ou tel site. Comme, là encore, une implémentation évidente d'un tel système est via le DNS, SOPA a suscité des réactions vigoureuses de la part des acteurs du DNS, ce qui explique en partie le recul des promoteurs du projet. Toutefois, la présence ou l'absence de cette loi ne sera pas forcément le facteur principal : un certain nombre d'opérateurs censurent déjà via le DNS (c'est donc une censure privée, contrairement à SOPA qui proposait une censure étatique).

Naturellement, cette censure ne restera pas sans réponse. Des tas de gens chercheront des contournements, des moyens de passer outre à la censure, comme cela s'est déjà produit pour Wikileaks. Comme le dit An dans les commentaires d'un blog : « Dans le temps, on s'échangeait des adresses de ftp warez. Dans un futur proche, on s'échangera peut-être des fichiers hosts contenant des listes:

warez1 @IP1
warez2 @IP2
etc...

et on lancera bien gentiment notre navigateur sur http://warez1, http://warez2 etc.. les sites webs auront été hackés et se verront ajouter un hostname warez1 qui servira des films de vacances d'été comme au bon vieux temps du ftp warez. Ça ne tiendra pas longtemps, ça sera difficilement traçable, et ça bougera bien trop rapidement pour être coincé. ». D'autres tentatives ont déjà été faites, de diffuser des listes d'adresses IP, suscitant de vives discussions. En d'autres termes, il s'agit de revenir aux anciennes listes genre hosts.txt distribuées, et jamais parfaitement à jour (comme le note Pierre Beyssac, ce sera du « hosts.txt, cloud-style »).

Autre solution, on verra apparaître des résolveurs DNS promettant de ne pas censurer comme ceux de Telecomix. Des outils apparaîtront pour permettre de changer de résolveur DNS plus facilement (comme le montre l'article de Korben).

Ces réactions entraineront à leur tour des contre-réactions, vers davantage de contrôle, comme l'industrie du divertissement le prévoit déjà.

Lors d'une discussion sur la liste FRnog, Ronan Keryell s'exclamait : « Je pense qu'il faut à la base arrêter de tuer Internet. C'était mieux avant (quand nous utilisions tous les 2 Internet dans les années 80... :-) ). Doit-on vraiment revenir au bon vieux hosts.txt (RFC 952 pour ceux qui ont oublié ou plus probablement ici n'ont jamais connu) face à tous ces délires de filtrage et de résolution de faux problèmes imaginaires pour le bonheur de l'utilisateur comme dans toute dictature qui se respecte ? Stop ! On s'arrête ! ».

Mais nous en sommes déjà là, à revenir à des systèmes mal fichus, dont le résultat varie selon l'utilisateur, et dont la fiabilité n'est pas garantie. Les gens qui font les lois comme LOPPSI ou SOPA se moquent bien de tuer l'Internet. Ce n'est pas par ignorance de la technique qu'ils décident des mesures qui vont gravement blesser l'Internet. Ils veulent le contrôle avant tout, même au prix de problèmes permanents pour les utilisateurs.

Petit à petit, ces utilisateurs vont se servir de systèmes de résolution « inhabituels ». Ce seront des résolveurs DNS avec des règles spéciales (comme le plugin Firefox de Pirate Bay) puis des infrastructures utilisant le protocole DNS mais avec des données différentes (comme les racines alternatives sauf que cette fois, cela sera réellement adopté massivement, car il existe une forte motivation, qui manquait aux racines alternatives d'il y a dix ans, qui n'avaient rien à proposer aux utilisateurs).

On verra par exemple des « pseudo-registres » qui partiront des données des « vrais » registres puis les « corrigeront », ajouteront des termes ou d'autres, à partir d'une base à eux (contenant les domaines censurés).

Puis cela sera des systèmes de résolution nouveaux, comme Namecoin, avec des passerelles vers le DNS (projet .bit).

Pour l'utilisateur, cela entrainera désordre et confusion. Des noms marcheront à certains endroits et pas d'autres. On verra des tas de discussions sur des forums avec des conseils plus ou moins avisés du genre « pour voir tous les .fr, utilise telle ou telle adresse de résolveur DNS, et pas ceux de X ou de Y qui sont censurés ».

À la fin de l'année 2011, ce scénario catastrophe semble difficilement évitable, sauf réaction vigoureuse contre les ayant-trop-de-droits et autres censeurs.


L'article seul

RFC 6474: vCard Format Extensions : place of birth, place and date of death

Date de publication du RFC : Décembre 2011
Auteur(s) du RFC : K. Li, B. Leiba (Huawei Technologies)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF vcarddav
Première rédaction de cet article le 24 Décembre 2011


Le format de carte de visite numérique vCard, normalisé dans le RFC 6350, est un des grands succès de l'Internet. On trouve ces cartes partout. Le format de base définit un jeu de données limité mais permet des extensions. Ce RFC est donc la première extension à vCard version 4 (ex-aequo avec celle du RFC 6473), et normalise des champs pour indiquer un lieu de naissance, un lieu de mort et une date de mort (la date de naissance, BDAY, est dans le format de base).

La section 2 décrit ces trois propriétés, toutes facultatives :

  • BIRTHPLACE indique le lieu de naissance. Il peut être indiqué en texte libre ou bien sous forme d'une URI, comme par exemple les URI de plan geo: du RFC 5870. Ainsi, Jésus-Christ pourrait avoir BIRTHPLACE: Dans une grange, Bethléem (Palestine) ou bien BIRTHPLACE;VALUE=uri:geo:31.7031,35.196.
  • DEATHPLACE indique le lieu de mort, par exemple DEATHPLACE: Colline du Golgotha, Jérusalem (le RFC fournit un exemple où la longitude et latitude indiqués sont celles du point où a coulé le Titanic).
  • DEATHDATE indique la date de la mort. Il avait longtemps été envisagé de la garder dans le format de base, comme BDAY mais elle avait finalement été retirée, suite à la réunion IETF de Pékin en 2010. Comme son homologue BDAY, le format préféré de DEATHDATE est celui d'ISO 8601 (cf. RFC 6350, section 4.3), par exemple DEATHDATE:00300501 (date mise un peu au hasard, vu le manque de sources fiables...). Mais on peut aussi utiliser du texte libre pour le cas où on doit utiliser des formules vagues comme « au début du treizième siècle ».

Un exemple complet d'une vCard avec ces trois propriétés est :

BEGIN:VCARD
VERSION:4.0
FN:Jeanne d'Arc
N:d'Arc;Jeanne;;;
UID:urn:uuid:4f660936-28d5-46bf-86c6-9720411ac02a
GENDER:F
KIND:individual
TITLE:Bergère
TITLE:Pucelle
TITLE:Sauveuse de la France
PHOTO:http://commons.wikimedia.org/wiki/File:Lenepveu,_Jeanne_d%27Arc_au_si%C3%A8ge_d%27Orl%C3%A9ans.jpg
LANG:fr
URL:http://fr.wikipedia.org/wiki/Jeanne_d%27arc
BDAY:14120106
BIRTHPLACE:Domrémy (Lorraine)
DEATHDATE:14310530
DEATHPLACE:Rouen (Normandie)
END:VCARD

Ces trois nouvelles propriétés sont désormais enregistrées dans le registre IANA.


Téléchargez le RFC 6474


L'article seul

RFC 6434: IPv6 Node Requirements

Date de publication du RFC : Décembre 2011
Auteur(s) du RFC : E. Jankiewicz (SRI International), J. Loughney (Nokia), T. Narten (IBM Corporation)
Pour information
Réalisé dans le cadre du groupe de travail IETF 6man
Première rédaction de cet article le 22 Décembre 2011


Il existe des tas de RFC qui concernent IPv6 et le programmeur qui met en œuvre ce protocole dans une machine risque fort d'en rater certains, ou bien d'implémenter certains qu'il aurait pu éviter. Ce RFC est donc un méta-RFC, chargé de dresser la liste de ce qui est indispensable dans une machine IPv6. Les deux points les plus chauds concernent la configuration (par DHCP ou par RA - Router Advertisment ?) et la gestion d'IPsec, désormais officiellement facultative.

Ce document remplace son prédécesseur, le RFC 4294. Il vise le même but, servir de carte au développeur qui veut doter un système de capacités IPv6 et qui se demande s'il doit vraiment tout faire (réponse : non). Ce RFC explique clairement quels sont les points d'IPv6 qu'on ne peut pas négliger, sous peine de ne pas pouvoir interagir avec les autres machines IPv6. Le reste est laissé à l'appréciation du développeur. La section 2 résume ce but.

Les deux gros changements par rapport au RFC 4294 sont :

  • DHCP monte en grade, bien que restant derrière les RA pour la configuration des machines IPv6,
  • IPsec n'est plus obligatoire.

Ce RFC s'applique à tous les nœuds IPv6, aussi bien les routeurs (ceux qui transmettent des paquets IPv6 reçus qui ne leur étaient pas destinés) que les machines terminales (toutes les autres).

Bien, maintenant, les obligations d'une machine IPv6, dans l'ordre. D'abord, la couche 2 (section 4 du RFC). Comme IPv4, IPv6 peut tourner sur des tas de couches de liaison différentes et d'autres apparaîtront certainement dans le futur. En attendant, on en a déjà beaucoup, Ethernet (RFC 2464), 802.16 (RFC 5121), PPP (RFC 5072) et bien d'autres, sans compter les tunnels.

Ensuite, la couche 3 (section 5 du RFC) qui est évidemment le gros morceau puisque c'est la couche d'IP. Le cœur d'IPv6 est normalisé dans le RFC 2460 et ce dernier RFC doit donc être intégralement implémenté, à l'exception de l'en-tête de routage de type 0, qui a été abandonné par le RFC 5095.

Comme IPv6, contrairement à IPv4, ne permet pas aux routeurs intermédiaires de fragmenter les paquets, la découverte de la MTU du chemin est particulièrement cruciale. La mise en œuvre du RFC 1981 est donc recommandée. Seules les machines ayant des ressources très limitées (genre où tout doit tenir dans la ROM de démarrage) sont dispensées. Mais le RFC se doit de rappeler que la détection de la MTU du chemin est malheuresement peu fiable dans l'Internet actuel, en raison du grand nombre de pare-feux configurés avec les pieds et qui bloquent tout l'ICMP. Il peut être donc nécessaire de se rabattre sur les techniques du RFC 4821).

Le RFC 2460 décrit le format des paquets et leur traitement. Les adresses y sont simplement mentionnées comme des champs de 128 bits de long. Leur architecture est normalisée dans le RFC 4291, qui est obligatoire.

Également indispensable à toute machine IPv6, l'autoconfiguration sans état du RFC 4862, ainsi que ses protocoles auxiliaires comme la détection d'une adresse déjà utilisée.

ICMP (RFC 4443) est évidemment obligatoire, c'est le protocole de signalisation d'IP (une des erreurs les plus courantes des administrateurs réseaux incompétents est de bloquer ICMP sur les pare-feux).

Dernier protocole obligatoire, la sélection de l'adresse source selon les règles du RFC 3484, pour le cas où la machine aurait le choix entre plusieurs adresses (ce qui est plus fréquent en IPv6 qu'en IPv4).

Le reste n'est en général pas absolument obligatoire mais recommandé (le terme a un sens précis dans les RFC, définie dans le RFC 2119 : ce qui est marqué d'un SHOULD doit être mis œuvre, sauf si on a une bonne raison explicite et qu'on sait exactement ce qu'on fait). Par exemple, la découverte des voisins (NDP, RFC 4861) est recommandée. Toutes les machines IPv6 en ont besoin, sauf si elles utilisent les liens ne permettant pas la diffusion.

Moins générale, la sélection d'une route par défaut s'il en existe plusieurs, telle que la normalise le RFC 4191. Elle est particulièrement importante pour les environnements SOHO (RFC 6204).

On a vu que l'autoconfiguration sans état (sans qu'un serveur doive se souvenir de qui a quelle adresse) était obligatoire. DHCP (RFC 3315), lui, n'est que recommandé.

Une extension utile (mais pas obligatoire) d'IP est celle des adresses IP temporaires du RFC 4941, permettant de résoudre certains problèmes de protection de la vie privée. Évidemment, elle n'a pas de sens pour toutes les machines (par exemple, un serveur dans son rack n'en a typiquement pas besoin). Elle est par contre recommandée pour les autres.

Encore moins d'usage général, la sécurisation des annonces de route (et des résolutions d'adresses des voisins) avec le protocole SEND (RFC 3971). Le déploiement effectif de SEND est très faible et le RFC ne peut donc pas recommander cette technique pour laquelle on n'a pas d'expérience, et qui reste simplement optionnelle.

L'une des grandes questions que se pose l'administrateur réseaux avec IPv6 a toujours été « autoconfiguration RA - Router Advertisment - ou bien DHCP ? » C'est l'un des gros points de ce RFC et la section 6 le discute en détail. Au début d'IPv6, DHCP n'existait pas encore pour IPv6 et les RA ne permettaient pas encore de transmettre des informations pourtant indispensables comme les adresses des résolveurs DNS (le RFC 6106 a résolu cela). Aujourd'hui, les deux protocoles ont à peu près des capacités équivalentes. RA a l'avantage d'être sans état, DHCP a l'avantage de permettre des options de configuration différentes par machine. Alors, quel protocole choisir ? Le problème de l'IETF est que si on en normalise deux, en laissant les administrateurs du réseau choisir, on court le risque de se trouver dans des situations où le réseau a choisi DHCP alors que la machine attend du RA ou bien le contraire. Bref, on n'aurait pas d'interopérabilité, ce qui est le but premier des normes Internet. Lorsque l'environnement est très fermé (un seul fournisseur, machines toutes choisies par l'administrateur réseaux), ce n'est pas un gros problème. Mais dans un environnement ouvert, par exemple un campus universitaire ou un hotspot Wifi, que faire ? Comme l'indiquent les sections 5.9.2 et 5.9.5, seul RA est obligatoire, DHCP ne l'est pas. RA est donc toujours la méthode recommandée si on doit n'en choisir qu'une, c'est la seule qui garantit l'interopérabilité. (Voir aussi la section 7.2 sur DHCP.)

Continuons à grimper vers les couches hautes. La section 7 est consacrée aux questions DNS. Une machine IPv6 devrait pouvoir suivre le RFC 3596 et donc avoir la possibilité de gérer des enregistrements DNS de type AAAA (les adresses IPv6) et la résolution d'adresses en noms grâce à des enregistrements PTR dans ip6.arpa. Les anciens enregistrements A6 (RFC 3363) ont été abandonnés mais on constate que ces enregistrements sont toujours très demandés lors des requêtes à des serveurs DNS faisant autorité, comme ceux de .fr (dans les 0,5 % des requêtes, soit davantage que SRV ou DS).

À noter qu'une machine IPv6, aujourd'hui, a de fortes chances de se retrouver dans un environnement où il y aura une majorité du trafic en IPv4 (c'est certainement le cas si cet environnement est l'Internet). La section 8 rappelle donc qu'une machine IPv6 peut avoir intérêt à avoir également IPv4 et à déployer des techniques de transition comme la double-pile du RFC 4213.

Encore juste une étape et nous en sommes à la couche 7, à laquelle la section 9 est consacrée. Si elle parle de certains détails de présentation des adresses (RFC 5952), elle est surtout consacrée à la question des API. En 2011, on peut dire que la grande majorité des machines a IPv6, côté couche 3 (ce qui ne veut pas dire que c'est activé, ni que le réseau le route). Mais les applications sont souvent en retard et beaucoup ne peuvent tout simplement pas communiquer avec une autre machine en IPv6. L'IETF ne normalise pas traditionnellement les API donc il n'y a pas d'API recommandée ou officielle dans ce RFC, juste de l'insistance sur le fait qu'il faut fournir une API IPv6 aux applications, si on veut qu'elles utilisent cette version d'IP, et qu'il en existe déjà, dans les RFC 3493 (fonctions de base) et RFC 3542 (fonctions avancées).

La sécurité d'IPv6 a fait bouger beaucoup d'électrons, longtemps avant que le protocole ne soit suffisamment déployé pour qu'on puisse avoir des retours d'expérience. Certains ont survendu IPv6 en prétendant que, contrairement à IPv4, il avait la sécurité intégrée dès le début et était donc plus sûr. Cette légende vient du fait qu'en théorie, IPsec était obligatoire pour toute mise en œuvre d'IPv6. Ce point n'a jamais été respecté par les implémentations (et puis, de toute façon, avoir IPsec est une chose, l'activer, avec sa complexe configuration, en est une autre). Désormais, depuis la sortie de notre RFC 6434, ce point n'est même plus vrai en théorie, IPsec (RFC 4301) est officiellement simplement recommandé.

Le RFC note donc bien que la sécurité est un processus complexe, qui ne dépend certainement pas que d'une technique magique (« IPsec est intégré donc il n'y a pas de problème de sécurité ») et qu'aucun clair gagnant n'émerge de la liste des solutions de sécurité (IPsec, TLS, SSH, etc). D'autant plus qu'IPv6 vise à être déployé dans des contextes comme « l'Internet des Trucs » où beaucoup de machines n'auront pas forcément les ressources nécessaires pour faire de l'IPsec.

Toutes les règles et recommandations précédentes étaient pour tous les nœuds IPv6. La section 12 expose les règles spécifiques aux routeurs. Ils doivent être capables d'envoyer les Router Advertisment et de répondre aux Router Solicitation du RFC 4861 et on suggère aux routeurs SOHO d'envisager sérieusement d'inclure un serveur DHCP (RFC 6204) et aux routeurs de réseaux locaux de permettre le relayage des requêtes DHCP.

Enfin, la section 13 se penche sur la gestion des réseaux IPv6 en notant que deux MIB sont obligatoires, celle du RFC 4292 sur la table de routage, et celle du RFC 4293 sur IP en général.

Les changements par rapport au RFC 4294 sont résumés dans l'annexe 16. Les deux plus importants, comme déjà noté, sont IPsec et DHCP, un qui descend, l'autre qui monte. Mais on y trouve aussi l'arrivée de SEND (mais en option), celle des options DNS du RFC 6106, et beaucoup de détails et de clarifications.


Téléchargez le RFC 6434


L'article seul

Administration de machines Unix dans plusieurs fuseaux horaires

Première rédaction de cet article le 16 Décembre 2011
Dernière mise à jour le 17 Décembre 2011


Si vous administrez des machines Unix situées dans plusieurs fuseaux horaires, vous vous êtes peut-être déjà posé la question : quel fuseau indiquer à la machine ? Celui de sa localisation physique ? Celui de votre localisation physique ? Un autre ?

Voici la situation : Jean Michu, administrateur système est à Paris et il gère des machines à Newark, Saint-Louis et d'autres endroits. Sur Unix, on peut configurer chaque machine pour indiquer son fuseau horaire (je ne crois pas qu'il existe de moyen standard, par contre, sur Debian, c'est dpkg-reconfigure tzdata). Mais lequel indiquer ? Il y a au moins trois solutions :

  • La localisation physique de la machine. Cela peut être plus pratique lorsqu'on veut communiquer avec des humains qui sont sur place, par exemple pour coordonner une intervention. Mais, autrement, cette localisation est une des choses les moins importantes dans l'Internet d'aujourd'hui. Avec le nuage, on peut même ne pas savoir dans quel fuseau horaire se trouve la machine qu'on administre. En outre, cela rend plus difficile de comparer des estampilles temporelles sur les différentes machines (par exemple pour déterminer si elles ont eu le même problème au même moment).
  • La localisation physique de l'administrateur système. Cela a certainement plus de sens que celle de la machine : contrairement aux ordinateurs, les humains sont fortement dépendants de l'heure (la machine se moque de travailler à deux heures du matin ou à quatre heures de l'après-midi). Mais l'administrateur peut se déplacer. S'il se trouve temporairement en Chine, il va devoir jongler entre le fuseau horaire de sa localisation habituelle et celui de sa localisation actuelle. Et, surtout, s'il y a plusieurs administrateurs système, qui peuvent être dans des fuseaux horaires différents, cette méthode ne marche plus du tout.
  • UTC? Ce fuseau horaire a l'avantage d'être normalisé, et d'avoir un sens pour tout le monde quel que soit sa localisation sur la planète. Lorsqu'il faut communiquer avec d'autres personnes (par exemple parce qu'il y a eu un problème de sécurité et qu'il faut indiquer le contenu d'un journal), UTC est la seule référence internationale.

C'est donc la dernière solution que j'ai choisie. Je configure toutes mes machines de manière à ce que leur heure par défaut soit UTC, ce qui produit des journaux utilisant cette heure.

Mais n'est-ce pas pénible que la commande date donne cette heure UTC qui ne correspond pas au vécu de l'humain ? Et que ls -l ne donne pas l'heure légale ? Heureusement, Unix a réglé le problème depuis longtemps. Il suffit à chaque administrateur système de définir la variable d'environnement TZ et il aura l'heure dans son fuseau horaire :

% date
Fri Dec 16 20:03:03 UTC 2011

% export TZ=Europe/Paris
%
 
% date                  
Fri Dec 16 21:03:08 CET 2011

Même chose pour ls. Si les États-uniens font parfois preuve de provincialisme (par exemple en utilisant ASCII sans penser que sept bits ne suffisaient pas pour toutes les écritures du monde), le fait que leur pays compte plusieurs fuseaux horaires a certainement contribué à mettre en place une gestion correcte de ce concept sur Unix.

Évidemmment, aucune solution n'est parfaite. Par exemple, si on veut configurer cron pour lancer une tâche à une heure légale particulière, il faudra faire un peu de calcul avant de le programmer. Ceci dit, vous pouvez demander à date de le faire pour vous (merci à Gabriel Kerneis pour le rappel). Si vous voulez savoir quelle est l'heure légale à Doualalorsque UTC est à midi :

% TZ=Africa/Douala date --date="2011-12-16 12:00:00Z"      
Fri Dec 16 13:00:00 WAT 2011

(Le format utilisé est celui du RFC 3339, Z signifiant UTC.)

Si on veut faire l'inverse, trouver quelle sera l'heure UTC correspondant à une certaine heure légale (ici, on se demande quelle sera l'heure UTC lorsqu'il est cinq heures du matin en Californie) :

% TZ=UTC date --date="$(TZ=America/Los_Angeles date --date='2011-12-16 05:00:00')" 
Fri Dec 16 13:00:00 UTC 2011

Une dernière chose sur les fuseaux horaires. Certaines personnes disent que l'argument de communication (« We observed an abnormal traffic from your AS around 0200 UTC ») n'est pas si important que ça car on peut toujours indiquer le fuseau horaire explicitement, même lorsqu'il n'est pas UTC (« We observed an abnormal traffic from your AS around 0300 CET »). Le problème est que ces abréviations ne sont pas forcément connues mondialement (demandez à un États-unien ce qu'est CET et à un Français à quoi correspond MST) et qu'elles sont ambigues : par exemple EST peut être un fuseau horaire aux États-Unis ou bien en Australie. On peut demander à date d'afficher l'heure avec un fuseau horaire explicite, indiqué numériquement, sans ses abréviations (ici, pour le fuseau horaire de la Californie) :

# Par défaut, affiche une abréviation ambigue
% date 
Sat Dec 17 14:16:40 PST 2011

# Avec un décalage numérique, tout est plus clair
% date --rfc-3339=seconds
2011-12-17 14:16:46-08:00

mais les utilisateurs n'y pensent pas toujours.


L'article seul

Est-ce la même chose d'accéder à une donnée individuelle, et d'avoir un accès en masse ?

Première rédaction de cet article le 14 Décembre 2011


Dans les discussions sur la protection de la vie privée, une confusion est souvent faite entre « donnée accessible publiquement » et « la totalité des données est récupérable » (ce qu'on nomme en anglais le bulk access).

Par exemple, cette confusion est souvent faite dans le cas de l'accès aux données stockées dans le DNS. N'importe qui peut interroger les serveurs DNS de .fr pour savoir si le nom anemelectroreculpedalicoupeventombrosoparacloucycle.fr existe ou pas (on peut aussi le faire via le protocole whois). En revanche, le fichier comportant tous les noms existants dans .fr n'est pas disponible. (Certaines zones permettent cet accès.) N'y a-t-il pas une incohérence ? Si les données sont publiques, quel mal y aurait-il à donner un accès à l'ensemble de ces données, un « bulk access » (accès en masse) ?

Techniquement, la différence peut en effet sembler mince : si on peut faire une requête DNS (ou whois) pour un nom, il est trivial de faire une boucle pour essayer plein de noms. Cela se nomme une attaque par dictionnaire et les serveurs de .fr en voient régulièrement. Mais ce n'est pas très discret.

Et surtout, penser que l'accès individuel (éventuellement répété dans une boucle) équivaut à l'accès en masse, c'est oublier l'explosion combinatoire, qui limite sérieusement les possibilités d'une attaque par dictionnaire. Imaginons qu'on soit intéressé par les variantes de mabanqueserieuse.example. Imaginons également qu'on se limite aux variations d'un seul caractère. mabanqueserieuse a 17 caractères. En exploration systématique par des requêtes DNS, il faudrait 36 essais (les lettres d'ASCII, plus les chiffres et le tiret, moins le caractère existant) par caractère soit 612 essais. Et cela ne teste que les substitutions, pas les ajouts ou suppressions (dont on verra plus loin qu'ils existent). Bref, de tels tests seraient assez bavards et feraient râler l'administrateur des serveurs DNS (et c'est encore plus net avec whois). Dans la plupart des cas, énumérer toutes les variantes « intéressantes » (pour faire ensuite des requêtes DNS) n'est pas faisable.

Si on a l'accès en masse, tout est plus simple, car de superbes algorithmes existent pour rechercher de manière plus efficace. Voyons un exemple avec le programme agrep (tre-agrep en fait), -E 1 signifiant qu'on cherche les noms qui ne diffèrent que d'un seul caractère :

% grep mabanqueserieuse example.txt
mabanqueserieuse.example

% tre-agrep -E 1 mabanqueserieuse example.txt
mabanqueserieuse.example
mabanqueserieusr.example
mabanqueserieusse.example
mbanqueserieuse.example
manbanqueserieuse.example
...

et on trouve ainsi de nombreuses autres variantes (testé avec une banque réelle, où presque toutes les variantes avaient été enregistrées par un bureau d'enregistrement situé aux Bahamas). Le fait d'avoir accès à la totalité de la base permet également des recherches sur une partie du nom et de trouver ainsi les doppelgangers comme wwwmabanqueserieuse.fr.

Dans ce cas précis, vous me direz peut-être que détecter les cybersquatteurs opérant depuis un paradis fiscal ne serait pas une mauvaise chose. Mais mon but était de montrer que l'accès aux données en masse permettait des recherches bien plus poussées, et que cela peut se faire au détriment d'innocents (par exemple des particuliers harcelés par les détenteurs de titre de propriété intellectuelle, comme dans l'affaire Milka).

C'est pour cela que le mécanisme NSEC3 du RFC 5155 était important. Sans lui, il était possible d'énumérer tous les noms d'une zone DNS signée avec DNSSEC. Certaines personnes avaient relativisé ce risque en disant « les données DNS sont publiques, de toute façon », ce qui est une sérieuse erreur, comme indiqué plus haut.

Si vous préférez aborder le problème sous l'angle juridique, il faut lire les articles L. 342-1 à 3 du Code de la Propriété Intellectuelle (merci à Thomas Duboucher pour les indications).

Les curieux noteront que les algorithmes de recherche approximative de texte sont proches de ceux utilisés en génomique comme Smith et Waterman ou Needleman et Wunsch. En effet, la recherche d'une séquence de bases dans un génome ne peut pas se faire littéralement, comme avec grep. En raison des mutations et des erreurs dans le séquençage, la correspondance n'est jamais parfaite, et il faut donc accepter, comme dans l'exemple avec tre-agrep, un certain nombre de différences.


L'article seul

Quel est le sexe des RFC ?

Première rédaction de cet article le 14 Décembre 2011


Vous l'avez remarqué, ce blog parle entre autres des RFC, qui représentent un bon bout des articles. Les RFC y sont actuellement mentionnés au masculin (« un RFC », « le RFC 6455 »). Est-ce une règle ? Est-ce la meilleure ?

Je le dis tout de suite, il n'y a pas de réponse simple à cette question. Le terme RFC veut dire en anglais Request For Comments qu'on peut traduire par « demande de commentaires » ou « appel à commentaires » (la traduction que je préfère). Dans le premier cas, on devrait utiliser le féminin, dans le second le masculin. En anglais, la langue dans laquelle sont écrits (écrites ?) les RFC, le terme est neutre. Il ne faut donc pas chercher un argument d'autorité pour trancher.

Et l'usage, que nous dit-il ? Si on cherche sur Google en faisant s'affronter "le RFC" contre "la RFC" ou bien "un RFC" contre "une RFC", on obtient des scores très proches (en décembre 2011, "un RFC" -> 38 200 résultats, "une RFC" -> 29 400 résultats). Il n'y a pas d'interprétation dominante. On trouve même des textes où l'auteur dit à un endroit « une RFC » et à un autre « le RFC 2616 ». À défaut de l'opinion majoritaire, quelle est celle des experts ? Le site du projet de traduction des RFC utilise le féminin. Wikipédia fait de même.

Les arguments basés sur la traduction de Request For Comments ne sont pas parfaits. Écartons d'abord la traduction erronée « requête de commentaires » qui n'est pas du français correct (une requête n'est pas une request). Mais toutes les traductions, même justes, souffrent du même défaut : le sigle n'a plus beaucoup de signification, même en anglais. À l'origine, il avait été choisi par modestie (puisque les costards-cravate refusaient aux documents Internet le titre de normes, on les appelait « appel à commentaires ») et il reflétait une certaine réalité. Aujourd'hui, les RFC sont figés (une fois publié, un RFC n'est jamais modifié, même d'une virgule) et l'étymologie du sigle est devenue très trompeuse (il y a même des projets à l'IETF de supprimer le développé Request For Comments et de ne garder que le sigle).

Une autre traduction possible, qui respecte le sigle, serait « Référence Formalisée par la Communauté », qui décrit bien mieux la réalité des RFC (merci à Emmanuel Saint-James).

Bref, pour l'instant, je traduis par « appel à commentaire » (même si cela ne reflète pas leur réalité de documents stables) et je parle des RFC au masculin. Ça changera peut-être plus tard, mais il me faudra reprendre tout mon blog...


L'article seul

Les malheurs du réseau 128.0.0.0/16

Première rédaction de cet article le 13 Décembre 2011


Une série de chiffres en vaut une autre, pensez-vous ? Eh bien non. Quoique numériques, toutes les adresses IP ne se valent pas. Le préfixe 128.0.0.0/16, quoique parfaitement légal, est ainsi invisible depuis une bonne partie de l'Internet.

Tentez l'expérience depuis votre machine en visant l'amer mis en place par le RIPE-NCC :

%  ping -c 3 128.0.0.1
PING 128.0.0.1 (128.0.0.1) 56(84) bytes of data.
64 bytes from 128.0.0.1: icmp_req=1 ttl=55 time=83.6 ms
64 bytes from 128.0.0.1: icmp_req=2 ttl=55 time=83.8 ms
64 bytes from 128.0.0.1: icmp_req=3 ttl=55 time=83.5 ms

--- 128.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 83.519/83.692/83.890/0.367 ms

Si cela marche (comme ci-dessus), vous faites partie des favorisés. Sinon :

%  ping -c 3 128.0.0.1
PING 128.0.0.1 (128.0.0.1) 56(84) bytes of data.

--- 128.0.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2010ms

Mais pourquoi ? Qu'est-ce que ce chiffre a de particulier ? C'est parce qu'une bogue des routeurs Juniper traite ce réseau différemment et, par défaut, le considère comme « martien » (anormal sur l'Internet) et refuse les annonces BGP pour lui (ce préfixe était réservé, mais le RFC 3330 l'a libéré en 2002). Le numéro (interne) de bogue chez Juniper est le PSN-2011-10-393. Le problème est bien expliqué dans un article des RIPE labs et son effet mesuré par les sondes Atlas. Aujourd'hui, un tiers de l'Internet ne peut pas joindre ce réseau 128.0.0.0/16. Autre façon de mesurer le même problème, regarder la propagation des annonces BGP, par exemple au RIS qui, en décembre 2011, voit une propagation de seulement 80 %.

Une mise à jour existe désormais chez Juniper. On peut aussi changer la configuration par défaut (qui est incorrecte). Si votre routeur Juniper affiche 128.0.0.0/16 en réponse à show route martians, c'est que vous avez la mauvaise configuration. Changez-la  :

set routing-options martians 128.0.0.0/16 orlonger allow 
set routing-options martians 191.255.0.0/16 orlonger allow 
set routing-options martians 223.255.255.0/24 exact allow 

(Trois préfixes sont concernés, même si c'est surtout le premier qui a fait parler de lui.)

Si vous n'arivez pas à pinguer l'adresse de l'amer ci-dessus, tapez sur votre FAI jusqu'à ce qu'il mette à jour ses routeurs (et ainsi de suite récursivement car cela dépend également de l'opérateur qui connecte le FAI).

Avant la mise à jour, sur la console du routeur :

admin@m7i-2-sqy> show route 128.0.0.1

admin@m7i-2-sqy> show route 128.0.0.1 hidden

SERVICE.inet.0: 395145 destinations, 730370 routes (394162 active, 0
holddown, 1051 hidden)
+ = Active Route, - = Last Active, * = Both

128.0.0.0/21        [BGP/170] 1w5d 21:07:00, localpref 100
                      AS path: 2200 20965 1103 12654 I
                    > to 193.51.182.46 via ge-1/3/0.0

Après la mise à jour :

admin@m7i-2-sqy> show route 128.0.0.1

SERVICE.inet.0: 369404 destinations, 369404 routes (368357 active, 0
holddown, 1047 hidden)
+ = Active Route, - = Last Active, * = Both

128.0.0.0/21       +[BGP/170] 00:01:55, localpref 100
                      AS path: 2200 20965 1103 12654 I
                    > to 193.51.182.46 via ge-1/3/0.0

Merci à Sylvain Busson pour sa prompte mise à jour des routeurs.


L'article seul

RFC 6455: The WebSocket protocol

Date de publication du RFC : Décembre 2011
Auteur(s) du RFC : I. Fette (Google), A. Melnikov (Isode)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF hybi
Première rédaction de cet article le 12 Décembre 2011


Ce nouveau protocole, WebSocket, vise à résoudre un problème embêtant pour les développeurs d'applications réseau. L'architecture de l'Internet était conçue pour que le seul point commun réellement obligatoire soit le protocole de couche 3, IP. Ce protocole est simple et fournit peu de services. Les développeurs qui voulaient des choses en plus les mettaient dans leurs applications ou, la plupart du temps, comptaient sur les protocoles de transport comme TCP. Si aucun des protocoles de transport existant ne satisfaisaient leurs besoins, ils avaient parfaitement le droit d'en inventer un autre et de le déployer sans rien demander à personne (principe dit « de bout en bout »). Ce modèle ne marche plus guère aujourd'hui. Il est devenu très difficile de faire passer un autre protocole de transport que TCP à travers les innombrables obstacles du réseau (NAT et pare-feux, notamment), et même un protocole applicatif nouveau, tournant sur un port TCP à lui, risque d'avoir le plus grand mal à passer. D'où l'idée de base de WebSocket : faire un protocole de transport au dessus de HTTP, qui va être le seul à passer à peu près partout. WebSocket est donc l'aboutissement d'un processus, qui a mené à ce que le protocole d'unification ne soit plus IP mais HTTP. Bienvenue dans l'Internet d'aujourd'hui « Tout sur le port 80 ».

WebSocket n'est toutefois pas un protocole généraliste, il est conçu pour fonctionner essentiellement dans le cadre du navigateur Web qui charge du code inconnu (typiquement en JavaScript) et qui va ensuite l'exécuter. Ce code pourra utiliser le réseau, dans une certaine limite (vers la même origine, cf. RFC 6454) mais les possibilités de communication offertes précédemment étaient limitées. WebSocket donne à ce code JavaScript (ou écrit dans d'autres langages) les possibilités d'une vraie communication réseau bidirectionnelle.

Avant, les applications s'exécutant sur le navigateur n'avaient pas de moyen simple de faire de telles communications, équivalentes à ce qu'on fait en TCP. Des applications comme la messagerie instantanée, le partage d'un document en cours d'édition ou bien comme des jeux en commun souhaitaient un modèle d'interaction plus riche que le traditionnel GET du client vers le serveur. Bien sûr, elles auraient pu être extérieures au navigateur, ce qui était certainement plus propre du point de vue architectural. Mais elles se heurtent alors au problème de filtrage décrit plus haut. Et, dans le navigateur, elles dépendaient de XMLHttpRequest ou bien de <iframe> et de polling. Par exemple, un code tournant sur le navigateur qui voulait simplement se mettre en attente de donnés émises de manière asynchrone par le serveur n'avait pas d'autres solutions que d'interroger ce dernier de temps en temps. Ce problème est décrit en détail dans le RFC 6202. Il avait plusieurs conséquences fâcheuses comme un surcoût en octets (tout envoi de données nécessitait les en-têtes HTTP complets) ou comme un modèle de programmation peu naturel.

WebSocket vise à résoudre ce problème en transformant HTTP en un protocole de transport. Il réutilise toute l'infrastructure HTTP (par exemple les relais ou bien l'authentification). Passant sur les mêmes ports 80 et 443, on espère qu'il réussira à passer partout. Comme le note un observateur, « WebSocket est un protocole totalement alambiqué pour contourner la stupidité du monde ».

Le résultat n'est donc pas parfait (rappelez-vous que HTTP n'avait pas été conçu pour cela) et le RFC note qu'on verra peut-être un jour les services de WebSocket fonctionner directement sur TCP (personnellement, j'ai des doutes, puisqu'on pourrait aussi bien dans ce cas utiliser des protocoles de transport qui fournissent les mêmes services, comme SCTP - RFC 4960).

Une petite note avant d'attaquer le RFC : si vous avez l'habitude de lire des RFC, vous noterez que celui-ci a des notations originales (section 2.1) comme d'utiliser les tirets bas pour souligner les définitions, les barres verticales pour encadrer les noms d'en-têtes ou de variables et les barres obliques pour les valeurs des variables.

La section 1.2 résume le fonctionnement du protocole (le lecteur pressé du RFC peut d'ailleurs se contenter de la section 1, non normative mais qui contient l'essentiel sur WebSocket). Le principe de base est d'utiliser du HTTP normal (RFC 2616) mais le client ajoute un en-tête Upgrade: à une requête GET, pour indiquer sa volonté de faire du WebSocket :

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Le serveur répond alors par un code 101 et en indiquant upgrade dans l'en-tête Connection: et en ajoutant des en-têtes spécifiques à WebSocket :

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

Bien sûr, d'autres en-têtes HTTP sont possibles comme les petits gâteaux du RFC 6265. Une fois que le client a fait sa demande, et que le serveur l'a acceptée, il existe une connexion bidirectionnelle entre ces deux acteurs et on peut faire passer les données.

Contrairement à TCP (mais comme dans SCTP), la communication n'est pas un flot d'octets sans structure ; c'est une suite de messages, chacun composé d'une ou plusieurs trames. Les trames sont typées et toutes les trames d'un même message ont le même type. Par exemple, il existe un type texte, où les trames contiennent des caractères Unicode encodés en UTF-8. Il existe évidemment un type binaire. Et il existe des trames de contrôle, conçues pour l'usage du protocole lui-même.

La section 1.3 se focalise sur la poignée de main entre client et serveur qui lance le protocole (les détails complets étant en section 4). On l'a vu, le client doit ajouter l'en-tête Upgrade: websocket pour demander au serveur de basculer en WebSocket (RFC 2616, section 14.42 ; la valeur websocket pour cet en-tête est enregistrée à l'IANA, cf. section 11.2, et aussi le RFC 2817, section 7.2). Le client indique également des en-têtes spécifiques à WebSocket comme Sec-WebSocket-Protocol: qui permet d'indiquer un protocole applicatif au dessus de WebSocket (chat dans l'exemple plus haut). Ces protocoles applicatifs (section 1.9) sont normalement enregistrés à l'IANA pour assurer l'unicité de leurs noms. L'en-tête Origin: du RFC 6454 sert à indiquer quelle était l'origine de la page Web qui a chargé le script client. Quand à Sec-WebSocket-Key:, son rôle est de permettre de vérifier que la connexion était bien prévue pour être du WebSocket et pas des jeux faits par un programme malveillant qui enverrait des données ressemblant à du WebSocket sur le port 80, sans être passé par la poignée de main normale. Le serveur doit combiner la valeur de l'en-tête Sec-WebSocket-Key: avec un GUID (RFC 4122) fixe, 258EAFA5-E914-47DA-95CA-C5AB0DC85B11. Il passe le résultat par SHA-1 puis par Base64 et retourne ce résultat au client (dans un en-tête Sec-WebSocket-Accept:), qui peut alors être sûr que c'est bien ce serveur qui a reçu sa poignée de main. (Voir la section 1.6 sur ce point. Les en-têtes commençant par Sec ne peuvent pas être ajoutés via du code XMLHttpRequest normal et, donc, un client JavaScript ordinaire ne peut pas se comporter en client WebSocket.)

À noter que les en-têtes spécifiques de WebSocket ont été ajoutés au registre des en-têtes.

La réponse du serveur utilise le code HTTP 101 (qui avait été prévu de longue date par le RFC 2616, section 10.1.2), qui signifie que le serveur accepte le changement de protocole. Tout autre code indique que le serveur n'accepte pas WebSocket et que le client doit donc continuer en HTTP normal. Ainsi, un serveur HTTP normal refusera l'en-tête Upgrade: :

% telnet www.bortzmeyer.org http
Trying 2605:4500:2:245b::bad:dcaf...
Connected to www.bortzmeyer.org.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.bortzmeyer.org
Upgrade: websocket

HTTP/1.1 400 Bad Request
Date: Tue, 29 Nov 2011 21:15:34 GMT
Server: Apache/2.2.16 (Debian)
Vary: Accept-Encoding
Content-Length: 310
Connection: close
Content-Type: text/html; charset=iso-8859-1

La section 1.4, elle, décrit la fermeture de la connexion (détails en section 7). Elle se fait par l'envoi d'une trame de contrôle ad hoc. Notez que la simple fermeture de la connexion TCP sous-jacente ne suffit pas forcément : en présence d'intermédiaires, par exemple les relais, elle peut être insuffisante.

Un peu de philosophie après ces détails ? La section 1.5 décrit les concepts à la base de WebSocket. Par exemple, l'un des buts était de garder au strict minimum le nombre de bits de tramage. La structure des données que permet WebSocket est donc réduite (séparation des trames, et typage de celles-ci) et toute structuration plus sophistiquée (par exemple pour indiquer des méta-données) doit être faite par l'application, au dessus de WebSocket.

Dans cette optique « ne pas trop en ajouter », cette section note que WebSocket ajoute à TCP uniquement :

  • Le modèle de sécurité du Web, fondé sur la notion d'origine du RFC 6454,
  • Un mécanisme de nommage permettant de mettre plusieurs applications sur le même port (c'est le chemin donné en argument de la commande GET),
  • Un système de tramage, que n'a pas TCP, qui ne connait que les flots d'octets sans structure,
  • Un mécanisme de fermeture explicite de la connexion (on l'a dit, TCP seul ne suffit pas, dans la jungle qu'est le Web d'aujourd'hui, truffé de middleboxes).

Et c'est tout. Le reste doit être fait par les applications. Compte-tenu des contraintes spécifiques du Web, WebSocket offre donc pratiquement le même service aux applications que TCP. Sans ces contraintes Web (de sécurité, de fonctionnement à travers les middleboxes), du TCP brut suffirait.

Voila, vous connaissez maintenant l'essentiel de WebSocket. Le reste du RFC précise les détails. La section 3 décrit les URI WebSocket. Ils utilisent le plan ws: (non chiffré, port 80 par défaut) ou le wss: (chiffré avec TLS, port 443 par défaut). La section 11 décrit l'enregistrement de ces plans dans le registre IANA. Par exemple ws://example.com/chat est un URI WebSocket (pour la connexion donnée en exemple au début de cet article), comme ws://www.3kbo.com:9090/servers/1/status ou wss://foobar.example/newsfeed.

Comment fonctionne le tramage, le découpage du flot de données en trames bien délimitées ? La section 5 le normalise avec précision. Une trame a un type, une longueur et des données. On trouve également quelques bits comme FIN qui indique la dernière trame d'un message, ou comme RSV1, RSV2 et RSV3, réservés pour de futures extensions du protocole. Une grammaire complète est donnée en section 5.2, en utilisant ABNF (RFC 5234. Les fanas d'ABNF noteront que cette grammaire ne décrit pas des caractères mais des bits, ce qui représente une utilisation originale de la norme.

Le type est nommé opcode et occupe quatre bits. Les valeurs de 0x0 à 0x7 indiquent une trame de données, les autres sont des trames de contrôle. 0x1 indique une trame de texte, 0x2 du binaire, 0x8 est une trame de contrôle signalant la fin de la connexion, 0x9 une demande d'écho (ping), 0xA une réponse (pong), etc. La sémantique des trames de contrôle figure en section 5.5. On y apprend par exemple que des échos non sollicités (pong non précédé d'un ping) sont légaux et peuvent servir à indiquer qu'une machine est toujours en vie.

On le sait, l'insécurité est une des plaies du Web, on trouve tout le temps de nouvelles manières de pirater les utilisateurs. Les problèmes viennent souvent de nouveaux services ou de nouvelles fonctions qui semblent super-cool sur le moment mais dont on découvre après qu'elles offrent plein de pièges. Il n'est donc pas étonnant que la section 10, sur la sécurité, soit longue.

D'abord, le serveur WebSocket doit se rappeler qu'il peut avoir deux sortes de clients (section 10.1) : du code « embarqué » par exemple du JavaScript exécuté par un navigateur et dont l'environnement d'exécution contraint sérieusement les possibilités. Par exemple, l'en-tête Origin: est mis par ce dernier, pas par le code Javascript, qui ne peut donc pas mentir sur sa provenance. Mais un serveur WebSocket peut aussi être appelé par un client plus capable, par exemple un programe autonome. Celui-ci peut alors raconter ce qu'il veut. Le serveur ne doit donc pas faire confiance (par exemple, il ne doit pas supposer que les données sont valides : il serait très imprudent de faire une confiance aveugle au champ Payload length, qu'un client malveillant a pu mettre à une valeur plus élevée que la taille de la trame, pour tenter un débordement de tampon).

WebSocket ayant été conçu pour fonctionner au dessus de l'infrastructure Web existante, y compris les relais, la section 10.3 décrit les risques que courent ceux-ci. Un exemple est l'envoi, par un client malveillant, de données qui seront du WebSocket pour le serveur mais qui sembleront un GET normal pour le relais. Outre le tramage, la principale protection de WebSocket contre ce genre d'attaques est le masquage des données avec une clé contrôlée par l'environnement d'exécution (l'interpréteur JavaScript, par exemple), pas par l'application (section 5.3 pour en savoir plus sur le masquage). Ainsi, un code JavaScript méchant ne pourra pas fabriquer des chaînes de bits de son choix, que WebSocket transmettrait aveuglément.

Un peu d'histoire et de politique, maintenant. WebSocket a une histoire compliquée. L'idée de pousser les informations du serveur vers le client (connue sous le nom de Comet) est ancienne. Le protocole WebSocket (dont l'un des buts est justement cela) a été créé par Ian Hickson (qui a aussi écrit les premiers projets de RFC mais n'apparait plus comme auteur). Le groupe de travail WHATWG a ensuite beaucoup participé. La plupart des mises en œuvre de WebSocket citent ce groupe ou bien les anciens Internet-Drafts, écrits avant la création du groupe de travail IETF HyBi en janvier 2010.

Le principe même de WebSocket a souvent été contesté. Pourquoi passer tant d'efforts à contourner les problèmes de l'Internet aujourd'hui (notamment les middleboxes abusives) plutôt qu'à les résoudre ? Un intéressant texte de justification a été écrit à ce sujet. Notez qu'il inclut des exemples de code. Le groupe HyBi a connu de vives discussions, avec menaces de scission (« À WHATWG, c'était mieux, on va quitter l'IETF si ça n'avance pas »). Un des points d'affrontement était par exemple les problèmes de sécurité (résolus par la solution du masquage). Cela s'est ensuite arrangé, début 2011.

Si vous voulez vous lancer dans la programmation d'applications WebSocket tournant dans le navigateur, regardez l'API. Aujourd'hui, on trouve des implémentations de WebSocket pour les différents serveurs (GlassFish, Jetty, Apache). Dans les environnements de développement, on trouve du WebSocket chez Django et bien d'autres. Chez les clients, Firefox l'a en théorie depuis la version 6, Chrome et Internet Explorer l'ont annoncé pour une version prochaine. Bon, en pratique, c'est compliqué, et la démo ne donne pas toujours les résultats attendus (elle me refuse mon Firefox 7 mais accepte un Chrome).

Attention si vous lisez les sources, pas mal d'implémentations ont été faites en suivant des vieilles versions de la spécification de WebSocket, antérieures à sa normalisation à l'IETF. Cela se sent par exemple dans les noms des variables utilisés. (Un terme comme « opcode » pour le type est dans le RFC mais pas toujours dans les programmes.)

En dehors du monde des navigateurs, si vous voulez programmer du WebSocket, vous avez, entre autres :

Si vous voulez jouer plutôt avec un programme client comme curl, vous avez un bon article qui explique comment faire du WebSocket avec curl.

Si vous cherchez des fichiers pcap de Websocket, on en trouve sur pcapr mais attention, la plupart concernent des mises en œuvres de versions antérieures du protocole. Mais Wireshark n'a pas l'air encore capable de décoder le framing Websocket.


Téléchargez le RFC 6455


L'article seul

Articles des différentes années : 2012  2011  2010  2009  2008  2007  2006  Précédentes années

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