Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

echoping

Ève

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


Assez des URL spécifiques pour les clients « mobiles »

Première rédaction de cet article le 28 avril 2015


Un certain nombre de sites Web (pas tous, heureusement) redirigent les clients qui semblent être des appareils mobiles vers un autre URL, spécifique aux mobiles. C'est une très mauvaise idée.

En général, la redirection se fait dès que le serveur Web croit, à tort ou à raison, qu'il voit passer un appareil mobile, par exemple un phono sapiens. On peut le voir avec wget, en faisant varier le champ HTTP User-Agent: (RFC 7231, section 5.5.3) :

% wget --user-agent="Mozilla/5.0 (Android; Mobile; rv:37.0) Gecko/37.0 Firefox/37.0" http://fr.wikipedia.org/wiki/Virgule_d%27exclamation 
--2015-04-27 17:29:04--  http://fr.wikipedia.org/wiki/Virgule_d%27exclamation
Resolving fr.wikipedia.org (fr.wikipedia.org)... 91.198.174.192, 2620:0:862:ed1a::1
Connecting to fr.wikipedia.org (fr.wikipedia.org)|91.198.174.192|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://fr.m.wikipedia.org/wiki/Virgule_d%27exclamation [following]
--2015-04-27 17:29:04--  http://fr.m.wikipedia.org/wiki/Virgule_d%27exclamation
Resolving fr.m.wikipedia.org (fr.m.wikipedia.org)... 91.198.174.204, 2620:0:862:ed1a::1:c
Connecting to fr.m.wikipedia.org (fr.m.wikipedia.org)|91.198.174.204|:80... connected.
HTTP request sent, awaiting response... 200 OK
...

On a été redirigé (code de réponse 302, RFC 7231, section 6.4) depuis le bon URL http://fr.wikipedia.org/wiki/Virgule_d%27exclamation vers http://fr.m.wikipedia.org/wiki/Virgule_d%27exclamation (le composant m dans le nom de domaine indiquant une version pour mobile). Avec un User-Agent: qui n'indiquait pas un mobile, on n'était pas redirigé :

% wget --user-agent="Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.6.0" http://fr.wikipedia.org/wiki/Virgule_d%27exclamation
--2015-04-27 17:28:31--  http://fr.wikipedia.org/wiki/Virgule_d%27exclamation
Resolving fr.wikipedia.org (fr.wikipedia.org)... 91.198.174.192, 2620:0:862:ed1a::1
Connecting to fr.wikipedia.org (fr.wikipedia.org)|91.198.174.192|:80... connected.
HTTP request sent, awaiting response... 200 OK
...

On trouve de telles redirections dans Wikipédia mais aussi les Échos, Rue89, etc.

Ces URL sont utilisés pour transmettre un contenu différent selon les clients. Les problèmes que posent ces URL spécifiques aux mobiles sont les suivants :

  • Ils violent un principe de base du Web, qui est que l'URL est la même pour tout le monde, afin qu'on puisse la transmettre, la passer à quelqu'un d'autre, et que l'affichage suive automatiquement. Le Web a été conçu pour cela. Il n'y a aucune bonne raison technique de faire du contenu spécifique pour mobile.
  • Il n'y a pas un seul type de « mobile » mais des tas de modèles, avec notamment des tailles d'écran très différentes. Même si on pense qu'il faut des contenus différents selon les machines, ces URL spécifiques ne dispensent donc pas le webmestre d'adapter le contenu à chaque écran.
  • Ces URL empêchent d'utiliser une des fonctions de base du Web, passer un URL d'un utilisateur à l'autre (par XMPP, courrier, Twitter, etc). En effet, si je consulte un site sur un smartphone, que je l'envoie en XMPP et que le destinataire est sur un ordinateur de bureau, il verra une version inadaptée. (Rue89 redirige depuis le site mobile vers le site immobile, mais Wikipédia ne le fait pas.)
  • Si on stocke les URL dans une base de données, à des fins de documentation ou de constitution d'une base de connaissances, on aura des doublons puisque le système croira qu'il s'agit de deux ressources différentes. Ainsi, SeenThis affiche un joli petit triangle noir devant chaque URL qui a déjà été cité mais il ne peut plus le faire si on utilise l'URL « mobile » et l'URL « normal » pour la même ressource.
  • La redirection nécessite une nouvelle connexion TCP et une nouvelle requête, donc augmente la latence, alors que les mobiles ont justement souvent la plus mauvaise connexion.

Est-ce qu'au moins on peut corriger à la main l'URL qu'on voulait partager ou enregister ? Chez Wikipédia, c'est relativement facile, le schéma est évident. On retire juste le composant m du nom de domaine, et http://fr.m.wikipedia.org/wiki/Potamoch%C3%A8re redevient http://fr.wikipedia.org/wiki/Potamoch%C3%A8re. Par contre, Rue89 utilise des URL radicalement différents (http://m.rue89.nouvelobs.com/node/257496 est http://rue89.nouvelobs.com/2015/04/23/deconnectes-mal-connectes-les-pauvres-numerique-257496, excellent article, au passage) et empêche donc cette réécriture.

Terminons par un argument d'autorité avec deux excellents textes du W3C contre cette idée d'URL spécifiques aux mobiles. Ces deux articles ont été écrits dans le contexte du TLD .mobi (un échec complet et mérité) : « The ".mobi" Proposal is Inconsistent with Device Independence Principles » et « New Top Level Domains .mobi and .xxx Considered Harmful » (qui couvre en outre bien d'autres sujets et est donc plus difficile à utiliser pour ce problème des URL pour mobiles).


L'article seul

Qui est le numéro 1 de l'Internet ?

Première rédaction de cet article le 27 avril 2015


Le 23 avril dernier, le gouvernement français annonce qu'il a rencontré « les dirigeants d'internet ». Cela a, à juste titre, beaucoup fait rire, mais pas toujours pour de bonnes raisons. C'est que c'est compliqué de savoir qui dirige (ou pas) l'Internet.

Le communiqué du gouvernement français est en ligne mais a été modifié depuis. Le texte original disait « le Gouvernement mobilise les dirigeants d'internet » et la version modifiée suite aux rires des internautes dit « le Gouvernement mobilise les dirigeants des grands opérateurs de l'internet ». Notez que l'URL, qui reprend le titre du communiqué, n'a pas changé. C'est bien de ne pas l'avoir changé mais, désormais, le titre et l'URL ne sont plus en accord (voilà pourquoi il faut éviter de mettre trop de sémantique dans les URL).

Il y a bien des choses à critiquer dans le communiqué du gouvernement, notamment le ridicule des mouvements martiaux du menton (« le Gouvernement mobilise... ») ou surtout la gravissime faute qu'est la sous-traitance de la censure à des entreprises privées, plus soucieuses d'éviter les problèmes que de défendre la liberté d'expression. Mais les nombreuses critiques du communiqué gouvernemental se sont surtout focalisées sur le titre, comme celle de Numérama. Ce journal constate à juste titre qu'il est ridicule de parler des « dirigeants d'Internet » (et le gouvernement français doit être de cet avis puisqu'il a modifié son texte irréfléchi) car la gouvernance de l'Internet est complexe et ne se réduit pas à une poignée de « dirigeants ».

L'erreur n'est pas innocente, de la part du gouvernement. Celui-ci est en effet complètement perdu devant le mécanisme complexe qu'est l'Internet. Comme le héros du Prisonnier, les ministres passent leur temps à demander « qui est le numéro 1 ? » Ils ne peuvent en effet pas imaginer d'autres systèmes politiques que ce qu'ils ont appris à Sciences Po : un système très hiérarchique, avec une poignée d'acteurs (publics ou privés, peu importe pour eux), quelques dirigeants régnant sur une masse de « fond d'organigramme ». Rien d'étonnant que, perturbés par l'Internet, ils cherchent à toute force à le ramener au seul cas qu'ils connaissent, celui où on discute dans des bureaux feutrés, loin des rumeurs du monde, avec quelques messieurs « responsables ». Numérama a raison de pointer du doigt cette curieuse réduction de l'Internet à « Google, Facebook, Microsoft, Apple et Twitter mais aussi des responsables des principaux fournisseurs d'accès à Internet (dont les membres de l'association des fournisseurs d'accès et de services Internet comme Orange, Bouygues Telecom, SFR) ». Pourquoi ces entreprises privées particulières, et qui a décidé de leur confier l'Internet ? Personne, et surtout pas un processus démocratique. Mais ces entreprises sont toutes prêtes à suivre la voie de la censure privée (Facebook s'y est engagé depuis très longtemps). En façade, les politiciens français aiment se plaindre des GAFA (Google, Apple, Facebook, Amazon), mais ils sont très à l'aise avec cet oligopole de (pour citer Numérama) « gigantesques silos contenant des quantités inouïes de données personnelles, pour le plus grand bonheur des services de renseignement ». Bien plus à l'aise en tout cas qu'avec les millions d'acteurs de l'Internet qui le façonnent au quotidien. Il suffit de voir comment les politiciens français font tout pour détruire les échanges de contenu en pair à pair, encourageant ainsi les utilisateurs à se servir uniquement de quelques gros silos, avec lesquels on pourra ensuite parler.

Mais, si le gouvernement a tort de désigner les GAFA et les telcos comme « dirigeants d'Internet », qui sont alors les vrais dirigeants ? Numérama dérape ici en reprenant le jargon inimitable de l'ICANN et en prétendant que l'Internet serait géré par tout le monde, avec une très large participation. Ce serait en effet idéal mais, contrairement à ce que prétend l'ICANN pour essayer de faire oublier sa très faible légitimité, ce n'est pas le cas. Des entreprises comme les gros telcos, ou comme les GAFA, ont effectivement un pouvoir disproportionné. Si le terme de « dirigeants d'Internet » est exagéré, on ne peut pourtant pas nier, et c'est un gros problème de gouvernance en soi, que l'excessive concentration des échanges dans quelques silos (encouragée, comme on l'a vu, par les gouvernements successifs, que le pair à pair hérisse), entraine forcément un excès de pouvoir chez ces silos.

Et Numérama se contredit ensuite en prétendant avoir trouvé les vrais dirigeants : « ce n'est pas en direction des "GAFA" qu'il fallait se tourner, mais plutôt vers l'ICANN, le forum sur la gouvernance d'Internet (IGF), l'Internet Engineering Task Force (IETF), l'Internet Research Task Force (IRTF), l'Internet Society (ISOC), les registres Internet régionaux, l'ISO 3166 MA (Autorité de Maintenance), le W3C ou encore l'Internet Architecture Board (IAB), les forums de rencontre des opérateurs ainsi que les agences intergouvernementales ». À quelques exceptions près comme les « forums de rencontre des opérateurs », cette liste fait la part belle à des institutions clairement identifiables, justement ce que voudraient Cazeneuve et ses pareils. D'ailleurs, la liste tient du catalogue de Prévert en mêlant des organisations ayant un vrai pouvoir (RIR, ICANN, ISOC), des simples forums de bavardage (IGF), des organisations aux pouvoirs purement techniques et limités (IETF) et de mystérieuses « agences intergouvernementales » (on penserait à l'UIT si elle jouait le moindre rôle dans la gouvernance d'Internet).

Bref, il faut s'y résigner, la gouvernance de l'Internet est complexe, il n'y a pas de numéro 1 (dommage pour les ministres français), mais il n'y a pas non plus de « processus ouverts, bottom->up et multipartiesprenantes », quoi que prétende l'ICANN. Il y a beaucoup d'acteurs, avec des rôles variés et des pouvoirs très différents. Ça le rend difficile à gouverner ? Tant mieux, c'est aussi ce qui assure sa résilience face aux tentatives de contrôle.


L'article seul

RFC 7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks

Date de publication du RFC : Avril 2015
Auteur(s) du RFC : B. Moeller, A. Langley (Google)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF tls
Première rédaction de cet article le 25 avril 2015


Le protocole TLS offre un grand nombre de choix : choix de la version, choix des algorithmes cryptographiques, plein d'options... Tous ces choix ne sont pas équivalents en terme de sécurité : les versions anciennes de TLS ont des vulnérabilités absentes des plus récentes, par exemple. Dès qu'un protocole cryptographique a des choix, il y a un risque de sécurité : que l'attaquant tente de perturber la négociation initiale entre les deux parties, pour les amener à choisir les variantes les moins sécurisées, en faisant croire à chacun que son partenaire ne peut pas gérer les meilleures variantes. C'est ce qu'on nomme une attaque par repli (downgrade attack) et c'est une plaie classique des protocoles cryptographiques (sauf de ceux qui n'offrent aucun choix, mais qui ont d'autres problèmes, notamment l'impossibilité d'évoluer). Ce RFC présente une nouvelle technique TLS pour empêcher certaines attaques par repli : annoncer un algorithme cryptographique qui n'est pas un vrai algorithme mais qui signale qu'on a effectué un repli, permettant au partenaire de détecter que quelqu'un a interféré avec la communication. Cette technique se nomme SCSV, pour Signaling Cipher Suite Value.

Normalement, un tel signalement n'est pas nécessaire (c'est très bien expliqué dans cet article sur StackExchange), les règles de négociation de TLS se chargent de tout (RFC 5246, sections 7.3 et 7.4). Mais il y a des serveurs TLS bogués qui réagissent mal avec certaines variantes. Au lieu d'indiquer proprement qu'ils ne gèrent pas ces variantes, ils coupent la communication. Un client TLS qui veut donc maximiser ses chances de se connecter va donc réessayer, en ne proposant pas les choix qui ont pu mener au précédent échec. C'est sympa du point de vue de l'interopérabilité mais cette downgrade dance est dangereuse du point de vue de la sécurité : le serveur, lors de la deuxième tentative, ne sait pas qu'il s'agit d'un repli. Prenons l'exemple d'un attaquant qui a trouvé une faille dans TLS 1.0 mais qui n'existe plus dans TLS 1.2 (celui du RFC 5246). Si Alice et Bob savent tous les deux parler 1.2, c'est cette version qu'ils choisiront, par défaut. Il faut donc les convaincre de se replier en 1.0. Un attaquant actif peut perturber la négotiation TLS (par exemple en ne transmettant pas le ServerHello, donnant au client l'impression que le serveur a ignoré son ClientHello). Certains clients vont alors se dire « zut, demander 1.2 perturbe le serveur, je vais réessayer directement en 1.0 ». Et l'attaquant aura atteint son but. Le serveur, qui sait faire du TLS 1.2, verra une demande en 1.0 et se dire juste « tiens, un vieux client qui ne sait pas faire de 1.2 ». Jusqu'à ce nouveau RFC, la seule protection contre ces attaques était de configurer le serveur pour refuser certains choix vraiment trop mauvais, question sécurité. Cette solution était trop rigide (pour reprendre l'exemple précédent, TLS 1.0 n'est pas catastrophique : il est raisonnable d'autoriser les vieux clients à se connecter en 1.0, mais on veut empêcher que les clients récents ne soient amenés à se limiter à 1.0). Au passage, un exemple d'une telle démarche est discutée dans l'article présentant la configuration TLS de mon blog (la ligne GnuTLSPriorities SECURE:-VERS-SSL3.0:-ARCFOUR-128:-ARCFOUR-40).

L'idéal serait bien sûr qu'il n'y ait pas de serveurs bogués, que la négociation TLS normale suffise, et que les clients n'aient jamais à faire de downgrade dance. Mais, dans le monde cruel où nous vivons, cela n'arrivera pas, les programmeurs ne lisent pas les normes et ne testent pas leur travail. À noter que, même en l'absence d'un attaquant actif, on voit parfois des replis malencontreux : un problème temporaire de réseau peut mener le client TLS à se dire « tiens, pas de réponse, je vais réessayer en TLS 1.0 et sans les extensions, pour voir ».

Donc, pour permettre au serveur de détecter que le client a fait un repli à tort, notre RFC introduit un nouveau pseudo-algorithme de chiffrement, TLS_FALLBACK_SCSV, valeur 0x56,0x00 (désormais dans le registre IANA). Il sera envoyé uniquement par le client, jamais par le serveur. Ce n'est pas un vrai algorithme, juste un signalement par le client qu'une première connexion a échoué et que le client tente un repli (section 4 du RFC). Si le client envoie le pseudo-algorithme TLS_FALLBACK_SCSV dans son ClientHello, et indique un protocole de version inférieure à ce que le serveur peut gérer, le serveur peut alors se rendre compte que le client a effectué un repli à tort (cf. section 3). Il peut alors répondre avec un nouveau message d'erreur, l'alerte TLS inappropriate_fallback (valeur 86).

Le signalement par le client qu'il s'est replié est un (pseudo-)algorithme de chiffrement, pas une extension TLS, car le but est qu'il ne pose de problème avec aucun serveur, même le plus ancien et le plus bogué. Le mécanisme d'indication des algorithmes de chiffrement date des débuts de SSL et on peut donc certainement compter dessus. Au passage, la technique de notre nouveau RFC est la deuxième utilisation de ce principe du SCSV, après la TLS_EMPTY_RENEGOTIATION_INFO_SCSV de la section 3.3 du RFC 5746.

La section 6 de notre RFC explore les cas où le client a intérêt à envoyer un TLS_FALLBACK_SCSV ou pas. Si le client n'a pas pu se connecter en TLS v1 ou supérieur, et se replie sur SSL v3, alors, le TLS_FALLBACK_SCSV est vraiment nécessaire car SSL v3 a de nombreuses faiblesses (la faille Poodle par exemple). Par contre, quand un client a une toute nouvelle version de TLS (à l'heure de la publication de ce RFC, la version 1.3 est en cours de développement), des difficultés avec les vieux serveurs sont à prévoir et il peut être préférable de ne pas envoyer TLS_FALLBACK_SCSV, et d'accepter le repli.

Des mesures faites en novembre 2014 indiquaient que 14 % des serveurs TLS sur l'Internet géraient déjà ce pseudo-algorithme TLS_FALLBACK_SCSV. Si vous voulez tester vous-même, vous pouvez par exemple vous servir d'OpenSSL en ligne de commande :

% openssl s_client -connect google.com:443 -state -fallback_scsv -tls1_1
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL3 alert read:fatal:unknown
SSL_connect:failed in SSLv3 read server hello A
1077786776:error:1409443E:SSL routines:SSL3_READ_BYTES:tlsv1 alert inappropriate fallback:s3_pkt.c:1260:SSL alert number 86
1077786776:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:

Ici, on a tenté de se connecter à Google en envoyant le SCSV (option -fallback_scsv) et en indiquant comme numéro de version TLS 1.1 (alors que Google et OpenSSL savent tous les deux faire du 1.2). Google a donc envoyé l'alarme (le message alert inappropriate fallback). Avec un serveur qui ne gère pas SCSV, on aurait au contraire eu une connexion sans alerte. Si, au lieu du programme openssl, on veut le faire depuis une application qu'on écrit, il y a instructions et code sur le Wiki d'OpenSSL. Notez que le tests des SSL Labs regarde aussi SCSV (message « This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks » ou bien aucune indication dans le cas contraire). Vu avec tshark, le test avec openssl montrera :

client -> serveur:

        Handshake Protocol: Client Hello
            Version: TLS 1.1 (0x0302)
                Cipher Suite: Unknown (0x5600) [version trop ancienne
		de Wireshark, qui n'affiche pas le nom de la SCSV]

serveur -> client:

    TLSv1.1 Record Layer: Encrypted Alert                                                                     
        Content Type: Alert (21)                                                                              
        Version: TLS 1.1 (0x0302)                                                                             
        Length: 2                                                                                             
        Alert Message: Encrypted Alert         

(L'alerte est chiffrée et donc pas décodée par défaut par Wireshark.)

Côté navigateurs Web, Firefox et Chrome gèrent cette technique SCSV mais il semble qu'Internet Explorer ne le fera pas.

Et, pour finir, une bonne explication de SCSV, avec des exemples Wireshark. Et merci à Florian Maury pour sa relecture.


Téléchargez le RFC 7507


L'article seul

RFC 7512: The PKCS#11 URI Scheme

Date de publication du RFC : Avril 2015
Auteur(s) du RFC : J. Pechanec, D. Moffat (Oracle Corporation)
Chemin des normes
Première rédaction de cet article le 23 avril 2015


La norme technique PKCS#11 décrit une interface d'accès à des fonctions cryptographiques. Par exemple, elle permet à un logiciel de signature de signer en utilisant une clé privée stockée dans une base de données, un HSM, une carte à puce (smart card) ou autres dépôts. Jusqu'à présent, la désignation des objets auxquels on pouvait accéder par PKCS#11 n'était pas normalisée et chaque logiciel avait sa méthode. Désormais, il existe un plan d'URI standard pour cela, spécifié dans ce RFC. Bienvenue à pkcs11:object=cle-de-machin;type=public;id=%69%95%3E%5C%F4%BD%EC%91 et à ses copains.

Prenons l'exemple de l'outil de manipulation de certificats certtool, de GnuTLS. Son option load-ca-certificate permet de charger le certificat d'une AC. La valeur de cette option peut être le nom d'un fichier local mais cela peut aussi être un URI PKCS#11, autorisant ainsi l'accès à tous les mécanismes de stockage ayant une interface PKCS#11. Le principe de ces URI PKCS#11 est de permettre l'accès à des objets (comme les certificats, les clés publiques, les clés privées, etc), en donnant une série d'attributs qui identifient l'objet (dans mon exemple au premier paragraphe, les attributs étaient object, type et id). Le but de ces URI est limité à la récupération d'objets existants, on ne s'en sert pas pour créer de nouveaux objets.

Donc, la définition formelle de ce plan d'URI (section 3 de notre RFC) : le plan est pkcs11 (et les URI commencent donc par pkcs11: et ce plan a été réservé dans le registre IANA), et l'URI est ensuite composé de paires attribut-valeur, séparées par des points-virgules. L'attribut id a une valeur binaire (et qui est donc pourcent-encodée dans l'exemple au premier paragraphe), tous les autres sont du texte en UTF-8. Voici les principaux attributs, avec leur nom dans les URI et l'équivalent dans l'API PKCS#11 :

  • id (CKA_ID) est l'identificateur d'un objet. C'est, comme on l'a vu, une valeur binaire opaque.
  • object (CKA_LABEL) est le nom d'un objet. Contrairement à l'id, c'est du texte.
  • serial (serialNumber dans CK_TOKEN_INFO) est le numéro de série du token, le dispositif de stockage des objets (un HSM, par exemple).
  • token (label dans le CK_TOKEN_INFO), le nom du dispositif de stockage.
  • type (CKA_CLASS), désigne le type d'objet stocké qu'on veut récupérer. Cela peut être cert (un certificat), public (une clé publique), private (une clé privée en cryptographie asymétrique), secret-key (une clé secrète en cryptographie symétrique).

Il est également possible d'ajouter des requêtes dans l'URI, après le point d'interrogation. Par exemple, si le dispositif de stockage réclame un PIN, on peut mettre quelque chose comme ?pin-source=file:/etc/dnssec/token_pin dans l'URI (ici, cela dit que le PIN se trouve dans le fichier /etc/dnssec/token_pin).

La section 4 contient plusieurs exemples d'URI PKCS#11, désignant :

  • Une clé publique, identifiée uniquement par son nom : pkcs11:object=my-pubkey;type=public.
  • Un certificat, en indiquant le nom du dépôt matériel (token) utilisé, et l'id du certificat : pkcs11:token=The%20Software%20PKCS%2311%20Softtoken;manufacturer=Snake%20Oil,%20Inc.;model=1.0;object=my-certificate;type=cert;id=%69%95%3E%5C%F4%BD%EC%91. Notez les attributs manufacturer et model, que je n'avais pas cité dans la liste des attributs les plus utilisés.
  • Une clé privée, en utilisant une nouvelle requête, module-name, qui permet d'indiquer la bibliothèque dynamique à charger pour parler au dépôt des clés (PKCS#11 est une API, pas un protocole, et il faut donc une bibliothèque différente par type de HSM ou smart card) : pkcs11:object=my-sign-key;type=private?module-name=snakeoil-pkcs11. Ici, sur une machine Unix, l'application PKCS#11 va donc tenter de charger la bibliothèque snakeoil-pkcs11.so.

Il existe plusieurs implémentations des URI PKCS#11, le document était en développement depuis longtemps. Ainsi, OpenConnect documente « Objects from PKCS#11 tokens are specified by a PKCS#11 URI. ». Le projet Fedora tente de standardiser tous ses logiciels qui font de la cryptographie autour de ces URI « Currently, there are many different ways to tell each application how to find the certificate. [...] where PKCS#11 objects are specified in a textual form which is visible to the user (e.g. on the command line or in a config file), objects SHOULD be specified in the form of a PKCS#11 URI as as described ». Pour un programme développé avec GnuTLS :

/* In addition the following functions can be used to load PKCS #11
key and certificates by specifying a PKCS #11 URL instead of a
filename. */
int gnutls_certificate_set_x509_trust_file (gnutls_certificate_credentials_t cred, const char * cafile, gnutls_x509_crt_fmt_t type)
...

Téléchargez le RFC 7512


L'article seul

RFC 7469: Public Key Pinning Extension for HTTP

Date de publication du RFC : Avril 2015
Auteur(s) du RFC : C. Evans, C. Palmer, R. Sleevi (Google)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF websec
Première rédaction de cet article le 18 avril 2015


Depuis que les piratages de Comodo et DigiNotar ont fait prendre conscience du peu de sécurité qu'apportent les certificats X.509, plusieurs solutions ont été proposées pour combler les failles des autorités de certification. La proposition de ce RFC consiste à permettre à un client d'épingler (to pin) les clés cryptographiques d'un serveur HTTP utilisant TLS, c'est-à-dire à s'en souvenir pendant une durée spécifiée par le serveur. Ainsi, même si un faux certificat est émis par une AC, il ne sera pas accepté.

Un exemple plus récent d'un « vrai / faux certificat » (certificat vrai car émis par une AC reconnue, mais faux car émis sans l'autorisation du titulaire du nom de domaine, et dans l'intention de tromper les utilisateurs) est celui du ministère des finances français. Comme souvent avec les certificats mensongers, celui-ci visait Google (je soupçonne fort que le but était de lire le courrier Gmail des employés, mais, à Bercy, on dément, et on affirme que les buts étaient de pouvoir effectuer un filtrage du contenu sur le Web externe, et de passer les flux à l'antivirus) et c'est ce qui explique que cette compagnie soit très présente dans les forums comme l'IETF où on cherche des solutions aux sérieuses faiblesses de X.509. Parmi les solutions élaborées, il y a DANE, qui s'appuie sur le DNS (RFC 6698), mais Google préfère les certificats à la lumière du jour du RFC 6962 et l'épinglage (pinning) des clés, dans ce tout nouveau RFC 7469.

À noter qu'il existe déjà des en-têtes HTTP permettant au serveur de spécifier au client son comportement, comme le HSTS du RFC 6797. Mais l'épinglage de clés est indépendant de HSTS.

L'épinglage fait partie des techniques TOFU (Trust On First Use) : la première fois qu'un client se connecte au serveur, il ne peut pas savoir si la clé est bonne (il doit se fier à la validation X.509, avec ses limites). À la première connexion, le client HTTP (par exemple un navigateur Web) doit espérer qu'il n'y a pas d'homme du milieu ayant réussi à obtenir un faux certificat (pour cette raison, une attaque persistente, comme celle du ministère des finances, citée plus haut, ne serait pas empêchée par l'épinglage). Aux connexions suivantes, le client HTTP pourra par contre vérifier l'identité du serveur, grâce à la clé épinglée, c'est-à-dire gardée en mémoire. Ce n'est pas idéal (imaginez un homme du milieu ayant un faux certificat pour la première connexion et épinglant ses propres clés, empêchant ainsi toute correction ultérieure !) mais c'est un progrès sur la situation actuelle (valider les clés est un problème difficile en cryptographie). À part des clés partagées à l'avance directement entre les correspondants (ce qui ne passerait évidemment pas à l'échelle pour le Web entier), il n'y a pas de solution parfaitement sûre pour la validation des clés.

La section 2 décrit les détails pratiques. Elle définit un nouvel en-tête HTTP, Public-Key-Pins:. Présent dans une réponse HTTPS, cet en-tête indique au client HTTP que ce serait souhaitable qu'il épingle, qu'il mémorise, la clé publique. Le contenu de l'en-tête Public-Key-Pins: est le condensat de la clé publique utilisée pour TLS, condensat encodé en Base64 (RFC 4648). L'algorithme de condensation est indiqué dans la valeur de l'en-tête. Aujourd'hui, c'est forcément SHA-256 (RFC 6234). La clé est l'encodage DER du champ subjectPublicKeyInfo du certificat X.509 (à noter que les cas des clés brutes du RFC 7250 ou des clés PGP du RFC 6091 ne semblent pas traités, car elles n'ont pas les problèmes des certificats X.509). Une directive max-age est obligatoire dans l'en-tête HTTP, pour indiquer le nombre de secondes que doit durer l'épinglage (après quoi le client HTTP « oublie » la clé). Voici un exemple :

Public-Key-Pins: max-age=604800;
       pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="

Il existe aussi deux directives facultatives. includeSubDomains indique que l'épinglage s'applique aussi aux serveurs dont le nom est un sous-domaine de celui-ci. Si le client se connecte en HTTPS à bar.example.com et reçoit un Public-Key-Pins: avec includeSubDomains, et qu'il se connecte plus tard à foo.bar.example.com, il exigera de trouver la clé épinglée (voir la section 4.2 pour quelques pièges de cette directive). Autre directive facultative, report-uri indique à quel URI le client doit signaler les erreurs résultant de l'épinglage. En effet, on peut prévoir que, comme avec toute technique de sécurité, il y aura des problèmes. Par exemple, des webmestres changeront de clé et oublieront de modifier le Public-Key-Pins:. Il est donc important que ces problèmes soient détectés rapidement. Ce signalement se fera selon la technique décrite plus loin en section 3. Attention aux conséquences pour la vie privée ! La très détaillée section 5 couvre ce risque d'intrusivité. Voici un exemple avec ces deux directives, et l'utilisation de plusieurs clés (par exemple parce qu'un remplacement est en cours) :

Public-Key-Pins: max-age=2592000;
       pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
       pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";
       includeSubDomains;
       report-uri="https://other.example.net/pkp-report"

À noter qu'un deuxième en-tête est défini, Public-Key-Pins-Report-Only:, qui a exactement la même syntaxe, mais une sémantique différente : le client HTTP teste la clé épinglée et, si elle est fausse, le signale à l'URI indiqué par report-uri (qui devient donc obligatoire), mais n'empêche pas l'accès au serveur. C'est utile pour tester avant le vrai déploiement. Les deux en-têtes sont désormais dans le registre des en-têtes.

Comme indiqué plus haut, la section 3 décrit la façon dont un client HTTP peut signaler une erreur de validation. Pour cela, le client HTTP doit fabriquer un message en JSON (RFC 7159) et l'envoyer avec la méthode POST de HTTP à l'URI indiqué dans la directive report-uri. Voici un exemple d'un tel message (la date est au format du RFC 3339) :

 {
    "date-time": "2014-04-06T13:00:50Z",
    "hostname": "www.example.com",
    "port": 443,
    "effective-expiration-date": "2014-05-01T12:40:50Z"
    "served-certificate-chain": [
      "-----BEGIN CERTIFICATE-----\n
      MIIEBDCCAuygAwIBAgIDAjppMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT\n
      ...
    ],
    "validated-certificate-chain": [
      "-----BEGIN CERTIFICATE-----\n
      MIIEBDCCAuygAwIBAgIDAjppMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT\n
      ...
    ],
    "known-pins": [
      'pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="',
      "pin-sha256=\"E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=\""
    ]
  }

Comme souvent en sécurité, le diable est dans les détails, et c'est ce qui explique que la section 4, l'obligatoire « Security Considerations » soit particulièrement longue. Par exemple, l'épinglage peut avoir des conséquences néfastes si on s'est fait voler sa clé privée : normalement, on génère une nouvelle clé, un nouveau certificat et on demande à l'AC de re-signer. Mais on ne pourra pas l'utiliser car la clé publique correspondant à la clé volée est toujours épinglée dans des tas de navigateurs. On peut réduire ce problème en diminuant la durée d'épinglage. Mais, alors, on réduit aussi la durée de la protection dans le cas où une AC génère un certificat mensonger. Un compromis est donc nécessaire. Une approche possible est d'épingler, non pas la clé du serveur mais une clé intermédiaire dans la chaîne des certificats. Supposons que la société Example, qui gère example.com soit cliente de l'AC SmallAC qui a elle-même son certificat signé par une AC très largement reconnue, BigAC. En épinglant la clé de SmallAC, on se protège contre un vol de la clé privée d'example.com, et contre un faux certificat, même émis par BigAC. La société Example reste vulnérable à un faux certificat produit par SmallAC mais cela diminue sérieusement le nombre d'acteurs qui peuvent attaquer Example. (Notez que DANE a les mêmes possibilités : on peut publier dans le DNS sa propre clé, ou bien celle d'une AC.)

On a vu plus haut qu'on pouvait avoir plusieurs clés dans l'en-tête Public-Key-Pins:. Une des utilisations de cette possibilité est le cas où on a une clé de réserve (backup pin), non utilisée mais gardée en un endroit différent de la clé du certificat actuel. Ainsi, si, pour une raison ou pour une autre, la clé est inutilisable, la clé de réserve peut prendre le relais immédiatement puisqu'elle est déjà épinglée.

Autre cas où l'épinglage peut avoir un effet néfaste, celui de l'épinglage hostile. Imaginons un méchant qui obtienne un faux certificat. Il détourne le trafic (par exemple par un empoisonnement DNS) et envoie les gens vers son serveur HTTPS, qui semblera légitime, en raison du faux certificat. Avec l'épinglage, il peut même prolonger son attaque en épinglant sa clé. Si le site légitime n'avait pas été visité avant, ou s'il ne faisait pas d'épinglage, l'attaque peut réussir, bloquant le client HTTPS sur la clé de l'agresseur pour la durée max-age spécifiée par ledit agresseur. Il n'y a pas de solution miracle pour ce problème. Une possibilité est de précharger les clés de sites connus dans le navigateur. Une autre est d'utiliser les certificats au grand jour du RFC 6962. (Et, bien sûr, il y a DANE, RFC 6698, que Google prend toujours soin de ne pas mentionner.)

Autres risques, ceux pour la vie privée (section 5). Un serveur peu sympathique peut utiliser l'épinglage comme une sorte de cookie discret. Par exemple, il peut mettre une petite image dans un sous-domaine, épingler des fausses clés pour ce sous-domaine (une différente par visiteur) et attendre les signalements à report-uri pour identifier un client HTTPS unique. Des sites différents peuvent même coopérer pour avoir le même report-uri, pour suivre un client à travers plusieurs sites.

À noter aussi que les signalements d'un problème de validation contiennent la chaîne de certificats utilisée. Cela peut permettre d'identifier l'utilisation de faux certificats par telle ou telle organisation. C'est plutôt une bonne chose pour détecter des attaques comme celle effectuée au ministère des finances mais cela ne sera évidemment pas apprécié de ceux qui veulent faire du détournement de trafic.

Comme toujours en sécurité, l'utilisabilité est cruciale (section 7). Lorsqu'un épinglage a eu lieu, et que le trafic est ensuite détourné vers un faux serveur, le client HTTPS (par exemple le navigateur Web) va refuser l'accès à ce faux serveur ce qui, du point de vue de M. Toutlemonde devant son navigateur, est un déni de service. Il va donc falloir bien expliquer à M. Toutlemonde ce qui se passe, pour éviter qu'il n'accuse le site légitime.

Le RFC recommande aussi que l'utilisateur puisse accéder facilement à la liste des clés épinglées et aussi, ce qui me semble plus contestable, qu'il puisse la modifier, par exemple en désépinglant les clés. Cela me semble dangereux car cela peut ouvrir une voie à l'ingénierie sociale (« il y a un petit problème technique, si l'accès vous est refusé, cliquez sur Clear all pinned keys »).

L'annexe A contient un exemple, utilisant OpenSSL en ligne de commande, pour générer le Public-Key-Pins:. J'en ai fait un petit script qui s'utilise ainsi :

% make-pin.sh www.ietf.org
...
DHKscLdFrBmZiBGxMdZiyaxp29vnyyPltRS1ZmTF09Y=

Et hop, on n'a plus qu'à mettre Public-Key-Pins: max-age=604800; pin-sha256="DHKscLdFrBmZiBGxMdZiyaxp29vnyyPltRS1ZmTF09Y=" dans la réponse du serveur HTTP. (Tom me fait remarquer à juste titre qu'une clé de secours est obligatoire - section 4.3 - et que donc il faut toujours au moins deux pin-sha256. J'ai simplifié.) Les premières versions de l'Internet-Draft qui a mené à ce RFC utilisaient un programme en Go, make-pin.go :

% openssl s_client -connect www.ietf.org:443 > ietf.pem
...
% ./make-pin ietf.pem 
Hex: 0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6
Base64: DHKscLdFrBmZiBGxMdZiyaxp29vnyyPltRS1ZmTF09Y=

À noter que l'annexe B contient quelques conseils pratiques à l'usage des gérants de serveurs HTTPS, sur le bon déploiement de l'épinglage. Par exemple, il est recommandé de commencer doucement, en mode report-only avant de se jeter dans le grand bain et de risquer de bloquer ses clients. Comme avec n'importe quelle technique de sécurité, on risque de se planter soi-même si on ne fait pas attention : n'épinglez pas bêtement !

Question mises en œuvre, Chrome et Firefox avaient déjà de l'épinglage, avec une série de clés mise en dur dans le logiciel (voir la description de Mozilla et leur annonce). Vous pouvez tester ici si votre navigateur gère l'épinglage. Une description de l'épinglage des clés dans Chrome avait été faite par Adam Langley et sa lecture est recommandée (par exemple pour comprendre pourquoi on épingle juste des clés et pas des certificats entiers). Pour le monde Microsoft, voir leur article. Il y aussi un article détaillé sur le concept, chez OWASP, et l'article de Robert Love avec des détails pratiques,

Merci à Florian Maury et Kim Minh Kaplan pour leur relecture.


Téléchargez le RFC 7469


L'article seul

RFC 7498: Service Function Chaining Problem Statement

Date de publication du RFC : Avril 2015
Auteur(s) du RFC : P. Quinn (Cisco Systems), T. Nadeau (Brocade)
Pour information
Réalisé dans le cadre du groupe de travail IETF sfc
Première rédaction de cet article le 15 avril 2015


Le projet SFC à l'IETF, dont voici le premier RFC, vise à mettre de l'ordre dans les innombrables traitements que suivent les flux IP dans l'Internet. Pare-feux, répartiteurs de charge, dispositifs de censure et d'espionnage, et leurs copains veulent tous appliquer des traitements aux communications et, actuellement, il n'existe pas de cadre unificateur pour ordonnancer proprement ces traitements, encore moins de normes techniques. Ce premier RFC expose le problème qu'on tente de résoudre.

Certains des traitements souhaités sont plutôt dans la couche 3, d'autres peuvent concerner les applications. La liste des traitements potentiellement effectués est très vaste, elle comprend les services de surveillance utilisant la DPI (comme les boîtes noires de Cazeneuve), le NAT, les caches, les divers optimiseurs (TCP, TLS) qui assurent certaines fonctions à la place de la machine terminale, etc. Le RFC n'en parle pas mais des fonctions de censure comme les mensonges DNS du réseau chinois rentrent également dans cette liste.

Certains traitements peuvent concerner une seule machine et d'autres la totalité des communications. Actuellement, ces traitements sont très couplés à la topologie du réseau. Par exemple, pour filtrer le trafic indésirable, on met un pare-feu en coupure du réseau, forçant tout le trafic à passer par le pare-feu. Si on veut effectuer un autre traitement, il faut mettre une seconde machine. Le tout devient vite très rigide, difficile à changer, et difficile à analyser dans ses effets combinés. C'est surtout dommage dans les environnements « à la demande » où on crée et détruit très vite des machines virtuelles et même des réseaux entiers.

Le terme de SFC (Service Function Chain) a été créé pour désigner une nouvelle façon de concevoir ces services : on définit des fonctions abstraites (comme celle de pare-feu) et on a une liste ordonnée de telles fonctions, que le réseau peut appliquer, indépendamment de sa topologie. Le concept est développé plus longuement en section 3 du RFC.

Mais, d'abord, en section 2, l'exposé plus détaillé du problème. Cette section est le gros morceau de ce RFC. On l'a vu brièvement plus haut, aujourd'hui, pour assurer une fonction sur les flux réseau, il faut une topologie particulière. Par exemple, le pare-feu doit être sur le chemin et avoir deux « pattes », introduire un pare-feu là où il n'y en avait pas nécessite donc souvent de ré-architecturer son réseau, ajoutant des sous-réseaux IP qui n'étaient pas nécessaires. Ça manque sérieusement de souplesse. Idéalement, on voudrait que le réseau soit architecturé uniquement autour de la délivrance des paquets, et que les services en plus soient déployables en appuyant sur un bouton, sans refaire le réseau à chaque nouveau service.

Un autre exemple de rigidité concerne les répartiteurs de charge, si communs devant les serveurs Web. Il faut souvent configurer le répartiteur comme étant le routeur par défaut des serveurs HTTP, si bien que même le trafic non-Web (par exemple les communications de gestion en SNMP ou SSH) passe par le répartiteur, sans nécessité.

Autre conséquence de cette dépendance vis-à-vis de la topologie, cela rend difficile le changement du service de transport sous-jacent. Si on passe de MPLS à GRE, on risque de devoir changer pas mal de services, alors que, a priori, ils étaient indépendants des couches basses.

Tout cela fait que les réseaux sont plus complexes qu'ils ne le devraient. Changer un paramètre aussi simple que l'ordre dans lequel sont appliqués des services (filtrer d'abord, puis répartir le trafic après, ou bien le contraire) nécessite de changer la topologie. Résultat, les réseaux tendent à rester plutôt statiques, et à ne pas profiter à fond de la souplesse que permettrait la virtualisation (section 2.7). Et assurer la haute disponibilité devient très compliqué, puisque les services de secours doivent conserver la même topologie que le service principal (afin de recevoir les mêmes traitements).

Un autre problème lié au couplage trop fort entre les services et la topologie du réseau est celui de la sélection du trafic (section 2.8). Souvent, on ne veut appliquer les services qu'à une partie du trafic. Or, dans les architectures actuelles, cela va souvent obliger à faire passer tout le trafic par la machine qui met en œuvre le service. Ou, sinon, à mettre en œuvre des mécanismes de redirection peu pratiques. Prenons un exemple : on veut censurer certaines pages de Wikipédia mais pas toutes. Faire passer la totalité du trafic par le système de DPI qui déterminera quelles pages sont demandées serait lent, nécessiterait de grosses machines pouvant faire de la DPI à ce rythme et pourrait être considéré comme abusif par rapport au but à atteindre. Actuellement, les censeurs déploient donc souvent des architectures mixtes (proxy HTTP transparent, puis redirection du trafic des serveurs Wikipédia - et de seulement ceux-ci - vers le système de DPI, qui n'aura donc à traiter qu'une partie du trafic). C'est quand même peu élégant, et il serait donc souhaitable de découpler sélection du trafic et application du service.

Et, bien sûr, dans l'état actuel des choses, comme il n'y a aucun standardisation des services réseaux et de la manière dont ils s'insèrent, faire coexister des services réseau de plusieurs vendeurs différents est très difficile. Une standardisation, même partielle, simplifierait la vie des administrateurs réseau (le but de ce RFC n'est pas de réaliser cette standardisation, ce qui serait très prématuré, mais d'explorer le problème).

La section 3 de notre RFC, elle, décrit de manière positive ce qu'on attend du service chaining, de la composition des services. Pour découpler le service de la topologie, il faudra un overlay par service. Changer la liste, ou l'ordre de la liste des services appliqués, ne nécessitera donc que de changer la connexion entre ces overlays.

Le mécanisme devra fournir un moyen de classer le trafic, en fonction de critères de sélection. En pratique, les possibilités exactes du système de classification dépendront du matériel et logiciel sous-jacents, et la classification sera donc plus ou moins grossière.

Souvent, les services réseau n'ont besoin que des métadonnées pour agir, et il n'est donc pas forcément nécessaire d'envoyer aux services la totalité des flux.

Voilà, c'est très vague, comme description, je sais, mais c'est l'état actuel de la réflexion sur la composition de services (et cette section 3 a déjà suscité beaucoup de discussion dans le groupe de travail). D'autres RFC sont en préparation, plus concrets, comme le document d'architecture de SFC, presque fini.

Un tel système de composition de services soulève évidemment d'amusantes questions de sécurité (section 4). Certaines sont traitées par des protocoles existants (par exemple la création et la maintenance des overlays, qui n'est pas un problème nouveau).

Le RFC note que certains services peuvent nécessiter des connaissances détaillées sur les données transmises, et que des techniques comme le chiffrement peuvent donc limiter ces services. En pratique, on aura moins d'informations, mais on pourra souvent se débrouiller avec. (Il reste des métadonnées non chiffrées.) D'ailleurs, à propos de chifffrement, le RFC note qu'il faudra aussi protéger le trafic SFC : les machines qui effectuent un certain service peuvent être loin de celles qui se « contentent » de faire passer les paquets et il ne faudrait pas que le trafic entre les deux soit espionné ou, pire, modifié, par un tiers (la protection est parfois assurée par le protocole d'overlay). C'est particulièrement important dans un contexte multi-clients (un grand réseau partagé par de nombreux utilisateurs).

À noter qu'Ericsson prétend avoir un brevet même sur la simple description du problème !


Téléchargez le RFC 7498


L'article seul

RFC 7500: Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries

Date de publication du RFC : Avril 2015
Auteur(s) du RFC : R. Housley (Vigil Security), O. Kolkman (Internet Society)
Pour information
Première rédaction de cet article le 14 avril 2015


Traditionnellement, le fonctionnement de la normalisation dans l'Internet sépare deux fonctions : l'IETF développe les normes techniques (qui sont publiées dans les RFC, documents immuables) et l'IANA gère les nombreux registres qui stockent les paramètres des protocoles de l'IETF. Au contraire des RFC, ces registres changent tout le temps. Ce nouveau RFC décrit les principes de haut niveau sur lesquels repose le fonctionnement de l'IANA.

Pendant longtemps, la gestion des registres et la publication des RFC étaient assurés par le même homme, Jon Postel à l'ISI. Aujourd'hui, les deux opérations sont complètement séparées, https://www.iana.org/ et https://www.rfc-editor.org/.

Ces registres sont cruciaux pour le bon fonctionnement de l'Internet. Presque tous les protocoles Internet dépendent d'un ou de plusieurs registres. Aujourd'hui, il existe plus de 2 000 registres à l'IANA (la liste complète est en https://www.iana.org/protocols). Les valeurs stockées peuvent être des nombres, des chaînes de caractères, des adresses, etc. Leur allocation peut être centralisée (tout est à l'IANA) ou décentralisée, avec l'IANA déléguant à des registres qui à leur tour délèguent, comme c'est le cas pour les noms de domaine et pour les adresses IP.

L'IANA n'a pas de pouvoirs de police : le respect des registres IANA dépend uniquement de la bonne volonté générale. Évidemment, la pression est forte pour respecter ces registres, puisque le bon fonctionnement de l'Internet en dépend. Ce RFC présente les principes sur lesquels ces registres reposent (sections 2 et 3 du RFC) :

  • Unicité des identificateurs. C'est l'un des principaux buts des registres, s'assurer que qu'il n'y a qu'un seul .fr ou .org, ou que l'algorithme 13 de DNSSEC désigne bien ECDSA pour tout le monde.
  • Stabilité. Les registres doivent tenir plus longtemps que la page Web corporate moyenne. Leur contenu existant ne doit pas changer sauf s'il y a une très bonne raison.
  • Prédictabilité. Le processus d'enregistrement doit être prévisible et ne pas comporter de soudaines surprises (« finalement, il faut tel papier en plus »). Parfois, un jugement humain est nécessaire donc le processus n'a pas à être algorithmique, ni à être limité dans le temps, mais il ne doit pas soudainement ajouter des étapes non prévues.
  • Publicité. Les registres doivent être publics (en pratique, le principal mode de distribution est via le Web). Ce n'est pas si évident que cela, les dinosaures attardés de la normalisation, comme l'AFNOR, l'ISO ou l'IEEE ne le font pas.
  • Ouverture. Le processus qui détermine les politiques d'enregistrement doit être ouvert à tous ceux qui désirent participer. Dans presque tous les cas, c'est l'IETF qui détermine cette politique (les exceptions sont importantes comme la gestion de la racine des noms de domaine), via un RFC développé en effet dans un processus ouvert. Le RFC 5226 détaille les politiques IANA possibles. (Parmi elles, certaines nécessitent un examen par un expert, le jugement humain mentionné plus haut.)
  • Transparence. La gestion des registres ne doit pas être opaque. On peut écrire à l'IANA, ou bien passer les voir Away From Keyboard pendant les réunions IETF, où l'IANA a toujours un stand.
  • Redevabilité. L'IANA doit rendre compte de sa gestion. Selon le RFC 6220, la supervision de la fonction IANA incombe à l'IAB (RFC 2850). En outre, l'IAOC (RFC 4071) a un SLA avec l'actuel opérateur de la fonction IANA, l'ICANN. L'IAB et l'IAOC sont eux-même redevables devant une communauté plus large, via le processus NomCom (RFC 3777). Pour les adresses IP et les ressources associées, le RFC 7249 fait gérer la redevabilité par les RIR (RFC 7020). Ceux-ci sont des organisations ouvertes et eux-même redevables devant leurs membres. (Avez-vous noté quel registre n'était pas mentionné comme bon exemple par le RFC ?)

Téléchargez le RFC 7500


L'article seul

RFC 7497: Rate Measurement Test Protocol Problem Statement and Requirements

Date de publication du RFC : Avril 2015
Auteur(s) du RFC : A. Morton (AT&T Labs)
Pour information
Réalisé dans le cadre du groupe de travail IETF ippm
Première rédaction de cet article le 13 avril 2015


La capacité d'un accès Internet est un critère de choix important pour l'utilisateur et c'est même en général le seul qui est mis en avant dans la publicité (« choisissez la fibre qui fonce à 100 Mb/s »). Peut-on la mesurer sérieusement et objectivement ? Ce RFC explore la question, sans donner encore de réponse définitive.

La capacité est définie dans le RFC 5136. Notre nouveau RFC parle de rate et pas de capacity mais la différence est subtile (je vous laisse la découvrir dans le RFC si vous êtes intéressé). En revanche, il faut se méfier de termes flous et souvent utilisés de manière erronée comme « bande passante » ou « débit ». Ce qui intéresse M. Michu (ou, plus exactement, sa fille qui veut télécharger les quatre premiers épisodes de la saison 5 le plus vite possible), c'est bien la capacité de son accès Internet (cf. RFC 6703). Comme c'est un argument commercial essentiel, bien des gens souhaiteraient la mesurer, qu'ils soient simples citoyens, associations de défense des consommateurs ou bien régulateurs des télécoms. C'est ainsi que l'ARCEP a un tel programme de mesure et que l'Union européenne en a lancé un à travers les sondes SamKnows, qui a donné lieu à un excellent rapport, montrant bien les différences entre les proclamations commerciales et la réalité.

Le groupe de travail IPPM de l'IETF travaille depuis longtemps à normaliser les mesures de performance (qui sont souvent floues et approximatives, permettant ainsi toutes les manipulations). Avec la normalisation de la mesure, on pourrait envisager des comparaisons sérieuses entre les offres des FAI. Ce RFC 7497 ne propose pas encore une telle normalisation mais essaie simplement de décrire rapidement le problème. Il se focalise sur l'accès à l'Internet, pas sur les mesures au sein du cœur du réseau (où les capacités sont beaucoup plus élevées). La plupart du temps, le goulet d'étranglement du chemin suivi par les paquets IP sera le lien entre l'utilisateur et le FAI. Ce choix de mesurer l'accès à l'Internet met quelques limites à l'efficacité de la mesure (dans le cœur, on peut utiliser des engins de mesure perfectionnés et coûteux ; chez l'utilisateur, on devra souvent se contenter de dispositifs moins sophistiqués, par exemple ayant une horloge moins précise). Combien de bits/seconde va pouvoir faire passer M. Michu ? Notez que tout dépend d'où on part. De la box ? D'un PC connecté en Wi-Fi ? Le RFC 7398 mettait déjà en avant l'importance de décrire le chemin emprunté par la mesure (le réseau Wi-Fi de M. Michu peut être très chargé, donnant l'impression d'une capacité plus faible qu'elle ne l'est réellement). Autre piège, les FAI imposent souvent aux abonnés des capacités asymétriques : la capacité descendante (dans la terminologie des FAI, qui se voient au-dessus des utilisateurs) est supérieure à la capacité montante.

Une des nombreuses difficultés de la mesure est que les paquets peuvent être traités différemment selon leurs caractéristiques (RFC 2330, section 13) : paquets longs vs. paquets courts, TCP vs. UDP, différence selon le port de destination, etc. Idéalement, le trafic de test, que l'on injectera pour mesurer combien de bits/seconde passeront, devra être une imitation aussi proche que possible du trafic réel de M. Michu. Ce n'est qu'un des très nombreux pièges qui se présentent lorsqu'on veut faire des mesures sur l'Internet. Au moment de la sortie du rapport ARCEP, on avait ainsi vu pas mal de gens peu informés et n'ayant manifestement jamais réfléchi à la question s'exprimer très fort sur divers forums. Ils affirmaient bien haut leurs certitudes (« LOL mais non, c'est idiot, il ne faut pas faire comme cela ») sans que rien n'indique qu'ils avaient compris la complexité du problème.

Dernier piège cité en section 2 de notre RFC, le moment où faire les mesures actives qui sont indispensables à la détermination de la capacité. Si on les fait aux moments pré-définis, on aura des résultats différents selon qu'à ces moment l'utilisateur télécharge en HD ou pas. Il serait préférable d'attendre un moment calme. Mais cela soulève d'intéressants problèmes de protection de la vie privée (par exemple, la documentation de la SamKnows précise qu'il faut l'installer en coupure, de manière à ce qu'elle puisse voir passer tout le trafic).

La section 3 du RFC décrit plus précisément ces mesures actives. Il faut évidemment un protocole de contrôle permettant la coordination entre la sonde de mesure et l'amer (genre RFC 5357 et RFC 4656). Il faut d'autre part que le trafic généré pour le test soit réduit à ce qui est strictement nécessaire pour mesurer la capacité (l'un des problèmes essentiels des mesures actives est qu'elles perturbent le réseau, cf. section 5 du RFC 2680 et section 4 du RFC 3148, et les sections 6 et 7 de notre RFC, qui insistent sur l'importance du consentement). Comme le lien d'accès typique a des capacités asymétriques, l'idéal serait de pouvoir faire des mesures dans une seule direction. Mais c'est en général irréaliste (il faut des équipements de mesure bien synchronisés, notamment du point de vue temporel, et qui soient des boîtes spécialisées, sachant faire ce que ne peut pas faire une machine Unix ordinaire). Donc, la plupart des mesures seront une mesure de l'aller-retour, dont il faudra extraire ensuite les capacités dans chaque direction.

Au bout du compte, ces mesures actives nécessiteront trois composants :

  • L'émetteur, qui est capable d'envoyer des paquets ayant les caractéristiques souhaitées,
  • Le receveur,
  • Et le rapporteur, qui mesure et envoie les résultats dans le format demandé.

Parmi les caractéristiques demandées pour les paquets (section 4), il faut pouvoir choisir la longueur, le contenu (certains équipements réseaux, par exemple ceux qui effectuent de la compression, donnent des résultats différents selon le contenu), les différents champs de l'en-tête IP (comme ceux du RFC 2474), le protocole (TCP ou UDP), les ports, etc. Ces paquets doivent pouvoir être transmis à un rythme choisi. Bien que le RFC passe très rapidement sur ce point, il faut aussi pouvoir, si on utilise TCP, contrôler l'algorithme d'évitement de la congestion.


Téléchargez le RFC 7497


L'article seul

RFC 7401: Host Identity Protocol Version 2 (HIPv2)

Date de publication du RFC : Avril 2015
Auteur(s) du RFC : R. Moskowitz (Verizon), T. Heer (Hirschmann Automation and Control), P. Jokela (Ericsson Research NomadicLab), T. Henderson (University of Washington)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF hip
Première rédaction de cet article le 10 avril 2015


HIP, décrit dans ce RFC, est un protocole très ambitieux, puisqu'il vise à compléter IP en fournissant une séparation de l'identificateur et du localisateur, permettant d'améliorer la sécurité (notamment la résistance aux DoS) et de mieux gérer la mobilité et le multi-homing. Ce RFC décrit la version 2 de HIP, désormais norme officielle (au lieu de protocole expérimental, ce qu'était HIP v1).

L'architecture générale de HIP est décrite dans le RFC 4423 (vous pouvez lire mon article de résumé de HIP). Notre RFC normalise, lui, le protocole concret. HIP repose d'abord sur la séparation entre un nouvel identificateur, le HI (Host Identity) et un localisateur, plus concret, qui sera simplement l'adresse IP, réduite à un rôle moins visible, sans exigence de stabilité. Par exemple, HIP permettra le changement de localisateur (d'adresse IP) en cours de connexion, sans rompre celle-ci, ce qui sera précieux pour la mobilité.

HIP est donc déployable uniquement en modifiant les machines terminales du réseau (si les coupe-feux le laissent passer), sans toucher aux routeurs. Il en existe des mises en œuvres pour FreeBSD et Linux. Le projet OpenHIP adapte également des logiciels comme Wireshark pour qu'ils aient un support HIP. InfraHIP travaille également à l'infrastructure HIP.

Si on ne veut pas lire le RFC 4423, on peut néanmoins avoir une bonne introduction à HIP en lisant les sections 1 et 2 de notre RFC (ou, si on est très pressé, mon article). Elles expliquent le vocabulaire (par exemple, HIP, étant un protocole situé en haut de la couche 3 n'utilise pas le terme de connexion mais celui d'association), le nouvel espace de nommage et les principes du protocole.

L'espace de nommage fait l'objet de la section 3. On distingue les HI (Host Identity), qui sont des clés publiques d'un couple clé privée / clé publique et qui sont de taille variable, et les HIT (Host Identity Tag, décrits dans la section 3.1), qui sont un résumé cryptographique des HI. Ils sont de taille fixe (donc plus faciles à traiter), 128 bits, la taille d'une adresse IPv6. Un préfixe ORCHID (RFC 7343), le 2001:20::/28, sert à éviter toute collision avec les « vraies » adresses IPv6. Avec OpenHIP, la clé peut être générée par le programme hitgen qui fabrique un fichier XML ressemblant à ceci :


<?xml version="1.0" encoding="UTF-8"?>
<my_host_identities>
  <host_identity alg="RSA" alg_id="5" length="128" anon="no" incoming="yes" r1count="10">
    <name>horcrux-1024</name>
    <N>C6EBA2894C33A1312B38853A8ECC0D7967496237A65529807EDF23C4DA753EE88F8FBF71BE38B6910181D5B75DB075B9962326D9BB50C65121DBFD712F1B7F4E2B035953AD650EB5C96B56295FE2731B3B36E8AFED7FB5CD48B73C31A224D4CE4F097D84888EC2E3CA8F3A78939D89B7BCFC5E6DEEAF670695349BFFFE8445F1</N>
    <E>010001</E>
    <D>383A51165838DBDE872611DACC94775692D09677BE87A214954843D7181D3E2C04B0905FF9721481069909AD2C497DED78B7F4FA64CD5F517DADAE8538D89FF21B0498A72F1132545328ABD371B1BAC8ED46441D900921523B78BA55F3FC227F432F2061C92CE9665CB99C1CF425AA90CFC6345FA4E7DA43E477EAF69F86A801</D>
    <P>FF03F93454C9C2D8EC47FE8C9DBF0D82F05E13905F304A5ACA42C45E579F917B4C8CEFEF6B06AAB9BCB7A911D5514B7AEE685DA91E7CC60DDC4C37BA94A22E71</P>
    <Q>C7B0394EB5506B2B75E19E5654262E843659BB76A465C2A7AC47A430749944378E3161FF805B4C6CB037B5CB111F0EF49FF03047FB1CFC51DC0D72DEDAD64F81</Q>
    <dmp1>7426C128DEBD8EEBF2A2D004080D6F0006AF32C5FD352788B6BB3669AA0B59DE08FDE082F202755C67E25735722DB6ED650D502BA961376C34BCDA5D3739AF61</dmp1>
    <dmq1>1B97DE5361FA9AD4869586ABA7351F78658A40BD443A4B8B9FE2C66D6BAF421DEB2827C2869A17156DC444FAAA83002E0D6BC3402F12F24ADD7D7E420D3B5001</dmq1>
    <iqmp>7499A27F59CA1746F1A6E5DE832592F8ACF80B814DD511C490614C44DC92B5CD1650AC944ED5751F28846487C221E8C17E68264DFEF748B86E38EB1F238D94A9</iqmp>
    <HIT>2001:1f:cd4:7125:2427:f77c:d1b6:e15f</HIT>
    <LSI>1.182.225.95</LSI>
  </host_identity>
</my_host_identities>

Notez bien que le fait d'utiliser XML est un choix de OpenHIP, qui n'est utilisé qu'en local. Il n'est pas imposé par la norme qui, sur le câble, n'utilise que du binaire. Les éléments comme P, Q ou iqmp sont les éléments d'une clé RSA (HIP peut utiliser d'autres algorithmes que RSA, comme ECDSA). Le HIT est représenté en utilisant la syntaxe des adresses IPv6, puisqu'il a la même taille et a été conçu pour être stocké comme une adresse par les applications.

La section 3.2 explique comment générer un HIT à partir du HI. Étant un résumé cryptographique (fait avec SHA-256 ou un équivalent), il est sûr, on ne peut pas fabriquer facilement un HI qui aurait le même HIT (cf. annexe E).

Pour signer les paquets, les deux machines utiliseront au début un échange de Diffie-Hellman.

La section 4 donne une vision générale du protocole, qui sera ensuite détaillée dans les sections ultérieures. HIP a reçu le numéro de protocole 139 (il n'a pas changé avec la version 2 de HIP).

La section 4.1 décrit comment former une association entre deux machines HIP. Celle qui demande l'association est nommée l'initiateur, celle qui l'accepte le répondeur. Le protocole d'association nécessite quatre paquets. En effet, avec seulement trois paquets, comme le fait TCP (RFC 793) lors de l'établissement d'une connexion (three-way handshake), on ne peut pas à la fois se protéger contre les DoS et permettre des options par connexion. Se protéger contre les DoS nécessite de ne pas garder d'état tant que le pair n'est pas authentifié, même faiblement. Les techniques qui permettent à TCP de ne pas garder d'état sur le « répondeur », telles que les SYN cookies du RFC 4987 sont incompatibles avec les options TCP.

Voici pourquoi les protocoles plus récents comme SCTP (RFC 3286) ou comme HIP nécessitent quatre paquets.

Dans HIP, ils sont nommés I1, R1, I2 et R2. Les paquets I sont envoyés par l'initiateur et les paquets R par le répondeur.

L'établissement d'une association se passe donc comme ceci :

  • L'initiateur envoie I1 au répondeur. Le paquet contient l'identificateur (le HIT) de l'initiateur et (optionnellement) celui du répondeur. Il contient également les paramètres de la session Diffie-Hellman (attention, c'est un changement par rapport à HIP v1). Aucun état n'est créé chez le répondeur.
  • Le répondeur envoie R1. Ce paquet contient un « puzzle » cryptographique que l'initiateur devra résoudre. Et ce paquet est signé. (Si l'initiateur ne connaissait pas le HI du répondeur, ce qu'on nomme le « mode opportuniste », il ne peut évidemment pas vérifier cette signature, et le mode opportuniste est donc vulnérable aux attaques de l'homme du milieu lors de l'établissement de la connexion, mais pas après. Même ce mode fournit donc au moins autant de sécurité que l'IP actuel.)
  • L'initiateur envoie I2, qui contient la solution du puzzle et les paramètres Diffie-Hellman pour le répondeur. Ce paquet est signé. Tant que cet I2 n'a pas été reçu, le répondeur ne garde aucun état chez lui, ce qui le protège de la plupart des attaques par déni de service.
  • Le répondeur envoie R2 pour accepter l'association. Ce paquet est signé.

Le puzzle, détaillé en section 4.1.1, est un petit problème de calcul que l'initiateur doit résoudre pour montrer qu'il est prêt à « payer », à faire un effort pour que l'association soit acceptée. La difficulté du puzzle peut être réglée par le répondeur, par exemple en étant plus difficile lorsqu'une attaque dDoS est en cours. D'une manière analogue au « minage » Bitcoin, le puzzle consiste simplement à trouver un nombre J tel que, concaténé avec le nombre I envoyé par le répondeur (et imprévisible, pour empêcher les pré-calculs par un attaquant), et avec les HIT des deux pairs, le condensat comprenne un certain nombre K de zéros initiaux (voir l'annexe A pour les détails). Ce K est donc la difficulté du puzzle. À noter qu'il n'y a pas d'estampille temporelle dans les paramètres de la demande de connexion, et que les attaques par rejeu sont donc possibles (mais cela dispense d'une synchronisation d'horloges globale, cf. section 4.1.4).

En pratique, il est très difficile d'imaginer un puzzle qui soit dissuasif contre des attaquants disposant d'un botnet entier, tout en étant soluble par des appareils simples, genre téléphone portable, ne possédant guère de puissance de calcul. (La section 4.1.1 détaille ce problème et les solutions possibles.)

La section 4.1.3 détaille l'utilisation du Diffie-Hellman.

Une des nouveautés de HIP v2 est l'agilité cryptographique, c'est-à-dire le fait que les algorithmes cryptographiques utilisés sont des paramètres du protocole, pas des décisions définitives. On peut donc ainsi changer d'algorithme suivant les progrès de la cryptanalyse. Mais l'agilité a aussi des inconvénients comme le risque d'attaques par repli où, lors de la négociation entre les deux pairs, un homme du milieu réussit à faire croire à Alice que Bob ne gère pas tel algorithme, forçant ainsi Alice à se replier sur un algorithme plus faible. Une nouveauté de ce RFC 7401 est donc la section 4.1.7 sur les protections contre le repli. Contrairement à d'autres protocoles cryptographiques, HIP signe presque tous les paquets relatifs à la négociation d'algorithmes. Ils ne peuvent donc pas être modifiés. Une attaque par rejeu reste possible : Bob met à jour son logiciel, accepte désormais de meilleurs algorithmes mais Mallory a enregistré ses anciens paquets et les envoie à Alice, qui croira alors (même après la vérification de la signature) que Bob continue à ne gérer que de vieux algorithmes. HIP dispose donc d'autres protections comme le fait que les paramètres Diffie-Hellman sont aussi dans ces paquets de négociation et qu'un vieux paquet mènera donc à un échec de la négociation Diffie-Hellman.

Une des grandes forces de HIP est la possibilité de mettre à jour une association existante (section 4.2). À tout moment, pendant la session, un paquet de type UPDATE peut être envoyé pour changer certains paramètres de la session, comme les localisateurs (les adresses IP) utilisées. La signature des paquets permet de s'assurer que le paquet UPDATE est authentique.

Une fois l'association établie, les machines peuvent échanger des données. Si elles utilisent des protocoles comme ESP (RFC 7402), ces données sont protégées contre l'écoute et la modification (HIP lui-même ne chiffre pas).

La section 5 est longue car elle détaille le format, bit par bit, de tous les paquets échangés. Il y a huit types de paquets (section 5.3) comme I1, R1, I2, R2 ou comme UPDATE, présenté plus haut. Dans l'en-tête fixe, commun à tous les paquets, se trouve une liste de paramètres HIP, encodés en TLV, qui permettent de transporter des informations comme les caractéristiques du puzzle (dans les paquets R1), la liste des algorithmes cryptographiques, etc). La liste de tous les paramètres se trouve dans un registre IANA.

Enfin, la section 6 détaille le traitement des paquets, ce qu'il faut faire en les recevant, les erreurs et la façon de les gérer (règle simple : ne pas renvoyer de paquets HIP en cas d'anomalie, seulement des ICMP, et avec un débit limité, car on ne peut pas être sûr du pair s'il y a une erreur), etc.

Notez aussi la section 7 de notre RFC, qui est consacrée à la politique de gestion des identificateurs. Elle recommande fortement que toute mise en œuvre de HIP permette de gérer au moins deux HI différents par machine. Un sera publié et servira à être contacté et au moins un autre sera « anonyme » (terme inexact mais c'est celui du RFC), non publié, utilisé uniquement pour initier des connexions et sera donc plus difficilement traçable. Un inconvénient de l'authentification forte des machines est en effet que cela risque de faire perdre de la vie privée. D'où cette idée d'identificateurs non reliables à une autre identité (si on est très prudent, on utilise un HI différent pour chaque répondeur auquel on se connecte).

La section 8 de notre RFC se penche sur les problèmes de sécurité, une plaie récurrente sur l'Internet d'aujourd'hui, et qui frappera certainement également HIP, s'il est massivement déployé. D'abord, les attaques par déni de service. Celles-ci prennent en général leur source dans une asymétrie, par exemple dans le fait que les coûts soient plus élevés pour l'une des parties. Voici pourquoi il faut quatre paquets pour établir une association : le premier envoyé par le répondeur, R1, peut être un paquet général, envoyé pour toutes les demandes d'association. Le répondeur ne stocke aucun état tant que l'initiateur n'a pas pu prouver son identité.

Comme le R1 est bien plus gros que le I1, HIP pourrait être utilisé pour une attaque par amplification (une attaque où la réponse est plus grosse que la question), en usurpant l'adresse IP source de sa victime. Comme avec le DNS et son RRL, un bon répondeur devrait limiter le rythme d'envoi des R1 par adresse IP.

Enfin, le plus dur, quand on compte sur la cryptographie pour se protéger, c'est de combattre les Hommes du Milieu. Rien ne sert de chiffrer avec les meilleurs algorithmes de cryptographie si, en croyant parler à son correspondant, on parle en fait à un homme du milieu qui s'est fait passer pour le correspondant. HIP a donc ce problème. Certes, les paquets sont signés mais comment être sûr que le HI du correspondant, qui sert à vérifier ces signatures, est le bon ? La seule solution fiable est de valider le HI du correspondant via un tiers. Par exemple, on a trouvé ce HI dans le DNS, dans une zone sécurisée par DNSSEC. Ou bien le HI était dans un certificat X.509 qu'on a validé.

On l'a vu, ce RFC 7401 normalise la version 2 de HIP. Quels sont les principaux changements par rapport à la version 1, normalisée dans le RFC 5201 ? La section 11 répond à cette question. D'abord, on utilise pour représenter les HIT la version 2 d'ORCHID, normalisée dans le RFC 7343 et non plus la v1 du RFC 4843, qui ne permettait l'agilité cryptographique. Résultat, les HIT commenceront désormais par 2001:20... et non plus 2001:10.... Ensuite, les HI peuvent désormais utiliser les courbes elliptiques, via ECDSA. Le protocole d'établissement de l'association a sérieusement changé, avec les paramètres Diffie-Hellman mis plus tôt. Et il y a également d'innombrables changements moins importants, mais qui font que le protocole est différent et incompatible avec la v1. La base installée de HIP étant très faible pour l'instant, cela n'est pas trop gênant. Ces modifications viennent de l'expérience avec HIP v1, obtenue par de nombreux essais avec les différentes mises en œuvre du protocole. Cette expérience a permis de faire passer HIP du statut « Expérimental », celui du RFC 5201, à celui de « Chemin des normes ».

Il existe plusieurs mises en œuvre de HIP v1 (cf. RFC 6538) et HIP for Linux ainsi que OpenHIP ont annoncé leur intention de les adapter à HIP v2.


Téléchargez le RFC 7401


L'article seul

RFC 7538: The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)

Date de publication du RFC : Avril 2015
Auteur(s) du RFC : J. Reschke (greenbyte)
Chemin des normes
Première rédaction de cet article le 10 avril 2015


Le protocole HTTP définit plusieurs codes de retour pour une redirection (« la ressource que tu cherches n'est pas ici, va voir là »). La section 6.4 du RFC 7231 classe ces trois codes de retour en notant que deux désignent des redirections temporaires (302 et 307) et qu'un désigne une redirection permanente (301). Deux codes permettent au client HTTP de remplacer, pour la nouvelle requête, la méthode POST par un GET (301 et 302), un autre ne le permet pas (307). Si vous avez suivi, vous avez noté qu'il manquait un code voulant dire « redirection permanente mais sans changer la méthode HTTP ». C'est l'objet du nouveau code décrit à l'origine dans le RFC 7238, et désormais normalisé dans ce RFC, le code 308.

Donc, 308 veut dire (section 3 de notre RFC) que la ressource Web convoitée a changé de place, que c'est permanent et que le client HTTP devrait donc aller chercher la ressource au nouvel endroit et, s'il le peut, modifier sa base de données (dans le cas d'un crawler, par exemple, ou dans celui d'un navigateur qui modifie les marque-pages). Où est indiqué « le nouvel endroit » ? Par l'en-tête Location: de la réponse HTTP (cf. section 7.1.2 du RFC 7231). Il est recommandé d'inclure un petit texte en HTML fournissant un autre moyen de suivre la redirection, si le client HTTP n'a pas compris le 308. Bref, le 308 est très proche du 301, à la seule exception près qu'un client n'a pas le droit de changer la méthode HTTP (POST, GET, etc) utilisée. Le nouveau code est désormais dans le registre IANA.

Est-ce que l'information comme quoi il y a redirection peut être mémorisée dans les caches ? Il n'y a pas de mécanisme parfait pour cela mais lesdits caches sont invités à regarder le RFC 7234.

Ajouter un nouveau code HTTP peut provoquer des problèmes de déploiement (section 4). En effet, la section 6 du RFC 7231 dit que les codes inconnus commençant par 3 doivent être traités comme le code 300 (qui annonce des choix multiples, en cas de négociation de contenu). Au début, 308 va être inconnu de tous les clients HTTP et sera donc mal interprété. (Vous pouvez tester votre navigateur ici.) Il n'y aura pas de redirection automatique. En attendant que tous les clients soient mis à jour, le webmestre prudent n'utilisera 308 que s'il connait les clients utilisés, ou s'il sait que l'absence de redirection automatique n'est pas trop grave. Le RFC déconseille formellement de faire varier la réponse selon le client (ou selon ce qu'on croit être le client, rappelez-vous que le champ User-Agent: peut être trompeur), cela rend le Web trop difficile à déboguer.

Une façon de s'en tirer pourrait être via le code HTML suggéré plus haut. Par exemple :


HTTP/1.1 308 Permanent Redirect
Content-Type: text/html; charset=UTF-8
Location: http://example.com/new
Content-Length: 454

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
                      "http://www.w3.org/TR/html4/strict.dtd">
<html>
   <head>
      <title>Permanent Redirect</title>
      <meta http-equiv="refresh"
                 content="0; url=http://example.com/new">
   </head>
   <body>
      <p>
         The document has been moved to
         <a href="http://example.com/new">
         http://example.com/new</a>.
      </p>
   </body>
</html>

Ainsi, un navigateur Web qui ne comprend pas le 308 sera redirigé, via le <meta http-equiv="refresh" ....

Où en sont les mises en œuvre ? Vous pouvez tester sur le test de libcurl. Pour les navigateurs et autres clients :

Enfin, je signale deux bons articles sur le 308, un en français et un en anglais. Et, plus technique, la liste des tests qui ont montré que les déploiements du code 308 étaient suffisants pour que l'ancien RFC, expérimental, le RFC 7238, soit remplacé par ce nouveau RFC, qui est, lui, sur le chemin des normes. Aucun changement technique n'a été apporté, juste ce changement de statut.


Téléchargez le RFC 7538


L'article seul

RFC 7503: OSPFv3 Auto-Configuration

Date de publication du RFC : Avril 2015
Auteur(s) du RFC : A. Lindem (Cisco Systems), J. Arkko (Ericsson)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ospf
Première rédaction de cet article le 10 avril 2015


Le protocole de routage OSPF est traditionnellement configuré statiquement, et à la main par l'administrateur réseaux. Certains réseaux, comme par exemple des réseaux un peu complexes à la maison, ont besoin d'un protocole de routage, mais sans avoir d'administrateur réseaux disponible. Il faudrait un OSPF qui se configure tout seul, « plug and play ». Ce court RFC montre que c'est possible, avec très peu de modifications des mises en œuvre d'OSPF.

Ce RFC concerne OSPF v3, normalisé dans le RFC 5340. Les changements du protocole par rapport à cette norme sont minimes. Par exemple, deux routeurs OSPF sont désormais autorisés à devenir adjacents (à établir une sorte de session entre eux), mais si leurs valeurs des paramètres annoncés dans le paquet Hello, comme HelloInterval, diffèrent (dans un réseau auto-configuré, on ne peut pas espérer que tous les routeurs aient la même valeur, malgré ce que demandait l'annexe A.3.2 du RFC 5340). Autre exemple, une hystérésis a été ajouté lors de l'envoi de certains LSA (Link State Advertisement, les messages d'OSPF). Un routeur ayant les modifications permettant l'auto-configuration peut participer à un réseau avec des routeurs n'ayant pas ces modifications (l'inverse n'est pas vrai : un routeur OSPF classique aura du mal à s'insérer dans un réseau auto-configuré). Ces changements sont nécessaires pour s'adapter aux réseaux qui, tout en étant non-gérés, sont composés de plusieurs liens et plusieurs routeurs, commme ceux envisagés par le projet Homenet (RFC 7368).

La section 2 de notre RFC liste les paramètres que doivent adopter les routeurs auto-configurés :

  • La zone (area) doit être 0.
  • OSPF doit être activé sur toutes les interfaces IPv6 du routeur, sauf si on est sûr d'avoir une très bonne raison de ne pas le faire. Par exemple, pour un routeur CPE, genre box, le RFC 7084 demande évidemment qu'on ne fasse pas tourner de protocole de routage dynamique sur l'interface qui mène au FAI.
  • Le type de réseau OSPF (broadcast network ou point-à-point) doit être configuré en fonction du type de réseau physique (Ethernet et Wi-Fi seront tous les deux broadcast network, cf. RFC 2328, section 1.2).
  • Chaque routeur a le choix de paramètres comme HelloInterval (voir la section 3 du RFC pour les détails).
  • Le choix de l'Instance ID (RFC 5838) doit être 0 pour IPv6 et 64 pour IPv4.

A priori, les réseaux auto-configurés n'auront aucune forme d'authentification, celle-ci nécessitant une certaine action de l'administrateur, par exemple entrer les mots de passe (section 4 de notre RFC). Si, toutefois, on veut authentifier, il est recommandé d'utiliser l'option du RFC 7166.

Dans OSPF, chaque routeur a un router ID (RFC 2328, section 1.2), qui fait 32 bits mais n'est pas une adresse IPv4. Il doit être unique dans la zone donc il faut que tous les routeurs auto-configurés se débrouillent pour ne pas prendre le même (autrefois, c'était une adresse IPv4, et celle du routeur - RFC 5340, annexe C.1, donc l'unicité était facilement garantie). Il faut donc désormais la générer aléatoirement, en utilisant comme graine du générateur aléatoire une information unique, comme le router hardware fingerprint décrit en section 7.2.2.

Même dans ce cas, des collisions de router ID sont possibles. Il faut donc une procédure de détection des duplicatas (section 7) qui consiste, pour les voisins immédiats, à se rendre compte qu'un LSA porte le même router ID que vous, avec une adresse IPv6 différente. Il faudra alors changer : c'est le routeur avec la plus petite adresse IP qui doit changer son router ID. Cette procédure de détection et de correction a été le plus gros sujet de discussion au sein du groupe de travail à l'IETF.

Pour les routeurs non-voisins, on utilise un nouveau TLV placé dans le LSA d'auto-configuration, Router-Hardware-Fingerprint, déjà mentionné au paragraphe précédent (au passage, ce nouveau LSA, prévu pour l'auto-configuration, est le numéro 15 et les valeurs qu'il contient font l'objet d'un nouveau registre). Sa valeur est un nombre qui a de très fortes chances d'être unique. Il est recommandé de le fabriquer en concaténant des valeurs probablement uniques, mais stables, comme l'adresse MAC, et numéro de série du routeur.

Comme vu plus haut au sujet de l'authentification, la sécurité ne s'entend pas bien avec l'auto-configuration (section 8 du RFC). L'auto-configuration fait que n'importe quelle nouvelle machine va être « adoptée » par le réseau et pourra y participer immédiatement. Une aubaine pour un attaquant. Si on n'est pas prêt à accepter cela, il faut recourir aux mécanismes d'authentification décrits dans la section 4 (RFC 7166 ou RFC 4552).

Tout le monde n'a pas forcément envie d'utiliser l'auto-configuration, surtout étant donné ses conséquences en termes de sécurité. Il faut donc un moyen de débrayer cette possibilité (section 9 de notre RFC). (Bien sûr, il faut aussi des moyens de configurer des paramètres comme le HelloInterval ou comme le mot de passe, si on veut faire de l'auto-configuration mais en choisissant certains paramètres.)

Voilà, il ne reste plus qu'à déployer ces nouveaux réseaux : d'après les auteurs, il y a déjà deux ou trois mises en œuvre d'OSPF qui incorporent les règles de ce RFC.


Téléchargez le RFC 7503


L'article seul

RFC 7485: Inventory and Analysis of WHOIS Registration Objects

Date de publication du RFC : Mars 2015
Auteur(s) du RFC : L. Zhou, N. Kong, S. Shen (CNNIC), S. Sheng (ICANN), A. Servin (LACNIC)
Pour information
Réalisé dans le cadre du groupe de travail IETF weirds
Première rédaction de cet article le 9 avril 2015


Dans le cadre de la mise au point du protocole RDAP d'accès aux informations sur des objets enregistrés, le groupe de travail à l'IETF s'était livré à une intéressante étude sur les objets enregistrés et accessibles via l'ancien protocole whois. Cette étude a servi à mieux définir ce qu'il fallait comme services dans RDAP, et à spécifier le format de sortie de RDAP, normalisé dans le RFC 7483. Elle a montré, sans surprises, une grande variabilité : si beaucoup d'éléments d'information sont communs à un grand nombre de registres, c'est souvent sous des noms différents. Cette variabilité est, selon les goûts, un des charmes ou un des principaux défauts des registres de l'Internet.

L'étude qui a servi de base à ce RFC date de 2012 (section 3 de notre RFC, pour la méthodologie). Les données ont été récoltées via whois mais aussi via les interfaces Web d'interrogation des registres (à la fois registres de noms de domaine et registres d'adresses IP). Pour les TLD, le nom nic.$TLD a été utilisé, 106 ccTLD ont permis de récupérer de l'information sur ce nom, ainsi que 18 gTLD. Parfois, l'information a été vérifiée en essayant d'autres noms que nic.$TLD. Les capacités des serveurs whois interrogés étaient très variées (cf. section 5.1). Par exemple, si tous permettent évidemment des requêtes au sujet d'un domaine donné, certains permettent aussi des requêtes pour un contact précis ou pour un BE particulier. Pour les registres d'adresses IP, les cinq RIR ont été interrogés.

La section 4 présente les résultats pour les RIR. On y voit déjà la variété des étiquettes qui fait la beauté de whois. Ainsi, le nom de l'organisation titulaire d'un préfixe IP est étiqueté organisation à AfriNIC, Owner à LACNIC et org-name au RIPE-NCC. La date d'enregistrement d'un contact est changed à AfriNIC, RegDate à ARIN et created à LACNIC. Un préfixe IP se nomme inetnum à l'APNIC ou au RIPE-NCC, mais NetRange ou CIDR à l'ARIN (selon qu'il est IPv4 ou IPv6 !) Voici un exemple à l'APNIC :

inetnum:        1.2.2.0 - 1.2.2.255
netname:        KNET
descr:          KNET Techonlogy (BeiJing) Co.,Ltd.
descr:          4,South 4th treet, Zhongguancun,Haidian District,Beijing
admin-c:        ZX2975-AP
tech-c:         WL1818-AP
country:        CN
mnt-by:         MAINT-CNNIC-AP
mnt-irt:        IRT-CNNIC-CN
mnt-routes:     MAINT-CNNIC-AP
status:         ALLOCATED PORTABLE
changed:        ipas@cnnic.cn 20150107  

Certains éléments ne sont pas présents dans tous les RIR et ceux qui le sont reçoivent, comme on vient de le voir, des noms différents.

Et pour les registres de noms de domaine ? C'est évidemment encore plus varié (au fait, les résultats bruts de la collecte faite pendant l'étude sont disponibles en ligne). Au total, 68 éléments différents ont été identifiés, sous 550 étiquettes distinctes. Les auteurs du RFC les ont classé en éléments publics et autres éléments. Les éléments publics sont ceux qui sont mentionnés dans le document ICANN, « gTLD Applicant Guidebook » de 2012, ou bien dans les RFC sur EPP, RFC 5730, RFC 5731, RFC 5732 ou RFC 5733 (un choix très contestable qui donne une sorte de privilège aux règles des TLD régulés par le gouvernement états-unien).

Parmi les exemples d'éléments publics, on peut trouver évidemment le nom de domaine (l'étiquette la plus fréquente étant domain name mais cinq autres ont été trouvées) suivi de la date de création (en général created mais vingt-trois autres étiquettes sont possible, la deuxième plus grande variété de vocabulaire). 95 % des registres ont donc un élément « nom de domaine » (on peut se demander comment font les 5 % restants...), 85 % une date de création, 77 % un statut du domaine, etc. Par contre, « dernier transfert », le moins fréquent, n'est présent que chez 3 % des registres.

On retrouve la même variété pour les titulaires et les contacts. Aucun élément n'est présent dans la majorité des registres (même pas l'adresse de courrier électronique). Ceux qui le sont ont des noms très variés. Ainsi, pour le contact technique, le téléphone dudit contact est décrit par pas moins de dix étiquettes différentes.

Le cas des serveurs de noms est plus compliqué car, contrairement aux contacts, le serveur de noms n'est pas forcément un objet de première classe dans le modèle de données du registre : il peut être un simple attribut du domaine. C'est pour cela que, dans le monde EPP, le RFC 5732 n'est pas mis en œuvre partout. Ainsi, alors que 92 % des registres indiquent les serveurs de noms dans les réponses (sous 63 étiquettes distinctes, un record, en partie dû à des mécanismes de nommage comme nameserver N avec N indiquant le rang du serveur), tous ne permettent pas des requêtes whois directes sur un serveur de noms.

Enfin, il y a les éléments « divers », ceux qui ne sont pas spécifiés dans les règles ICANN ou dans les RFC sur EPP et qui incluent, par exemple, l'URL d'un site Web associé au domaine, un champ de commentaires (remarks), une date d'anniversaire (six TLD sont dans ce cas, probablement tous à l'AFNIC), un identificateur de marque déposée, etc. La section 6 de notre RFC suggère que des extensions au modèle de données de RDAP pourraient s'inspirer de ces éléments divers, par exemple le point de contact du NOC (pourquoi diable ne pas se contenter du contact technique ?), le fait que l'identité du titulaire soit masquée (ce qui est parfois noté, bien à tort, anonymous), etc.

Il n'y a pas que le modèle de données (et la terminologie associée) qui varie beaucoup d'un registre à l'autre, il y a aussi le format de présentation. Les deux les plus populaires sont clé:valeur et en bloc. Un exemple en clé:valeur est donné par .org :

Domain Name:TV5.ORG
Creation Date: 1995-09-29T04:00:00Z
Updated Date: 2013-09-30T14:24:25Z
Sponsoring Registrar:Gandi SAS (R42-LROR)
...
Registrant Name:Thomas Derobe
Registrant Organization:TV5 Monde
Registrant Street: 131 avenue de Wagram

Un exemple de bloc par le registre de .za :

    Domain Name:
        sab.co.za

    Registrant:
        The South African Breweries Limited
        
        Email: domains@sabmiller.com
        Tel: +27.118818414
        Fax: +27.118818136

    Registrant's Address:
        P.O.Box 782178
        2196 Sandton Sandown
        ZA

    Registrar:
        Ascio

    Relevant Dates:
        Registration Date: 1997-05-06
        Renewal Date:      2015-05-06

    Domain Status:
        Registered until renewal date

Mais il faut remarquer qu'on trouve de tout. Comment classer le résultat du whois de .jp ?

Domain Information:
a. [Domain Name]                YAMAHA.CO.JP
g. [Organization]               YAMAHA Corporation
l. [Organization Type]          Corporation
m. [Administrative Contact]     HN050JP
n. [Technical Contact]          TT9781JP
p. [Name Server]                ns1.dhs.jtidc.jp
p. [Name Server]                ns2.dhs.jtidc.jp
s. [Signing Key]                
[State]                         Connected (2016/03/31)
[Registered Date]                
[Connected Date]                2010/08/02
[Last Update]                   2015/04/01 01:12:19 (JST)

À noter également que onze registres envoient l'information autrement qu'en anglais dans l'alphabet latin (le RFC, comme beaucoup de documents écrits dans le milieu ICANN, confond langue et écriture et écrit « 11 registries give local script responses. The WHOIS information of other registries are all represented in English. »).

Bref, ce RFC illustre bien une des motivations principales du projet RDAP : normaliser la sortie du serveur, de façon à faciliter les traitements automatiques.


Téléchargez le RFC 7485


L'article seul

RFC 7530: Network File System (NFS) Version 4 Protocol

Date de publication du RFC : Mars 2015
Auteur(s) du RFC : T. Haynes (Primary Data), D. Noveck (Dell)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF nfsv4
Première rédaction de cet article le 7 avril 2015


Le protocole d'accès aux fichiers NFS est très ancien. Sa version 2 est décrite dans le RFC 1094, sa version 3 dans le RFC 1813 et la version 4 faisait l'objet du RFC 3530, qui vient d'être remplacé par ce nouveau RFC. Rien de spectaculaire, juste des clarifications. Notez que, malgré son ancienneté, NFSv3 reste encore très utilisé.

NFS est un gros protocole compliqué (ce RFC fait 300 pages tout rond, et la section 1.1 affirme sans rire qu'une des caractéristiques de NFS est sa simplicité) et n'est pas ma spécialité donc je vais passer rapidement et me contenter des grandes lignes du protocole. NFS permet donc l'accès distant à des fichiers. Les versions anciennes utilisaient au moins deux protocoles distincts, NFS lui-même et « mount » mais NFSv4 n'en a plus qu'un. De même, les éventuels protocoles supplémentaires pour avoir des fonctions de verrouillage des fichiers ont disparu, tout étant désormais intégré dans NFS. Autres caractéristiques importantes de la version 4 (qui fêtera ses quinze ans à la fin de l'année), une meilleure prise en compte de la sécurité (avec négociation de la sécurité), de l'internationalisation, des possibilités de cache chez le client, et un meilleur fonctionnement au dessus de l'Internet (les versions précédentes marchaient surtout en réseau local). NFSv4 essaie aussi d'être plus agnostique par rapport au système d'exploitation sous-jacent, les précédentes versions étant très orientées Unix.

À noter que les RFC sur les versions 2 et 3 de NFS étaient de simples documentations d'un protocole développé de manière fermée par Sun, alors que NFSv4 est entièrement développé à l'IETF.

NFS repose sur la représentation XDR, RFC 7531 et sur le mécanisme RPC (RFC 4506 et RFC 5531, étendu, pour la sécurité, par le RFC 5403).

NFS est un service d'accès aux fichiers : son modèle est celui d'un système de fichiers hiérarchique (avec des répertoires qui peuvent contenir des fichiers et d'autres répertoires). Les noms des fichiers et répertoires sont forcément en UTF-8, pour l'internationalisation. Le contenu des fichiers n'est pas interprété par NFS, c'est juste une suite d'octets. Quand un client NFS ouvre un fichier, il reçoit un filehandle, un identificateur qu'il utilisera dans les requêtes d'entrée/sortie suivantes. Avec les précédentes versions de NFS, on obtenait ce filehandle via le protocole « mount » mais ce protocole a désormais disparu (entre autres en raison de sa faible sécurité, et car il ne permettait pas facilement de passer les pare-feux). Désormais (idée qui remonte aux RFC 2054 et RFC 2055), les filehandles s'obtiennent directement avec le protocole NFS. Les filehandles peuvent être permanents ou temporaires (une nouveauté de NFSv4). Chaque fichier peut avoir toute une collection d'attributs, comme le type du fichier (fichier ordinaire ou répertoire) ou comme des ACL.

Autre changement par rapport à NFSv3, les opérations d'ouverture et de fermeture du fichier sont désormais explicites. La fermeture permet au serveur de libérer tout état associé au fichier, ce qui était impossible dans les vieilles versions de NFS.

Autre propriété importante de NFSv4 : le serveur peut déléguer à un client certaines responsabilités. Si un client a une délégation de lecture, il est sûr qu'aucun autre client ne pourra écrire dans le fichier pendant ce temps. S'il a une délégation d'écriture, personne n'aura aucun accès au fichier tant que la délégation durera.

NFSv2 et NFSv3 utilisaient un port fixe, 2049 (tout en dépendant de portmap pour des raisons que je n'ai jamais comprises). NFSv4 permet d'utiliser plusieurs transports, comme TCP ou SCTP, et n'est pas forcément sur le port 2049.

La section 1.5 de notre RFC résume les changements qu'a connus NFSv4 depuis le RFC 3530. Le protocole est le même, ce sont surtout des différences de rédaction comme :

  • XDR a été déplacé vers un RFC distinct, le RFC 7531.
  • Les références à des noms de domaine, par exemple pour les noms de propriétaires des fichiers, suivent désormais la nouvelle norme IDN, le RFC 5891.

Il existe aujourd'hui des mises en œuvre de NFS pour tous les systèmes. Certaines font au choix du NFSv3 ou du NFSv4, certaines sont encore purement NFSv3.


Téléchargez le RFC 7530


L'article seul

Fiche de lecture : Hadopi - Plongée au cœur de l'institution la plus détestée de France

Auteur(s) du livre : Tris Acatrinei
Éditeur : Fyp
978-2-36405-101-0
Publié en 2013
Première rédaction de cet article le 6 avril 2015


Qui s'intéresse encore à l'HADOPI ? Cette institution, créée pour plaire aux ayant-trop-de-droits qui veulent à tout prix maintenir leur modèle économique existant, a été en effet « l'institution la plus détestée de France », au moins chez les internautes. Depuis, nous avons eu les révélations de Snowden sur la NSA, la censure administrative du Web, le projet de loi Renseignement et l'HADOPI semble, par comparaison, bien inoffensive. Pourtant, c'était une des institutions qui ont pavé la voie pour un contrôle de plus en plus étroit de l'Internet par l'administration et, à ce titre, il est toujours utile de suivre son histoire. Ce récit très vivant par une ex-employée de l'HADOPI est toujours intéressant à lire. (Le site officiel.)

C'est que l'HADOPI a eu une histoire compliquée, hésitant entre jouer franchement son rôle de méchant, chargé de la répression des tentatives de partage de la culture, et faire semblant d'être une organisation progressiste, défrichant des nouvelles voies, faisant de la pédagogie, développant des nouveaux moyens de diffuser la culture. Plusieurs personnes de bonne volonté se sont fait prendre à ce discours et ont choisi de donner un coup de main pendant un certain temps à l'HADOPI (notamment dans ses « Labs »). L'auteure de ce livre, elle, a été recrutée pour le plus beau métier du monde : community manager, elle était chargée de défendre la HADOPI face à ces internautes que l'institution était chargée de persécuter.

Difficile de tirer un bilan de cette courte expérience : malgré un budget démesuré, l'HADOPI ne s'est jamais lancé dans des projets vraiment ambitieux (par exemple développer l'offre légale...) Détestée des internautes, ridiculisée par des campagnes de publicité lamentables, ou par des projets sans suite (comme le label PUR, pour lequel j'avais failli remplir un dossier, pour que ce blog soit labelisé...), vite rejetée par les ayant-tous-les-droits qui la trouvaient pas assez répressive, l'HADOPI ne laissera que le souvenir d'un grand gaspillage.

L'intérieur ne vaut pas l'extérieur et Tris Acatrinei raconte tout ce qui avait aussi plombé l'HADOPI en interne : bureaucratie incompréhensible, règles administratives ultra-contraignantes qui bloquaient bien des projets, luttes entre services, les ingrédients habituels d'une administration. Son récit du cheminement d'un simple article de blog, qui devait être validé à l'issue d'un long processus (utilisant le papier, bien sûr), illustre bien le décalage entre l'administration française et l'Internet.

Bien sûr, tout n'était pas de la faute de l'HADOPI. Tris Acatrinei décrit bien l'étonnant maquis des intermédiaires de la culture, comme ces innombrables organisations qui collectent l'argent à la place des créateurs, bénéficient d'un statut bizarre (organisations de droit privé mais bénéficiant d'un monopole public) et s'opposent à tout changement, sauf s'il va encore plus loin dans la protection de leurs droits (qui ne sont évidemment pas ceux des auteurs).

L'auteure remet bien la question, finalement très secondaire, de l'HADOPI en perspective : elle rappelle la genèse de cette organisation, au milieu de tous les débats qui ont agité la France au sujet de la diffusion de la culture sur l'Internet. Et, après avoir exposé le fonctionnement de l'HADOPI vu de l'intérieur, elle se lance dans une réflexion sur les moyens d'améliorer cette diffusion. Finalement, le plan du livre résume bien ce qu'a été la trajectoire de l'HADOPI : un problème mal posé, une organisation inefficace et répressive, un problème toujours grand ouvert.


L'article seul

RFC 7481: Security Services for the Registration Data Access Protocol

Date de publication du RFC : Mars 2015
Auteur(s) du RFC : S. Hollenbeck (Verisign Labs), N. Kong (CNNIC)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF weirds
Première rédaction de cet article le 4 avril 2015


Une des faiblesses les plus souvent citées de l'ancien protocole whois est son manque de sécurité : pas d'authentification du client (et donc pas de moyen simple de servir des contenus plus ou moins complets selon le client), et pas de confidentialité. Le candidat à sa succession, RDAP, va-t-il faire mieux ? En tout cas, il propose de nombreux services de sécurité, détaillés dans ce RFC. Comment et au profit de qui les utiliser, voici qui va sans doute déclencher de nouvelles disputes de gouvernance.

Le nouveau protocole RDAP est normalisé dans plusieurs RFC comme le RFC 7480 qui décrit comment faire tourner RDAP sur HTTP avec une architecture REST. La grande majorité des fonctions de sécurité de RDAP découlent de cette utilisation de HTTP. Ces fonctions étaient réclamés dès le cahier des charges pour un successeur de whois, le RFC 3707.

La section 3 de notre RFC liste les services de sécurité attendus, et la manière dont RDAP les fournit, en général en s'appuyant sur les services équivalents fournis par HTTP et HTTPS. Ainsi, la premier service demandé est le contrôle d'accès et la section 10.2.2 du RFC 7483, RFC consacré au format des réponses RDAP (en JSON) prévoit un mécanisme standard pour indiquer qu'une partie de la réponse a été délibérement tronquée ou omise.

Ensuite, l'authentification (section 3.1.4.2 du RFC 3707). Pas d'autorisation fine sans authentification préalable. Avec whois, on doit servir les mêmes données à tout le monde, car il n'y a pas d'authentification disponible (parfois, une authentification sommaire est faite via l'adresse IP du client, un registre peut servir davantage d'informations à ses employés, en vérifiant que l'adresse IP source est celle du réseau local du registre). Quand RDAP tourne sur HTTP, il doit donc utiliser les mécanismes d'authentification de HTTP, décrits dans le RFC 7235. Si on utilise le mécanisme basic, qui envoie en clair le mot de passe, il faut en plus utiliser TLS (RFC 2818). On peut aussi tout faire avec TLS, en authentifiant le client par un certificat (section 7.4.6 du RFC 5246) mais c'est optionnel dans RDAP, contrairement aux mécanismes du RFC 7235, qui doivent être présents. Ces mécanismes ne permettent pas d'authentifier le serveur, mais on peut, là encore, se servir de TLS pour cela (en vérifiant le certificat du serveur).

Les mécanismes classiques d'authentification via HTTP nécessitent que le client gère des informations de créance pour tous les serveurs. Or, un même client RDAP peut parler à de nombreux serveurs. Il est donc intéressant de regarder du côté des mécanismes d'authentification fédérés, qui peuvent permettre de n'avoir qu'une seule information de créance, utilisée pour tous les serveurs. Il existe pour cela plusieurs techniques utilisable en HTTP, OAuth (RFC 6749), OpenID, des assertions SAML, ou bien des certificats client avec des AC reconnues par tous les serveurs. À noter que RDAP ne dispose pas (pas encore ?) d'une solution pour découvrir quel mécanisme d'authentification est utilisé par quel serveur.

Une fois qu'on a l'authentification, on peut bâtir l'autorisation et donner des accès aux clients en fonction de leur identité (section 3.1.4.2 du RFC 3707). On peut par exemple :

  • Permettre un accès à tout client (mode « anonyme » comme avec le whois actuel) mais en ne donnant accès qu'à peu d'informations,
  • Ne donner un accès complet qu'aux informations ayant un rapport avec le client (par exemple permettre à un titulaire de tout voir sur ses propres noms),
  • Donner un accès complet aux clients authentifiés comme travaillant pour la NSA.

Au bout du compte, il s'agit de décisions politiques, à prendre dans chaque registre, et ce RFC n'indique donc pas de politique, il indique juste les bases sur lesquelles mettre en œuvre une telle politique.

Parmi les services de sécurité, il y a bien sûr la disponibilité : un serveur RDAP super-protégé mais qui serait tout le temps en panne n'aurait guère d'utilité. Notre RFC rappelle donc qu'il existe un RFC sur les attaques par déni de service (le RFC 4732). Un serveur RDAP est autorisé à se prémunir contre les attaques et les excès, par exemple en limitant d'autorité le trafic. Si un client est refusé en raison de cette limitation, le code de retour HTTP recommandé est le 429 (RFC 6585). Si le client est simplement trop enthousiaste, il ralentira alors ses accès. Évidemment, si c'est un attaquant, il continuera.

Autre service de sécurité essentiel, la confidentialité. Whois n'avait aucun mécanisme de protection contre un tiers qui écoute le réseau (d'un autre côté, comme tout était public...) RDAP permet d'utiliser HTTP sur TLS (RFC 2818), permettant ainsi au chiffrement de protéger la confidentialité des données. (On note que les serveurs RDAP expérimentaux actuellement existants sont loin de tous permettre un accès en HTTPS.) À noter que TLS protège le canal, pas les données : il n'y a pas de chiffrement de bout en bout dans RDAP, pour l'instant.

Et le dernier service de sécurité dont on veut disposer est l'intégrité, la garantie que les données ne soient pas modifiées en route. Il n'existe pas non plus de mécanisme de signature des données dans RDAP, mécanisme qui assurerait une protection de bout en bout. Il faut donc utiliser TLS, dont les paquets comportent un MAC qui permet de détecter les modifications.

On a parlé de confidentialité mais la section 4 de notre RFC pose le problème dans une perspective plus générale, celle de la protection de la vie privée. Ce problème est la plaie de whois (« notre conflit du Moyen-Orient », disait Fadi Chehadé en faisant allusion à la durée du problème et à l'absence de perspectives de solution) et a fait l'objet d'innombrables débats, à l'ICANN ou ailleurs. Comme whois ne fournit aucun accès différencié (tout est public ou pas distribué du tout), les données stockées dans les registres, qui sont souvent sensibles, sont envoyées à tous. Résultat, la seule protection est souvent de mentir, dissimulant ses données personnelles. Parfois, il existe des services intermédiaires qui masquent les données, relaient le courrier, etc. RDAP ne change pas la question des données récoltées et stockées par le registre (si le registre se fait pirater, ou bien s'il donne toutes ses données à des services de surveillance étatiques ou non, la vie privée sera compromise, RDAP ou pas RDAP). En revanche, il permet de ne pas envoyer les données à tout le monde, réservant par exemple les données personnelles à certains clients. RDAP permet par exemple de transmettre davantage de données à des membres des forces de l'ordre, dûment authentifiés. Notez donc que RDAP va soulever des problèmes à lui, que n'avait pas whois. Whois ne permettait techniquement pas de donner plus d'informations aux forces de l'ordre, ou aux ayant-droits, ou à d'autres catégories. RDAP le permet techniquement et certains acteurs le demanderont sans aucun doute.

Comme toujours en protection des données personnelles, le mieux, pour éviter les ennuis, est de ne pas récolter les données du tout. Cette solution simple est la plus efficace, protégeant aussi bien du piratage que d'un opérateur indélicat. Ainsi, les réponses RDAP utilisent jCard (RFC 7095) pour les données personnelles. jCard a énormément de champs possibles et tous ne sont pas pertinents pour le registre. Il est donc possible de ne pas les collecter (et donc de ne pas les envoyer).

À noter qu'il existe aussi un risque lié à la vie privée pour le client : les requêtes qu'il fait peuvent donner des informations sur son activité. Le chiffrement protège contre l'accès d'un tiers à ces informations, mais pas contre le registre lui-même, qui doit donc rester discret sur les requêtes qu'il reçoit.

La section 5 du RFC couvre quelques risques de sécurité résiduels. Par exemple, on voit souvent dans les réponses whois des tentatives d'injection, notamment de code HTML. Notre RFC rappelle donc que les données renvoyées par RDAP ne sont pas forcément sûres et qu'un client RDAP ne doit pas les afficher aveuglément, ni les mettre dans une base de données sans faire attention.

Et, enfin, la section 5 de notre RFC rappelle aussi que le protocole peut assurer des choses comme l'intégrité des données (ce qui a été reçu par le client est bien ce qui avait été envoyé par le serveur) mais que cela ne garantit pas l'exactitude des données : celles-ci étaient peut-être fausses dès le début, soit par négligence de la part de celui qui les a déclarées, soit parce que mentir est, à l'heure actuelle, souvent le seul moyen de protéger ses données personnelles.


Téléchargez le RFC 7481


L'article seul

Fiche de lecture : Neuroland

Auteur(s) du livre : Sébastien Bohler
Éditeur : Robert Laffont
9-782221-144756
Publié en 2015
Première rédaction de cet article le 4 avril 2015


Ce roman commence avec des attentats islamistes et un ministre de l'Intérieur qui veut en profiter pour faire avancer un projet de haute technologie que lui avait vendu un commercial ambitieux. Non, ce n'est pas Blue Coat convaincant Bernard Cazeneuve de déployer des boîtes noires dans l'Internet. (Le livre a été écrit avant les événements de janvier et avant le projet de loi Renseignement.) C'est plus que cela, il s'agit d'explorer directement le cerveau. Comme dans la précédent roman de Sébastien Bohler, « Les soldats de l'or gris », on va exploiter la neurologie pour faire la guerre.

Mais les ambitions scientifiques ont un peu baissé : on n'essaie plus de contrôler le cerveau, juste de lire dedans. Un ambitieux scientifique prétend qu'on pourra bientôt connaître les pensées grâce aux avancées en traitement des images de l'activité cérébrable. Le ministre est facilement convaincu : après un attentat épouvantable, les gens réclament de l'action. Et puis le ministre espère bien avoir un monopole sur cette activité, imaginant déjà toutes les polices du monde apportant discrètement leurs suspects dans les locaux de Neuroland, à Saclay, pour lire leurs pensées.

Mais est-ce réellement faisable techniquement ? Et le scientifique qui a vendu cette idée est-il de confiance ? Les ambitions des scientifiques ne sont pas forcément compatibles entre elles, ni avec celles du patron de Neuroland, ou avec celles du ministre, et beaucoup de choses ont été dissimulées pour lancer le projet, choses dont la révélation peut le mettre en péril. Pour sauver le projet, il faudra un peu oublier les principes du début...

Excellent mélange de science, de violence, et de politique, une lecture très recommandée. Je vous laisse essayer de retrouver de quels personnages réels sont inspirés des gens comme le fondateur de Neuroland. Ne vous arrêtez pas aux trois premiers chapitres, la fin est bien plus riche et plus compliquée.

Avertissement : j'ai reçu un exemplaire gratuit (mais je ne fais de critiques favorables que s'il est accompagné d'une boîte de chocolats.)

Une bonne critique radiophonique (mais qui révèle un peu trop de l'intrigue) est chez France Bleu. (Il y a aussi celle-ci sur Europe 1, vers 25'30 du début, mais je ne l'ai pas encore écoutée.)


L'article seul

RFC 7484: Finding the Authoritative Registration Data (RDAP) Service

Date de publication du RFC : Mars 2015
Auteur(s) du RFC : M. Blanchet (Viagenie)
Chemin des normes
Première rédaction de cet article le 1 avril 2015


Le nouveau protocole RDAP d'accès à l'information sur les objets (noms de domaines, adresses IP, etc) stockés dans un registre fonctionne en interrogeant le serveur en HTTP. Encore faut-il trouver le serveur. Comment le client RDAP qui veut des informations sur 2001:67c:288::2 sait-il à quel serveur demander ? Ce fut une des plus chaudes discussions au sein du groupe de travail IETF qui a mis au point RDAP. Ce RFC décrit le mécanisme choisi. En gros, l'IANA gère des « méta-services » qui donnent la liste de serveurs RDAP, mais il peut aussi y avoir redirection d'un serveur RDAP vers un autre.

Le protocole RDAP est décrit entre autres dans le RFC 7480 qui précise comment utiliser HTTP pour transporter les requêtes et réponses RDAP. Comme indiqué plus haut, il ne précise pas comment trouver le serveur RDAP responsable d'un objet donné. Avant d'exposer la solution utilisée, la section 1 de notre RFC rappelle comment ces objets (noms de domaine, adresses IP, numéros d'AS, etc) sont alloués et délégués. L'IANA délégue les TLD aux registres de noms de domaines, des grands préfixes IP et les blocs de numéros d'AS aux RIR. Il est donc logique que RDAP suive le même chemin : pour trouver le serveur responsable, on commence par demander à l'IANA, qui a déjà les processus pour cela, et maintient les registres correspondants (adresses IPv4, adresses IPv6, numéros d'AS et domaines).

Pour permettre à RDAP de fonctionner, ce RFC demande donc à l'IANA quelques fichiers supplémentaires, au format JSON (RFC 7159), dont le contenu dérive des registres cités plus haut. (À noter que c'est le premier registre IANA au format JSON.) Et l'IANA doit aussi prévoir des serveurs adaptés à servir ces fichiers, nommés RDAP Bootstrap Service, à de nombreux clients RDAP.

Le format de ces fichiers JSON est décrit dans la section 3 de notre RFC. Chaque bootstrap service contient des métadonnées comme un numéro de version et une date de publication, et il contient un membre nommé services qui indique les URL où aller chercher l'information (la syntaxe formelle figure en section 10). Actuellement, ces services sont encore vides :

 
% curl http://data.iana.org/rdap/ipv4.json
{
  "description": "RDAP bootstrap file for IPv4 address allocations",
  "publication": "2015-03-20T20:39:57Z",
  "services": [],
  "version": "1.0"
}

Mais dans le futur, ce sera un tableau donnant, pour des objets donnés, les URL des serveurs RDAP à contacter pour ces objets indiqués, par exemple :

 {
       "version": "1.0",
       "publication": "2024-01-07T10:11:12Z",
       "description": "RDAP Bootstrap file for example registries.",
       "services": [
         [
           ["1.0.0.0/8", "192.0.0.0/8"],
           [
             "https://rir1.example.com/myrdap/"
           ]
         ],
...

Le membre publication indique la date de parution au format du RFC 3339. Les URL indiqués se terminent par une barre oblique, le client RDAP a juste à leur ajouter une requête formulée selon la syntaxe du RFC 7482. Ainsi, cherchant des informations sur 192.0.2.24, on ajoutera ip/192.0.2.24 à l'URL de base ce qui, avec le bootstrap service précédent, donnerait https://rir1.example.com/myrdap/ip/192.0.2.24.

Pour les adresses IP (section 5), les entrées sont des préfixes, comme dans le premier exemple montré plus haut et la correspondance se fait avec le préfixe le plus spécifique (comme pour le routage IP). Les préfixes IPv4 suivent la syntaxe du RFC 4632 et les IPv6 celle du RFC 4291. Voici un exemple IPv6 :

       "services": [
         [
           ["2001:200::/23", "2001:db8::/32"],
           [
             "https://rir2.example.com/myrdap/"
           ]
         ],
         [
           ["2600::/16", "2100:ffff::/32"],
           [
             "http://example.org/"
           ]
         ],
         [
           ["2001:200:1000::/36"],
           [
             "https://example.net/rdaprir2/",
             "http://example.net/rdaprir2/"
           ]
          ]
       ]

Si on cherche de l'information sur le préfixe 2001:200:1000::/48, il correspond à deux entrées dans le tableau des services (2001:200::/23 et 2001:200:1000::/36) mais la règle du préfixe le plus long (le plus spécifique) fait qu'on va utiliser 2001:200:1000::/36, et la requête finale sera donc https://example.net/rdaprir2/ip/2001:200:1000::/48. (Si elle échoue, on peut passer au deuxième URL du tableau, celui sans HTTPS.)

Pour les domaines (section 4), les entrées des services sont des noms de domaine :

...
       "services": [
         [
           ["net", "com", "org"],
           [
             "https://registry.example.com/myrdap/"
           ]
         ],
         [
           ["foobar.org", "mytld"],
           [
             "http://example.org/"
           ]
         ],
...

L'entrée sélectionnée est la plus longue (en nombre de composants du nom, pas en nombre de caractères) qui correspond. Dans l'exemple ci-dessus, si on cherche des informations sur foobar.org, on ira voir le serveur RDAP en http://example.org/, si on en cherche sur toto.org, on ira en https://registry.example.com/myrdap/.

Pour les numéros d'AS (section 5.3), on se sert d'intervalles de numéros :

"services": [
         [
           ["2045-2045"],
           [
             "https://rir3.example.com/myrdap/"
           ]
         ],
         [
           ["10000-12000", "300000-400000"],
           [
             "http://example.org/"
           ]
         ],
...

Les entités (section 6 de notre RFC) posent un problème particulier, elles ne se situent pas dans un espace arborescent, contrairement aux autres objets utilisable avec RDAP. (Rappel : les entités sont les contacts, les titulaires, les BE...) Il n'existe donc pas de bootstrap service pour les entités (ni, d'ailleurs, pour les serveurs de noms, cf. section 9). En pratique, si une requête RDAP renvoie une réponse incluant un handle pour une entité, il n'est pas idiot d'envoyer les requêtes d'information sur cette entité au même serveur RDAP.

Notez (section 7) que le tableau services ne sera pas forcément complet et que certains objets peuvent ne pas s'y trouver. Par exemple, dans un tableau pour les TLD, les registres n'ayant pas encore de serveur RDAP ne seront logiquement pas cités. On peut toujours tenter un autre serveur, en espérant qu'il utilisera les redirections HTTP. Par exemple, ici, on demande au serveur RDAP de l'APNIC pour une adresse RIPE. On est bien redirigé avec un code 301 (RFC 7231, section 6.4.2) :


%  curl -v http://rdap.apnic.net/ip/2001:67c:288::2
...
> GET /ip/2001:67c:288::2 HTTP/1.1
> User-Agent: curl/7.38.0
> Host: rdap.apnic.net
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Date: Wed, 01 Apr 2015 13:07:00 GMT
< Location: http://rdap.db.ripe.net/ip/2001:67c:288::2
< Content-Type: application/rdap+json
...

La section 8 couvre quelques détails liés au déploiement de ce service, qui a pris du temps et n'a été effectif que le 25 mars 2015, en pleine réunion IETF à Dallas. C'est que le Bootstrap Service est différent des autres registres IANA. Ces autres registres ne sont consultés que rarement (par exemple, lors de l'écriture d'un logiciel) et jamais en temps réel. Si le serveur HTTP de l'IANA plante, ce n'est donc pas trop grave. Au contraire, le Bootstrap Service doit marcher en permanence, car un client RDAP en a besoin. Pour limiter la pression sur les serveurs de l'IANA, notre RFC recommande que les clients RDAP ne consultent pas ce service à chaque requête RDAP, mais qu'au contraire ils mémorisent le JSON récupéré, en utilisant le champ Expires: de HTTP (RFC 7234) pour déterminer combien de temps doit durer cette mémorisation. Néanmoins, l'IANA a dû ajuster ses serveurs HTTP et louer les services d'un CDN pour assurer ce rôle relativement nouveau.

Le client RDAP doit d'autre part être conscient que le registre n'est pas mis à jour instantanément. Par exemple, si un nouveau TLD est ajouté par le gouvernement états-unien, via Verisign, TLD dont le registre a un serveur RDAP, cette information ne sera pas disponible immédiatement pour tous les clients RDAP.

Comme son ancêtre whois, RDAP soulève plein de questions de sécurité intéressantes, détaillées plus précisement dans le RFC 7481.

La section 12 de notre RFC détaille les processus IANA à l'œuvre. En effet, et c'est une autre différence avec les registres IANA habituels, il n'y a pas de mise à jour explicite des registres du bootstrap service, ils sont mis à jour implicitement comme effet de bord des allocations et modifications d'allocation dans les registres d'adresses IPv4, adresses IPv6, numéros d'AS et domaines. Il faudra juste modifier les procédures de gestion de ces registres existants, pour permettre d'indiquer le serveur RDAP (une information qui n'est pas récoltée aujourd'hui, ce qui explique pourquoi le bootstrap service est vide). Ainsi, le formulaire de gestion d'un TLD par son responsable devra être modifié pour ajouter un champ "serveur RDAP" comme il y a aujourd'hui un champ "serveur Whois".

Aujourd'hui, les fichiers de ce service sont :

  • http://data.iana.org/rdap/dns.json
  • http://data.iana.org/rdap/ipv4.json
  • http://data.iana.org/rdap/ipv6.json
  • http://data.iana.org/rdap/asn.json

Voici, par exemple, celui d'IPv6 (encore vide) :


% curl -v http://data.iana.org/rdap/ipv6.json
...
> GET /rdap/ipv6.json HTTP/1.1
> User-Agent: curl/7.38.0
> Host: data.iana.org
> Accept: */*
> 
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Type: text/plain; charset=UTF-8
< Date: Wed, 01 Apr 2015 13:47:28 GMT
< Etag: "63ea7-96-511be51c6e140"
< Last-Modified: Fri, 20 Mar 2015 20:39:57 GMT
< Server: ECAcc (ewr/14C3)
< X-Cache: HIT
< Content-Length: 150
< 
{
  "description": "RDAP bootstrap file for IPv6 address allocations",
  "publication": "2015-03-20T20:39:57Z",
  "services": [],
  "version": "1.0"
}

Question lecture, John Levine, dans son article sur RDAP, parlait de ce problème de bootstrap : « The biggest delay in getting RDAP done turned out to be the bootstrap, figuring out where the server is for each top level domain, IP range, or ASN range. A lot of proposals that seemed reasonable, like a fixed name (http://rdap.domain) or a DNS approach like SRV records turned out either to have administrative issues, or to be hard to implement (you can't do SRV lookups from Javascript.) There were also issues that were arguably technical or political (depending which side you're on) about specifying the URL syntax of the queries. » Notez qu'on parle parfois de bootstrap service pour désigner, non pas un ensemble de fichiers dirigeant vers le bon serveur RDAP, comme décrit dans ce RFC, mais un serveur qui ne fait que des redirections, comme celui (expérimental) en rdap.org qui, ici, redirige à juste titre vers Afilias :

  
% curl -v http://rdap.org/domain/rmll.info
...
> GET /domain/rmll.info HTTP/1.1
> User-Agent: curl/7.35.0
> Host: rdap.org
> Accept: */*
> 
< HTTP/1.0 301 Moved Permanently
< Date: Thu, 26 Mar 2015 13:57:20 GMT
< Server: Apache
< X-Powered-By: PHP/5.3.3
< Content-Language: en
< Status: 301
< Location: http://rdg.afilias.info/.well-known/rdap/domain/rmll.info
< Content-Length: 0
< Content-Type: application/rdap+json; charset=UTF-8

D'ailleurs, si vous cherchez une mise en œuvre d'un tel redirecteur, il y a rdapbootstrap (en Java).


Téléchargez le RFC 7484


L'article seul

RFC 7493: The I-JSON Message Format

Date de publication du RFC : Mars 2015
Auteur(s) du RFC : T. Bray (Textuality Services)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF json
Première rédaction de cet article le 1 avril 2015


Le format JSON, normalisé dans le RFC 7159, est aujourd'hui très répandu dans l'Internet et largement utilisé. Il a pourtant des faiblesses, notamment une définition un peu floue sur certains points, qui laisse planer un doute sur l'interopérabilité : si j'envoie dans le fichier un objet JSON où deux membres portent le même nom, le destinataire pourra-t-il le traiter ? Ce nouveau RFC résoud le problème en créant un profil, une restriction de JSON, nommée I-JSON, qui n'a pas ces flous et garantit donc normalement l'interopérabilité.

On peut penser qu'il aurait mieux valu préciser la norme JSON (aujourd'hui dans le RFC 7159) pour éliminer les ambiguités. Mais cela n'est pas possible sans casser la compatibilité. Si, par exemple, on interdisait dans la norme les objets dont deux membres ont le même nom, on rendrait illégaux des textes JSON existants, qui profitaient du flou de la norme. Cela a été jugé inacceptable, d'où ce choix d'un profil de JSON. Ceux qui veulent continuer à profiter du vague de la norme restent au JSON traditionnel, ceux qui veulent le maximum d'interopérabilité envoient désormais uniquement du I-JSON (ce qui veut dire « Internet JSON » et qui, curieusement, n'a pas de type MIME à lui, on continue à utiliser application/json). Ne pas casser l'existant était d'autant plus nécessaire que bien des analyseurs JSON mettent directement en correspondance les objets JSON avec des structures de données équivalentes dans leur langage de programmation, et qu'il ne fallait donc pas leur imposer une vérification préalable.

Donc, définition du format (section 2). Un texte I-JSON est un texte JSON, puisque I-JSON est un profil, un sous-ensemble de JSON. Il est forcément encodé en UTF-8 et ne doit pas utiliser les surrogates (seizets d'indirection) d'Unicode, ni des points de code qui sont des non-caractères.

Il y a deux grands problèmes d'interopérabilité avec JSON : la représentation des nombres (voir la section 6 du RFC 7159), et les noms de membres dupliqués dans les objets (cf. la section 4 du RFC 7159). La section 2.2 traite les nombres : un texte I-JSON ne devrait pas (sauf raison vitale) utiliser des nombres flottants qui ne sont pas représentables en IEEE 754-2008 binary64, soit en raison de leur taille (1E400...), soit à cause de leur précision (3.141592653589793238462643383279). Pour les entiers, il ne faut pas espérer que les nombres en dehors de l'intervalle [ -(2**53)+1 , (2**53)-1 ] soient acceptés.

Pour les noms de membres, la section 2.3 est claire : les noms dupliqués sont interdits. Donc, cet objet est du JSON légal, quoique dangereux, alors qu'il n'est pas du I-JSON, en raison du Title dupliqué :

"Image": {
            "Width":  800,
            "Height": 600,
            "Title": "View from 15th Floor",
            "Title": "Nice view"
}

D'autre part, I-JSON dit clairement que l'ordre des membres d'un objet ne compte pas. Ces deux objets sont identiques :

"Image": {
            "Width":  800,
            "Height": 600}

"Image": {
            "Height": 600, "Width":  800}

La section 3 de notre RFC précise bien qu'une mise en œuvre de I-JSON est tout à fait autorisée à rejeter ou ignorer un texte JSON qui n'est pas du bel I-JSON bien propre. Les protocoles Internet qui utilisent I-JSON sont invités à prévoir un moyen de signaler ce genre d'erreurs à l'envoyeur.

La section 4 du RFC couvre quelques choix supplémentaires. D'abord, comme dans l'ancien RFC 4627, et de manière différente de ce que permet le RFC 7159, un texte I-JSON doit avoir un objet ou un tableau au niveau supérieur. Ce texte est du JSON valable (depuis le RFC 7159) mais pas du I-JSON :

"Ma belle chaîne n'est pas acceptée car elle n'est pas objet ou tableau"

Il est recommandé que les protocoles qui utilisent I-JSON précisent que le type de plus haut niveau d'un texte soit un objet et que les membres inconnus de cet objet soient ignorés. Il existe en effet deux politiques dans les protocoles pour traiter les éléments inconnus : Must-Ignore et Must-Understand. La première indique que le receveur d'un message doit en ignorer les membres qu'il ne connait pas et continuer comme s'ils étaient absents. La deuxième indique qu'il faut connaitre tous les membres présents, et donc rejeter un message comportant des membres inconnus. La politique Must-Ignore permet l'extensibilité du protocole : une nouvelle version permet d'ajouter des membres à un objet, sans craindre que les anciens récepteurs ne plantent.

I-JSON ajoute aussi des contraintes aux types de données de base. Ainsi, il impose que les dates et heures soient au format du RFC 3339, avec en outre uniquement des lettres en majuscules et des secondes indiquées explicitement :

"creation": "2015-03-23T09:13:00Z"

Et une dernière contrainte sur les données, le binaire devra être encodé en base64url (section 5 du RFC 4648). Ce point fut l'un des plus chaudement disputés dans le groupe de travail.

Je n'ai pas trouvé d'outil qui testerait qu'un texte JSON est conforme à cette nouvelle norme I-JSON. Si quelqu'un connait...

I-JSON est expliqué par l'auteur du RFC sur son blog.


Téléchargez le RFC 7493


L'article seul

Faut-il refaire l'Internet en partant de zéro ?

Première rédaction de cet article le 30 mars 2015
Dernière mise à jour le 7 avril 2015


Hier, aux Journées du Logiciel Libre à Lyon, j'ai fait un exposé sur la question de la « refondation » de l'Internet.

Les supports de l'exposé :


L'article seul

RFC 7478: Web Real-Time Communication Use-cases and Requirements

Date de publication du RFC : Mars 2015
Auteur(s) du RFC : C. Holmberg, S. Hakansson, G. Eriksson (Ericsson)
Pour information
Réalisé dans le cadre du groupe de travail IETF rtcweb
Première rédaction de cet article le 30 mars 2015


Le système WebRTC permet une communication interactive et multimédia entre deux applications tournant dans un navigateur Web (d'où le nom de WebRTC). La vision est qu'Alice et Bob lanceront leur navigateur, iront sur une page qui chargera le code du logiciel (typiquement du JavaScript) et qu'ils communiqueront ensuite. Contrairement à Skype, WebRTC ne nécessitera pas l'installation d'un logiciel, et, surtout, il s'agira d'un protocole ouvert. Ce RFC, le premier du groupe de travail rtcweb, décrit certains scénarios d'usage de WebRTC, pour aider à comprendre quel rôle il joue exactement. Il ne prétend pas être un cahier des charges pour WebRTC et, bien que publié tardivement, il représente plutôt l'état d'esprit au début du projet.

WebRTC peut permettre la communication avec des systèmes extérieurs et au moins un des scénarios décrits envisage une communication avec un téléphone SIP. Les demandes mises par ce document sur le (à cette époque) futur protocole WebRTC sont marquées Fn (où n est un entier) mais, on l'a vu, ce document ne prétend pas être un cahier des charges et WebRTC ne suivra pas forcément rigoureusement ces demandes. Les demandes marquées An concernent uniquement l'API de WebRTC (le protocole est développé par l'IETF, l'API par le W3C, oui, c'est un peu compliqué). L'annexe A contient ces exigences concernant l'API mais il faut voir le W3C pour avoir l'information fiable.

Les clients WebRTC peuvent être connectés en IPv4, en IPv6, les deux, avoir des capacités réseau très différentes, être sur des réseaux dont la capacité effective varie (liens radio, liens congestionnés), être derrière des pare-feux fascistes, et, bien sûr, être coincés derrière des NAT, des NAT de toutes les sortes (RFC 4787).

Attaquons maintenant les scénarios en commençant par le plus simple : ces chers Alice et Bob veulent discuter par vidéo. Ils ont le même opérateur WebRTC, sont informés en temps réel de la disponibilité de l'autre par une notification au navigateur, et, en cliquant sur le nom du correspondant, peuvent lui parler, l'écouter, le voir et se montrer. On a bien sûr les fonctions classiques, une petite vignette avec un retour de sa propre caméra, la capacité de couper le son pour crier une remarque à son conjoint sans que le correspondant l'entende, etc. Chaque partie peut raccrocher quand elle le veut. Évidemment, Bob et Alice ont des navigateurs de modèles différents, tournant sur des systèmes d'exploitation différents. Bien sûr, on veut de la sécurité, tout le trafic audio et vidéo doit évidemment être chiffré, authentifié et protégé contre toute modification.

De ce premier scénario d'usage, le cas le plus simple et le plus courant, on en déduit les exigences de base. Je ne vais pas toutes les citer mais en voici un échantillon, avec leur identificateur Fn :

  • F1 : le navigateur doit avoir accès au micro et à la caméra,
  • F2 : le navigateur doit pouvoir envoyer des données, même en présence de NAT,
  • Diverses exigences sur la qualité des flux multimédia (F3, réagir à la congestion, F6, détecter que le pair ne reçoit plus rien, F8, pouvoir synchroniser audio et vidéo),
  • F11 : Protection contre les écoutes et autres « interceptions de sécurité » (RFC 2804 et RFC 7258),
  • F13 : authentification et intégrité,
  • F14 : vie privée, il doit exister un mode où Alice communique avec Bob sans lui révéler son adresse IP (possibilité de passer par un serveur pour se protéger).

Les autres exigences apparaissent au fur et à mesure des autres scénarios, qui présentent des cas de plus en plus complexes. Par exemple, Alice ou Bob est derrière un réseau fasciste ou mal configuré qui bloque complètement UDP. On en déduit l'exigence F18, pouvoir passer même quand UDP est bloqué. Variante : un réseau encore plus fasciste ou mal conçu qui n'autorise que HTTP, et via un relais. L'exigence F21 traite cas cas.

Réussir à faire passer une communication malgré les middleboxes, les pare-feux et le NAT est le grand défi des applications réseau modernes. Les solutions nécessitent en général d'utiliser STUN (RFC 5389) et TURN (RFC 5766, le tout avec ICE (RFC 5245). L'exigence F19 impose de pouvoir utiliser ces services, y compris dans le cas où il y a plusieurs serveurs STUN et TURN disponibles. F20 impose de permettre l'utilisation de serveurs STUN et TURN qui ne sont pas ceux du fournisseur WebRTC (par exemple, au sein d'une organisation qui a son propre serveur STUN).

Lorsqu'on utilise des équipements mobiles, le problème peut se compliquer par un changement de réseau en cours de communication, menant presque toujours à un changement d'adresse IP (un smartphone qui était connecté en 4G et qui rentre au bercail où il bascule vers la WiFi). F17 demande que WebRTC puisse continuer à fonctionner dans ce cas, pour éviter le « Allo, Alice, je vais passer en WiFi, je te rappelle ».

Satisfaits de ces services, Alice et Bob multiplient leur exigence. Voilà tout à coup qu'apparait dans le RFC leur désir de partager l'écran, pendant la communication, avec un tiers, que ce dernier puisse suivre ce qu'il se passe (exigence F36).

Laissons maintenant Alice et Bob tranquilles, ils ont peut-être enfin réussi à communiquer. Le RFC passe ensuite à des scénarios plus collectifs, autour du hockey. Un chercheur de talents est à un match avec son téléphone portable (qui a deux caméras, une devant et une derrière), il filme les joueurs qui lui semblent les plus prometteurs et il veut en discuter en télé-conférence avec le patron du club, à distance, et qui regarde le match transmis par le chercheur de talents. WebRTC doit donc pouvoir gérer de nombreux flux multimédias (exigence F25).

Ce genre de demandes s'étend à tout système de conférence à plusieurs, loin du cas simple des seuls Alice et Bob. WebRTC doit jongler avec les flux et de nombreux pairs qui veulent les recevoir (exigences F23 à F29).

C'est bien joli de communiquer avec les autres utilisateurs de WebRTC mais, souvent, on voudrait communiquer avec des gens qui n'ont pas WebRTC, en passant par une passerelle vers leur système, par exemple vers la téléphonie classique. Un premier exemple est celui d'un opérateur qui permet à ses abonnés de passer un appel téléphonique depuis un navigateur Web. L'utilisateur se connecte au site de l'opérateur, s'authentifie, puis appelle qui il veut, comme s'il utilisait un téléphone traditionnel. WebRTC doit donc gérer les codecs traditionnels de la téléphonie (exigence F31).

Si le service qu'on appelle a des commandes comme « pour signaler un problème, appuyez sur la touche 1 », il faut évidemment un moyen de le faire (exigence F32).

Voilà, je n'ai pas tout indiqué mais cela vous donne déjà une bonne idée de ce que WebRTC doit permettre. La section 3 de notre RFC résume toutes ces exigences de manière synthétique, si vous ne voulez pas lire tout le RFC.

Notez que, comme avec tout système qui apporte de nouvelles possibilités, il y a aussi de nouveaux risques. La section 4 liste les risques connus de WebRTC. Notamment, il faut obtenir le consentement éclairé de l'utilisateur avant de permettre l'utilisation du micro et de la caméra (songez aux facilités d'espionnage qu'on aurait si un script WebRTC sur un site Web pouvait allumer la caméra...) et il faut prévenir clairement l'utilisateur que micro et caméras sont allumés.


Téléchargez le RFC 7478


L'article seul

Articles des différentes années : 2015  2014  2013  2012  2011  2010  2009  Précédentes années

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