Les RFC (Request For Comments) sont les documents de référence de l'Internet. Produits par l'IETF pour la plupart, ils spécifient des normes, documentent des expériences, exposent des projets...
Leur gratuité et leur libre distribution ont joué un grand rôle dans le succès de l'Internet, notamment par rapport aux protocoles OSI de l'ISO organisation très fermée et dont les normes coûtent cher.
Je ne tente pas ici de traduire les RFC en français (un projet pour cela existe mais je n'y participe pas, considérant que c'est une mauvaise idée), mais simplement, grâce à une courte introduction en français, de donner envie de lire ces excellents documents.
Le public visé n'est pas le gourou mais l'honnête ingénieur ou l'étudiant.
Date de publication du RFC : Février 2012
Auteur(s) du RFC : F. Gont (SI6 Networks / UTN-FRH), S. Bellovin (Columbia University)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF tcpm
Première rédaction de cet article le 2 Février 2012
Ce court RFC spécifie les précautions que doit prendre une mise en œuvre de TCP pour éviter qu'un attaquant ne puisse deviner le numéro de séquence initial. Rien de nouveau, les précautions en question étant programmées dans TCP depuis de nombreuses années, juste un rappel et une mise à jour du précédent RFC sur ce sujet, le RFC 1948.
Pour comprendre le problème de sécurité des numéros de séquence, et les solutions présentées dans ce RFC, il vaut mieux revenir à l'attaque qui exploitait les anciennes vulnérabilités. C'est fait dans l'annexe A du RFC, que je reprends ici.
Le but de l'attaquant est de s'en prendre à un serveur qui autorise par adresse IP. À l'époque du RFC 1948, cela concernait rsh mais, de nos jours, SSH a complètement remplacé cet archaïque protocole. Aujourd'hui, ce serait plutôt un serveur DNS qui authentifie le transfert de zones ainsi, ou bien un serveur SMTP qui autorise seulement certaines adresses IP à passer par lui - même s'il ferait mieux de se servir du RFC 4954, ou encore un serveur HTTP qui ne permet l'invocation de certaines actions qu'aux utilisateurs de certaines adresses. En deux mots, dès que l'autorisation se fait par adresse IP uniquement, il faut s'assurer que vous utilisez un TCP qui mette en œuvre les recommandations de ce RFC 6528.
On le sait, il est trivial pour un attaquant d'envoyer des paquets avec une fausse adresse IP source (le RFC 2827, censé l'empêcher, n'étant quasiment pas déployé). Mais, dans ce cas, l'attaquant ne reçoit pas les réponses. Or, si on veut maintenir une connexion TCP avec sa victime, il faut lui envoyer des paquets avec les données qu'elle attend, notamment le numéro de port et les numéros de séquence. Sinon, la victime va jeter ces paquets TCP qui lui sembleront anormaux. Pour les numéros de port, le RFC 6056 s'en occupe. Pour les numéros de séquence, voyons ce qui se passe. Tout paquet TCP doit inclure ces numéros, un pour chaque sens de la conversation (RFC 793, section 3.3). Ce numéro identifie l'octet suivant à envoyer. Une ouverture de connexion TCP normale ressemble donc, pour le cas où Alice veut parler à Bob, à :
SYN est mis, avec un numéro de séquence initial
ISNa - ISN = Initial Sequence Number.)Voici d'ailleurs, vu par tcpdump, un exemple d'ouverture de connexion (vers le dépôt git de Linux) :
% tcpdump -S -n -r tmp/3wayhandshake.pcap reading from file tmp/3wayhandshake.pcap, link-type EN10MB (Ethernet) 09:47:53.086347 IP 192.134.6.69.39859 > 149.20.4.72.9418: Flags [S], seq 3366079112, ... 09:47:53.242880 IP 149.20.4.72.9418 > 192.134.6.69.39859: Flags [S.], seq 3075029842, ack 3366079113, ... 09:47:53.242910 IP 192.134.6.69.39859 > 149.20.4.72.9418: Flags [.], ack 3075029843, ...
Le S entre crochets indique un paquet
SYN. L'option -S est là pour indiquer à tcpdump
d'afficher les numéros de séquence absolus, tels qu'ils sont envoyés
sur le câble (par défaut, il montre des numéros relatifs, sauf pour
les paquets SYN). On note aussi que tcpdump
n'affiche pas le premier numéro de séquence s'il n'y a pas de données,
et n'affiche pas le second si le bit ACK n'est
pas mis.
Le deuxième paquet n'a été accepté par Alice que parce qu'il contenait un numéro de séquence attendu. Mëme chose pour le troisième. Un attaquant qui procéderait au hasard, envoyant des numéros de séquence quelconques, n'aurait aucune chance que ses paquets soient acceptés. Imaginons maintenant que l'attaquant puisse connaître les numéros de séquence utilisés. Bob fait confiance à Alice mais Mallory, l'attaquant, va se faire passer pour Alice. Mallory n'est pas situé sur le chemin entre Alice et Bob (sinon, cela serait trivial, il lui suffirait d'écouter le réseau) :
SYN est mis, avec un numéro de séquence initial
ISNa.)Et comment Mallory a-t-il trouvé le numéro de séquence que va utiliser Bob ? Le RFC originel, le RFC 793 ne mettait pas du tout en garde contre cette attaque, inconnue à l'époque (1981). Il ne se préoccupait que du risque de collision accidentel entre deux connexions et suggérait donc un algorithme où l'ISN était simplement incrémenté toutes les quatre micro-secondes, ce qui le rendait très prévisible (l'attaquant ouvre une connexion, regarde l'ISN, et sait quel va être celui de la prochaine connexion). Le premier article décrivant une faiblesse dans les mises en œuvre de TCP, faiblesse permettant de trouver le prochain numéro de séquence, a été publié en 1985 (Morris, R., A Weakness in the 4.2BSD UNIX TCP/IP Software, CSTR 117, AT&T Bell Laboratories). À l'époque, elle était suffisante pour établir des sessions rsh avec la victime.
À noter qu'Alice, elle, reçoit l'accusé de réception de Bob, auquel
elle ne s'attend pas. Elle va donc émettre un paquet
RST qui va fermer la connexion. Diverses
techniques permettent à l'attaquant de réussir quand même (par exemple
en montant au même moment une attaque DoS
contre Alice pour ralentir ses paquets, donnant à l'attaque le temps de réussir).
C'est pour répondre à cette attaque que le RFC 1948 avait été écrit en 1996,
documentant la pratique qui était devenue courante, de générer des
numéros de séquence, sinon aléatoires, en tout cas
imprévisibles. (Un article plus récent et plus détaillé sur la
vulnérabilité initiale était celui de Shimomura, T., Technical
details of the attack described by Markoff in NYT,
envoyé sur Usenet, en
comp.security.misc, Message-ID:
<3g5gkl$5j1@ariel.sdsc.edu>, en 1995.) Notre RFC 6528 met à jour ce RFC 1948. La section 2 expose les principes d'un bon algorithme de
génération d'ISN (Initial Sequence Number), la
section 3 décrit l'algorithme proposé. Commençons par celui-ci. Il
tient en une formule :
ISN = M + F(localip, localport, remoteip, remoteport)
où M est un compteur qui s'incrémente toutes les quatre micro-secondes, et F une fonction pseudo-aléatoire, qui va prendre comme paramètre le tuple qui identifie une connexion TCP (adresse IP locale, port local, adresse IP distante, port distant). F ne doit pas être prévisible de l'extérieur et le RFC suggère une fonction de hachage cryptographique, comme MD5 (RFC 1321), hachant le tuple ci-dessus après l'avoir concaténé à une clé secrète. La sécurité reposera sur cette clé, l'algorithme de hachage utilisé étant sans doute connu. On peut envisager qu'elle soit générée aléatoirement (vraiment aléatoirement, en suivant le RFC 4086), ou configurée à la main (en espérant que l'ingénieur système ne choisira pas « toto »). Il est recommandé de la changer de temps en temps.
Notez que, bien que MD5 ait de nombreuses faiblesses cryptographiques pour d'autres utilisations, il est parfaitement sûr pour celle-ci (et bien plus rapide que ses concurrents).
La section 2, elle, définissait le cahier des charges :
qu'attend t-on d'un algorithme de sélection de l'ISN ? D'abord, il
n'est pas forcé d'empêcher des vieux paquets IP
qui traînent dans le réseau d'être acceptés. Pour cela, il vaut mieux
compter sur l'état TIME_WAIT de TCP (après la fin
d'une connexion, garder l'état pendant deux MSL - Maximum
Segment Life, cf. RFC 1323). Ça ne
marche pas forcément si les connexions sont créées à un rythme très
rapide mais c'est la seule solution sûre (mais consommant de la mémoire). On peut lire à ce sujet deux
articles sur les générateurs d'ISN, leurs avantages et inconvénients, « Strange Attractors and TCP/IP Sequence
Number Analysis » et « Strange Attractors and TCP/IP
Sequence Number Analysis - One Year Later ».
Compte-tenu de ces risques, une génération aléatoire de l'ISN suffirait. Mais elle aurait l'inconvénient de de ne pas permettre de deviner si un nouveau paquet TCP appartient à une ancienne connexion ou pas. L'idée de base de ce RFC est donc de créer un espace de numéros de séquence par identificateur TCP (le tuple {adresse IP locale, port local, adresse IP distante, port distant}) et, dans chacun de ces espaces, de suivre les règles d'incrémentation progressive de l'ISN du RFC 793.
Pour ceux qui veulent pousser l'analyse de sécurité, la section 4
prend de la hauteur et rappelle quelques points importants. D'abord
que la vraie solution serait évidemment de protéger les paquets IP par
de la cryptographie comme le fait
IPsec, ou au niveau TCP comme le fait le TCP-AO
du RFC 5925 (TLS ou
SSH ne suffisent pas, ils n'empêchent pas une
attaque par déni de service avec des faux
paquets TCP RST).
La section 4 fait aussi remarquer que rien n'est parfait et que l'algorithme proposé dans notre RFC a des effets de bord, comme de permettre le comptage du nombre de machines qui se trouvent derrière un routeur NAT, ce qui peut être une information qu'on souhaiterait garder privée.
Et, surtout, elle rappelle que toutes les précautions de notre RFC 6528 ne s'appliquent que si l'attaquant est en dehors du chemin entre les deux pairs TCP. S'il est sur le chemin et qu'il peut écouter le réseau, elles ne servent à rien.
Quels sont les changements depuis le RFC 1948 ? Il n'y a pas de changement sur le fond (l'algorithme est le même donc un TCP compatible avec le RFC 1948 l'est également avec le RFC 6528). Les changements sont résumés dans l'annexe B. Le statut du RFC a changé (désormais sur le chemin des normes), les exemples maintenant dépassés par l'évolution des techniques ont été mis à jour ou supprimés,
On l'a dit, les précautions décrites dans ce RFC sont présentes
dans les implémentations depuis longtemps. Pour un exemple de mise en œuvre de cet algorithme, on peut
regarder le code source de NetBSD. Il se trouve
en sys/netinet/tcp_subr.c. Son comportement est
contrôlé par la variable sysctl
iss_hash. Mise à 1, elle indique qu'il faut
utiliser l'algorithme ci-dessus. À 0, qu'il faut utiliser une valeur
aléatoire. Prenons le premier cas, celui de notre RFC. On voit la
génération du secret (un nombre aléatoire, issu de
cprng_strong()) puis le hachage
MD5 de l'identifiant de connexion avec le secret :
/*
* If we haven't been here before, initialize our cryptographic
* hash secret.
*/
if (tcp_iss_gotten_secret == false) {
cprng_strong(kern_cprng,
tcp_iss_secret, sizeof(tcp_iss_secret), 0);
tcp_iss_gotten_secret = true;
}
/*
* Compute the base value of the ISS. It is a hash
* of (saddr, sport, daddr, dport, secret).
*/
MD5Init(&ctx);
MD5Update(&ctx, (u_char *) laddr, addrsz);
MD5Update(&ctx, (u_char *) &lport, sizeof(lport));
MD5Update(&ctx, (u_char *) faddr, addrsz);
MD5Update(&ctx, (u_char *) &fport, sizeof(fport));
MD5Update(&ctx, tcp_iss_secret, sizeof(tcp_iss_secret));
MD5Final(hash, &ctx);
memcpy(&tcp_iss, hash, sizeof(tcp_iss));
return (tcp_iss);
Pour Linux (remerciements au passage à @ackrst), il faut regarder le
net/core/secure_seq.c qui contient à peu près la
même chose (la variable net_secret est
initialisée au tout début de ce fichier) :
__u32 secure_tcp_sequence_number(__be32 saddr, __be32 daddr,
__be16 sport, __be16 dport)
{
u32 hash[MD5_DIGEST_WORDS];
hash[0] = (__force u32)saddr;
hash[1] = (__force u32)daddr;
hash[2] = ((__force u16)sport << 16) + (__force u16)dport;
hash[3] = net_secret[15];
md5_transform(hash, net_secret);
Date de publication du RFC : Janvier 2012
Auteur(s) du RFC : M. Kucherawy (Cloudmark)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF appsawg
Première rédaction de cet article le 17 Janvier 2012
Un court RFC pour un format simple : le type
MIME multipart/report
permet d'envoyer des rapports structurés au sujet d'un message. Ce RFC est la
dernière version de la norme sur
multipart/report, marquée par un léger allègement
des règles d'utilisation.
Pas de grands changements, sinon. L'idée de base de
multipart/report est de pouvoir faire des
messages à propos des messages. Par exemple, un avis de non-remise
(RFC 3461) est un message disant qu'un message
n'a pu être remis, et intégrant le message originel. Un rapport
ARF (RFC 5965) est un message disant qu'un message est
abusif (spam, par exemple) et intégrant
également le message originel. D'où l'idée d'avoir un type commun pour
tous ces « messages sur les messages », et c'est
multipart/report, normalisé dans notre RFC 6522, qui succède au RFC 3462 (qui
succédait lui-même au RFC 1892). Ce type
multipart/report est très largement utilisé
depuis longtemps, et par de nombreux logiciels.
La présentation détaillée du type « rapport » figure en section 3. Voici d'abord un exemple d'un tel message, ici pour indiquer une non-délivrance, généré par un MTA Postfix :
Date: Wed, 11 Jan 2012 13:45:44 +0000 (UTC)
From: MAILER-DAEMON@bortzmeyer.org (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: bortzmeyer@nic.fr
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="154CD3AC2C.1326289544/mail.bortzmeyer.org"
Content-Transfer-Encoding: 8bit
This is a MIME-encapsulated message.
--154CD3AC2C.1326289544/mail.bortzmeyer.org
Content-Description: Notification
Content-Type: text/plain; charset=us-ascii
[La première partie du rapport, lisible par un humain.]
This is the mail system at host mail.bortzmeyer.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
--154CD3AC2C.1326289544/mail.bortzmeyer.org
Content-Description: Delivery report
Content-Type: message/delivery-status
[La deuxième partie du rapport, conçue pour être analysée par des
programmes.]
Reporting-MTA: dns; mail.bortzmeyer.org
X-Postfix-Queue-ID: 154CD3AC2C
X-Postfix-Sender: rfc822; bortzmeyer@nic.fr
Arrival-Date: Wed, 11 Jan 2012 12:24:50 +0000 (UTC)
Final-Recipient: rfc822; nothere@nowhere.example
Action: failed
Status: 5.4.4
Diagnostic-Code: X-Postfix; Host or domain name not found. Name service error
for name=nowhere.example type=AAAA: Host not found
--154CD3AC2C.1326289544/mail.bortzmeyer.org
Content-Description: Undelivered Message
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit
[Puis le message originel, dans la troisième partie du rapport.]
Notez le paramètre report-type, qui a ici la
valeur delivery-status. (Cela serait
feedback-report pour du ARF.)
Notez surtout le découpage en trois parties (la dernière est optionnelle) :
message/delivery-status
du RFC 3464).Si on trouve le message originel trop gros, la troisième partie
peut se composer uniquement des en-têtes du message. Elle aura alors
le type message/rfc822-headers (section 4 de
notre RFC).
Naturellement, les messages multipart/report
ne sont pas plus authentifiés que les autres messages : il faut donc
éviter d'agir automatiquement lors de leur réception (section 7).
Le seul changement de fond depuis le RFC 3462
concerne une ancienne restriction :
multipart/report ne pouvait apparaître qu'au plus
haut niveau du message (rappelez-vous que MIME
est récursif, un message MIME peut contenir d'autres messages
MIME). Cela interdisait, par exemple, de faire un
multipart/report au sujet d'un
multipart/report. Il semble bien que personne ne
mettait en œuvre cette restriction et ce nouveau RFC 6522 l'a donc supprimé. (Voir section 1.)
Date de publication du RFC : Février 2012
Auteur(s) du RFC : G. Lebovitz, M. Bhatia (Alcatel-Lucent)
Pour information
Réalisé dans le cadre du groupe de travail IETF karp
Première rédaction de cet article le 2 Février 2012
Dans l'ensemble du travail engagé pour améliorer la sécurité du routage sur l'Internet, un sous-problème important est celui de la gestion des clés. En cryptographie, c'est souvent par une faiblesse dans cette gestion que les systèmes de sécurité sont compromis. Le groupe de travail KARP de l'IETF est occupé à améliorer les protocoles de gestion de clés et son premier RFC, ce RFC 6518, expose les propriétés attendues des futurs protocoles de gestion des clés des routeurs.
Prenons par exemple N routeurs OSPF qui veulent s'authentifier les uns les autres. La technique du RFC 2328 est d'avoir un secret partagé par tous les routeurs du même réseau local. Les messages OSPF sont concaténés avec ce secret, le résultat de la concaténation est ensuite condensé cryptographiquement, ce qui permettra au destinataire de s'assurer que l'émetteur connaissait bien le secret. Ce secret partagé est une clé cryptographique. Qui va la générer ? Comment la distribuer de façon sûre ? Comment la changer facilement et rapidement si le secret est compromis (ou, tout simplement, si un employé quitte l'entreprise) ? Ce genre de questions est la problématique de gestion de clés. Dans le cas d'OSPF, actuellement, la quasi-totalité des opérateurs de routeurs fait cela à la main (on se logue sur chaque routeur et on change le secret...) ou, à la rigueur, via un protocole général de configuration des routeurs. Peut-on faire mieux ? C'est en tout cas ce que va essayer de faire le groupe KARP.
C'est que les mécanismes actuels ne sont pas satisfaisants. Comme le rappelle la section 1 du RFC, lors d'un colloque en 2006 (cf. RFC 4948), les participants avaient dénoncé la vulnérabilité des routeurs aux tentatives de prise de contrôle et appelé à durcir leur sécurité. Quatre axes d'amélioration avaient été identifiés, améliorer la gestion des routeurs (groupe de travail OPSEC), améliorer les IRR, valider les annonces de route (groupe de travail SIDR), et enfin sécuriser les communications entre routeurs (groupe de travail KARP), ce qui fait l'objet de ce RFC. Les informations de routage sont échangées via un protocole et la protection de ce protocole se fait par la cryptographie. Qui dit cryptographie dit clés. Lorsqu'un routeur cherche une clé pour protéger un message, où demande-t-il ? Pour l'instant, il n'y a pas de mécanisme standard et KARP va essayer d'en développer un. Le plus courant aujourd'hui est la gestion manuelle des clés (l'opérateur configure les clés, les change à la main - lorsqu'il y pense, les communique via PGP, SCP voire sans aucune sécurité) mais le RFC estime que le futur est dans des mécanismes automatisés de gestion de clés, les KMP (pour Key Management Protocol). Un KMP, par exemple, change automatiquement les clés au bout d'une période pré-définie.
Compte-tenu de la variété des protocoles de routage, et du transport qu'ils utilisent, ce sera un mécanisme abstrait, pas un protocole précis (ce RFC 6518 n'a donc pas d'implémentation, il définit juste un cadre). Plus précisement, KARP va concevoir les interfaces abstraites entre le système de gestion de clés et le protocole de routage, puis, pour chaque protocole de routage, la correspondance entre cette interface abstraite et le protocole réel. Un projet ambitieux.
Maintenant, au boulot. Qu'est-ce qui est déjà fait dans ce RFC ? La
section 2 classe les protocoles de routage selon leurs
propriétés. L'idée est que les protocoles de routage qui partagent les
mêmes propriétés pourront, avec un peu de chance, utiliser les mêmes
mécanismes de gestion de clés. Première propriété, le type de
message. Certains protocoles sont de type un-vers-un : les messages
d'un routeur sont envoyés à un autre routeur. Les
UPDATE BGP (RFC 4271) fonctionnent
ainsi. Mais c'est aussi le cas de LDP (RFC 5036), de BFD (RFC 5880) et même d'OSPF (RFC 2328 dans certaines conditions (liens point
-à-point). D'autres protocoles fonctionnent en un-vers-plusieurs. Un
routeur diffuse sur le réseau local l'information de routage. C'est le
mode de fonctionnement le plus courant d'OSPF et c'est aussi celui de
RIP (RFC 2453). Enfin,
il y a les protocoles utilisés pour le multicast.
Deuxième propriété pour classer les protocoles de routage, proche de la précédente mais pas identique, le fait que la clé soit par groupe ou par pair. Dans BGP ou LDP, les clés sont individuelles, on a une clé différente par pair. Dans OSPF, la clé est la même pour tous les pairs d'un groupe.
La section 3 liste ensuite les points auxquels il faut penser lorsqu'on envisage un protocole de gestion de clés, un KMP. Le RFC 4107 fournit les bases générales et notre RFC l'adapte aux protocoles de routage. Entre autres, il faudra penser aux paramètres à passer avec le système de gestion de clés, comme la durée de vie pour les clés, l'identificateur de l'association de sécurité (SPI dans IPsec, KeyID dans TCP-AO, etc), l'algorithme de chiffrement et plusieurs autres.
Deux points sont soulignés par le RFC, les questions particulières des clés asymétriques (section 3.1) et le cycle de vie des clés (section 3.2). Les clés asymétriques sont souvent une bonne solution aux problèmes de sécurité : déjà utilisées par les routeurs (lorsqu'ils sont administrés via SSH), générées sur le routeur, elles peuvent n'avoir jamais besoin de le quitter (le RFC ne le dit pas clairement mais on peut même imaginer un petit HSM dans le routeur). Générées aléatoirement, elles ne peuvent pas être devinées comme le sont tant de mots de passe choisis par des humains. Il faut juste faire attention à leur taille, pour limiter les risques des attaques par force brute (RFC 3766). L'algorithme classique pour ces clés est RSA mais les algorithmes à base de courbes elliptiques commencent à se répandre, et permettent d'utiliser des clés plus courtes.
Quant au cycle de vie des clés, notre RFC insiste surtout sur la nécessité d'avoir des remplacements (rollover) de clés qui soient discrets : un remplacement de clés ne devrait pas casser les sessions de routage existantes, car cela imposerait des recalculs lourds des tables de routage, se propageant dans tout le réseau, et entraînant parfois des perturbations dans la connectivité. (Le RFC ne le cite pas mais la traditionnelle authentification MD5 de BGP - RFC 2385 - n'a pas cette propriété. Changer la clé impose de relancer les sessions BGP. C'est sans doute une des raisons pour lesquelles ces clés ne sont jamais changées, même quand tout le monde les connait.)
Pourquoi, d'ailleurs, faut-il changer les clés de temps en temps ? Il peut y avoir des raisons cryptographiques (progrès de la cryptanalyse, mais le RFC note qu'en pratique, ce sont les cas les plus rares, des problèmes moins prestigieux scientifiquement sont bien plus communs), des raisons liées au personnel (départ d'un ingénieur qui connaissait les clés), des raisons plus urgentes (compromission d'une machine où étaient stockées des clés). Même s'il n'y a aucune raison immédiate de changer, un remplacement des clés de temps en temps peut être nécessaire pour s'assurer qu'un attaquant qui a obtenu une clé et l'utilise discrètement (de manière purement passive), ne puisse pas profiter de son butin éternellement.
Lorsque les procédures de changement de clés sont manuelles, les changements peuvent être en eux-mêmes une source de vulnérabilité (l'erreur est humaine...).
Après ces préliminaires, la section 4 dessine le travail futur. Il y a deux chantiers génériques (indépendants du protocole de routage) importants, le premier étant un pré-requis du second :
Pour que les mécanismes nouveaux aient des chances de succès, ils doivent pouvoir être déployés sans ajouter de complexité par rapport à ce que font déjà les opérateurs (qui connaissent SSH, TCP-MD5, HTTPS et les certificats, etc). Le but n'est pas de faire un système qui empêche l'opérateur de faire une erreur (comme d'utiliser « foobar » comme mot de passe pour tous les systèmes) mais de faire un système qui soit utilisé dans le monde réel, et pour cela, la simplicité et la déployabilité sont des critères essentiels (mais très souvent oubliés par les experts en sécurité, qui se soucient d'avantage de faire des systèmes parfaits que des systèmes déployables, cf. section 6).
Avec une gestion manuelle des clés, on ne peut gérer de manière raisonnablement sûre que des petits réseaux. La deuxième étape sera donc de déployer le mécanisme de gestion automatique.
Le travail d'amélioration de chaque protocole de routage est décrit en section 4.2 sous forme d'une liste de tâches :
On l'a vu en section 2, KARP classe les protocoles de routage en catégories selon leurs propriétés. La section 5 examine les points qui sont spécifiques à chaque catégorie. BGP, LDP et quelques autres sont dans la catégorie « messages un-vers-un et clés par pair ». BGP fonctionne toujours sur TCP, LDP parfois sur TCP et parfois sur UDP. Pour le cas de TCP, une bonne partie du travail a déjà été faite dans le groupe TCPM, avec la technique d'authentification AO (RFC 5925) qui a les propriétés voulues pour la première phase du travail de KARP (agilité des algorithmes et changement de clé facile). Il ne reste donc que le cas de LDP sur UDP.
Pour la catégorie « un-vers-plusieurs avec clés par groupe », qui comprend OSPF, IS-IS et RIP, rien de générique n'est fait. Le problème est ici bien plus difficile, d'autant plus que ces protocoles n'utilisent pas en général de protocole de transport standard, et ne peuvent donc pas réutiliser un mécanisme fourni par la couche 4 (comme peut le faire BGP avec AO).
BFD est un cas à part et qui nécessitera sa propre équipe. Par exemple, il est beaucoup plus sensible aux délais que les autres. Pour lui, une milliseconde est très longue.
On l'a vu, ce RFC répète régulièrement qu'il est essentiel de prévoir un déploiement incrémental des nouveaux mécanismes de sécurité. Pas question d'ignorer l'existant. La section 6 insiste sur ce point. Contrairement à une attitude fréquente chez les experts en sécurité, qui est de chercher une solution parfaite, KARP va essayer de trouver des solutions qui puissent être déployées par étapes, sans casser le routage actuel, même si ces solutions ne sont pas les meilleures, question sécurité. Par exemple, les routeurs configurés avec les nouveaux mécanismes doivent pouvoir interagir sans ennuis avec les vieux routeurs non sécurisés.
Un des problèmes de sécurité les plus difficiles dans l'Internet est celui des attaques par déni de service (section 7). Ces attaques touchent aussi les routeurs et les protocoles de routage. Il ne faut donc pas que les nouvelles techniques conçues dans le cadre du groupe KARP aggravent le problème. Par exemple, les calculs cryptographiques peuvent être coûteux, surtout pour les ressources matérielles souvent limitées des routeurs, et les protocoles ne doivent donc pas permettre à un attaquant de faire faire au routeur une énorme quantité de ces calculs. Pour éviter cela, il faut permettre au routeur de faire des vérifications non-cryptographiques, donc bien plus légères, avant de se lancer dans les calculs compliqués. Par exemple, le RFC 5082 utilise le TTL du paquet entrant (quelque chose de trivial à vérifier) pour empêcher certaines attaques. Il est important, dans le cadre de KARP, de développer et de documenter de telles alternatives. D'autre part, le protocole doit être conçu de manière à ce que ce soit l'initiateur de la connexion (un attaquant potentiel) qui ait le plus de travail cryptographique à faire, et qui doive maintenir un état pendant ce temps.
La section 9 du RFC, la traditionnelle section sur la sécurité, détaille quelques points précis qui n'avaient pas trouvé leur place dans le reste du RFC. Par exemple, il est important de considérer aussi si le protocole de routage qu'on veut protéger est un IGP ou un EGP (certains protocoles peuvent être utilisés pour les deux, comme BGP avec son mode iBGP). Les deux sont sans doute aussi importants mais les menaces et les solutions ne seront pas forcément les mêmes. Un routeur purement interne et qui n'a aucun accès à l'Internet est ainsi sans doute moins menacé qu'un routeur BGP posé sur un point d'échange avec des dizaines d'autres routeurs inconnus.
Autre question transversale, celle des clés partagées ou uniques. Faut-il utiliser la même clé à plusieurs endroits ? Le débat est simple : c'est la sécurité (clés uniques !) contre la commodité (clés partagées). Actuellement, dans la grande majorité des environnements, les opérateurs ont choisi la commodité, réutilisant la même clé à plusieurs endroits. Les clés des routeurs sont stables dans l'espace (utilisées dans plusieurs routeurs) et dans le temps (on les change rarement, voire jamais et certains routeurs gardent la même clé toute leur vie). L'un des buts de KARP est de casser ce dilemne « sécurité ou commodité » en fournissant des mécanismes de gestion de clés qui soient sûrs (clés uniques) tout en étant faciles à déployer.
Enfin, la section 9.4 discute du dernier problème transversal, la distribution des clés. La méthode la plus courante aujourd'hui est un mécanisme « hors-bande », par exemple l'administrateur qui se connecte en SSH au routeur et entre manuellement les clés dans la configuration. Ça ne passe pas tellement à l'échelle (il faudrait automatiser les connexions SSH, par exemple avec Capistrano, pour faire l'opération sur N routeurs). Et changer toutes les clés en cas, par exemple de départ d'un administrateur (ou, pire, en cas de compromission de la clé) est trop lent. L'approche d'un KMP, protocole de gestion de clés, est donc préférée par KARP, comme nous l'avons déjà vu. Mais le RFC ne cache pas que le KMP a ses propres problèmes : lenteur au début (davantage de calculs cryptographiques) et surtout risques liés au manque de maturité des programmes, les KMP étant encore chose récente.
Une des possibilités envisagées est de réutiliser un KMP existant comme IKE, adapté au monde du routage, mais tournant en dehors du protocole de routage. L'autre possibilité est un nouveau KMP, embarqué dans le protocole de routage. Mais la décision n'est pas encore prise.
Date de publication du RFC : Décembre 2011
Auteur(s) du RFC : K. Li, B. Leiba (Huawei Technologies)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF vcarddav
Première rédaction de cet article le 24 Décembre 2011
Le format de carte de visite numérique
vCard, normalisé dans le RFC 6350, est un des grands succès de l'Internet. On trouve ces
cartes partout. Le format de base définit un jeu de données limité
mais permet des extensions. Ce RFC est donc la
première extension à vCard version 4 (ex-aequo avec celle du RFC 6473), et normalise des
champs pour indiquer un lieu de naissance, un lieu de mort et une date
de mort (la date de naissance, BDAY, est dans le
format de base).
La section 2 décrit ces trois propriétés, toutes facultatives :
BIRTHPLACE indique le lieu de naissance. Il
peut être indiqué en texte libre ou bien sous forme d'une
URI, comme par exemple les URI de plan
geo: du RFC 5870. Ainsi,
Jésus-Christ pourrait avoir
BIRTHPLACE: Dans une grange, Bethléem
(Palestine) ou bien
BIRTHPLACE;VALUE=uri:geo:31.7031,35.196.DEATHPLACE indique le lieu de
mort, par exemple DEATHPLACE: Colline
du Golgotha, Jérusalem (le RFC fournit un exemple où la
longitude et latitude
indiqués sont celles du point où a coulé le
Titanic).DEATHDATE indique la date de la mort. Il
avait longtemps été envisagé de la garder dans le format de base,
comme BDAY mais elle avait finalement été
retirée, suite à la réunion IETF de
Pékin en 2010. Comme
son homologue BDAY, le format préféré de
DEATHDATE est celui
d'ISO 8601 (cf. RFC 6350,
section 4.3), par exemple DEATHDATE:00300501 (date mise un peu au hasard, vu le manque de sources fiables...). Mais on peut aussi utiliser du texte libre pour le cas où
on doit utiliser des formules vagues comme « au début du treizième
siècle ».Un exemple complet d'une vCard avec ces trois propriétés est :
BEGIN:VCARD VERSION:4.0 FN:Jeanne d'Arc N:d'Arc;Jeanne;;; UID:urn:uuid:4f660936-28d5-46bf-86c6-9720411ac02a GENDER:F KIND:individual TITLE:Bergère TITLE:Pucelle TITLE:Sauveuse de la France PHOTO:http://commons.wikimedia.org/wiki/File:Lenepveu,_Jeanne_d%27Arc_au_si%C3%A8ge_d%27Orl%C3%A9ans.jpg LANG:fr URL:http://fr.wikipedia.org/wiki/Jeanne_d%27arc BDAY:14120106 BIRTHPLACE:Domrémy (Lorraine) DEATHDATE:14310530 DEATHPLACE:Rouen (Normandie) END:VCARD
Ces trois nouvelles propriétés sont désormais enregistrées dans le registre IANA.
Date de publication du RFC : Janvier 2011
Auteur(s) du RFC : C. Lewis (Nortel
Networks), M. Sergeant (Symantec Corporation), J. Levine (Taughannock Networks)
Pour information
Première rédaction de cet article le 19 Janvier 2012
En raison de l'importance du problème du spam (et d'autres comportements tout aussi nuisibles), un grand nombre de sites utilisent des listes noires des gens avec qui on ne veut pas communiquer (DNSBL pour DNS-based Black List). Ces listes sont souvent distribuées via le DNS, et gérées par des organismes très divers, dont le niveau de sérieux et d'honnêteté est très variable. La question étant très polémique, documenter le comportement attendu de ces organismes n'a pas été une mince affaire. Ce RFC 6471 décrit donc ce qu'on espère d'un gérant de DNSBL.
Rien ne dit qu'il sera suivi, bien sûr. Mais l'espoir est que ce document serve à faire évoluer les choses dans le bon sens. À noter que le groupe en charge de ce RFC, l'Anti-Spam Research Group de l'IRTF, n'a pas toujours réussi à se mettre d'accord sur le comportement idéal de la DNSBL. Dans ces cas, ce RFC 6471 se contente d'indiquer des recommandations sur la forme (« le gérant de DNSBL devrait documenter ce qu'il fait » si le RFC ne peut pas dire ce qui devrait être fait). La section 1.4 rappelle d'ailleurs que les règles de l'IRTF n'imposent pas de consensus au sein du groupe avant publication. À noter que ce RFC ne parle pas de protocole, les questions purement techniques étant traitées dans le RFC 5782.
Le sujet est tellement polémique que je ne vais pas forcément me contenter d'un compte-rendu neutre, objectif et ennuyeux de ce RFC et que je risque de glisser quelques opinions personnelles, pour lesquelles je demande l'indulgence de mes lecteurs. C'est que les DNSBL sont un marécage de gens bizarres, de racketteurs (« pour être retiré de notre liste, il faut payer »), d'éradicateurs (« nous avons mis les trois-quarts de l'Afrique en liste noire ») et de quelques personnes sérieuses. Le groupe ASRG représente plutôt le point de vue des éradicateurs (« dans le doute, on filtre »).
La section 1 du RFC rappelle ce qu'est une DNSBL et comment elle fonctionne. Les détails techniques du fonctionnement de ce service sont exposés dans le RFC 5782. L'idée est de publier dans le DNS les noms de domaine des méchants, ou bien les adresses IP de leurs serveurs de messagerie. Le serveur qui reçoit du courrier peut alors, en consultant le DNS (ce qui est simple et rapide), prendre connaissance de la « note » attribuée au domaine ou à l'adresse IP par le gérant de la DNSBL. Sur la base de cette note, il peut alors décider de filtrer, de contrôler plus étroitement, etc. Rappelons-bien que c'est le destinataire qui décide quoi faire du courrier, pas le gérant de la DNSBL, qui se contente de publier une information. Au bout du compte, c'est le gérant du serveur de messagerie de destination qui est responsable de l'usage qu'il fait de cette information. Beaucoup sont irresponsables, et filtrent aveuglément sur la base de listes noires sur lesquelles ils n'ont même pas pris la peine de se renseigner.
Comme le DNS est une technique éprouvée, très fiable et rapide, cet
usage original des DNSBL s'est étendu. On voit aujourd'hui des DNSWL
(listes blanches, désignant ceux qui ont droit à un traitement de
faveur), listes d'URI dont la présence dans un
courrier indique un spam, etc. On voit aussi des changements dans
l'usage de ces listes. Très binaire autrefois (l'adresse IP est
présente dans la liste noire => on rejette le message), il est
devenu plus souple, les résultats d'une recherche dans la liste noire
étant souvent un facteur de décision parmi d'autres
(SpamAssassin fonctionne ainsi). Poursuivant
cette idée d'utiliser le DNS pour récupérer de l'information, on voit
aussi des services de géolocalisation utilisant
le DNS et d'autres encore plus techniques (je me sers beaucoup du
domaine aspath.routeviews.org de Route Views, qui permet de
récupérer les informations de routage d'une
adresse). Enfin, les listes distribuées par le DNS sont désormais
utilisées pour bien d'autres choses que le courrier, par exemple pour
du contrôle d'accès à des serveurs IRC ou des
formulaires Web. Bref, on peut tout faire avec le DNS, qui a cessé il y bien
longtemps d'être uniquement un service qui « traduit des noms de domaine en
adresses IP ».
Quelles sont les DNSBL aujourd'hui ? Il y a de tout, certaines sont privées, gérées par une organisation pour son besoin propre, d'autres publiques et gratuites, d'autres payantes (beaucoup de DNSBL sont gratuites en dessous d'un certain seuil d'utilisation et payantes ensuite). On estime qu'il existe plus de 700 listes publiques, la plus ancienne ayant été créée en 1997. À cette époque, les spammeurs utilisaient leurs propres machines et c'est en grande partie en raison des DNSBL, qui distribuaient rapidement les adresses de ces machines, que les spammeurs sont passés à d'autres tactiques (comme les relais de courrier ouverts), tactiques à lesquelles les DNSBL ont dû s'adapter.
Il n'y a pas que le statut juridique et administratif qui différencient les DNSBL actuelles. Elles se différencient également par leurs politiques (comment une entrée est-elle ajoutée à la base et, plus important, comment elle est retirée) et, comme le note pudiquement le RFC, les DNSBL se différencient aussi par le niveau d'honnêteté de leurs responsables.
Justement, cette politique (qui va être mis dans la liste noire, sur quels critères ?) est un point de controverse permanent. Des cow-boys qui vous blacklistent un /20 entier parce qu'une adresse a envoyé un spam, aux gens sérieux qui prennent beaucoup de temps et d'effort avant d'ajouter une adresse à la base, il y a un large spectre d'opinions. Ce RFC 6471 n'essaie pas de trancher entre ces opinions. Il ne dit pas quelle est la bonne politique, simplement que le gérant de la DNSBL doit documenter ses critères d'inclusion et d'exclusion, et faire ensuite réellement ce qu'il annonce (ce qui est très loin d'être le cas). C'est ensuite à l'utilisateur de la DNSBL (l'administrateur d'un serveur de messagerie qui décide d'interroger cette base avant d'accepter un message) de s'informer et de s'assurer que la politique de la DNSBL lui convient.
La section 1.2 fournit une bonne check-list pour ledit utilisateur, sous forme d'une série de questions à se poser avant d'utiliser une DNSBL. Par exemple (entre parenthèses, une étude de l'application de cette check-list à Spamhaus, pour sa liste SBL) :
Il faut en outre réviser ces questions de temps en temps, les listes évoluent et plus d'une a cessé tout fonctionnement.
Le RFC enfonce le clou à plusieurs reprises : c'est
l'utilisateur qui est responsable, au final, pas la
DNSBL. Certes, c'est un plaidoyer pour les gérants de DNSBL
(« ce n'est pas nous qui filtrons », remarque courante des DNSBL face aux contestations) mais cela reflète la
réalité. Filtrer avec une DNSBL, c'est sous-traiter une partie
de sa sécurité, c'est confier les décisions à d'autres (la section 4
revient sur ce point et rappelle que des DNSBL ont déjà listé
0/0 c'est-à-dire tout l'Internet). Il est donc
crucial d'évaluer les sous-traitants. Le
postmaster responsable
comprend ce point : la DNSBL exprime une opinion, mais c'est lui qui
décide d'agir sur la base de cette opinion.
Bref, quels sont les conseils effectifs de ce RFC 6471 ? Ils commencent en section 2. D'abord, la transparence de l'offre. La DNSBL doit écrire noir sur blanc quels sont les critères pour être mis dans la liste noire et quels sont ceux pour être enlevés. Par exemple, une liste qui s'appuie sur un pot de miel peut avoir comme critère d'ajout « On ajoute toute adresse IP qui a envoyé au moins trois messages dans une semaine aux adresses du pot de miel » et comme critère de retrait « On retire toute adresse qui n'a rien écrit au pot de miel depuis deux mois ». Cette politique doit ensuite être suivie rigoureusement et honnêtement. Dans la jungle des DNSBL, on a déjà vu des gérants de liste qui ajoutaient à la liste noire les adresses IP des gens qui les critiquaient (spite listing)... Il y a des tas de politiques raisonnables, l'important est de se tenir à celle publiée. Si on prétend gérer une liste de relais de courrier ouverts, on ne doit pas y mettre des adresses IP pour une autre raison, même en rapport avec le spam.
La transparence n'empêche pas des politiques dingues, mais ouvertement assumées par le gérant de la liste. Un bel exemple est chez UCEprotect, qui menace directement les critiques « Should you want to contact us, you should keep this in mind and behave rationally and calmly in order not to aggravate your situation. [...] Applying legal action or other pressure against us will result in your IP address and/or your network range being listed in our database. ».
À noter que cette règle de transparence n'impose pas de donner tous les détails. Par exemple, l'opérateur de la liste ne va évidemment pas publier les adresses du pot de miel, cela détruirait complètement son efficacité.
Ensuite, la traçabilité. La DNSBL devrait maintenir un historique des ajouts et retraits, avec les raisons, et publier cet historique. Là encore, l'historique publié peut être expurgé mais il doit contenir suffisamment d'informations pour qu'un utilisateur (ou l'administrateur d'une machine listée dans la liste noire) puisse comprendre pourquoi. Si on prend (un peu au hasard), la liste CBL, on trouve juste : « IP Address X.Y.Z.170 is listed in the CBL. It appears to be infected with a spam sending trojan or proxy. It was last detected at 2011-12-17 12:00 GMT (+/- 30 minutes), approximately 4 hours ago. », ce qui est un peu court.
Beaucoup de gérants de DNSBL sont du genre « éradicateur » et n'hésitent pas devant les dommages collatéraux. Le RFC dit d'ailleurs franchement qu'on ne fait pas d'omelette sans casser d'œufs. Ainsi, il arrive que des listes répondent pour des adresses qui n'ont pas eu de comportement malveillant mais font partie du même préfixe (mettre dans la liste tout un /28 lorsqu'une seule adresse IPv4 de ce /28 a mal agi, par exemple). Le RFC recommande que cette pratique d'élargissement soit clairement documentée.
L'entrée dans la liste est une chose. Mais, avec la plupart des DNSBL, les problèmes sont encore pires pour sortir de la liste. Même quand l'entrée est correctement faite, et à juste titre, on peut avoir des difficultés incroyables pour se faire rayer de la liste. Par exemple, une machine Windows devient un zombie, crache du spam à tout va, et se retrouve « noirlistée », ce qui est normal. Ensuite, l'administrateur système prend les choses en main, reformate le disque, installe NetBSD à la place, et va tenter de « délister » la machine, désormais propre. Avec la plupart des DNSBL, il aura un mal fou. Être enregistré dans une liste est facile, la quitter est très très dur. C'est le même problème lorsqu'une organisation disparait et que ses adresses IP sont récupérées par une autre, qui va s'apercevoir, mais trop tard, que le RIR lui a passé des adresses plombées par une mauvaise réputation.
Le RFC demande donc que les gérants de liste changent de perspective. Au lieu de considérer le retrait comme une opération en soi, toute la liste devrait être considérée comme temporaire et la sortie devrait être automatique au bout d'un moment.
Quelle durée avant cette expiration automatique ? Cela dépend de comment est constituée la liste. Si elle est faite manuellement, sur la base d'informations relativement statiques, comme les allocations de préfixes IP, alors les durées de vie peuvent être longues. Si la détection est automatique (par exemple une liste noire de relais HTTP ouverts), alors une durée de vie très courte est plus raisonnable. Ainsi, la machine dont la configuration a été corrigée disparaîtra vite de la liste et la machine qui rechute sera vite réadmise dans la liste. Dans tous les cas, le RFC demande que la politique d'expiration soit elle aussi publiée. Des informations comme « dernière vérification le tant » sont très précieuses pour évaluer la qualité d'une entrée de la base.
Autre bonne pratique, la fourniture d'un canal privé pour demander le retrait d'une entrée dans la base. Il est nécessaire qu'un tel canal soit disponible. Cela peut être aussi simple qu'une adresse de courrier ou qu'un formulaire Web. Mais, en tout cas, une DNSBL ne devrait pas exiger de discussion publique de la demande de retrait. (Oui, certaines le font, comme forme de punition des administrateurs systèmes qui ont fait preuve de négligence, et laissé leur machine être utilisée pour le spam.)
Et, bien sûr, la DNSBL doit fournir un canal de communication qui
ne soit pas lui-même bloqué par la DNSBL... Si l'administrateur de
192.0.2.25 veut demander le retrait de cette
adresse de la liste, et que le canal des demandes de retrait est une
adresse de courrier, sur un serveur qui utilise la DNSBL, on se
retrouverait dans une situation très kafkaïenne. Bien sûr, ces adresses de demande de
retrait reçoivent beaucoup de spam mais le filtrage qui les protège
devrait être très prudent, pour ne pas rejeter des demandes
légitimes.
Les réponses à ces demandes de retrait devraient être raisonnablement rapides. Le RFC suggère deux jours (et sept au grand maximum).
Certaines DNSBL n'acceptent de demandes de retrait de la liste noire que lorsqu'il y a eu une forme d'authentification que le demandeur est bien en charge de l'adresse en question (vérification de l'adresse de courrier dans les bases des RIR, par exemple). Cette pratique est déconseillée car une telle authentification est souvent très difficile à fournir dans l'Internet d'aujourd'hui.
Le RFC recommande même de sérieusement envisager la possibilité de retirer automatiquement les adresses incriminées, sur simple requête (politique dite « pas de question » car on ne demande rien au demandeur). Si l'inscription dans la liste est le résultat d'un test automatique, l'adresse IP « coupable » sera très vite remise, de toute façon. Si on craint une guerre d'ajout/retrait dans la base, il suffit de mettre une limitation au rythme des requêtes (par exemple, deux retraits maximum en vingt-quatre heures) ou de détecter ces guerres et de verrouiller alors l'adresse dans la base. Une telle politique « pas de question » permet de corriger très vite les erreurs dans la base, et ne diminue pas sensiblement l'efficacité globale de la DNSBL (qui ne dépend pas de quelques adresses). Enfin, cette politique permet de désamorcer les (nombreux) conflits entre les gérants de la DNSBL et les responsables des adresses noirlistées.
On l'a vu, ce RFC ne veut pas trancher la question de savoir si une politique d'ajout dans la liste est correcte ou pas. Par contre, la liste des bonnes pratiques demande qu'il y ait symétrie entre la politique d'ajout et celle de retrait. Normalement, si une adresse est ajoutée pour une raison X, et que X cesse d'être vrai, l'adresse devrait être retirée. Par exemple, si une DNSBL stocke les adresses IP des relais de courrier ouverts, elle devrait retirer les adresses qui ne sont plus de tels relais (parce que l'administrateur a réparé la configuration). Cette recommandation du RFC va à l'encontre de la pratique de certaines DNSBL de punir les gérants des machines en question, en demandant une autocritique publique, voire carrément de l'argent, pour être délisté.
Enfin, dernière bonne pratique dans la section 2, cette question du paiement. Le RFC explique qu'il est normal qu'une DNSBL fasse payer ses clients pour y accéder (la définition d'une DNSBL commerciale, après tout). Mais faire payer les administrateurs système, responsables des adresses listées, est, comme le dit le RFC avec euphémisme « proche du racket ». Pour convaincre les administrateurs de listes noires que cette pratique devrait être abandonnée, le RFC note que, même lorsqu'elle est faite avec les meilleures intentions du monde, elle est susceptible de déclencher des réactions négatives, et de mettre en péril le principe même des DNSBL.
Les points traités dans la section 2 étaients de nature plutôt
politique. La section 3 touche plutôt aux questions
techniques. Quelles sont les bonnes pratiques opérationnelles ? Il y
en a plusieurs, par exemple l'importance de disposer d'un ensemble de
serveurs de noms suffisant pour faire face à la charge. Il s'agit non
seulement de la charge normale, mais également de celle, bien plus
élevée, qui surviendra lors d'une dDoS (les
spammeurs n'ont pas le sens de l'humour et les attaques par déni de
service contre les listes noires ne sont pas rares). Pour être sûr que
le nom de domaine « principal » de l'opérateur (mettons
spamhaus.org) soit à l'écart des problèmes, le
RFC conseille que la DNSBL soit dans un sous-domaine délégué, avec ses
propres serveurs de noms :
% dig NS sbl-xbl.spamhaus.org ; <<>> DiG 9.7.3 <<>> NS sbl-xbl.spamhaus.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16914 ;; flags: qr rd ra; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;sbl-xbl.spamhaus.org. IN NS ;; ANSWER SECTION: sbl-xbl.spamhaus.org. 86400 IN NS b.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS 5.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS 0.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS k.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS d.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS o.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS x.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS h.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS l.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS 2.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS 4.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS i.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS 3.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS r.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS f.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS g.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS t.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS 8.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS q.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS 1.ns.spamhaus.org. sbl-xbl.spamhaus.org. 86400 IN NS c.ns.spamhaus.org. ;; Query time: 341 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Dec 17 17:40:40 2011 ;; MSG SIZE rcvd: 388
Un des problèmes récurrents avec les DNSBL est que la plupart des
administrateurs système ne testent jamais si leur configuration est
toujours bonne, et lorsqu'une DNSBL cesse son activité, elle continue
à être interrogée. Pour éviter cela, certaines DNSBL en fin de vie ont
choisi la solution radicale de lister la totalité de l'Internet. À
chaque adresse, elles répondaient qu'elle était listée. Pour détecter
rapidement ce genre de problèmes, le RFC rappelle qu'on peut tester
127.0.0.1. Cette adresse ne devrait jamais
apparaître dans une DNSBL. Si elle le fait, c'est que la liste a un
gros problème et ne devrait plus être utilisée. Si la liste comprend
des noms de domaines et pas des adresses IP, c'est le domaine
invalid qui joue ce rôle. (Le RFC 5782 donne des détails sur ces conventions. D'autres
domaines réservés par le RFC 2606 peuvent être
utiles comme test.)
Néanmoins, la première responsabilité est celle du gérant de la liste : s'il arrête le service, il doit le faire proprement (prévenir sur son site Web au moins un mois à l'avance, etc) et surtout pas en se mettant soudain à lister tout l'Internet dans sa base. Il est important de garder le nom de domaine actif : si celui-ci était libéré, un méchant pourrait l'enregistrer et monter une fausse liste noire, qui serait utilisée par tous les clients distraits qui ont oublié de changer leur configuration.
Du point de vue technique, la méthode recommandée est de changer les serveurs de noms de la zone où se trouve la liste pour des adresses IP qui ne peuvent pas exister, par exemple celles réservées pour la documentation (RFC 5735). Ainsi, on est sûr que le domaine ne marchera pas et qu'aucun enregistrement ne sera retourné, montrant bien aux clients que la liste n'est plus en service. Par exemple, avec la syntaxe standard des fichiers de zone DNS :
dnsbl.example.com. 604800 IN NS u1.example.com.
604800 IN NS u2.example.com.
u1.example.com. 604800 IN A 192.0.2.1
u2.example.com. 604800 IN A 192.0.2.2
Le RFC a aussi des recommandations opérationnelles à faire pour le cas spécifiques des DNSBL qui listent les adresses IP de machines présentant une certaine vulnérabilité (relais SMTP ou HTTP ouverts, par exemple), détectée par un programme. D'abord, le programme ne devrait pas tester des machines préventivement (la question est controversée : certains défendent la légitimité de balayages systématiques de tout l'Internet, d'autres ne sont pas d'accord). Il ne devrait le faire que si quelque chose (un rapport d'envoi de spam, par exemple) attire l'attention sur des machines spécifiques.
Ensuite, une fois une adresse listée, les tests périodiques qui visent à évaluer si la machine est toujours vulnérable devraient être relativement espacés (pas plus d'une fois par jour). Et, bien sûr, le test ne doit pas avoir d'effet négatif (pas d'envoi de grandes quantités de données, par exemple).
Les logiciels qui sont derrière la DNSBL, comme tous les logiciels, ont des bogues. Et les utilisateurs d'une DNSBL peuvent faire des erreurs de configuration. Il est donc important que tout soit vérifié et testé et que des procédures soient en place pour faire face aux problèmes (par exemple, le gérant de la DNSBL doit être prêt à vider manuellement la base ou une partie de celle-ci, si une erreur entraîne le listage erronée d'adresses IP).
À noter que le Wikipédia anglophone a un intéressant tableau de comparaison des DNSBL.
Pour résumer, on a vu que ce RFC résultait d'un compromis entre ceux qui voulaient des listes noires opérant comme elles le voulaient et ceux qui souhaitaient les rendre un peu plus responsables. Le compromis a été de donner peu de recommandations concrètes excepté de documenter les choix effectués. À l'heure actuelle, le moins qu'on puisse dire est que la plupart des listes noires ne font même pas ce minimum...
Date de publication du RFC : Janvier 2012
Auteur(s) du RFC : A. Cooper (Center for Democracy and Technology)
Pour information
Première rédaction de cet article le 17 Janvier 2012
Après une très longue période d'ignorance quasi-complète des problèmes de protection de la vie privée, l'IETF a évolué et on n'entend plus gère ses participants écarter d'un revers de main ces questions, en disant « Nous, on fait juste de la technique, tout ça, c'est de la politique, ça ne nous concerne pas. » De nos jours, au contraire, la prise de conscience est nette et l'IETF a désormais une activité structurée autour de la notion de vie privée, activité qui se traduit par un programme dédié et une liste de diffusion. Faut-il aller plus loin ? C'était une des questions posées lors de l'Atelier « Internet Privacy Workshop 2010 », atelier qui s'est tenu du 8 au 9 décembre 2010 à Cambridge et dont ce RFC est le compte-rendu. (L'auteure travaille pour une ONG qui lutte pour les libertés sur l'Internet.)
Pas de décisions à attendre tout de suite, donc. On en est à un stade d'exploration. L'atelier de Cambridge était coorganisé par l'IETF, le MIT et le W3C pour voir ce que les SDO pouvaient faire en terme de protection de la vie privée. On est loin d'un accord unanime (et le résumé du RFC dit bien qu'aucun des organismes présents n'a de position officielle sur ces questions) mais au moins quelques pistes de travail émergent. L'IETF étant chargé de produire des spécifications concrètes, une bonne partie de l'atelier a porté, non pas sur des discours généraux sur la vie privée, mais sur les tâches envisageables.
La question de la protection de la vie privée sur l'Internet est immense et couvre beaucoup de domaines très différents. Certains problèmes apparaissent de manière récurrente, le fingerprinting (la détermination d'une identité à partir de traces numériques qui n'étaient a priori pas conçues pour cela), la fuite d'informations, la difficulté à distinguer les partenaires primaires (à qui on a donné directement de l'information) des tiers (qui ont eu de l'information sans qu'on interagisse explicitement avec eux), le manque d'informations des utilisateurs sur les avantages et inconvénients d'une meilleure protection, etc. (Notons que le RFC mentionne les faiblesses des utilisateurs, mais pas l'aggressivité avec laquelle les capitalistes collectent et revendent de l'information privée.) Le RFC note que la vie privée n'est pas un absolu et que, par exemple, la protéger peut influer négativement sur l'utilisabilité d'un service. Bref, il y a pour l'instant davantage de défis que de solutions (section 1).
Plus précisement, de quoi a-t-on parlé pendant l'atelier (les supports présentés sont disponibles en ligne) ? La section 2 résume tout cela. D'abord, une discussion technique (section 2.1). Commençons par l'adresse IP. Elle donne souvent bien trop d'informations (il est trivial de remonter d'une adresse IP à un utilisateur, ce qui explique pourquoi elle est considérée comme une donnée personnelle). Certains protocoles offrent des risques particuliers comme certaines techniques de mobilité, qui permettent de suivre un utilisateur à la trace.
C'est d'ailleurs dans le cas de l'adresse IP qu'on trouve un des rares exemples d'une technologie IETF spécialement développée pour répondre à des craintes concernant la vie privée : les adresses IP temporaires du RFC 4941, qui sont partiellement aléatoires, et regénérées de temps en temps, pour éviter le suivi de l'utilisateur.
Autre mécanisme bien connu pour empêcher le suivi par l'adresse IP : le routage en oignon, surtout connu grâce à Tor. Ce service route les paquets à travers plusieurs nœuds distincts, chiffrant leur contenu à chaque fois. Seuls les premiers et derniers nœuds voient le message en clair. Observer le trafic ne permet de trouver, au pire, que l'origine (si on espionne au début), ou bien que la destination (si on espionne à la fin).
Mais Tor n'est pas parfait : le contenu des messages peut donner des indications sur l'origine (cookies, par exemple, pour une requête HTTP). Si on veut vraiment être anonyme, utiliser Tor ne suffit pas : il faut aussi couper bien des choses sur son navigateur, à commencer par Flash et JavaScript, et certains peuvent considérer cela comme un problème. Comme souvent en sécurité, rien n'est gratuit. Protéger sa vie privée peut nécessiter des sacrifices.
Les participants à l'atelier ont également planché sur le mode private browsing qu'offrent certains navigateurs. C'est un mode dans lequel le navigateur ne stocke pas localement les identifiants de session (comme les cookies). Son but n'est pas de protéger contre un suivi de l'utilisateur par le serveur mais de protéger contre d'autres utilisateurs du même poste client. L'expérience indique que beaucoup d'utilisateurs ne comprennent pas la différence et croient que le private browsing leur procure une navigation sans flicage. C'est un exemple d'un autre problème courant en sécurité : les utilisateurs ne comprennent pas les risques.
Enfin, dernière discussion technique, sur les propositions Do Not Track, qui permettent à un utilisateur d'indiquer clairement aux sites Web qu'il ne veut pas être suivi à la trace. Pour l'instant, ce ne sont que des propositions, sans accord technique ou politique.
Après ces discussions techniques, l'atelier s'est demandé quel
pouvait être le rôle des SDO dans cette
histoire. Dans le passé, il n'y a pas eu d'appproche systématique de
la vie privée dans les protocoles IETF. Cela ne veut pas dire que rien
n'a été fait : certains RFC ont été entièrement conçus pour résoudre
un problème de vie privée (comme le RFC 4941
pour IPv6 ou le RFC 3323 pour
SIP). Certains services particulièrement
sensibles ont bénéficié de davantage d'efforts, par exemple
l'indication de présence (RFC 2778) ou bien sûr
la géolocalisation (RFC 3693). Un protocole
comme ALTO (RFC 5693) a
également vu ses problèmes de vie privée étudiés dès le début. Le cas
d'ALTO est difficile car le protocole est d'autant plus efficace que
l'utilisateur révèle beaucoup de choses sur lui (en demandant à
l'oracle « Je veux télécharger
le fichier Serge Reggiani - Les Loups Sont Entrés
Dans Paris.mp3 de taille 4732679 octets et de
MD5
2d79e0d7e25c8c10c9879cefcef4102a et voici la
liste complète des pairs BitTorrent qui l'ont »
par rapport au plus discret mais moins efficace
« je voudrais savoir si le pair 2001:db8:1::1 est
plus ou moins rapide que le
2001:db8:67e::34a:1ff3 »).
La protection de la vie privée a pas mal de rapports avec la sécurité (la section 8 discute du rapprochement de ces deux concepts) et la sécurité est un bon exemple d'une préoccupation transverse (elle affecte tous les protocoles) qui était largement ignorée au début de l'IETF et a vu son rôle de plus en plus pris en compte. L'IETF a ainsi bâti une culture de la sécurité. Ainsi, depuis le RFC 1543, tous les RFC doivent inclure une section Security Considerations pour exposer l'analyse sécurité du protocole. Elle peut être vide mais elle doit être présente avec une mention expliquant pourquoi les auteurs du RFC ont consciemment laissé la section vide. Cette obligation bureaucratique n'est évidemment pas suffisante et l'IETF a ajouté une direction de la sécurité, un RFC dédié pour guider les auteurs de RFC (RFC 3552), de nombreux tutoriels pour auteurs de RFC aux réunions physiques, etc. La même méthode peut-elle être appliquée à la vie privée ? (Le RFC 2828, qui rassemble la terminologie IETF sur la sécurité, contient des termes liés à la protection de la vie privée.)
Le W3C a également procédé à un effort semblable. Un de ses premiers grands efforts a été P3P, un mécanisme pour permettre aux sites Web d'exprimer de manière formelle leur politique de gestion des données personnelles. P3P est un langage riche, qui permet d'indiquer des politiques complexes. Mais il a été très peu adopté en pratique. Opinion personnelle : comme pour la neutralité du réseau, tout le monde prétend que l'information du consommateur résoud tous les problèmes, qu'il suffit d'annoncer sa politique et que le marché choisira. Mais personne ne veut le faire réellement. P3P permettait d'exprimer les politiques de protection des données personnelles en des termes simples et non ambigus et c'était évidemment intolérable pour les e-commerçants, qui préfèrent infliger à l'utilisateur des privacy policies de vingt pages écrites en langage légal.
Après ce tour d'horizon du travail effectué et des acteurs en place, l'atelier s'est attaqué aux défis (section 3). Quels sont les grands problèmes à résoudre ?
D'abord, la trop grande facilité à identifier un utilisateur donné
par les informations que donne le logiciel qu'il utilise : adresse IP,
champs de la requête HTTP comme
User-Agent: ou
Accept-Language:, cookies
(RFC 6265), et plein
d'autres paramètres font qu'on peut identifier un utilisateur ou une
machine bien trop souvent. C'est ce
qu'on nomme le fingerprinting et c'est bien
démontré par le Panopticlick.
Comme dans toute réunion de geeks, les participants à l'atelier ont évidemment pris plaisir à explorer en détail des techniques de fingerprinting particulièrement rigolotes comme d'envoyer du code JavaScript qui va transmettre au serveur la liste des polices installées dans le navigateur (elle est souvent unique).
Capturés par un simple script WSGI sur le
serveur (testez-le en http://www.bortzmeyer.org/apps/env
; les variables d'environnement dont le nom commence par
HTTP_ sont les en-têtes de la requête HTTP), voici une partie de ce
qu'envoie un Firefox typique, depuis une machine
Ubuntu :
HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_USER_AGENT: Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0 HTTP_ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP_ACCEPT_LANGUAGE: en-us,en;q=0.5 HTTP_ACCEPT_ENCODING: gzip, deflate
Cette combinaison d'options et de numéros de version est probablement unique, ou en tout cas rare sur le Web, et identifie donc assez bien une machine (sans même avoir besoin de cookie). Une telle combinaison a par exemple déjà été utilisée pour confondre un agresseur agissant pour le compte de l'industrie du divertissement.
Ces informations n'étaient pas prévues pour cet usage (par exemple, les adresses IP étaient prévues pour router les paquets, pas pour identifier une machine ou une personne). Mais remplacer ces informations par des mécanismes qui empêchent ou limitent le fingerprinting ne sera pas trivial. D'autant plus que pas mal de gens se sont habitués à les utiliser dans ce but et qu'il sera de plus en plus difficile de revenir en arrière. Ainsi, le fingerprinting est souvent utilisé pour détecter des fraudes, ou pour fournir du contenu adapté (et le RFC, qui est gentil et évite les sujets qui fâchent, ne cite pas les applications répressives du fingerprinting, pour identifier l'auteur d'un délit abominable, comme de partager des œuvres d'art). Il y aura probablement beaucoup de désaccords sur le compromis entre vie privée et service « amélioré » grâce au fingerprinting.
Au minimum, l'IETF et le W3C vont essayer de documenter les points qui, dans les protocoles courants (TCP, HTTP, SIP), facilitent le fingerprinting.
Un problème proche est celui de la fuite d'informations (section 3.2) : des
mécanismes conçus pour des motifs tout à fait honorables transmettent
néanmoins plus d'information qu'ils ne le devraient. Ainsi, le champ
Referer: dans une requête HTTP permet de savoir
d'où vient un visiteur Web (ce qui est utile) mais révèle également
des choses comme les ID de session (lorsqu'ils sont mis dans l'URL), les termes de recherche
utilisés, etc. Voici un exemple vu dans le
journal de mon blog (les informations trop sensibles ont été modifiées). On voit les termes de recherche utilisés dans Google :
192.0.2.70 - - [16/Dec/2011:17:08:53 +0000] "GET /1383.html HTTP/1.0" 200 3291 "http://www.google.fr/url?sa=t&rct=j&q=aide+rfc+dns...
Le contrôle sur les données privées repose normalement sur la possibilité de distinguer les récepteurs primaires des données des tiers (section 3.3). Ainsi, si je me connecte sur SeenThis, ce site est récepteur primaire de mes données et je ne suis pas surpris qu'il récolte des informations sur moi. Il s'agissait d'un choix conscient et informé de ma part. Mais l'examen du code source de ce site montre qu'il fait appel au service Google Analytics et donc, sans l'avoir demandé, sans même le savoir, je transmets également des données à Google, un tiers qui peut alors récolter des données sans que je l'ai choisi.
Le cas ci-dessus est relativement simple. Mais dans le Web d'aujourd'hui, on trouve d'autres cas où la distinction entre destinataire primaire et tiers est moins évidente. Un utilisateur qui met un widget amusant sur une page peut le considérer comme primaire alors que le navigateur (par exemple pour retourner les cookies) le traitera comme un tiers, et l'inverse existe également.
Enfin, le dernier grand défi est celui de l'information de l'utilisateur (section 3.4). La plupart du temps, le flicage de ce dernier se fait discrètement, sans qu'il se rende compte de l'immense quantité de données qui est collectée à son insu. La seule information disponible est composée de « policy statements » écrits dans un jargon juridique délibérement confus, conçu pour protéger le patron de l'entreprise et pas pour informer l'utilisateur. Le RFC note que des informations cruciales (comme la durée de conservation des données) en sont souvent absentes. Opinion personnelle : c'est pour cela que les mécanismes du marché - l'entreprise publie sa politique et le consommateur est libre de continuer ou pas - ne fonctionnent pas et qu'il faut des lois comme la loi I&L. Le marche suppose une information parfaite et des acteurs symétriques, ce qui n'est pas du tout le cas ici.
Le problème est d'autant plus sérieux que, si le technicien se doute bien de tout ce que le site Web peut apprendre sur son visiteur, l'utilisateur ordinaire n'a souvent pas pas idée de la quantité de traces numériques qu'il laisse.
Il est donc nécessaire de travailler à une meilleure information. P3P était un bon effort dans ce sens. Mais comme c'était un langage riche, il était difficile de traduire une politique P3P de manière claire pour l'utilisateur. Les efforts actuels portent plutôt sur un nombre limité d'icônes qui pourraient devenir largement connues (un panneau « danger, ici votre vie privée est menacée »...)
La section 4 étudie ensuite les défis liés au déploiement des bonnes pratiques. D'abord (section 4.1), le problème que les mesures techniques sont génériques, alors que les menaces effectives sont souvent spécifiques à un contexte donné. La vie privée n'est pas un concept binaire. Il y a d'autres stades que « complètement privé » et « public ». Mais il est très difficile de traiter cette complexité par des mesures techniques.
Par exemple, les solutions situées en couche 3 comme les adresses IP temporaires du RFC 4941 résolvent certes certains problèmes (le serveur qui reconnaît un visiteur récurrent uniquement sur son adresse) mais ne protège pas du tout contre un FAI ou un État qui essaie d'associer une adresse à un utilisateur. Selon la menace envisagée, ces adresses temporaires sont donc efficaces... ou pas du tout.
Il ne faut donc pas évaluer les solutions techniques en leur demandant de résoudre tous les problèmes possibles. Il ne serait pas raisonnable pour l'IETF d'exiger de ses protocoles qu'ils empêchent complètement toute atteinte à la vie privée. Il faut plutôt dire clairement quels sont les risques et qui (le programmeur, l'utilisateur, la loi) est chargé de les traiter.
Autre problème délicat de déploiement de solutions de protection de la vie privée : la tension entre l'utilisabilité et la protection (section 4.2). Comme souvent en matière de sécurité, il va falloir faire des choix douloureux. Les tenants du Roi Marché ont beau jeu de faire remarquer que les utilisateurs, lorsqu'ils ont le choix, vont vers les services qui violent le plus leur vie privée (Facebook, Google, etc) en échange d'applications sympas et qui brillent. La principale faiblesse de cet argument est qu'il suppose que l'utilisateur est parfaitement conscient des risques, et de ce qui peut lui arriver, ce qui est très optimiste.
Un bon exemple de ce compromis est donné par Tor. Celui-ci fournit une bonne protection mais complique et ralentit (en raison du nombre d'étapes de routage) la navigation. Résultat, il reste peu utilisé, en bonne partie parce que les utilisateurs font un calcul coût/bénéfice (peu informé, d'ailleurs) et décident que leur vie privée n'est pas assez importante pour justifier ce coût.
Avec Tor, le coût de la protection est élevé. Mais même des mesures
bien plus légères ont des coûts. Supprimer l'en-tête
Referer: des requêtes HTTP améliore certainement
la protection. Mais certains sites Web proposent une vue différente
selon la valeur de ce champ et, en le supprimant, on se prive de ce
service. Reste à savoir qui va décider du compromis, et sur quelles informations : comment exposer
ce choix (« Do not send Referer headers ») dans une
interface utilisateur, de manière qui permette un choix raisonné ?
Alors même que l'effet de ce choix va dépendre des sites (dans la
plupart des cas, le Referer: est inutile au
client Web.)
Ces problèmes d'utilisabilité sont cruciaux. Le RFC cite l'exemple de SIP, où un mécanisme normalisé de protection des requêtes contre l'écoute existe (RFC 3261, section 23) mais il n'est pas utilisé en pratique car trop contraignant.
Dernier obstacle au déploiement de techniques respectant davantage la vie privée, la difficulté à trouver les bonnes motivations (section 4.3). Les différents acteurs impliqués ne feront pas d'effort s'ils n'ont pas une motivation pour cela. Cela peut être la crainte du gendarme, la conviction que cela leur apportera plus de clients ou simplement le souci d'utiliser les meilleures techniques (ces trois motivations sont rarement présentes en même temps). La crainte du gendarme est discutée en section 4.3.1. Traditionnellement, beaucoup de services proposés sur l'Internet sont gratuits et la possibilité de vendre les données personnelles des utilisateurs est l'une des voies les plus évidentes pour gagner de l'argent. Comme l'illustre un dessin célèbre, « soit l'utilisateur est le client, soit il est la marchandise ». Dans un tel contexte, il n'y a pas de motivation économique à respecter la vie privée, bien au contraire. Les diverses autorités de régulation ont fini par froncer les sourcils, ce qui a mené les fournisseurs de ces services à publier de longues politiques d'utilisation des données sur leur site. Comme le note le RFC, ces politiques, écrites sans effort pédagogique, visent plutôt à protéger le fournisseur du service qu'à informer correctement et complètement l'utilisateur. Le RFC note à juste titre que ces problèmes ne se corrigeront pas tout seuls et qu'une approche régulatrice est nécessaire (cf. le rapport de la FTC de 2010 sur l'importance d'avoir des politiques publiques mieux écrites).
Le RFC soutient que cette tendance doit continuer : sans forte pression des régulateurs, de la loi, le patronat Internet va toujours essayer de concéder le moins de vie privée possible aux utilisateurs. Un exemple d'une telle pression est la directive européenne qui parle des cookies, indiquant qu'ils ne doivent pas être utilisés sans le consentement des utilisateurs.
Le cas de P3P, déjà cité, est un bon exemple de ce problème des motivations (section 4.3.2). L'idée de base était que les logiciels du côté du client allaient pouvoir lire et comprendre les politiques de protection de la vie privée et automatiquement réagir (par exemple en n'envoyant pas de cookies aux sites dont la politique était trop peu protectrice de la vie privée). C'est une idée très états-unienne : les acteurs libres s'informent mutuellement de leurs pratiques et décident ensuite librement, en adultes majeurs, informés et consentants, de poursuivre ou pas la relation. Si on croit qu'il y a égalité (d'information, de moyens de traitement, de pouvoir) entre le patron de Facebook et M. Michu, utilisateur de Facebook, cela peut marcher. Sinon, on préfère l'approche européenne où certaines pratiques sont interdites, qu'il y ait ou pas consentement de la marchandise, pardon, de l'utilisateur.
Donc, P3P permettait d'automatiser ce processus d'information et de décision. Microsoft a pris une décision importante en choisissant, dans Internet Explorer 6, de n'envoyer des cookies aux tiers que si ceux-ci avaient une politique P3P. Comme n'importe quelle politique, même outrageusement prédatrice, était acceptée par Internet Explorer, la plupart des sites Web se sont pliés à cette décision et ont copié/collé la première politique P3P qu'ils trouvaient (souvent l'exemple pris sur le site du W3C). Cette expérience menée grâce à Internet Explorer (les autres auteurs de navigateurs n'ont fait aucun effort et n'ont jamais intégré P3P) a permis de mettre en évidence une limite de P3P : le site qui publie sa politique peut mentir (« Nous ne vendons pas vos données personnelles »). Aucun mécanisme légal ou autre ne l'en empêche. (Voir par exemple l'article « Token Attempt: The Misrepresentation of Website Privacy Policies through the Misuse of P3P Compact Policy Tokens ».)
Le cas illustre bien la question des motivations : pour qu'ils reçoivent des cookies d'Internet Explorer, les sites devaient publier du P3P. Alors, ils l'ont fait (motivation technique). Il n'y avait pas de pression légale ou régulatrice pour dire la vérité dans ces politiques P3P, alors ils ne l'ont pas fait (pas de motivation légale). Les clients (en partie à cause de l'absence de gestion de P3P par les navigateurs) ne donnaient pas la préférence aux sites publiant du bon P3P, alors les sites n'ont pas cherché à l'améliorer (pas de motivation commerciale).
Il sera intéressant de voir si cela marche mieux en sens inverse : pour la géolocalisation, le RFC 4119 et le RFC 6280 fonctionnent de manière opposée à P3P, en permettant aux utilisateurs d'indiquer leurs choix en matière de protection des données personnelles. Ils sont normalement plus motivés que les entreprises capitalistes pour cela.
Bien sûr, on est ici très loin des questions techniques que se posent normalement les SDO. Mais la compréhension de ces enjeux économiques et légaux est nécessaire, si on veut que les futures techniques de protection de la vie privée aient plus de succès que P3P.
Conclusion, en section 5, quel est le plan d'action pour les SDO ?
Pour l'IETF, la synthèse est que cela va être compliqué. L'IETF
normalise des protocoles dans les couches
basses, sans présupposer d'un usage particulier, alors que
les menaces pour la vie privée sont très dépendantes du contexte. Il
va donc être difficile de trouver des réponses générales, dans les
protocoles IETF. Cela ne veut pas dire qu'il ne faut rien faire. Le
travail a déjà commencé autour d'une série de recommandations pour les
auteurs de RFC (rassemblées dans ce qui est aujourd'hui un
Internet-Draft,
draft-morris-privacy-considerations).
Les participants à l'atelier étaient tous d'accord sur la nécessité de poursuivre également le travail technique, par exemple sur les leçons apprises de Tor, ainsi que sur les capacités (plus fortes que prévues) de fingerprinting des protocoles existants.
Et le W3C ? Il est probablement mieux placé pour améliorer la protection de la vie privée, puisque les normes du W3C sont plus proches de l'utilisateur, et utilisées dans un contexte plus spécifique. Contrairement à l'IETF, le W3C peut se restreindre au Web.
L'annexe A résume quels sont les documents bruts disponibles pour ceux qui veulent approfondir leur connaissance des travaux de cet atelier :
Date de publication du RFC : Décembre 2011
Auteur(s) du RFC : R. Stewart (Adara Networks), M. Tuexen (Muenster University of Applied Sciences), K. Poon (Oracle Corporation), P. Lei (Cisco Systems), V. Yasevich (HP)
Pour information
Réalisé dans le cadre du groupe de travail IETF tsvwg
Première rédaction de cet article le 12 Décembre 2011
Il n'y a pas de protocole qui réussit sans une API, c'est-à-dire une spécification d'une interface qui permet au programmeur d'utiliser le protocole en question. Le protocole de transport SCTP, normalisé dans le RFC 4960, n'avait pas jusqu'à présent d'API standard et les programmes ne fonctionnaient donc qu'avec une seule bibliothèque. Désormais, avec ce RFC, SCTP a des chances de voir le développement de programmes portables.
SCTP est le principal concurrent de TCP dans la catégorie « protocole de couche 4 fiable » (i.e. qui garantit l'acheminement des données, contrairement à UDP). Mais il est beaucoup moins utilisé que TCP, plus ancien, et qui a une API standard depuis longtemps, interface décrite dans la norme POSIX. Il y a aussi d'autres raisons au moindre déploiement de SCTP. Mais l'absence d'API jouait certainement un rôle : pas moyen de programmer avec SCTP sans devoir se limiter, non seulement à un système donné, mais en prime à une mise en œuvre particulière de SCTP. Les instructions d'installation devenaient donc pénibles à lire. C'est ce problème que résoud notre RFC.
L'API décrite dans ce RFC est longue (le RFC fait 113 pages) donc je résume plutôt sauvagement. Elle permet d'écrire des programmes qui font la même chose qu'avec TCP, comme des programmes qui tirent profit des fonctions spécifiques de SCTP. Car la sémantique de SCTP n'est pas exactement la même que celle de TCP, le remplacement de l'un par l'autre n'est pas entièrement invisible aux applications. Les points importants de cette nouvelle API :
Ces deux styles ne sont pas compatibles dans le même programme, le programmeur devra choisir.
Notez que les efforts de conception d'une API SCTP sont anciens. Résultat, il traîne dans la nature des tutoriels, des Howto, des exemples de programme utilisant des mécanismes qui ne sont plus les mécanismes recommandés. Plusieurs éléments des API expérimentales qui ont précédé celle-ci sont repris dans ce RFC, en les notant comme dépassés et ne devant plus être utilisés pour de nouveaux programmes.
Un programme serveur typique qui utilise le style un-vers-N ressemble à :
socket(..., SOCK_SEQPACKET, IPPROTO_SCTP): /* Le type SOCK_SEQPACKET indique le style 1-vers-n. Section 3.1.1 */ bind(...); listen(...); /* Pas besoin de accept(). Les nouvelles associations sont gérées automatiquement (si le serveur le veut, il est prévenu lors des recvmsg(), évenement SCTP_ASSOC_CHANGE). Section 3.1.3 */ recvmsg(...); sendmsg(...); close(...); /* close() ferme tout. Pour ne fermer qu'une seule association, on utilise sendmsg() avec SCTP_EOF. */
pendant que le client fera plutôt :
socket(..., SOCK_SEQPACKET, IPPROTO_SCTP): sendmsg(...); recvmsg(...); close(...):
Toutes les associations du serveur seront représentées par une seule
prise et distinguées par leur identificateur d'association, de type
sctp_assoc_t. La section 3.3 fournit les détails
pour ce cas. Par exemple, si le programme n'utilise qu'un seul tampon
par prise réseau, une association qui traîne peut bloquer toutes les
autres. Le RFC recommande d'utiliser des prises non-bloquantes.
Quant au style un-vers-un, c'est celui de TCP et il est familier à tous les programmeurs réseau. Il est présenté en section 4. L'idée est qu'une application d'aujourd'hui, qui utilise TCP, sera ainsi portée en très peu de temps.
La séquence de commandes pour le serveur est typiquement :
socket(..., SOCK_STREAM, IPPROTO_SCTP); /* Le protocole IPPROTO_SCTP est la seule différence avec TCP. */ bind(...); listen(...); accept(...); /* Ensuite, recv() et send() avec la nouvelle prise retournée par accept(). */ close(...);
Et chez le client :
socket(..., SOCK_STREAM, IPPROTO_SCTP); connect(...); /* Ensuite, recv()/recvmsg() et send()/sendmsg() */ close(...);
Voici pour le code. La section 5 présente ensuite les nouvelles
structures de données, celles qui sont spécifiques à SCTP, lorsqu'on
utilise recvmsg() et
sendmsg() pour des opérations de
contrôle (et pas seulement d'envoi et de récupération de données). Ces
fonctions prennent un paramètre message de type
msghdr (RFC 3542). On peut
s'en servir pour définir des paramètres de la connexion (options
SCTP_INIT et SCTP_SNDINFO),
ou obtenir des informations supplémentaires lors de la réception de
données (option SCTP_RCVINFO, par exemple le
champ rcv_assoc_id indiquera par quelle
association est venue le message).
Pendant la durée de vie d'une connexion SCTP, des tas d'évenements
qui n'ont pas d'équivalent dans le monde TCP peuvent se produire :
changement d'adresse IP d'un pair
(SCTP_PEER_ADDR_CHANGE, section 6.1.2), établissement de nouvelles
associations (ou arrêt des anciennes,
cf. SCTP_ASSOC_CHANGE, section 6.1.1), etc. La section 6 décrit
comment être informé de ces évenements. Quant aux options des prises spécifiques
à SCTP, elles sont dans la section 8. Elles s'utilisent avec
setsockopt() et
getsockopt(). Par exemple,
SCTP_ASSOCINFO permet d'obtenir (ou de modifier)
les paramètres liés aux associations,
SCTP_PRIMARY_ADDR d'obtenir l'adresse IP du pair
pour une association donnée, etc.
Le RFC contient en annexe A deux exemples d'utilisation de cette API, un pour un serveur en un-vers-N et un pour un client en un-vers-un. Pour les raisons expliquées plus haut (retard à normaliser l'API et bibliothèque non standards développées en attedant), ces exemples ne compilent pas sur une Debian ou une Ubuntu récente :
% gcc sctp-sample-client.c sctp-sample-client.c: In function 'main': sctp-sample-client.c:40:25: error: storage size of 'info' isn't known sctp-sample-client.c:97:54: error: 'SCTP_SENDV_SNDINFO' undeclared (first use in this function) sctp-sample-client.c:97:54: note: each undeclared identifier is reported only once for each function it appears in
Je n'ai pas encore trouvé de système où ces exemples compilent. Il existe en effet plusieurs mises en œuvre de SCTP mais pas de cette API. Plus exactement, les implémentations de cette API sont ultra-récentes et ne sont pas encore arrivés chez l'utilisateur. On a :
Le RFC note que des implémentations de l'API standard existent sur Linux, FreeBSD et Solaris mais leur déploiement effectif est inconnu. Elles ont apparemment déjà servi à ajouter SCTP à Firefox et Chrome.
Le livre de référence sur la programmation réseau, celui de Stevens, ne parle pas de SCTP dans les deux premières éditions. C'est à partir de la troisième édition (réalisée par d'autres, après la mort de l'auteur) que SCTP apparaît.
En attendant, la bogue echoping #1676608 risque d'attendre longtemps (d'autant plus que je n'ai plus le temps de m'occuper d'echoping).
Date de publication du RFC : Décembre 2011
Auteur(s) du RFC : I. Fette (Google), A. Melnikov (Isode)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF hybi
Première rédaction de cet article le 12 Décembre 2011
Ce nouveau protocole, WebSocket, vise à résoudre un problème embêtant pour les développeurs d'applications réseau. L'architecture de l'Internet était conçue pour que le seul point commun réellement obligatoire soit le protocole de couche 3, IP. Ce protocole est simple et fournit peu de services. Les développeurs qui voulaient des choses en plus les mettaient dans leurs applications ou, la plupart du temps, comptaient sur les protocoles de transport comme TCP. Si aucun des protocoles de transport existant ne satisfaisaient leurs besoins, ils avaient parfaitement le droit d'en inventer un autre et de le déployer sans rien demander à personne (principe dit « de bout en bout »). Ce modèle ne marche plus guère aujourd'hui. Il est devenu très difficile de faire passer un autre protocole de transport que TCP à travers les innombrables obstacles du réseau (NAT et pare-feux, notamment), et même un protocole applicatif nouveau, tournant sur un port TCP à lui, risque d'avoir le plus grand mal à passer. D'où l'idée de base de WebSocket : faire un protocole de transport au dessus de HTTP, qui va être le seul à passer à peu près partout. WebSocket est donc l'aboutissement d'un processus, qui a mené à ce que le protocole d'unification ne soit plus IP mais HTTP. Bienvenue dans l'Internet d'aujourd'hui « Tout sur le port 80 ».
WebSocket n'est toutefois pas un protocole généraliste, il est conçu pour fonctionner essentiellement dans le cadre du navigateur Web qui charge du code inconnu (typiquement en JavaScript) et qui va ensuite l'exécuter. Ce code pourra utiliser le réseau, dans une certaine limite (vers la même origine, cf. RFC 6454) mais les possibilités de communication offertes précédemment étaient limitées. WebSocket donne à ce code JavaScript (ou écrit dans d'autres langages) les possibilités d'une vraie communication réseau bidirectionnelle.
Avant, les applications s'exécutant sur le navigateur n'avaient pas
de moyen simple de faire de telles communications, équivalentes à ce
qu'on fait en TCP. Des applications comme la messagerie instantanée, le partage d'un document en cours d'édition
ou bien comme des jeux en commun souhaitaient un
modèle d'interaction plus riche que le traditionnel
GET du client vers le serveur. Bien sûr, elles
auraient pu être extérieures au navigateur, ce qui était certainement
plus propre du point de vue architectural. Mais elles se heurtent
alors au problème de filtrage décrit plus haut. Et, dans le
navigateur, elles dépendaient de
XMLHttpRequest ou bien de <iframe> et de
polling. Par exemple, un
code tournant sur le navigateur qui voulait simplement se mettre en
attente de donnés émises de manière asynchrone par le serveur n'avait
pas d'autres solutions que d'interroger ce dernier de temps en temps. Ce problème est
décrit en détail dans le RFC 6202. Il avait
plusieurs conséquences fâcheuses comme un surcoût en octets (tout
envoi de données nécessitait les en-têtes HTTP complets) ou comme un
modèle de programmation peu naturel.
WebSocket vise à résoudre ce problème en transformant HTTP en un protocole de transport. Il réutilise toute l'infrastructure HTTP (par exemple les relais ou bien l'authentification). Passant sur les mêmes ports 80 et 443, on espère qu'il réussira à passer partout. Comme le note un observateur, « WebSocket est un protocole totalement alambiqué pour contourner la stupidité du monde ».
Le résultat n'est donc pas parfait (rappelez-vous que HTTP n'avait pas été conçu pour cela) et le RFC note qu'on verra peut-être un jour les services de WebSocket fonctionner directement sur TCP (personnellement, j'ai des doutes, puisqu'on pourrait aussi bien dans ce cas utiliser des protocoles de transport qui fournissent les mêmes services, comme SCTP - RFC 4960).
Une petite note avant d'attaquer le RFC : si vous avez l'habitude de lire des RFC, vous noterez que celui-ci a des notations originales (section 2.1) comme d'utiliser les tirets bas pour souligner les définitions, les barres verticales pour encadrer les noms d'en-têtes ou de variables et les barres obliques pour les valeurs des variables.
La section 1.2 résume le fonctionnement du protocole (le lecteur
pressé du RFC peut d'ailleurs se contenter de la section 1, non
normative mais qui contient l'essentiel sur WebSocket). Le principe
de base est d'utiliser du HTTP normal (RFC 2616) mais le client ajoute un en-tête
Upgrade: à une requête GET, pour indiquer sa volonté de faire du
WebSocket :
GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13
Le serveur répond alors par un code 101 et en indiquant upgrade dans
l'en-tête Connection: et en ajoutant des en-têtes
spécifiques à WebSocket :
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: chat
Bien sûr, d'autres en-têtes HTTP sont possibles comme les petits gâteaux du RFC 6265. Une fois que le client a fait sa demande, et que le serveur l'a acceptée, il existe une connexion bidirectionnelle entre ces deux acteurs et on peut faire passer les données.
Contrairement à TCP (mais comme dans SCTP), la communication n'est pas un flot d'octets sans structure ; c'est une suite de messages, chacun composé d'une ou plusieurs trames. Les trames sont typées et toutes les trames d'un même message ont le même type. Par exemple, il existe un type texte, où les trames contiennent des caractères Unicode encodés en UTF-8. Il existe évidemment un type binaire. Et il existe des trames de contrôle, conçues pour l'usage du protocole lui-même.
La section 1.3 se focalise sur la poignée de main entre
client et serveur qui lance le protocole (les détails complets étant en section 4). On l'a vu, le client doit
ajouter l'en-tête Upgrade: websocket pour
demander au serveur de basculer en WebSocket (RFC 2616, section 14.42 ; la valeur
websocket pour cet en-tête est enregistrée à l'IANA, cf. section 11.2, et aussi le RFC 2817, section 7.2). Le client indique également des
en-têtes spécifiques à WebSocket comme
Sec-WebSocket-Protocol: qui permet d'indiquer un
protocole applicatif au dessus de WebSocket (chat
dans l'exemple plus haut). Ces protocoles applicatifs (section 1.9)
sont normalement enregistrés à l'IANA pour
assurer l'unicité de leurs noms. L'en-tête Origin: du
RFC 6454 sert à indiquer quelle était l'origine de la page Web
qui a chargé le script client. Quand à
Sec-WebSocket-Key:, son rôle est de permettre de
vérifier que la connexion était bien prévue pour être du WebSocket et
pas des jeux faits par un programme malveillant qui enverrait des
données ressemblant à du WebSocket sur le port 80, sans être passé par
la poignée de main normale. Le serveur doit combiner la valeur de
l'en-tête Sec-WebSocket-Key: avec un
GUID (RFC 4122) fixe,
258EAFA5-E914-47DA-95CA-C5AB0DC85B11. Il passe le résultat par
SHA-1 puis par Base64
et retourne ce résultat au client (dans un en-tête Sec-WebSocket-Accept:), qui peut alors être sûr que c'est
bien ce serveur qui a reçu sa poignée de main. (Voir la section 1.6
sur ce point. Les en-têtes commençant par Sec ne
peuvent pas être ajoutés via du code
XMLHttpRequest normal et, donc, un client
JavaScript ordinaire ne peut pas se comporter en client
WebSocket.)
À noter que les en-têtes spécifiques de WebSocket ont été ajoutés au registre des en-têtes.
La réponse du serveur utilise le code HTTP 101 (qui avait été prévu
de longue date par le RFC 2616, section 10.1.2), qui signifie que le serveur accepte
le changement de protocole. Tout autre code indique que le serveur
n'accepte pas WebSocket et que le client doit donc continuer en HTTP
normal. Ainsi, un serveur HTTP normal refusera l'en-tête Upgrade: :
% telnet www.bortzmeyer.org http Trying 2605:4500:2:245b::bad:dcaf... Connected to www.bortzmeyer.org. Escape character is '^]'. GET / HTTP/1.1 Host: www.bortzmeyer.org Upgrade: websocket HTTP/1.1 400 Bad Request Date: Tue, 29 Nov 2011 21:15:34 GMT Server: Apache/2.2.16 (Debian) Vary: Accept-Encoding Content-Length: 310 Connection: close Content-Type: text/html; charset=iso-8859-1
La section 1.4, elle, décrit la fermeture de la connexion (détails en section 7). Elle se fait par l'envoi d'une trame de contrôle ad hoc. Notez que la simple fermeture de la connexion TCP sous-jacente ne suffit pas forcément : en présence d'intermédiaires, par exemple les relais, elle peut être insuffisante.
Un peu de philosophie après ces détails ? La section 1.5 décrit les concepts à la base de WebSocket. Par exemple, l'un des buts était de garder au strict minimum le nombre de bits de tramage. La structure des données que permet WebSocket est donc réduite (séparation des trames, et typage de celles-ci) et toute structuration plus sophistiquée (par exemple pour indiquer des méta-données) doit être faite par l'application, au dessus de WebSocket.
Dans cette optique « ne pas trop en ajouter », cette section note que WebSocket ajoute à TCP uniquement :
GET),Et c'est tout. Le reste doit être fait par les applications. Compte-tenu des contraintes spécifiques du Web, WebSocket offre donc pratiquement le même service aux applications que TCP. Sans ces contraintes Web (de sécurité, de fonctionnement à travers les middleboxes), du TCP brut suffirait.
Voila, vous connaissez maintenant l'essentiel de WebSocket. Le
reste du RFC précise les détails. La section 3 décrit les
URI WebSocket. Ils utilisent le plan
ws: (non chiffré, port 80
par défaut) ou le wss: (chiffré avec
TLS, port 443 par défaut). La section 11 décrit
l'enregistrement de ces plans dans le registre
IANA. Par exemple
ws://example.com/chat est un URI WebSocket (pour la connexion donnée en exemple au début de cet article), comme ws://www.3kbo.com:9090/servers/1/status ou wss://foobar.example/newsfeed.
Comment fonctionne le tramage, le découpage du flot de données en
trames bien délimitées ? La section 5 le normalise avec précision. Une
trame a un type, une longueur et des données. On trouve également
quelques bits comme FIN qui indique la dernière
trame d'un message, ou comme RSV1,
RSV2 et RSV3, réservés pour
de futures extensions du protocole. Une grammaire complète
est donnée en section 5.2, en utilisant ABNF
(RFC 5234. Les fanas d'ABNF noteront que cette
grammaire ne décrit pas des caractères mais des bits, ce qui
représente une utilisation originale de la norme.
Le type est nommé opcode et occupe quatre bits. Les valeurs de 0x0 à 0x7 indiquent une trame de données, les autres sont des trames de contrôle. 0x1 indique une trame de texte, 0x2 du binaire, 0x8 est une trame de contrôle signalant la fin de la connexion, 0x9 une demande d'écho (ping), 0xA une réponse (pong), etc. La sémantique des trames de contrôle figure en section 5.5. On y apprend par exemple que des échos non sollicités (pong non précédé d'un ping) sont légaux et peuvent servir à indiquer qu'une machine est toujours en vie.
On le sait, l'insécurité est une des plaies du Web, on trouve tout le temps de nouvelles manières de pirater les utilisateurs. Les problèmes viennent souvent de nouveaux services ou de nouvelles fonctions qui semblent super-cool sur le moment mais dont on découvre après qu'elles offrent plein de pièges. Il n'est donc pas étonnant que la section 10, sur la sécurité, soit longue.
D'abord, le serveur WebSocket doit se rappeler qu'il peut avoir
deux sortes de clients (section 10.1) : du code « embarqué » par
exemple du JavaScript exécuté par un navigateur
et dont l'environnement d'exécution contraint sérieusement les
possibilités. Par exemple, l'en-tête Origin: est
mis par ce dernier, pas par le code Javascript, qui ne peut donc pas
mentir sur sa provenance. Mais un serveur WebSocket peut aussi être
appelé par un client plus capable, par exemple un programe
autonome. Celui-ci peut alors raconter ce qu'il veut. Le serveur ne
doit donc pas faire confiance (par exemple, il ne doit pas supposer
que les données sont valides : il serait très imprudent de faire
une confiance aveugle au champ Payload length,
qu'un client malveillant a pu mettre à une valeur plus élevée que la
taille de la trame, pour tenter un débordement de
tampon).
WebSocket ayant été conçu pour fonctionner au dessus de
l'infrastructure Web existante, y compris les relais, la section 10.3
décrit les risques que courent ceux-ci. Un exemple est l'envoi, par un
client malveillant, de données qui seront du WebSocket pour le serveur
mais qui sembleront un GET normal pour le
relais. Outre le tramage, la principale protection de WebSocket contre
ce genre d'attaques est le masquage des données avec une clé contrôlée
par l'environnement d'exécution (l'interpréteur JavaScript, par
exemple), pas par l'application (section 5.3 pour en savoir plus sur
le masquage). Ainsi, un code JavaScript méchant ne pourra pas
fabriquer des chaînes de bits de son choix, que WebSocket
transmettrait aveuglément.
Un peu d'histoire et de politique, maintenant. WebSocket a une histoire compliquée. L'idée de pousser les informations du serveur vers le client (connue sous le nom de Comet) est ancienne. Le protocole WebSocket (dont l'un des buts est justement cela) a été créé par Ian Hickson (qui a aussi écrit les premiers projets de RFC mais n'apparait plus comme auteur). Le groupe de travail WHATWG a ensuite beaucoup participé. La plupart des mises en œuvre de WebSocket citent ce groupe ou bien les anciens Internet-Drafts, écrits avant la création du groupe de travail IETF HyBi en janvier 2010.
Le principe même de WebSocket a souvent été contesté. Pourquoi passer tant d'efforts à contourner les problèmes de l'Internet aujourd'hui (notamment les middleboxes abusives) plutôt qu'à les résoudre ? Un intéressant texte de justification a été écrit à ce sujet. Notez qu'il inclut des exemples de code. Le groupe HyBi a connu de vives discussions, avec menaces de scission (« À WHATWG, c'était mieux, on va quitter l'IETF si ça n'avance pas »). Un des points d'affrontement était par exemple les problèmes de sécurité (résolus par la solution du masquage). Cela s'est ensuite arrangé, début 2011.
Si vous voulez vous lancer dans la programmation d'applications WebSocket tournant dans le navigateur, regardez l'API. Aujourd'hui, on trouve des implémentations de WebSocket pour les différents serveurs (GlassFish, Jetty, Apache). Dans les environnements de développement, on trouve du WebSocket chez Django et bien d'autres. Chez les clients, Firefox l'a en théorie depuis la version 6, Chrome et Internet Explorer l'ont annoncé pour une version prochaine. Bon, en pratique, c'est compliqué, et la démo ne donne pas toujours les résultats attendus (elle me refuse mon Firefox 7 mais accepte un Chrome).
Attention si vous lisez les sources, pas mal d'implémentations ont été faites en suivant des vieilles versions de la spécification de WebSocket, antérieures à sa normalisation à l'IETF. Cela se sent par exemple dans les noms des variables utilisés. (Un terme comme « opcode » pour le type est dans le RFC mais pas toujours dans les programmes.)
En dehors du monde des navigateurs, si vous voulez programmer du WebSocket, vous avez, entre autres :
Si vous voulez jouer plutôt avec un programme client comme curl, vous avez un bon article qui explique comment faire du WebSocket avec curl.
Si vous cherchez des fichiers pcap de Websocket, on en trouve sur pcapr mais attention, la plupart concernent des mises en œuvres de versions antérieures du protocole. Mais Wireshark n'a pas l'air encore capable de décoder le framing Websocket.
Les autres registres IANA pour WebSocket
sont en http://www.iana.org/assignments/websocket/websocket.xml. Il existe un site de référence
sur WebSocket.
Date de publication du RFC : Décembre 2011
Auteur(s) du RFC : A. Barth (Google)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF websec
Première rédaction de cet article le 12 Décembre 2011
Chaque jour, plusieurs failles de sécurité sont annoncées frappant
un site Web, ou, plus rarement, un
navigateur. Ces failles proviennent souvent de
l'exécution de code, par exemple Java ou
JavaScript, téléchargé depuis un serveur qui
n'était pas digne de confiance, et exécuté avec davantage de privilèges
qu'il n'aurait fallu. Une des armes principales utilisées par la
sécurité du Web, pour essayer d'endiguer la marée de ces attaques, est
le concept d'origine. L'idée est que toute
ressource téléchargée (notamment le code) a une origine, et que cette
ressource peut ensuite accéder uniquement à ce qui a la même origine
qu'elle. Ainsi, un code JavaScript téléchargé depuis
www.example.com aura le droit d'accéder à l'arbre
DOM de www.example.com, ou
à ses cookies, mais pas à
ceux de manager.example.net. Ce concept d'origine
semble
simple mais il y a plein de subtileries qui le rendent en fait très
complexe et, surtout, il n'avait jamais été défini précisément. Ce que
tente de faire ce RFC.
Pour comprendre l'importance de l'origine,
revoyons un navigateur Web en action. Imaginons
qu'il n'impose aucune limite au code (Java,
JavaScript, Silverlight,
etc) qu'il exécute. Un méchant pourrait alors mettre du
code malveillant JavaScript sur son serveur, faire de la
publicité (par exemple via le spam) pour
http://www.evil.example/scarlet-johansson-pictures/,
et attendre les visites. Le navigateur récupérerait
l'HTML, puis le JavaScript inclus, et celui-ci
pourrait faire des choses comme lancer une DoS
par connexions HTTP répétées vers
http://www.victim.example/. C'est pour éviter ce
genre d'attaques que tous les navigateurs ont la notion d'origine. Le
code récupéré sur le site du méchant va avoir l'origine
www.evil.example, et le navigateur l'empêchera de
faire des requêtes HTTP vers un autre serveur que
www.evil.example. En gros, le principe
traditionnel de sécurité est « Le contenu récupéré depuis l'origine X
peut interagir librement avec les ressources ayant cette même
origine. Le reste est interdit. » (section 1 du RFC, pour un résumé).
Mais ce principe très simple à énoncer et à comprendre dissimule pas mal de pièges. Ce RFC va donc essayer de les mettre en évidence. À noter qu'il ne fait que fournir un cadre, ce n'est pas un protocole, et il n'y a donc pas besoin de modifier les navigateurs pour obéir à ce texte. Les détails concrets du principe d'origine vont en effet dépendre du protocole utilisé et chacun (HTML, WebSockets du RFC 6455, etc) va donc devoir décliner ce principe selon ses caractéristiques propres. Par exemple, pour le futur HTML5, voici la définition.
Donc, on attaque avec la section 3, qui expose ce qu'est ce
« principe de même origine » (Same Origin
Policy). D'abord, la
confiance (section 3.1) est exprimée sous forme
d'un URI. Lorsque le serveur
www.niceguy.example sert une page
HTML
https://www.niceguy.example/foo/bar.html qui contient :
<script src="https://example.com/library.js"/>
Il annonce sa confiance envers l'URI
https://example.com/library.js. Le code
JavaScript téléchargé via cet URI sera exécuté avec les privilèges de
https://www.niceguy.example/foo/bar.html, qui a choisi de lui faire confiance.
Cette idée de « confiance par URI » peut poser des problèmes dans
certains cas. Par exemple, si on utilise le
STARTTLS du RFC 2817, le
fait d'utiliser TLS ou pas n'apparait pas dans
l'URI et la page HTML ne peut donc pas exiger TLS. Les URI de plan
https: n'ont pas ce défaut, l'exigence de TLS y
est explicite.
Mais il y a une question plus sérieuse : dans
https://www.niceguy.example/foo/bar.html, quelle
est l'origine, celle dont vont dépendre les
autorisations ultérieures (section 3.2) ? Est-ce tout l'URI ? Ou bien
seulement le FQDN
www.niceguy.example ? Réponse : aucune des
deux.
Utiliser tout l'URL comme origine manquerait de souplesse. Un code
venu de http://www.niceguy.example/foo ne
pourrait pas interagir avec du contenu récupéré en
http://www.niceguy.example/bar. Mais n'utiliser
que le nom de domaine n'est pas génial non plus. Car cela permettrait
à du code JavaScript récupéré par
http://www.niceguy.example:8080/ de modifier un
arbre DOM de
https://www.niceguy.example/ (notez que la
seconde est sécurisée avec HTTPS ; ne se servir
que du nom de domaine comme origine permettrait à du contenu non sûr
de manipuler du contenu sûr).
Et faut-il utiliser tout le FQDN ? Cela
empêche http://portal.niceguy.example/ de jouer
avec http://manager.niceguy.example/ alors que
les deux sites sont sous la même autorité, celle de
niceguy.example. Mais le problème est que la
détermination de cette autorité est difficile. Contrairement à ce que
croient les débutants, elle n'est pas forcément dans les deux derniers
composants du nom de domaine. Par exemple,
jones.co.uk et smith.co.uk
ne sont pas sous la même autorité. Et, même lorsque c'est le cas, une
Université ne souhaite pas forcément que
http://students.example.edu/ (consacré aux pages
personnelles des étudiants) aient des droits sur
http://admin.example.edu/. Bien sûr, aucun
système n'est parfait. Avec le FQDN,
http://example.edu/students/~mark aura des droits
sur http://example.edu/grades/admin. Mais ce
modèle fondé sur le FQDN est maintenant trop ancien pour le changer
(rappelez-vous qu'il a évolué informellement, notre RFC 6454 ne fait que le documenter a posteriori).
Donc, pour résumer le point important de la section 3.2 : une
origine est un tuple {FQDN, plan, port}. Par exemple,
http://example.com/,
http://example.com:80 et
http://example.com/toto.html ont tous les trois la même origine,
le tuple {example.com, http,
80}. En revanche, http://example.com:81/ a une
autre origine (port différent), de même que
ftp://example.com (plan différent), ou
http://www.example.com/ (nom différent).
Ce principe de même origine ne répond pas à tous les risques de
sécurité. Il faut également intégrer la notion d'autorité (tel que ce
terme est utilisé en sécurité, notez que le RFC 3986 utilise ce mot dans un autre sens). L'autorité est
que le navigateur donne des droits différents selon le type de document. Une
image n'a aucun droit, c'est du contenu passif (du moins pour les formats traditionnels : avec des formats comme SVG, l'analyse de sécurité est bien plus complexe). En revanche, un
document HTML a le droit de déclencher le
chargement d'autres ressources (styles CSS mais
surtout code actif, par exemple JavaScript). Normalement, l'autorité
dépend du type MIME indiqué
(image/png pour une image,
text/html pour l'HTML). Si ce type est déterminé
par un utilisateur, de nouvelles vulnérabilités peuvent
survenir (et certains navigateurs sont assez imprudents pour deviner
le type MIME en examinant le contenu, une mauvaise pratique, connue
sous le nom de content sniffing). Pire, si l'utilisateur peut insérer du contenu qu'il choisit
dans des documents ayant une forte autorité (pages HTML), de nouveaux
risques peuvent survenir. Par exemple, une attaque
XSS débute par l'insertion de contenu dans une
page HTML, contenu qui sera ensuite interprété par le navigateur, et
exécuté avec l'origine de la page Web (cf. section 8.3). Or, ce cas est très fréquent
(pensez à un moteur de recherche qui affiche la requête originale sans
précaution, alorss qu'elle était choisie par un utilisateur
extérieur). La protection contre les XSS est complexe mais le conseil
de base est : modifiez tout contenu venu de l'extérieur avant de
l'inclure dans un document ayant de l'autorité (comme une page HTML),
de façon à ce qu'il ne puisse pas être interprété par le
navigateur. Le plus simple pour cela est d'utiliser exclusivement un
système de gabarit pour fabriquer les pages. Il
se chargera alors des précautions comme de transformer
les < en <.
Une fois déterminée l'origine, il reste à décider des privilèges donnés aux objets de la même origine (section 3.4). Pour les objets récupérés, on l'a vu, la politique est typiquement de ne donner accès qu'aux objets de même origine que le code. Mais pour les accès à d'autres objets, tout est bien plus complexe et la sécurité rentre ici en conflit avec l'utilisabilité. Par exemple, une application stricte du principe de même origine aux accès aux ressources interdirait à une page Web de mener à une autre page, d'origine différente, alors que c'est évidemment une fonction essentielle du Web. Moins caricatural, le cas d'images ou autres contenus embarqués dans une page Web. Bien que cela pose des problèmes de sécurité (pensez aux Web bugs), aucun navigateur n'impose que les images aient la même origine que la page qui les charge... De même, aucun navigateur n'interdit complètement d'envoyer des données à une autre origine, même si c'est la base de nombreuses CSRF.
Voilà, l'essentiel des principes du RFC tient dans cette section
3. Le reste, ce sont les détails pratiques. La section 4 formalise la
notion d'origine en en donnant une définition rigoureuse. Elle couvre
des cas rigolos comme les URI de plan file:
(autrefois, les navigateurs considéraient tous les fichiers locaux
comme ayant la même origine, aujourd'hui, les plus paranoïaques font
de chaque fichier une origine différente), ou bien explicite le cas
des ports par défaut de certains plans (vous avez remarqué
l'équivalence entre les URI http://example.com/,
http://example.com:80, plus haut ?). La section 5
décrit d'autres pièges comme le cas des plans où n'apparaissent pas de
noms de machine comme par exemple les data: du RFC 2397 (un cas amusant car
deux URI data: complètement identiques, bit par
bit, sont quand même d'origine différente). Et la section 6 explique
la sérialisation d'un URI, à des fins de comparaison simples avec
d'autres URI, pour déterminer s'ils ont la même origine. Par exemple,
http://www.example.com:80/ et
http://www.example.com/toto se sérialisent tous
les deux en http://www.example.com. Pour les URI
de type {scheme, host,
port} (les plus fréquents), une simple
comparaison de chaînes de caractères nous dira ensuite s'ils ont la
même origine (ici, oui).
Si on revient au premier exemple JavaScript que j'ai donné, celui
où https://www.niceguy.example/foo/bar.html
charge https://example.com/library.js, on voit
que l'origine n'est pas l'URI du script mais celle de la page qui le
charge. Or, on peut imaginer que le serveur
example.com voudrait bien connaître cette
origine, par exemple pour appliquer des règles différentes. ou tout
simplement pour informer le script du contexte dans lequel il va s'exécuter. C'est le rôle de l'en-tête
HTTP Origin:, normalisé
dans la section 7, et qui peut être ajouté aux requêtes. Ainsi, dans
l'exemple ci-dessus, la requête HTTP ressemblerait à :
[Connexion à exemple.com...] GET /library.js HTTP/1.1 Host: example.com Origin: https://www.niceguy.example ...
On voit que l'origine indiquée est la forme sérialisée comme indiqué
plus haut. Ce n'est donc pas l'équivalent de
Referer: qui indique un URI complet.
Cet en-tête est désormais dans le registre des en-têtes (cf. section 9).
Comme tout ce RFC décrit un mécanisme de sécurité, il est prudent de bien lire la section 8, Security Considerations, qui prend de la hauteur et rappelle les limites de ce mécanisme. Historiquement, d'autres modèles que le « principe de même origine » ont été utilisés (à noter que le RFC ne fournit pas de référence), comme le taint tracking ou l'exfiltration prevention mais pas avec le même succès.
D'abord, la notion d'origine est une notion unique qui s'applique à des problèmes très différents et peut donc ne pas être optimisée pour tous les cas.
Ensuite, elle dépend du DNS (section 8.1)
puisque la plupart des plans d'URI utilisent la notion
d'host et que la politique de même origine considère que deux serveurs sont les mêmes s'ils ont le
même nom. Si l'attaquant contrôle le DNS, plus aucune sécurité n'est
possible (on croit parler au vrai www.example.com et on
parle en fait à une autre machine).
À noter que le RFC prend bien soin de ne pas parler de la principale vulnérabilité de ce concept d'host : l'absence de notion générale d'identité d'une machine dans l'Internet (cette notion n'existe que pour certains protocoles spécifiques comme SSH). En l'absence d'une telle notion, des attaques sont possibles sans que l'attaquant ait eu à compromettre le DNS, comme par exemple le changement d'adresse IP.
Autre piège, le fait que le principe de même origine, ne soit pas
apparu tout de suite et que certaines techniques de sécurité du Web
utilisent une autre unité d'isolation que l'origine (section
8.2). Le Web n'a pas en effet de sécurité cohérente. C'est le cas des
cookies (RFC 6265), qui se servent d'un autre concept, le « domaine
enregistré ». Le navigateur essaie de trouver, lorsqu'il récupère un
cookie, à quel « domaine enregistré » il appartient
(l'idée étant que sales.example.com et
it.example.com appartiennent au même domaine
enregistré, alors qu'ils n'ont pas la même origine). Il enverra
ensuite le cookie lors des connexions au même
domaine enregistré. Pour déterminer ce domaine, notez que les
cookies ne font pas de différence entre HTTP et
HTTPS (sauf utilisation de l'attribut Secure) et
qu'un cookie acquis de manière sûre peut donc être
envoyé par un canal non sûr.
Notre RFC note que cette pratique d'utiliser le « domaine enregistré » est mauvaise et la déconseille. En effet :
a.co.jp et b.co.jp sont deux
domaines enregistrés différents. Il existe des listes publiques de
politiques d'enregistrement comme http://publicsuffix.org/ mais aucune n'est officielle et aucune
n'est à jour.Autre faiblesse du principe de même origine, l'autorité diffuse (section 8.3). L'autorité va dépendre de l'URI, pas du contenu. Or, un URI de confiance peut inclure du contenu qui ne l'est pas (pour le cas, fréquent, où une page Web inclut du contenu généré par l'utiisateur) et c'est alors un risque de XSS.
Résultat, le principe de même origine ne suffit pas à lui seul à protéger l'utilisateur (plusieurs attaques ont déjà été documentées.) Il faut donc ajouter d'autres pratiques de sécurité.
Notez que la question des mises en œuvre de ce RFC ne se pose pas, il a été réalisé après le déploiement du concept de même origine et tous les navigateurs Web utilisent aujourd'hui ce système. Toutefois, certains ne le font peut-être pas encore absolument comme décrit ici, par exemple en accordant au plan ou au port moins de poids qu'au host (il semble que cela ait été le cas de certaines versions d'Internet Explorer).
Une autre bonne lecture sur ce concept d'origine est l'article de Google pour les développeurs.
Date de publication du RFC : Novembre 2011
Auteur(s) du RFC : P. Faltstrom (Cisco), P. Hoffman (VPN Consortium)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF appsawg
Première rédaction de cet article le 13 Novembre 2011
Une des exigences de la norme sur les IDN
(RFC 5890) est la stabilité
: si un caractère est autorisé dans les
noms de domaine à un
moment donné, il devrait l'être pour toujours, sous peine qu'une
épée de Damoclès pèse sur les titulaires de
noms, la crainte qu'un nom qu'ils utilisent devienne subitement
invalide. Mais le mécanisme par lequel sont déterminés les caractères
autorisés ou interdits rend inévitable de tels problèmes, heureusement
dans des cas rares et marginaux. C'est ce qui vient de se produire
avec la sortie de la norme Unicode version 6 : le caractère ᧚ (U+19DA),
autrefois autorisé, est désormais interdit. S'il y avait eu des noms
de domaine l'utilisant (ce n'était apparemment pas le cas), ils
deviendraient subitement illégaux.
Vu que ce caractère est très rare, toute cette discussion n'est-elle pas une tempête dans un verre d'eau ? Pas complètement, parce que c'est la première fois que le problème se pose depuis la sortie de la version 2 de la norme IDN, et que la façon dont ce cas a été traité va servir de modèle pour des futurs problèmes qui pourraient être plus délicats.
Reprenons dès le début : dans la norme actuelle sur les IDN, dite « IDNAbis » (RFC 5890), les caractères Unicode peuvent être valides ou invalides dans un nom de domaine. Cette validité (qui était déterminée manuellement dans la première version d'IDN) découle d'un algorithme, normalisé dans le RFC 5892, qui prend en compte les propriétés que la norme Unicode attache à un caractère. Par exemple, si le caractère a la propriété « Est une lettre », il est valide. Ce système a l'avantage de remédier au principal inconvénient d'IDN version 1, le fait que le premier IDN était lié à une version particulière d'Unicode. Avec IDNAbis, au contraire, lorsque le consortium Unicode sort une nouvelle version de sa norme, il suffit de faire tourner à nouveau l'algorithme, et on a la liste des caractères valides dans cette nouvelle version.
Le problème que cela pose est que les propriétés d'un caractère
Unicode peuvent changer d'une version à l'autre. Elles ne sont pas
forcément couvertes par les engagements de stabilité du consortium
Unicode. C'est ce qui s'est produit en octobre
2010, lors de la sortie de la version 6 d'Unicode. Trois caractères ont vu leur
validité changer car leur GeneralCategory Unicode a
changé. Pour les deux premiers, rien de très grave. ೱ (U+0CF1)
et ೲ (U+0CF2), classés à tort comme des
symboles, ont été reclassés comme lettres et sont donc devenus
valides, alors qu'ils étaient invalides. Personne n'avait donc pu les
utiliser et le changement ne va donc pas affecter les titulaires de
noms de domaine.
Mais le troisième pose un problème épineux. Pas
quantitativement. Ce caractère ᧚ (U+19DA),
de l'écriture Tai
Lue n'a apparemment jamais été utilisé dans un nom de
domaine, en partie par ce que l'écriture dont il fait partie est peu
répandue (et ses utilisateurs sont peu connectés à l'Internet). Mais,
qualitativement, c'est ennuyeux car U+19DA (un
chiffre) fait le chemin inverse. D'autorisé, il devient
interdit. Potentiellement, il peut donc remettre en cause la stabilité
des noms de domaine. Si on applique aveuglément l'algorithme du RFC 5892, U+19DA va devenir
interdit. Alors, que faire ? Le RFC 5892 (section 2.7)
prévoyait une table des exceptions, où on pouvait mettre les
caractères à qui on désirait épargner le sort commun. Fallait-il y
mettre le chiffre 1 du Tai Lue ?
La décision finalement prise, et documentée par ce RFC (décision
pompeusement baptisée « IETF consensus », bien
que la section 5 rappelle qu'elle a été vigoureusement discutée) a
finalement été de laisser s'accomplir le destin. Aucune exception n'a
été ajoutée pour ces trois caractères, l'algorithme normal s'applique
et U+19DA ne peut donc plus être
utilisé. L'argument principal est que ce caractère n'était quasiment
pas utilisé. Les cas suivants mèneront donc peut-être à des décisions
différentes (la section 2 rappelle bien que, dans le futur, les choses
seront peut-être différentes).
Ce RFC 6452 documente donc cette décision. Bien qu'elle se résume à « ne touchons à rien », il était préférable de la noter, car un changement qui casse la compatibilité ascendante n'est pas à prendre à la légère.
Les deux autres caractères, utilisé en Kannada, ೱ (U+0CF1)
et ೲ (U+0CF2) ne créent pas le même
problème car ils ont changé en sens inverse (interdits autrefois, ils sont
désormais autorisés).
Date de publication du RFC : Novembre 2011
Auteur(s) du RFC : L. Vegoda (ICANN)
Réalisé dans le cadre du groupe de travail IETF grow
Première rédaction de cet article le 29 Novembre 2011
Dernière mise à jour le 5 Janvier 2012
Pour limiter certains risques de sécurité, des opérateurs réseaux filtraient en entrée de leur réseau les adresses IP non encore allouées (dites bogons). Les adresses IPv4 étant désormais totalement épuisées, cette pratique n'a plus lieu d'être et ce RFC demande donc que ces filtres soient démantelés.
L'idée était d'empêcher l'usage de ces préfixes IP non alloués. Ils représentaient des cibles tentantes, par exemple pour un spammeur qui voulait des adresses jetables et non traçables : on trouve un bloc non alloué, on l'annonce en BGP (puisqu'il n'est pas alloué, il n'y a pas de risque de collision), on envoie son spam et on arrête l'annonce BGP (voir les articles cités à la fin). Pour éviter cela, et d'autres attaques analogues, l'habitude s'est prise de filtrer les bogons, ces préfixes non alloués. Certains opérateurs rejetaient les annonces BGP pour ces bogons, d'autres bloquaient sur le pare-feu les paquets ayant une adresse source dans ces préfixes non alloués. Ces pratiques étaient largement documentées par exemple sur le site de référence sur les bogons.
Cette pratique a toujours posé des problèmes, notamment celui de la « débogonisation ». Lorsqu'un préfixe qui n'était pas alloué le devient, il faut toute une gymnastique pour le retirer des filtres existants, sachant que beaucoup de ces filtres ne sont que rarement mis à jour. On voit ainsi des messages sur les listes de diffusion d'opérateurs réseaux avertissant de l'arrivée prochaine d'un nouveau préfixe et demandant qu'il soit supprimé des filtres. Voici deux exemples de ces annonces en 2004 et en 2005. Pour permettre aux opérateurs de tester que tout va bien après cette suppression, les RIR mettent souvent un beacon, un amer, dans le préfixe, une adresse IP qu'on peut pinguer pour tester, comme le recommande le RFC 5943. Tout ce travail faisait donc que la chasse aux bogons était contestée depuis longtemps.
À noter (section 2) que le terme de bogon a été défini dans le RFC 3871, qui recommande leur blocage. Ce même RFC 3871 décrit en détail le problème que posent les bogons et la raison de leur éradication. Le terme de martien, plus flou (il vient du RFC 1208), est appliqué à toutes sortes de paquets dont l'adresse source est anormale (dans le DNS, il a un autre sens, celui de paquet de réponse à une question qui n'a pas été posée).
La section 3 représente le cœur du RFC : elle formule la nouvelle règle. Celle-ci, tenant compte de l'épuisement des adresses IPv4 est simple : tous les préfixes IPv4 sont désormais alloués ou réservés. Il ne faut donc filtrer que les réservés. Les autres peuvent désormais tous être une source légitime de trafic IP. La chasse aux bogons et les difficultés de la débogonisation faisant partie du folklore de l'Internet depuis très longtemps, c'est donc une page d'histoire qui se tourne. (Les adresses IPv6 sont, elles, loin d'être toutes allouées et ne sont donc pas concernées.)
La section 4 rappelle que l'autorité pour cette liste de préfixes réservés est le RFC 5735, ou son éventuel futur successeur. On y trouve par exemple les adresses privées du RFC 1918 ou bien les adresses réservées à la documentation du RFC 5737. Les listes de bogons qu'on trouve sur le réseau, comme celle de TeamCymru sont désormais réduites à ce groupe.
À noter que l'assertion « Tous les préfixes sont désormais alloués » ne vaut que pour les préfixes de longueur 8 (les « /8 ») distribués aux RIR. Certains peuvent filtrer à un niveau plus fin, en distinguant dans ces /8 les adresses que les RIR ont affectés de celles qui ne le sont pas encore. Comme le rappelle la section 3.2, cette pratique est risquée, les affectations par les RIR changeant vite. Le RFC demande donc que, si on a de tels filtres, ils soient changés au moins une fois par jour.
Pour en apprendre plus sur les bogons, on peut
regarder la bonne
analyse faite par BGPmon. On voit finalement peu d'annonces
BGP de bogons (6 seulement
en 2011), la plupart pour le préfixe
198.18.0.0/15 des mesures de performance (RFC 5735). Un bon résumé des
bogons et de la débogonisation avait été fait par
Dave Deitrich en 2005.
Quelques articles sur les trucs utilisés par des méchants (spammeurs, par exemple), en connexion avec les bogons :
Date de publication du RFC : Décembre 2011
Auteur(s) du RFC : E. Jankiewicz (SRI International), J. Loughney (Nokia), T. Narten (IBM Corporation)
Pour information
Réalisé dans le cadre du groupe de travail IETF 6man
Première rédaction de cet article le 22 Décembre 2011
Il existe des tas de RFC qui concernent IPv6 et le programmeur qui met en œuvre ce protocole dans une machine risque fort d'en rater certains, ou bien d'implémenter certains qu'il aurait pu éviter. Ce RFC est donc un méta-RFC, chargé de dresser la liste de ce qui est indispensable dans une machine IPv6. Les deux points les plus chauds concernent la configuration (par DHCP ou par RA - Router Advertisment ?) et la gestion d'IPsec, désormais officiellement facultative.
Ce document remplace son prédécesseur, le RFC 4294. Il vise le même but, servir de carte au développeur qui veut doter un système de capacités IPv6 et qui se demande s'il doit vraiment tout faire (réponse : non). Ce RFC explique clairement quels sont les points d'IPv6 qu'on ne peut pas négliger, sous peine de ne pas pouvoir interagir avec les autres machines IPv6. Le reste est laissé à l'appréciation du développeur. La section 2 résume ce but.
Les deux gros changements par rapport au RFC 4294 sont :
Ce RFC s'applique à tous les nœuds IPv6, aussi bien les routeurs (ceux qui transmettent des paquets IPv6 reçus qui ne leur étaient pas destinés) que les machines terminales (toutes les autres).
Bien, maintenant, les obligations d'une machine IPv6, dans l'ordre. D'abord, la couche 2 (section 4 du RFC). Comme IPv4, IPv6 peut tourner sur des tas de couches de liaison différentes et d'autres apparaîtront certainement dans le futur. En attendant, on en a déjà beaucoup, Ethernet (RFC 2464), 802.16 (RFC 5121), PPP (RFC 5072) et bien d'autres, sans compter les tunnels.
Ensuite, la couche 3 (section 5 du RFC) qui est évidemment le gros morceau puisque c'est la couche d'IP. Le cœur d'IPv6 est normalisé dans le RFC 2460 et ce dernier RFC doit donc être intégralement implémenté, à l'exception de l'en-tête de routage de type 0, qui a été abandonné par le RFC 5095.
Comme IPv6, contrairement à IPv4, ne permet pas aux routeurs intermédiaires de fragmenter les paquets, la découverte de la MTU du chemin est particulièrement cruciale. La mise en œuvre du RFC 1981 est donc recommandée. Seules les machines ayant des ressources très limitées (genre où tout doit tenir dans la ROM de démarrage) sont dispensées. Mais le RFC se doit de rappeler que la détection de la MTU du chemin est malheuresement peu fiable dans l'Internet actuel, en raison du grand nombre de pare-feux configurés avec les pieds et qui bloquent tout l'ICMP. Il peut être donc nécessaire de se rabattre sur les techniques du RFC 4821).
Le RFC 2460 décrit le format des paquets et leur traitement. Les adresses y sont simplement mentionnées comme des champs de 128 bits de long. Leur architecture est normalisée dans le RFC 4291, qui est obligatoire.
Également indispensable à toute machine IPv6, l'autoconfiguration sans état du RFC 4862, ainsi que ses protocoles auxiliaires comme la détection d'une adresse déjà utilisée.
ICMP (RFC 4443) est évidemment obligatoire, c'est le protocole de signalisation d'IP (une des erreurs les plus courantes des administrateurs réseaux incompétents est de bloquer ICMP sur les pare-feux).
Dernier protocole obligatoire, la sélection de l'adresse source selon les règles du RFC 3484, pour le cas où la machine aurait le choix entre plusieurs adresses (ce qui est plus fréquent en IPv6 qu'en IPv4).
Le reste n'est en général pas absolument obligatoire mais recommandé (le terme a un sens précis dans les RFC, définie dans le RFC 2119 : ce qui est marqué d'un SHOULD doit être mis œuvre, sauf si on a une bonne raison explicite et qu'on sait exactement ce qu'on fait). Par exemple, la découverte des voisins (NDP, RFC 4861) est recommandée. Toutes les machines IPv6 en ont besoin, sauf si elles utilisent les liens ne permettant pas la diffusion.
Moins générale, la sélection d'une route par défaut s'il en existe plusieurs, telle que la normalise le RFC 4191. Elle est particulièrement importante pour les environnements SOHO (RFC 6204).
On a vu que l'autoconfiguration sans état (sans qu'un serveur doive se souvenir de qui a quelle adresse) était obligatoire. DHCP (RFC 3315), lui, n'est que recommandé.
Une extension utile (mais pas obligatoire) d'IP est celle des adresses IP temporaires du RFC 4941, permettant de résoudre certains problèmes de protection de la vie privée. Évidemment, elle n'a pas de sens pour toutes les machines (par exemple, un serveur dans son rack n'en a typiquement pas besoin). Elle est par contre recommandée pour les autres.
Encore moins d'usage général, la sécurisation des annonces de route (et des résolutions d'adresses des voisins) avec le protocole SEND (RFC 3971). Le déploiement effectif de SEND est très faible et le RFC ne peut donc pas recommander cette technique pour laquelle on n'a pas d'expérience, et qui reste simplement optionnelle.
L'une des grandes questions que se pose l'administrateur réseaux avec IPv6 a toujours été « autoconfiguration RA - Router Advertisment - ou bien DHCP ? » C'est l'un des gros points de ce RFC et la section 6 le discute en détail. Au début d'IPv6, DHCP n'existait pas encore pour IPv6 et les RA ne permettaient pas encore de transmettre des informations pourtant indispensables comme les adresses des résolveurs DNS (le RFC 6106 a résolu cela). Aujourd'hui, les deux protocoles ont à peu près des capacités équivalentes. RA a l'avantage d'être sans état, DHCP a l'avantage de permettre des options de configuration différentes par machine. Alors, quel protocole choisir ? Le problème de l'IETF est que si on en normalise deux, en laissant les administrateurs du réseau choisir, on court le risque de se trouver dans des situations où le réseau a choisi DHCP alors que la machine attend du RA ou bien le contraire. Bref, on n'aurait pas d'interopérabilité, ce qui est le but premier des normes Internet. Lorsque l'environnement est très fermé (un seul fournisseur, machines toutes choisies par l'administrateur réseaux), ce n'est pas un gros problème. Mais dans un environnement ouvert, par exemple un campus universitaire ou un hotspot Wifi, que faire ? Comme l'indiquent les sections 5.9.2 et 5.9.5, seul RA est obligatoire, DHCP ne l'est pas. RA est donc toujours la méthode recommandée si on doit n'en choisir qu'une, c'est la seule qui garantit l'interopérabilité. (Voir aussi la section 7.2 sur DHCP.)
Continuons à grimper vers les couches hautes. La section 7 est
consacrée aux questions DNS. Une machine IPv6
devrait pouvoir suivre le RFC 3596 et donc avoir
la possibilité de gérer des enregistrements DNS de type AAAA (les
adresses IPv6) et la résolution d'adresses en noms grâce à des
enregistrements PTR dans
ip6.arpa. Les anciens enregistrements A6 (RFC 3363) ont été
abandonnés mais on constate que ces
enregistrements sont toujours très demandés lors des requêtes à des
serveurs DNS faisant autorité, comme ceux de
.fr (dans les 0,5 % des requêtes, soit davantage que SRV ou DS).
À noter qu'une machine IPv6, aujourd'hui, a de fortes chances de se retrouver dans un environnement où il y aura une majorité du trafic en IPv4 (c'est certainement le cas si cet environnement est l'Internet). La section 8 rappelle donc qu'une machine IPv6 peut avoir intérêt à avoir également IPv4 et à déployer des techniques de transition comme la double-pile du RFC 4213.
Encore juste une étape et nous en sommes à la couche 7, à laquelle la section 9 est consacrée. Si elle parle de certains détails de présentation des adresses (RFC 5952), elle est surtout consacrée à la question des API. En 2011, on peut dire que la grande majorité des machines a IPv6, côté couche 3 (ce qui ne veut pas dire que c'est activé, ni que le réseau le route). Mais les applications sont souvent en retard et beaucoup ne peuvent tout simplement pas communiquer avec une autre machine en IPv6. L'IETF ne normalise pas traditionnellement les API donc il n'y a pas d'API recommandée ou officielle dans ce RFC, juste de l'insistance sur le fait qu'il faut fournir une API IPv6 aux applications, si on veut qu'elles utilisent cette version d'IP, et qu'il en existe déjà, dans les RFC 3493 (fonctions de base) et RFC 3542 (fonctions avancées).
La sécurité d'IPv6 a fait bouger beaucoup d'électrons, longtemps avant que le protocole ne soit suffisamment déployé pour qu'on puisse avoir des retours d'expérience. Certains ont survendu IPv6 en prétendant que, contrairement à IPv4, il avait la sécurité intégrée dès le début et était donc plus sûr. Cette légende vient du fait qu'en théorie, IPsec était obligatoire pour toute mise en œuvre d'IPv6. Ce point n'a jamais été respecté par les implémentations (et puis, de toute façon, avoir IPsec est une chose, l'activer, avec sa complexe configuration, en est une autre). Désormais, depuis la sortie de notre RFC 6434, ce point n'est même plus vrai en théorie, IPsec (RFC 4301) est officiellement simplement recommandé.
Le RFC note donc bien que la sécurité est un processus complexe, qui ne dépend certainement pas que d'une technique magique (« IPsec est intégré donc il n'y a pas de problème de sécurité ») et qu'aucun clair gagnant n'émerge de la liste des solutions de sécurité (IPsec, TLS, SSH, etc). D'autant plus qu'IPv6 vise à être déployé dans des contextes comme « l'Internet des Trucs » où beaucoup de machines n'auront pas forcément les ressources nécessaires pour faire de l'IPsec.
Toutes les règles et recommandations précédentes étaient pour tous les nœuds IPv6. La section 12 expose les règles spécifiques aux routeurs. Ils doivent être capables d'envoyer les Router Advertisment et de répondre aux Router Solicitation du RFC 4861 et on suggère aux routeurs SOHO d'envisager sérieusement d'inclure un serveur DHCP (RFC 6204) et aux routeurs de réseaux locaux de permettre le relayage des requêtes DHCP.
Enfin, la section 13 se penche sur la gestion des réseaux IPv6 en notant que deux MIB sont obligatoires, celle du RFC 4292 sur la table de routage, et celle du RFC 4293 sur IP en général.
Les changements par rapport au RFC 4294 sont résumés dans l'annexe 16. Les deux plus importants, comme déjà noté, sont IPsec et DHCP, un qui descend, l'autre qui monte. Mais on y trouve aussi l'arrivée de SEND (mais en option), celle des options DNS du RFC 6106, et beaucoup de détails et de clarifications.
Date de publication du RFC : Novembre 2011
Auteur(s) du RFC : K. Li (Huawei), B. Leiba (Huawei)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF marf
Première rédaction de cet article le 11 Novembre 2011
Il existe un format standard pour la transmission de rapports d'abus entre acteurs de l'Internet qui permet, par exemple, à des opérateurs de serveurs de messagerie de signaler un spam, et de traiter automatiquement ces rapports. Ce format se nomme ARF et est normalisé dans le RFC 5965. Chaque rapport ARF indique un type d'abus et ce nouveau RFC 6430 ajoute le type not spam, qui permet d'attirer l'attention sur un message classé à tort.
Le format ARF est conçu pour de gros
opérateurs, traitant des millions de messages et d'innombrables
rapports d'abus (spam mais aussi
hameçonnage, distribution de logiciel
malveillant, etc). Avec de tels
volumes à traiter, l'automatisation est nécessaire et c'est ce que
permet ARF. Le type abuse, documenté en section
7.3 du RFC 5965, permet de signaler un message
comme n'étant pas désiré. Mais on a parfois besoin de l'inverse, signaler
qu'un message n'est pas du spam, pour que le destinataire du rapport
ajuste ses filtres. C'est ce qu'introduit notre RFC, suite à une
demande de l'OMA (« Mobile Spam Reporting
Requirements », OMA-RD-SpamRep-V1_0 20101123-C).
Bien sûr, le destinataire du rapport est libre de l'action à entreprendre. Il peut par exemple attendre d'avoir plusieurs rapports équivalents, Si l'opérateur accepte des rapports envoyés directement par les utilisateurs (ceux-ci ne vont pas taper du ARF à la main mais ils peuvent avoir un MUA muni d'un bouton Report as non-spam qui le fait pour eux), il doit tenir compte du fait que les utilisateurs peuvent se tromper (cliquer trop vite) ou même tenter d'influencer le système (mais non, cette publicité n'est pas du spam, laissez-la passer...). La section 4 rappelle donc de traiter avec prudence ces rapports.
Les détails de syntaxe figurent en section 3 du RFC. Voici un
exemple de rapport avec le Feedback-Type: à
not-spam. abusedesk@example.com
signale à abuse@example.net que le message de
someone@example.net n'est
pas, en dépit des apparences, du spam (mettons qu'il ait été envoyé en
réponse à une sollicitation d'un médecin) :
From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Discount on pharmaceuticals
To: <abuse@example.net>
Message-ID: <20030712040037.46341.5F8J@example.com>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="part1_13d.2e68ed54_boundary"
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
This is an email abuse report for an email message received
from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT.
For more information about this format please see
http://tools.ietf.org/html/rfc5965
Comment: I sell pharmaceuticals, so this is not spam for me.
--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report
Feedback-Type: not-spam
User-Agent: SomeGenerator/1.0
Version: 1
--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline
Received: from mailserver.example.net
(mailserver.example.net [192.0.2.1])
by example.com with ESMTP id M63d4137594e46;
Thu, 08 Mar 2005 14:00:00 -0400
From: <someone@example.net>
To: <Undisclosed Recipients>
Subject: Discount on pharmaceuticals
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 02 Sep 2004 12:31:03 -0500
Hi, Joe. I got a lead on a source for discounts on
pharmaceuticals, and I thought you might be interested.
[...etc...]
--part1_13d.2e68ed54_boundary--
Le type not-spam fait donc désormais partie du
registre des types de rapport ARF.
Date de publication du RFC : Novembre 2011
Auteur(s) du RFC : M. Wasserman (Painless Security, LLC), P. Seite (France Telecom - Orange)
Pour information
Réalisé dans le cadre du groupe de travail IETF mif
Première rédaction de cet article le 22 Novembre 2011
Il fut une époque où la machine terminale connectée à l'Internet n'avait typiquement qu'une seule interface réseau. Seuls les routeurs avaient plusieurs interfaces et donc des décisions difficiles à prendre comme « quelle adresse source choisir pour le paquet que je génère ? » Aujourd'hui, les machines les plus ordinaires ont souvent, à leur tour, plusieurs interfaces réseau. Mon smartphone a une interface WiFi et une 3G. Mon ordinateur portable a une interface filaire, une 3G, une Wifi et une Bluetooth. Qui dit plusieurs interfaces dit décisions à prendre. Quel serveur DNS utiliser ? Celui appris via l'interface filaire ou bien celui appris en Wifi ? Par quelle interface envoyer un paquet qui sort de la machine ? La question est d'autant plus difficile que les différentes interfaces fournissent en général des services très différents, en terme de qualité et de prix. Le groupe de travail MIF de l'IETF travaille à normaliser le comportement des machines sur ce point. Son premier RFC (un autre, le RFC 6418, concerne l'exposé du problème) commence par examiner l'état de l'art : que font aujourd'hui les divers systèmes d'exploitation confrontés à cette question ?
Le RFC ne prétend pas couvrir tous les systèmes. Il se contente de ceux que les membres du groupe de travail connaissaient, ceux sur lesquels ils avaient de la documentation et des informations : Nokia S60, Windows Mobile, Blackberry, Android, Windows, et des systèmes à base de Linux.
Comment ces systèmes gèrent cette multiplicité des interfaces
réseaux, se demande la section 2. Une première approche est de
centraliser la gestion des connexions : ce n'est pas l'application qui
choisit l'interface à utiliser, elle passe par un gestionnaire de
connexions (en lui transmettant parfois quelques souhaits) qui choisit
pour elle. Le gestionnaire peut choisir en fonction de la table de
routages (si l'application veut écrire à
172.23.1.35 et qu'une seule interface a une route
vers cette adresse, le choix est vite fait) mais elle ne suffit pas
toujours (que faire si deux interfaces sont connectées à un réseau
privé 172.23.0.0/16 ?). Le gestionnaire doit aussi tenir
compte d'autres facteurs. Le coût est souvent le plus important (prix
élevés de la 3G, surtout en itinérance, par
rapport au Wifi ou au filaire, par exemple).
Une autre solution est que l'application choisisse elle-même, en fonction des informations qu'elle reçoit du système. Certaines applications ont des idées bien précises sur la connexion qu'elles veulent utiliser. Par exemple, sur Android, la plupart des clients SIP refusent par défaut d'utiliser les connexions 3G, les opérateurs y interdisant en général le trafix voix (en violation de la neutralité du réseau). Les deux méthodes (gestionnaire de connexions centralisé et choix par l'application) ne sont pas complètement exclusives. Comme indiqué, on peut aussi avoir un gestionnaire centralisé, mais qui permet aux applications d'indiquer des préférences (« essaie d'éviter la 3G »).
Certains choix sont par contre typiquement réglés par une troisième approche : le faire entièrement dans le système, sans demander à l'utilisateur ou aux applications (section 2.3). Le système rassemble des informations de sources diverses (DHCP, RA (Router Advertisment), configuration manuelle par l'administrateur système) et fait ensuite des choix qui sont globaux au système, ou bien spécifiques à chaque interface. Il n'y a aucune règle commune entre les différents systèmes d'exploitation sur ce plan, et aucun ne semble fournir une solution parfaite.
Par exemple, la configuration DNS voit certains systèmes permettre un jeu de résolveurs DNS différent par interface, avec des règles indiquant quel jeu est choisi. D'autres ont au contraire un seul jeu de résolveurs.
La sélection de l'adresse source est plus « standard
». L'application fournit l'adresse de destination et, lorsqu'elle n'a
pas choisi une adresse source explicité (option
-b de OpenSSH, par
exemple), le système en sélectionne automatiquement une. Pour
IPv6, il existe même une norme pour cela, le
RFC 3484. Un grand nombre de systèmes d'exploitation ont
adapté cette norme à IPv4 et l'utilisent donc pour toutes les familles
d'adresses. En revanche, tous ne fournissent pas forcément un mécanisme
permettant à l'administrateur système d'influencer cette sélection (le
/etc/gai.conf sur Linux). Autre point où les
systèmes diffèrent, certains choisissent l'interface de sortie avant
l'adresse source, d'autres après.
La section 3 est ensuite l'exposé des pratiques des différents systèmes, à l'heure actuelle (une version future pourra changer leur comportement). Ainsi, le système S60 (qui tourne sur Symbian) introduit le concept d'IAP (Internet Access Point) ; un IAP rassemble toutes les informations sur une interface (physique ou virtuelle, dans le cas des tunnels). La machine a en général plusieurs IAP et l'application choisit une IAP au moment où elle a besoin du réseau. Ce choix est motivé par le fait que toutes les IAP ne fournissent pas forcément le service attendu par l'application. Par exemple, l'envoi d'un MMS nécessite l'usage d'un IAP qui donne accès à la passerelle MMS de l'opérateur, qui n'est en général pas joignable depuis l'Internet public. De même, une application qui accède aux serveurs privés d'une entreprise va choisir l'IAP qui correspond au VPN vers l'entreprise.
Ce concept d'IAP permet d'éviter bien des questions. Ainsi, le serveur DNS est indiqué dans l'IAP et, une fois celle-ci choisie, il n'y a pas à se demander quel serveur utiliser. (Reprenez l'exemple du VPN : cela garantira que l'application corporate utilisera un serveur DNS sûr et pas celui du hotspot où le téléphone est actuellement connecté.) De même, il existe une route par défaut par IAP et ce n'est donc pas un problème si deux interfaces de la même machine ont des plages d'adresses RFC 1918 qui se recouvrent (ou même si les deux interfaces ont la même adresse IP).
Comment l'application choisit-elle l'IAP ? Cela peut être fixé en dur dans le programme (cas de l'application MMS, en général), choisi par l'utilisateur au moment de la connexion, ou bien déterminé automatiquement par le système. La documentation de ce système figure en ligne.
Pour Windows Mobile et Windows Phone 7, tout dépend du Connection Manager. Celui-ci gère les connexions pour le compte des applications, en tenant compte de critères comme le coût ou comme la capacité du lien. Les applications peuvent l'influencer en demandant des caractéristiques particulières (par exemple une capacité minimale). Windows met en œuvre le RFC 3484 et l'administrateur système peut configurer des règles qui remplacent celles par défaut. Ce système est documenté en ligne.
Le Blackberry laisse les applications choisir la connexion qu'elles veulent, même s'il fournit un relais pour celles qui le désirent. Cela dépend toutefois de la configuration du réseau (l'utilisation obligatoire du Enterprise Server peut être choisie, par exemple). Les réglages comme le DNS sont par interface et non pas globaux au système. Plus de détails sont fournis dans la documentation.
Et Google Android ? Utilisant un noyau Linux, il partage certaines caractéristiques avec les autres systèmes Linux. Par défaut, il se comporte selon le modèle « machine terminale ouverte » (weak host model, cf. RFC 1122, section 3.3.4.2), mais peut aussi utiliser le modèle « machine strictement terminale » (strong host model). Dans le premier cas, les différentes interfaces réseaux ne sont pas strictement séparées, un paquet reçu sur une interface est accepté même si l'adresse IP de destination n'est pas celle de cette interface. Dans le second, la machine est stricte et refuse les paquets entrants si l'adresse IP de destination ne correspond pas à l'interface d'entrée du paquet.
La configuration DNS est globale (attention, Android ne la note pas
dans /etc/resolv.conf, dont le contenu est
ignoré). Cela veut dire que, dès qu'une réponse DHCP est reçue sur une
interface, la configuration DNS de cette interface remplace la
précédente.
Depuis Android 2.2, le RFC 3484 est géré. (Notez que, à l'heure actuelle, Android ne peut pas faire d'IPv6 sur l'interface 3G.)
La documentation figure dans le paquetage
android.net. Les
applications peuvent utiliser la classe
ConnectivityManager si elles veulent influencer
la sélection de l'interface. Pour cela, le système met à leur
disposition la liste des interfaces et leurs caractéristiques. (Pour étudier un programme qui l'utilise, vous pouvez par exemple regarder les occurrences de ConnectivityManager dans le source Java de CSIPsimple.)
Le RFC se penche aussi sur un système moins connu, Arena, qui utilise également Linux et fournit un gestionnaire de connexions pour choisir les interfaces, avec indication des préférences par les applications. Il sera décrit dans un futur RFC.
Et sur les systèmes d'exploitation utilisés sur le bureau ? Windows est présenté mais sera décrit plus en détail dans un autre RFC. Les systèmes utilisant Linux (comme Ubuntu ou Fedora) partagent plusieurs caractéristiques :
Les systèmes à base de BSD ont en gros les
mêmes caractéristiques. Dans les deux cas, Linux ou BSD, certaines
options permettent de passer outre les informations obtenues par
DHCP. Par exemple, des option modifiers dans le client DHCP OpenBSD offrent la possibilité
d'indiquer des valeurs à utiliser avant, ou bien à la place de, celles
fournies par le serveur DHCP. Mëme chose pour des options comme
-R du client DHCP
Phystech (qui indique de ne pas modifier
resolv.conf) ou comme nodns
et nogateway dans les options de Pump, pour ignorer les résolveurs DNS et la route
par défaut de certaines interfaces. D'autres systèmes disposent
d'options similaires.
Enfin, même si le RFC ne le mentionne que très rapidement, il existe des systèmes de plus haut niveau (comme Network Manager, très pratique pour les machines qui se déplacent fréquemment) dont la tâche est d'orchestrer tout cela, de surveiller la disponibilité des interfaces, de lancer le client DHCP lorsque c'est nécessaire, d'accepter ou de passer outre ses choix, etc.
Voilà en gros la situation actuelle. Prochains efforts du groupe MIF : l'améliorer... Le RFC 6418 donne le cahier des charges de cet effort.
Date de publication du RFC : Novembre 2011
Auteur(s) du RFC : P. Eardley (BT), L. Eggert (Nokia), M. Bagnulo (UC3M), R. Winter (NEC Europe)
Pour information
Première rédaction de cet article le 2 Novembre 2011
Nourri de la vaste expérience de ses auteurs (tous chercheurs et tous ayant écrit des RFC), ce document essaie de combler une partie du fossé entre la communauté des chercheurs et la normalisation, en encourageant ces chercheurs à participer à l'IETF, et en leur expliquant ce à quoi ils doivent s'attendre.
L'Internet est bien issu d'un projet de recherche, ARPANET, et a ensuite intégré un bon nombre de résultats de recherche. Normalement, le monde académique devrait se sentir à l'aise dans celui de la normalisation Internet. Mais ce n'est pas toujours le cas. Le chercheur isolé peut même trouver que l'IETF est une organisation mystérieuse et que le processus de normalisation y est très frustrant. C'est pour guider ces chercheurs que ce RFC leur explique ce nouveau (pour eux) monde.
Optimisme scientiste ou simplement désir de plaire aux lecteurs issus de la recherche ? En tout cas, le RFC commence par prétendre que le développement de nouvelles techniques est dû à la recherche scientifique. Après ce remontage de moral, la section 1 explique pourtant aux chercheurs candidats à un travail de normalisation à l'IETF qu'ils ne doivent pas s'attendre à un chemin de roses. Une SDO a d'autres motivations qu'une université. Dans la recherche, le plus important est qu'une solution soit correcte. Dans la normalisation, les problèmes à résoudre sont ceux du monde réel et le caractère pratique et réaliste de la solution a autant, voire plus d'importance, que sa parfaite correction.
Ainsi, l'IETF adopte souvent des solutions dont les limites, voire les défauts, sont connus, simplement parce que des alternatives « meilleures » ne semblent pas déployable sur le terrain. De même, une bonne solution à un problème intéressant peut être écartée, si ce problème ne se pose tout simplement pas dans l'Internet. Enfin, la normalisation progresse souvent par étapes incrémentales, nécessaires pour un déploiement effectif, et cela peut être jugé peu apétissant par des chercheurs qui veulent s'attaquer aux Grands Problèmes.
On voit ainsi régulièrement des malentendus, où des chercheurs arrivent à l'IETF avec des idées trop éloignées du domaine de l'IETF, ou bien trop générales pour qu'un travail concret (l'IETF normalise des bits qui passent sur le câble...) puisse commencer, des idées qui ne peuvent pas être déployées dans l'Internet d'aujourd'hui, ou encore des idées qui résolvent des problèmes qui ne sont pas, ou pas encore, d'actualité. Sans compter des problèmes moins techniques comme l'hésitation à passer leur bébé à l'IETF (perdant ainsi le contrôle de son évolution), la constatation que la normalisation est très chronophage, ou simplement l'impression qu'on ne les écoute pas réellement.
Cela ne veut pas dire que les chercheurs ne doivent même pas essayer. Bien au contraire, ce RFC doit leur permettre de mieux déterminer si et comment ils peuvent présenter leur travail à l'IETF. Il vient en complément de documents plus généraux sur l'IETF, notamment le fameux Tao (RFC 4677)).
Donc, première question à se poser (en section 2) : est-ce que l'IETF est le bon endroit pour ce travail ? Le RFC suggère deux questions simples aux candidats. Si votre travail était pris en compte :
La première question est une variante du classique « Quel problème essayez-vous de résoudre ? » Après tout, il y a déjà eu des tas de travaux (dont certains normalisés à l'IETF) qui n'ont jamais été déployés. Il est donc raisonnable de se demander si ce travail apportera un bénéfice. Un travail de recherche, même remarquable, n'est pas forcément dans ce cas.
La seconde question, sur les machines à mettre à jour en cas d'adoption de la technique, a pour but de pointer du doigt les problèmes de déploiement. Les chercheurs ont facilement tendance à les ignorer, préférant partir d'une table rase. Dans l'Internet d'aujourd'hui, utilisé par des milliards de personnes et pour qui des investissements colossaux ont été faits, cette approche n'est pas réaliste. Il est donc crucial de se demander « Est-ce que cette nouvelle technique pourra être déployée, et à quel coût ? » Par exemple, est-ce que la nouvelle technique nécessitera de mettre à jour seulement les routeurs, seulement les machines terminales, ou les deux ? Cette analyse est d'autant plus complexe qu'il faudra prendre en compte, non seulement les protocoles, mais également les pratiques opérationnelles et peut-être même certains modèles de business, qui pourraient être remis en cause.
Une fois cette analyse faite, si la conclusion est que le travail semble à sa place à l'IETF, comment convaincre celle-ci de s'y mettre (section 3) ? Il faut trouver le bon endroit dans l'IETF. Celle-ci n'est plus le petit groupe de travail du début, où tout le monde était impliqué dans tous les protocoles. C'est désormais un gros machin, avec des dizaines de groupes de travail différents (eux-même regroupés en zones - areas) et il faut trouver le bon. S'il existe, il faut le rejoindre (l'IETF n'a pas d'adhésion explicite, rejoindre un groupe, c'est simplement s'abonner à sa liste de diffusion). Et s'il n'existe pas ?
Alors, il va falloir construire une communauté d'intérêts autour de la nouvelle proposition. Après tout, la normalisation, contrairement à la recherche, nécessite un accord large et il va donc falloir se lancer dans le travail de persuasion. Le RFC note que cet effort aura des bénéfices, notamment celui d'améliorer la proposition technique, grâce aux remarques et commentaire des participants à l'IETF. Cela oblige également à documenter le protocole d'une manière compréhensible pour les autres (on peut s'inspirer du RFC 4101). C'est à ce stade qu'on peut tenir des réunions informelles (les Bar BoF) pendant les réunions physiques de l'IETF.
Si on n'a pas trouvé de groupe de travail qui convenait, que faut-il faire ? « En créer un ! », vont crier beaucoup de gens. Bonne idée, mais il faut d'abord lire la section 3.4, qui explique les étapes préalables, celles citées dans le paragraphe précédent, et la tenue recommandée d'une BoF (cf. RFC 5434).
Une fois que tout ceci est fait, la situation semble idyllique. L'IETF a accepté de travailler sur la nouvelle technique, un groupe de travail a été créé, il suffit d'attendre tranquillement son résultat ? Mais non. Comme le rappelle la section 4, il faut continuer à suivre le projet. Il faut prévoir pour cela des efforts importants, du temps et de la patience. Les gens qui n'ont jamais travaillé avec une SDO sont presque tous étonnés de la longueur et de la lourdeur du processus. Tout groupe de travail ne produit pas forcément de RFC et le succès va dépendre d'un travail continuel. Bien qu'en théorie, tout puisse se faire à distance, le RFC rappelle qu'une présence physique aux réunions va, en pratique, augmenter les chances de réussite (c'est comme pour les élections, il faut serrer des mains).
Pire, on a parfois l'impression que le processus s'enlise. L'IETF n'a pas de votes et encore moins de chefs qui décideraient tout. Un consensus relatif est nécessaire pour à peu près tout, et l'IETF n'est pas connue pour sa capacité à prendre des décisions... Bref, notre RFC prévient les candidats : deux ans au moins, depuis la création du groupe de travail. Si le projet de recherche qui a donné naissance à la nouvelle technique dure trois ans, cela veut dire qu'il faut commencer le travail de lobbying à l'IETF dès la première semaine du projet, si on veut que la nouvelle technique soit normalisée avant la fin du projet ! Il vaut donc mieux se préparer d'avance à ce que le projet ne soit pas complété par l'auteur lui-même, et soit terminé par d'autres.
Et c'est si tout se passe bien. Mais il y a parfois des chocs de cultures qui ralentissent le projet. Par exemple, le monde de la recherche privilégié la paternité (« l'algorithme X, décrit par Dupont et Durand dans leur article de 2008 ») alors que l'IETF privilégie le travail collectif. Une norme n'appartient pas à son auteur mais à toute la communauté. Il est donc préférable d'avoir une mentalité très ouverte avant de commencer.
Autre point sur lequel le choc des cultures est fréquent : la mise en œuvre de l'idée dans du vrai logiciel qui tourne. L'IETF accorde une grande importance à ce logiciel (le running code), qui montre que l'idée est viable, et que quelqu'un y a cru suffisamment pour dédier une partie de son précieux temps à sa programmation. C'est encore mieux si le programme connait un début de déploiement (le RFC suggère, pour un protocole réseau, d'essayer de le faire adopter dans le noyau Linux, par exemple). Si ces règles semblent contraignantes, il faut se rappeler qu'elles sont dues à de nombreuses expériences douloureuses, de protocoles déployés uniquement sur le papier, et qui avaient donc fait perdre du temps à tout le monde.
Pour rendre ces conseils plus concrets, le RFC contient une section d'exemples, la 5. On y trouve des résumés de l'incorporation dans le processus IETF de deux protocoles issus de la recherche « académique » :
Date de publication du RFC : Octobre 2011
Auteur(s) du RFC : E. Hammer-Lahav, B. Cook
Chemin des normes
Première rédaction de cet article le 1 Novembre 2011
Ce court RFC spécifie une convention qui
permet à un client Web de récupérer sur un
serveur une description formelle de
méta-données sur le site servi (par exemple
l'auteur du site Web, ou bien la licence du
contenu servi). Cela se fait en mettant ces méta-données au format
XRD dans une ressource nommée
/.well-known/host-meta.
Vous pouvez voir le résultat dans le /.well-known/host-meta de mon site, très inspiré de l'exemple
de la section 1.1 du RFC. Il est vraiment minimal et
n'inclut que des méta-données globales (le format
XRD permet également de s'en servir pour des
méta-données locales à une ressource, cf. section 4.2).
Notez que le vocabulaire peut être trompeur. Le RFC 3986 parle de host pour le
example.com de
http://example.com/truc/machin mais ce terme ne
désigne pas du tout une machine. Finalement, le terme marketing flou
de « site » est encore le moins mauvais.
Ce nouveau nom de host-meta a donc été le
premier à être enregistré (cf. section 6.1) dans le registre des ressources
bien connues qui avait été créé par le RFC 5785. (Deux ou trois autres sont venus juste après.)
Pour le client, par exemple un navigateur Web, récupérer les
méta-données consiste juste donc à faire une requête
GET sur le nom
/.well-known/host-meta (section 2). Il obtient en échange un
fichier XML au format
XRD, servi avec le type
application/xrd+xml.
Le contenu du document est détaillé dans la section 3. Ce
vocabulaire XRD a été normalisé par
OASIS et sert à beaucoup de choses très
compliquées. Mais l'accent est mis ici sur son utilisation pour
fournir des méta-données. Tout en gardant le modèle de données de XRD,
le serveur peut envoyer du XML (la syntaxe
habituelle) ou du JSON. Cette dernière syntaxe
est normalisée dans l'annexe A, sous le nom de JRD. On peut l'obtenir
(n'essayez pas sur mon site, il n'est pas configuré pour cela) en
utilisant la négociation de contenu HTTP (champ Accept:
application/json dans la requête) ou en demandant
/.well-known/host-meta.json au lieu de simplement /.well-known/host-meta.
Qui utilise ou va utiliser ces méta-données ? Pour l'instant, les moteurs de recherche ne semblent pas y accéder mais cela viendra peut-être bientôt (Yahoo et Google ont annoncé travailler sur le sujet). La communauté WebFinger est également très impliquée dans ce projet.
Sinon, ce choix d'utiliser une ressource avec un nom spécial (le préfixe
/.well-known a été normalisé dans le RFC 5785) est dû au fait qu'un serveur n'a pas
d'URI qui le désigne globalement et on ne peut
donc pas utiliser les techniques qui attachent les méta-données à une
ressource (par exemple les en-têtes HTTP comme
l'en-tête Link: du RFC 5988), sauf à utiliser des trucs contestables comme de
considérer que /, la racine du site, désigne tout
le site.
Date de publication du RFC : Octobre 2011
Auteur(s) du RFC : R. Housley (Vigil Security), D. Crocker (Brandenburg InternetWorking), E. Burger (Georgetown University)
Première rédaction de cet article le 12 Octobre 2011
Ce très court RFC met fin (provisoirement ?) à un très long et très agité débat au sein de l'IETF. Après de longs efforts, il réussit à réformer une vache sacrée du processus de normalisation des protocoles TCP/IP. Les RFC spécifiant ces protocoles avaient trois étapes sur le chemin des normes. Il n'y en a désormais plus que deux.
D'innombrables documents, cours et articles ont expliqué le
cheminement d'un RFC sur le chemin des normes,
tel que le décrit le RFC 2026. Un premier point
essentiel du RFC 2026 est que tous les RFC ne
sont pas sur le chemin des normes. Ils peuvent être simplement « expérimentaux » ou bien « pour information ». Un deuxième point
essentiel était que le chemin des normes comprenait trois étapes,
chacune marquant une progression vers le statut de norme complète et
achevée. L'étape atteinte par chaque RFC (pas encore adaptée à ce nouveau
RFC) est visible en http://www.rfc-editor.org/category.html.
Ce schéma était simple et bien décrit. Mais il a été peu appliqué en pratique. D'abord, même parmi les participants à l'IETF, peu ont vraiment compris les subtiles nuances entre les trois étapes. A fortiori, à l'extérieur, peu de gens prenaient leurs décisions techniques en fonction des niveaux atteints sur le chemin des normes ! (Je me souviens de réunions d'un groupe de travail anti-spam où la lobbyiste d'AOL pouvait ergoter sans fin sur les niveaux de maturité de normes comme SMTP, uniquement pour donner un habillage pseudo-juridique aux décisions déjà prises par AOL.) Enfin, on constate qu'avancer sur ce chemin était trop pénible. Certaines normes l'ont fait, car elles étaient poussées par un acteur décidé qui avait intérêt à un statut le plus élevé possible mais, dans d'autres cas, personne ne s'en est occupé et des tas de normes très stables et très déployées sont restées à une étape intermédiaire. C'est ainsi que EPP, bien que récent, a atteint l'étape suprême avec le RFC 5730, simplement parce que VeriSign a poussé très fort, alors que HTTP (RFC 2616) est coincé en étape Projet-de-norme, parce que personne n'a le courage de lobbyer pour qu'il avance. Même chose pour SMTP (RFC 5321) qui, comme HTTP, est indubitablement largement déployé et avec succès ! Bref, l'état actuel de ses RFC sur le chemin des normes ne reflète que très peu la qualité, la stabilité, la popularité et la maturité d'un protocole.
L'IETF a donc, non sans douleur, réfléchi depuis plusieurs années à une simplification du processus, en réduisant le nombre d'étapes à deux. Il y a eu de nombreuses discussions à ce sujet, certains voulant en profiter pour faire une refonte complète du système de normalisation à cette occasion. C'est finalement un choix plus conservateur qui a été fait : le changement reste limité. C'est déjà bien qu'il ait lieu, certains commençaient même à être sceptiques quant aux capacités de l'IETF à réformer ses processus.
Le RFC 2026 réclamait, pour bouger de la première étape (proposition de norme), un rapport explicite sur l'interopérabilité des mises en œuvre de la norme. Et pour atteindre la troisième (norme tout court), un déploiement massif était nécessaire. Ces deux critères sont désormais fusionnés en un seul, qui permettra le passage de la nouvelle première étape, à la nouvelle deuxième (et dernière) étape. Il faudrait plutôt dire la seconde étape, d'ailleurs, si on suit les règles du français soutenu, où « deuxième » implique qu'il y a d'autres étapes ensuite.
Les règles précises figurent en section 2. Il n'y a désormais que deux niveaux sur l'échelle :
Lors de son passage de la première à la seconde étape, une norme peut être révisée de façon mineure (c'est bien l'un des buts de ce chemin des normes que de permettre l'amélioration des normes, à la lumière de l'expérience). Mais, si l'utilisation réelle montre des problèmes sérieux, qui nécessitent une révision plus fondamentale du protocole, il faudra repartir de la première étape.
Donc, désormais, pour avancer de la première à la seconde étape, il faudra :
Et pour les RFC actuels, on fait quoi ? La section 2.3 traite de la transition et précise que les RFC à l'étape Norme-tout-court passent automatiquement à l'état Norme-Internet. Ceux à l'étape Proposition-de-norme y restent (rappelez-vous que cette étape n'a pas changé). Et ceux à l'étape (supprimée) Projet-de-norme y restent provisoirement, en attendant une reclassification par l'IESG (qui aura le droit, dans deux ans, de les passer tous, d'autorité, à l'état de Norme-Internet).
Ce RFC supprime également certaines obligations, bonnes sur le principe mais qui, en pratique, bloquaient certains RFC sur le chemin des normes, sans bonne raison (section 3). C'est ainsi qu'il n'est plus nécessaire :
Date de publication du RFC : Novembre 2011
Auteur(s) du RFC : R. Gellens (Qualcomm), J. Klensin
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF yam
Première rédaction de cet article le 16 Novembre 2011
Pendant longtemps, le système de courrier électronique de l'Internet ne faisait aucune différence entre le serveur de messagerie et le simple PC de l'utilisateur. Tous utilisaient le même protocole SMTP, spécifié dans le RFC 2821. Depuis le RFC 2476 et plus encore depuis le RFC 4409, précurseurs de notre RFC 6409, ce n'est plus vrai. Le simple PC doit désormais utiliser une autre solution, la soumission de message.
L'ancienne architecture était raisonnable à l'époque où toutes les machines connectées à l'Internet étaient de gros serveurs gérés par des professionnels. Ceux-ci pouvaient faire en sorte que tout soit correctement configuré. Et, donc les autres serveurs, les MTA pouvaient ériger en principe le "Pas touche" et ne jamais modifier ou contester un message reçu (section 1 du RFC ; en pratique, pas mal de MTA modifiaient quand même le contenu des messages, avec des conséquences négatives).
Aujourd'hui, avec le nombre de micro-ordinateurs non gérés qui sont connectés à Internet, cela n'est plus possible. Le RFC 2476 avait donc séparé les clients SMTP en deux catégories : les MTA qui se connectent au port traditionnel, le numéro 25 et les MUA qui, s'ils veulent envoyer en SMTP, doivent utiliser un autre service, nommé MSA, tournant en général sur le port 587 (section 3.1), et soumis à d'autres règles :
Attention toutefois, la section 8 rappelle que les modifications du message soumis ne sont pas toujours inoffensives et qu'elles peuvent, par exemple, invalider les signatures existantes.
Notre RFC, qui remplace le RFC 4409, qui lui-même remplaçait le RFC 2476, pose en principe que, désormais, les machines des simples utilisateurs devraient désormais utiliser ce service.
La soumission de messages, telle que normalisée dans ce RFC est ses prédécesseurs, a été un grand succès depuis dix ans, notamment depuis trois ans. Le port 25 est de plus en plus souvent bloqué en sortie des FAI (pour limiter l'envoi de spam par les zombies), et la seule solution pour écrire sans passer par le serveur de son FAI est désormais le port 587. La norme technique est sortie il y a désormais treize ans et est particulièrement stable et mûre.
Si vous utilisez Postfix, vous pouvez lire un exemple de configuration de Postfix conforme (partiellement) à ce RFC.
Notre RFC a été développé par le groupe de travail YAM de l'IETF. Ce groupe est chargé de prendre toutes les normes IETF liées au courrier électronique et de les faire avancer sur le chemin des normes, si possible. La soumission de courrier est ainsi devenue « norme tout court » (Full Standard) avec ce RFC 6409. Les changements depuis le RFC 4409 sont décrits dans l'annexe A. Les principaux sont l'importance plus grande de l'internationalisation (section 6.5, qui précise que le MSA peut changer l'encodage), et une mise en garde plus nette contre les risques encourus en cas de modification de messages par le MSA.
Date de publication du RFC : Octobre 2011
Auteur(s) du RFC : R. Barnes (BBN Technologies)
Pour information
Réalisé dans le cadre du groupe de travail IETF dane
Première rédaction de cet article le 28 Octobre 2011
Le projet DANE (DNS-based Authentication of Named Entities, anciennement KIDNS - Keys In DNS), vise à améliorer et/ou remplacer les certificats X.509 utilisés dans des protocoles comme TLS (RFC 5246). Ces certificats souffrent de plusieurs problèmes, le principal étant qu'une Autorité de Certification (AC) malhonnête ou piratée peut créer des certificats pour n'importe quelle entité, même si celle-ci n'est pas cliente de l'AC tricheuse. C'est ce qui s'est produit dans les affaires Comodo et DigiNotar et ces deux affaires ont sérieusement poussé aux progrès de DANE. Ce premier RFC du groupe de travail DANE établit les scénarios d'usage : quels problèmes veut résoudre DANE et selon quels principes ?
Revenons d'abord sur le fond du problème (section 1 du RFC) : lors de l'établissement
d'une session TLS (par exemple en HTTPS), le
client se connecte à un serveur dont il connait le nom (par exemple
impots.gouv.fr, cf. RFC 6125), le
serveur (et, plus rarement, le client) présente un
certificat numérique à la norme X.509 (bien
qu'un certificat PGP soit aussi possible,
cf. RFC 6091). Ce certificat suit le profil
PKIX, normalisé dans le RFC 5280, un sous-ensemble de X.509. Comme ce certificat peut avoir
été présenté par un homme du milieu qui a
intercepté la session (par exemple en jouant avec
BGP ou OSPF), il faut l'authentifier,
sinon TLS ne protégerait plus que contre les attaques
passives, laissant ses utilisateurs à la merci des attaques
actives. Cette authentification se fait typiquement aujourd'hui en
vérifiant que le certificat a été signé par une des plusieurs
centaines d'AC qui se trouvent dans le magasin de
certificats de n'importe quel navigateur Web. Le point important, et qui est l'une des deux
principales faiblesses de X.509 (l'autre étant son extrême
complexité), est que n'importe laquelle de ces centaines d'AC peut
signer un certificat. Ainsi, dans l'affaire
DigiNotar, une AC néerlandaise était piratée, le pirate lui
faisait générer des certificats pour *.google.com
ou *.gmail.com
(alors que Google n'est pas du tout client de
DigiNotar) et ces certificats sont acceptés par tous les
navigateurs. Le pirate a vendu ou donné les clés privées de ces
certificats au gouvernement iranien, qui n'a
plus eu qu'à monter une attaque de l'homme du
milieu (facile lorsqu'on est un état policier et qu'on
contrôle tous les FAI du pays) pour détourner les utilisateurs vers un faux
Gmail, qui présentait un certificat
acceptable. La dictature intégriste pouvait alors lire les messages
et emprisonner ou tuer les opposants. (Le fait que l'attaque venait
d'Iran est établi par les requêtes OCSP des
victimes. Cf. le rapport sur l'opération Tulipe
Noire.)
Identifiée depuis longtemps (mais niée par le lobby des AC ou par
l'UIT, à l'origine de la norme X.509), cette
vulnérabilité a mené au projet DANE. L'idée de base est qu'introduire
un intermédiaire (l'AC) est en général une mauvaise idée pour la
sécurité. Pour reprendre l'exemple ci-dessus, il vaudrait mieux
permettre à Google de prouver sa propre identité. Comme quasiment
toutes les transactions sur l'Internet commençent par une requête
DNS, pourquoi ne pas utiliser la zone DNS
google.com pour y mettre le certificat ? L'idée
est ancienne, mais elle ne suscitait guère d'intérêt tant que le DNS
lui-même n'était pas un tant soit peu sécurisé. Le déploiement rapide
de DNSSEC, à partir de
2009, a changé la donne : mettre des clés
cryptographiques ou des certificats dans le DNS devient réaliste. D'où
la création, en février 2011, du groupe de travail DANE de
l'IETF, chargé de trouver une technique de
sécurité qui marche.
Ce RFC ne donne pas encore de solution (au moment de sa parution, celle-ci est très avancée et a des chances sérieuses d'être publiée en 2012). Il explique les scénarios d'usage, pour aider à évaluer la future solution. Pour décrire ces scénarios, on recourt évidemment aux personae traditionnels :
alice.example.com,Trois scénarios sont ensuite décrits dans la section 3, le œur de ce RFC :
Dans les deux premiers cas, DANE ne fait qu'ajouter de la sécurité à X.509 et on a toujours besoin de l'IGC actuelle. Le troisième est le plus novateur, permettant de remplacer complètement l'IGC, et ne gardant de X.509 que son format de certificats.
Voyons d'abord le premier scénario (section 3.1) , les contraintes sur l'AC. Dans
un cas comme celui des piratages de Comodo ou de DigiNotar, Alice, qui
est cliente d'une autre AC, Charlie, est inquiète du risque d'un faux
certificat pour alice.example.com, émis par l'AC
voyoute. Elle voudrait dire aux visiteurs de
https://alice.example.com/ que les seuls
certificats légitimes sont ceux émis par Charlie. En d'autres termes,
elle voudrait que la vérification du certificat de son serveur parte
du certificat de Charlie, pas de n'importe quel certificat d'AC du
magasin.
Notez que, si Alice dispose d'un tel système, elle peut aussi s'en servir vis-à-vis de Charlie. Lorsqu'elle demande un certificat à ce dernier, il pourrait vérifier qu'Alice l'a bien listé comme AC.
Donc, Alice va mettre dans le DNS un enregistrement qui dit « je suis cliente de Charlie ». Cet enregistrement doit-il être sécurisé par DNSSEC ? La question est toujours très discutée au sein du groupe DANE. A priori, DNSSEC n'est pas impératif puisque cet enregistrement DNS n'est qu'une sécurité supplémentaire : le X.509 traditionnel fonctionne toujours en dessous. D'un autre côté, cette sécurité supplémentaire est très faible si on ne met pas DNSSEC : un attaquant qui peut monter une attaque de l'Homme du Milieu pour détourner vers son propre serveur peut probablement aussi supprimer les enregistrements DANE au passage. Notons aussi que le fait d'exiger la validation X.50 comme avant limite les possibilités d'attaque par un registre DNS. Avec le type 0 (contrainte sur l'AC), un attaquant devrait contrôler à la fois l'enregistrement DNS et l'Autorité de Cértification.
Second scénario, la contrainte sur le certificat (section 3.2),
alias type 1. Alice est cliente de Charlie mais se demande si Charlie
ne va pas émettre d'autres certificats pour
alice.example.com, par exemple parce que les
machines de Charlie ont été piratées. Elle voudrait donc indiquer aux
visiteurs de https://alice.example.com/> que seul
tel certificat est valable. Alice va donc mettre le certificat (ou un
condensat cryptographique de celui-ci) dans le DNS. Comme avec le type
0, toute la validation classique de X.509 est ensuite appliquée. Dans
ce mode, DANE ne fait qu'ajouter une vérification supplémentaire.
Bien plus « disruptive » est la possibilité de se passer complètement des AC et de dire dans le DNS « voici le certificat à utiliser », sans qu'il doit validé par d'autres mécanismes que DNSSEC. Cette possibilité (section 3.3), dite type 2, est l'équivalent des certificats auto-signés actuels, mais avec possibilité de les vérifier (grâce à DNSSEC). Alice se passe alors complètement de Charlie. (Notez que le cas où Alice est cliente de Trent est équivalent, le certificat de Trent n'étant quasiment dans aucun magasin. Alice va alors publier dans le DNS le certificat de Trent et non le sien.)
Notez que ce mécanisme n'empêche pas Bob d'avoir sa propre politique de validation. On pourrait imaginer un Bob suspicieux vis-à-vis de DNSSEC qui n'accepterait que les enregistrements DANE de type 0 ou 1. Ou un Bob qui aurait une liste noire des certificats à qui il ne fait pas confiance, DANE ou pas DANE.
Cette fois, avec le type 2, DNSSEC est absolument
indispensable. Sans lui, il n'y a plus aucune validation du
certificat. Ne publiez donc pas d'enregistrements de type 2 avant
d'avoir vérifié que DNSSEC était correctement déployé et que vous le
maîtrisez parfaitement. Pour la même raison, le type 2 est celui qui
met le plus de responsabilités chez les opérateurs DNS. Si ceux-ci
trahissent ou sont piratés, tout le système est en danger. Mais
rappelez-vous que, contrairement à ce qui se passe pour X.509, le
risque est uniquement dans les prestataires que vous choisissez. Si
vous choisissez d'utiliser un nom de domaine en
.org, vous savez
qu'Afilias peut tout faire rater, mais que ni
l'AFNIC, ni CNNIC n'ont
ce pouvoir. Alors qu'avec X.509, même en choisissant soigneusement son
AC, on peut être victime de n'importe quelle autre AC, qu'on n'a pas
choisi. Donc, conseil pratique, choisissez bien vos prestataires
(registre DNS, bureau d'enregistrement,
hébergeur DNS, etc).
Mais il est clair que DANE donne plus de responsabilité (on peut même dire de pouvoir) aux acteurs du DNS. Ce point est souvent à la base de la plupart des critiques de DANE.
Autre point à garder en tête lorsqu'on évalue la sécurité de DANE : aujourd'hui, avec X.509, le contrôle de la zone DNS donne déjà souvent accès à des certificats (bien des AC ne font pas d'autres vérifications que l'envoi d'un courrier avec un cookie, ou la publication d'un certain enregistrement).
Voilà, vous connaissez l'essentiel sur DANE. la section 4 couvre toutefois d'autres points, moins centraux, sous forme d'une liste de souhaits pour le futur protocole :
Le protocole qui mettra en œuvre ce cahier des charges n'est pas encore terminé. C'est en partie pour cela qu'il n'y a pas à proprement parler de mise en œuvre de DANE même si des expérimentations sont déjà faites.
Pour ceux qui souhaitent approfondir le sujet, j'ai fait un exposé sur la question (avec article détaillé) en novembre 2011 aux JRES à Toulouse.
Date de publication du RFC : Septembre 2011
Auteur(s) du RFC : M. Yevstifeyev
Pour information
Première rédaction de cet article le 19 Septembre 2011
L'expérimentation des ION (IETF Operational Notes, une série de documents IETF plus légers que les RFC) ayant été abandonnée, ce RFC reclassifie officiellement le RFC 4693, qui créait les ION, comme n'ayant qu'un intérêt historique.
Ce nouveau RFC, de même que la décision d'abandon, ne s'étend guère sur les raisons de l'échec et ne tire pas de bilan.
RFC des différentes séries : 0 1000 2000 3000 4000 5000 6000