DNS et vie privée : le travail de l'IETF

Introduction

Malgré les déclarations imprudentes de certains, utiliser l'Internet sans le DNS est presque impossible, sauf si on aime faire des traceroute -n adresse-IP toute la journée. Même si M. Michu ne tape jamais un nom de domaine, et compte sur Google pour tout, les liens renvoyés par Google utilisent le DNS, comme le chargement d'objets supplémentaires (JavaScript, CSS) depuis une page Web. C'est ainsi que le chargement de la seule page d'accueil du site Web de CNN nécessite environ cent requêtes DNS.

Donc, presque tout le monde utilise massivement le DNS. Or, on sait depuis longtemps que la vie privée n'est pas ce qui est le mieux préservé sur l'Internet. Le problème est bien connu et a mené à plusieurs solutions techniques, de PGP à HTTPS en passant par Tor et SSH. Le déploiement de ces solutions s'est sérieusement accéléré depuis les révélations d'Edward Snowden, grâce à qui l'ampleur de la surveillance massive du monde entier est désormais bien connue, même de ceux qui ricanaient au complotisme quelques années auparavant.

Mais peu de réflexions ont porté sur les questions spécifiques du DNS. Aujourd'hui encore, alors qu'on n'imagine pas un site Web un peu sérieux sans HTTPS, la quasi-totalité du trafic DNS passe en clair. En outre, le DNS fait appel à toute une série d'acteurs, bien loin du simpliste modèle « Alice communique avec Bob et Ève peut donc écouter dès qu'elle a accès au réseau situé entre Alice et Bob ». Ces acteurs sont peu connus du grand public, ou même des défenseurs de la vie privée.

1. La situation actuelle

Le DNS repose sur plusieurs acteurs et plusieurs types de serveurs. Regardons d'abord les logiciels. Lorsque M. Michu veut visiter https://impots.gouv.fr/, son navigateur Web (ou, plus exactement, les bibliothèques système chargées par le navigateur) est un « stub resolver », qui va faire des requêtes DNS à un résolveur récursif [2]. Ce dernier, à son démarrage, ne connaît rien [3], à part les adresses IP des serveurs DNS de la racine. Il va alors leur demander « Connaissez-vous l'adresse IP de impots.gouv.fr ? » [4].

Le serveur de la racine va répondre avec les noms des serveurs faisant autorité pour .fr, et le processus continuera, le résolveur posant la même question aux serveurs de .fr, qui vont répondre en donnant les noms des serveurs de noms de impots.gouv.fr [5]. Une fois que les serveurs de noms faisant autorité pour impots.gouv.fr sont connus, le résolveur leur pose la question « Connaissez-vous l'adresse IP de impots.gouv.fr ? » et il obtient cette fois l'adresse IP souhaitée en réponse. En outre, cette information est gardée en mémoire (le cache) pour accélérer les requêtes successives).

On voit que quatre serveurs ont vu la requête passer (sans compter les Ève qui écoutaient sur le câble), le résolveur, le serveur racine, celui de .fr  et celui de impots.gouv.fr. Ces serveurs peuvent être gérés par différentes organisations, ou sous-traités. Voici, avec tcpdump, ce que voit un serveur DNS faisant autorité (l'adresse IP source a été modifiée, ainsi que le TLD utilisé) :

On note dans cet exemple que le nom demandé peut être très révélateur (ici, on sait qu'il s'agit d'un utilisateur de BitTorrent).

Une des difficultés de l'analyse de sécurité du DNS est la complexité de l'écosystème. Il y a les registres, qui gèrent notamment les TLD comme .fr, il y a les BE [6], qui sont des intermédiaires obligatoires entre l'utilisateur et la plupart des registres, il y a les hébergeurs des serveurs DNS, qui peuvent être les BE, mais pas forcément...

En janvier 2015, la révélation du programme NSA « MoreCowBell » avait montré que les vulnérabilités du DNS ne sont pas purement théoriques. Elles sont effectivement exploitées par des organisations puissantes et sans scrupules.

Mais il faut aussi noter qu'il existe des utilisations éthiques de l'observation du trafic DNS. L'une des plus connues est le « passive DNS », qui consiste à enregistrer les réponses DNS des serveurs, de façon à constituer une base historique du contenu du DNS. Ces bases « Passive DNS », dont la plus connue est DNSDB, sont très utiles pour les chercheurs et pour les praticiens de la sécurité. Comme seules les réponses sont gardées, ni les questions, ni l'adresse IP de la source, elles ne sont pas des attaques dramatiques contre la vie privée, mais elles peuvent néanmoins être vues avec prudence.

2. L'approche IETF

À sa réunion de Vancouver, en novembre 2013, quelques mois après les révélations de Snowden, l'IETF [7] s'est engagée à « durcir l'Internet » contre la surveillance massive. Cet engagement s'est notamment traduit par la publication du RFC 7258 « Pervasive Monitoring Is an Attack » [8] et la création de la liste de diffusion PerPass, chargée d'étudier les points où les protocoles Internet ne protégeaient pas assez la vie privée, avec la possibilité, au minimum de documenter ces faiblesses, au maximum de les réparer.

Avant même la publication des documents de la NSA, l'IETF travaillait déjà sur le RFC 6973 « Privacy Considerations for Internet Protocols », qui exposait aux concepteurs de protocoles Internet comment mieux intégrer les préoccupations de vie privée dans ces protocoles. Un tel document comble un retard de l'IETF, où la culture dominante était plutôt de transparence totale des communications (ce qui a clairement l'avantage de faciliter le déboguage et les activités opérationnelles) et où les préoccupations de vie privée étaient souvent traitées avec désinvolture.

Concernant le cas du DNS, les efforts au sein de l'IETF se focalisent désormais sur trois axes, dans deux groupes de travail différents :

- Dans le groupe de travail DPRIVE, on travaille pour documenter le problème. On a vu que, jusqu'à présent, très peu de gens ont travaillé sur les problèmes de vie privée liés au DNS [9].

- Dans le même groupe de travail DPRIVE, plusieurs propositions pour chiffrer le trafic DNS, de manière à empêcher Ève de le lire. DPRIVE est spécialisé dans les problèmes de vie privée.

- Au contraire, dans le groupe de travail DNSOP, l'activité se répartit entre un grand nombre de travaux sur le DNS, dont l'un d'eux, la minimisation des données, concerne la vie privée. La répartition du travail entre DPRIVE et DNSOP se fait sur la base du fait que la charte du groupe DNSOP ne permet pas de changer de manière significative le protocole, ce que ferait sans doute le chiffrement.

D'autres possibilités d'amélioration de la vie privée dans le DNS ont été envisagées, mais n'ont pas fait jusqu'à présent l'objet d'un réel travail à l'IETF. C'est le cas de la proposition d'encourager les utilisateurs à avoir un résolveur/cache sur leur propre machine, pour limiter la quantité de requêtes qui sort.

3. Décrire le problème

Le premier travail est donc de décrire le problème. C'est qu'il ne faut pas se faire d'illusions : l'Internet n'est pas architecturé autour de la protection de la vie privée. Nos activités en ligne laissent des tas de traces, et le travail de l'IETF est d'améliorer l'Internet, pas de le refaire en partant de zéro. Donc, dans bien des cas, l'activité actuellement en cours visera à documenter les problèmes, pour que les utilisateurs puissent faire des analyses de risque sérieuses, et les éventuelles solutions resteront loin dans le futur. Le RFC 6973 a ainsi donné l'exemple, dans sa section 8, consacrée à l'analyse du service de présence, qui permet d'annoncer sur l'Internet si on est disponible ou pas, par exemple pour être contacté en messagerie instantanée. Un tel service est forcément très indiscret, son but même étant de distribuer des informations très personnelles à l'extérieur. Le RFC 6973 ne fournit donc pas de solutions, mais il analyse le service de présence et pointe des problèmes qui n'étaient pas forcément évidents au premier abord (par exemple, pourquoi la présence ne peut pas se faire en pair-à-pair et nécessite un serveur externe à qui on doit faire confiance).

Ce travail a donné naissance à l'Internet-Draft draft-ietf-dprive-problem-statement [10] « DNS privacy considerations ». Suivant l'esprit de la section 8 du RFC 6973, ce document prend bien soin de ne pas mentionner les solutions, uniquement de décrire le problème, les menaces et le rôle des différents acteurs. À noter qu'il n'est pas prévu à l'heure actuelle de le compléter par un document « cahier des charges », décidant des critères de choix des solutions. Certains groupes de travail à l'IETF ont écrit de tels cahiers des charges, mais cette démarche est contestée. Le projet « DNS et vie privée » aura donc uniquement une description du problème et une ou plusieurs solutions (pas forcément incompatibles entre elles) qui sont présentées dans les sections suivantes.

4. Chiffrer ses données

Face au risque d'une écoute par une tierce partie, la célèbre Ève, la solution la plus souvent citée est évidemment le chiffrement. Tout le monde ne la voit pas avec enthousiasme. Il faut se rappeler que le DNS est une infrastructure vitale. Tout problème dans le DNS revient à stopper l'Internet entier. Or, ajouter de la complexité, et une nouvelle couche logicielle, augmente les risques d'un tel problème. Et puis le chiffrement empêche les écoutes (c'est son but) et peut donc rendre plus compliquées certaines activités comme le déboguage, ou comme la collecte de réponses DNS à des fins opérationnelles [11]. Ensuite, le chiffrement a des conséquences en termes de performances. Le DNS est un service à très faible latence : une question entraîne immédiatement une réponse. Il n'est donc pas question d'utiliser un protocole de chiffrement qui, par exemple, nécessiterait avant chaque requête, un échange de plusieurs paquets, pour se mettre d'accord sur les paramètres cryptographiques et les clés. Enfin, le DNS fonctionne aujourd'hui surtout sur UDP et il y a bien moins de déploiements opérationnels du chiffrement avec UDP qu'avec TCP.

Sur le papier, il existe de nombreux mécanismes pour chiffrer le trafic DNS. On peut les classer en trois catégories :

- Faire le chiffrement dans une couche plus basse que le DNS, typiquement avec IPsec. On résout ainsi le problème de la confidentialité du DNS (et bien d'autres en même temps).

- Développer un protocole de chiffrement spécifique au DNS, ce que font DNScurve ou Confidential DNS.

- Utiliser TLS [12].

L'absence d'un déploiement universel d'IPsec condamne la première solution. Il faut ajouter qu'elle soulève des problèmes d'œuf et de poule importants, par exemple si les clés IPsec sont mises dans le DNS (RFC 4025).

La deuxième catégorie, un protocole spécifique, a l'avantage qu'on peut concevoir un protocole simple, optimisé pour le DNS. D'un autre côté, l'expérience des protocoles cryptographiques montre que concevoir un tel protocole n'est pas facile (il y a bien plus de faiblesses exploitables dans les protocoles que dans les algorithmes cryptographiques). Et on peut se demander si c'est une bonne utilisation des ressources de l'IETF que de développer encore un autre protocole de cryptographie alors qu'il en existe déjà plusieurs.

Pour la troisième catégorie, l'utilisation de TLS (RFC 5246), les arguments sont symétriques. On a l'avantage d'un protocole existant, éprouvé, que les administrateurs système connaissent bien, et qui est mis en œuvre dans de nombreux logiciels. D'un autre côté, TLS est complexe, et a déjà connu de nombreux bogues [13], en partie en raison de sa complexité. Néanmoins, il semble qu'à l'heure actuelle, cette solution soit préférée.

TLS est conçu pour fonctionner sur TCP. Il existe une variante pour UDP, nommée DTLS (RFC 6347), qui est notamment utilisée par WebRTC. Se servir du TLS normal, celui sur TCP, marquerait un important changement pour le DNS, le passage d'un trafic très majoritairement UDP à un trafic partiellement TCP. Est-ce une bonne idée et est-ce réaliste ? D'abord, indépendamment du chiffrement, la tendance lourde du DNS est bien d'utiliser plus souvent TCP [14]. Le RFC 5966 posait déjà comme principe que toute mise en œuvre du DNS devait pouvoir utiliser TCP et son successeur, actuellement à l'état d'« Internet-Draft », va plus loin en demandant que cette gestion de TCP se fasse au même niveau de qualité que celle d'UDP. Est-ce contradictoire avec ce que j'ai dit plus haut sur l'importance d'un service à faible latence ? Non, car il n'est évidemment pas question de faire une connexion TCP par requête DNS : la latence, et la consommation de ressources, seraient insupportables. L'idée est d'avoir des connexions TCP persistantes entre les serveurs, établies à la demande et supprimées lorsqu'elles ne sont plus utilisées, ou bien lorsque le serveur veut économiser des ressources. Le successeur du RFC 5966 imposera quelques améliorations à l'utilisation de TCP pour le DNS, notamment la possibilité de ne pas répondre aux questions dans l'ordre où elles sont posées (afin d'éviter qu'une question lente ne bloque une rapide) [15].

À l'heure actuelle, la proposition de chiffrement du DNS qui semble avoir le vent en poupe à l'IETF est celle d'ingénieurs de Verisign et de l'ISI, décrite dans l'Internet-Draft draft-hzhwm-dprive-start-tls-for-dns (et autrefois nommée T-DNS). Son idée de base est d'utiliser le protocole TLS existant, et de le faire sur TCP.  Cela nécessite donc un passage du DNS d'UDP à TCP, ce qui, comme indiqué plus haut, va sans doute dans le sens de l'histoire.

Une autre proposition repose sur un nouveau protocole. « Confidential DNS », décrit dans l'Internet-Draft draft-wijngaards-dnsop-confidentialdns, fonctionne sur l'UDP existant.

Beaucoup d'autres propositions ont été faites, la plupart vite abandonnées. Notez que je ne présente ici que ce qui a été soumis à l'IETF, et il existe au moins un système de chiffrement de la communication, DNScurve + DNScrypt, que ses auteurs n'ont pas proposé à un organisme de normalisation.

Tous ces protocoles font face aux mêmes problèmes : les deux les plus importants sont la récupération, de manière sécurisée et prouvée, de la clé publique du correspondant, et le problème des « middleboxes ». Le premier est un problème classique de la cryptographie : si on croit chiffrer pour son correspondant, alors qu'on chiffre pour un Homme du Milieu qui s'est mis sur le trajet, le chiffrement ne sert pas à grand-chose. Un chiffrement sans authentification sérieuse du correspondant ne protège que contre un observateur purement passif. Ce problème est difficile et n'a pas de solution idéale, notamment pour des raisons d'œuf et de poule, puisque le DNS est indispensable à la plupart des solutions. T-DNS remet le problème à plus tard (quel certificat X.509 utiliser ?), Confidential DNS propose d'utiliser DNSSEC [16], ce qui ne marche pas pour les premières requêtes (on doit donc commencer en clair, le temps d'avoir validé la clé trouvée dans le DNS).

Tout aussi sérieux, le problème des middleboxes, ces boîtiers situés sur le trajet de la plupart des connexions Internet (routeurs NAT, pare-feu, IPS, etc.), et qui interfèrent avec beaucoup de protocoles, menant à une ossification de l'Internet. Déployer un protocole de transport autre que UDP ou TCP, ou même simplement un nouveau protocole applicatif sur un autre port que 80 ou 443, devient de plus en plus difficile. Ainsi, chiffrer le DNS sur le port 53 peut poser un problème si un pare-feu fait du DPI et, examinant le contenu, en déduit que ce n'est pas du DNS, et coupe la communication (c'est pour cela que T-DNS propose un nouveau port, dont il n'est pas sûr du tout qu'il soit ouvert partout, ce qui amène à compléter ce nouveau port d'une solution sur le port 53 traditionnel).

Enfin, il y a le problème des performances, puisque le DNS nécessite une très faible latence. T-DNS a fait l'objet d'une étude quantitative poussée, décrite dans [ISI-TR-688].

5. Minimiser les données

La protection de la vie privée, quand elle est bien faite, marche sur deux jambes : mieux protéger les données (chiffrement) et avoir/envoyer moins de données. Les deux sont nécessaires, notamment parce qu'elles ne protègent pas contre les mêmes acteurs. Le chiffrement protège contre un tiers qui écoute les communications entre ordinateurs, mais il ne protège pas contre un relais qui reçoit légitimement les données, mais les communique ensuite à l'extérieur [17]. La minimisation des données est donc un composant indispensable de toute solution de préservation de la vie privée.

On a vu que les résolveurs DNS, aujourd'hui, envoient aux serveurs faisant autorité la question complète. Par exemple, si l'utilisateur se connecte à vip.tracker.thepiratebay.org, les serveurs de la racine voient le nom entier (qu'on peut considérer comme sensible...) alors que leur demander seulement org suffirait, puisque c'est tout ce que la racine connaît, de toute façon.

Le principe de la proposition « QNAME minimisation », dans l'Internet-Draft draft-ietf-dnsop-qname-minimisation, est donc de réduire la question posée par le résolveur DNS, le QNAME (« Query Name ») au strict nombre de composants nécessaires. Ainsi, pour miscmag.com, on n'enverra aux serveurs de la racine que la demande pour com.

C'est un peu plus difficile à faire que cela en a l'air, car les frontières des zones DNS ne sont pas apparentes dans un nom de domaine. Ainsi, dans mail.ssi.gouv.fr, il n'y a pas de frontière de zone (« zone cut ») entre gouv et fr : ce sont les mêmes serveurs de noms. Un résolveur DNS qui met en œuvre la « QNAME minimisation » doit donc avoir un algorithme spécial pour trouver les frontières de zones. Heureusement, cet algorithme est déjà implémenté dans la plupart des résolveurs, car il est également indispensable pour DNSSEC [18].

Outre cette « QNAME minimisation », un autre moyen de minimiser les données envoyées (mais qui n'a pas fait l'objet de beaucoup de discussions à l'IETF), serait d'encourager l'utilisation d'un résolveur local [19]. C'est probablement ce que feront de plus en plus d'utilisateurs, en raison des différentes manipulations du DNS, comme le filtrage administratif en France. Le cache de ce résolveur fait qu'on envoie moins de données. On est ainsi protégé contre les indiscrétions du résolveur mais, par contre, on l'est moins contre les serveurs faisant autorité puisque ceux-ci voient une adresse IP plus spécifique que celle du gros résolveur du FAI, adresse qui peut même être individuelle. Une solution possible est d'avoir son résolveur local et de faire suivre les requêtes non résolues [20] à un gros résolveur, comme celui du FAI [21]. Le cache du résolveur local limitera l'envoi de données à l'extérieur, et le passage par le gros résolveur externe masquera l'adresse IP du réseau ou de la machine locale vis-à-vis des serveurs faisant autorité. Du point de vue de la confidentialité, c'est la meilleure solution [22].

6. Un système alternatif ?

Vu les difficultés à ajouter la protection de la vie privée au DNS existant, sans tout casser au passage, on peut se demander s'il ne vaudrait pas mieux laisser tomber et passer à un système alternatif de résolution des noms en données. L'idée est séduisante, mais elle se heurte à deux gros obstacles. Le premier est la difficulté à remplacer un système existant et largement déployé. Les enthousiastes qui sous-estiment le poids de l'existant, des investissements déjà réalisés, et des gens déjà formés, risquent d'être déçus.

Le second obstacle est plus subtil, c'est la difficulté à faire un cahier des charges : tout le monde dit qu'il faudrait faire un système « meilleur » que le DNS, mais peu de gens explicitent ce que cela veut dire, avec les choix souvent douloureux qu'il faut faire. Par exemple, l'ancien système de nommage de UUCP (avant qu'il passe au DNS) était complètement pair-à-pair et ne dépendait d'aucune autorité centrale. N'importe qui pouvait créer une machine nommée « gandalf » sans rien demander à personne. Mais ce système n'assurait pas l'unicité des noms. Il pouvait y avoir plusieurs « gandalf ». Avant le passage au DNS, le problème avait été résolu par les « maps », qui introduisaient une certaine dose d'arborescence, en créant des serveurs bien connus à partir desquels on définissait un chemin. Cela illustre bien les questions à se poser avant de passer à un système « meilleur » : est-on prêt à abandonner l'unicité des noms, par exemple ?

Il y a aujourd'hui environ trois propositions de remplacement du DNS qu'on peut qualifier de sérieuses : GNUnet, Namecoin et les .onion de Tor. Aucune ne semble une alternative réaliste à court ou même à moyen terme, mais il est intéressant de suivre leurs développements futurs.

Conclusion

En mars 2015, juste après la réunion IETF de Dallas, l'état actuel de la normalisation est le suivant :

1. Le document de description du problème, l'Internet-Draft draft-ietf-dprive-problem-statement a passé avec succès le « Working Group Last Call » ce qui veut dire que, approuvé par le groupe de travail, il passe à l'IESG [23], qui prendra la décision de publication en RFC. Sauf grosse objection imprévue de l'IESG, sa publication est désormais surtout une question purement éditoriale.

2. La discussion est toujours vive sur le choix du mécanisme de chiffrement. L'ex T-DNS (draft-hzhwm-dprive-start-tls-for-dns) semble favori, mais rien n'est garanti. Il y a même désormais une discussion secondaire sur les critères de choix (Internet-Draft draft-am-dprive-eval).

3. La « QNAME minimisation » devrait faire l'objet d'un « Working Group Last Call » à brève échéance, qui semble devoir se dérouler sans problème. Notez que le statut attendu pour le document publié sera « Expérimental » [24], ce qui fait que sa mise en œuvre dans les résolveurs nécessitera un certain lobbying.

Je sais, les processus IETF sont longs et compliqués. Mais c'est le prix à payer pour obtenir un large consensus.

Bibliographie

[MORECOWBELL] Grothoff, C, Wachs, M, Ermert, M, Appelbaum, J, « NSA's MORECOWBELL : Knell for DNS », 2015, https://gnunet.org/mcb

[ISI-TR-688] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A. and N. Somaiya, « T-DNS : Connection-Oriented DNS to Improve Privacy and Security », 2014, ftp://ftp.isi.edu/isi-pubs/tr-688.pdf

Notes

[1] Domain Name System

[2] Dit aussi résolveur/cache ou résolveur complet. Un des problèmes de l'analyse de sécurité du DNS est l'absence d'un vocabulaire normalisé, pour bien des fonctions. Un travail est en cours à l'IETF, dans le groupe de travail DNSOP, pour normaliser la terminologie.

[3] On parle d' un « cache froid ».

[4] Bien des vidéos et des documentations de type « Internet pour les nuls » montrent le résolveur demander uniquement les serveurs de noms de .fr. mais c'est inexact, ce n'est pas ainsi que fonctionne le DNS.

[5] Et non pas de gouv.fr, l'exemple a été choisi exprès.

[6] Bureau d'Enregistrement, « registrar » en anglais.

[7] Internet Engineering Task Force, l'organisme qui fait les normes techniques de l'Internet, « de la couche 3 à la couche 7 ».

[8] Disponible en http://tools.ietf.org/html/rfc7258. Si vous voulez accéder à un RFC de numéro NNN, mettez juste http://tools.ietf.org/html/ devant rfcNNN.

[9] La bibliographie de l'Internet-Draft draft-ietf-dprive-problem-statement contient une liste d'exceptions à cette constatation.

[10] Disponible en https://tools.ietf.org/html/draft-ietf-dprive-problem-statement Tout Internet-Draft peut être récupéré dans une jolie version HTML en préfixant son nom par https://tools.ietf.org/html/.

[11] Comme le « Passive DNS »

[12] Transport Layer Security

[13] Portant en général des noms charmants, comme Beast, Crime, Lucky Thirteen... Attention, je parle bien des failles du protocole TLS, pas des bogues de certaines implémentations, comme HeartBleed.

[14] http://www.bortzmeyer.org/dns-over-tcp.html

[15] Les réponses sont identifiées par un « Query ID », pas par leur ordre d'arrivée.

[16] DNS Security Extensions, un mécanisme de signature cryptographique des données DNS.

[17] Songeons au programme PRISM : chiffrer vos communications avec Gmail ne sert à rien si Google fournit un accès général à la NSA.

[18] Le résolveur doit envoyer les requêtes pour le type DS (« Delegation Signer ») à la zone parente.

[19] Local à la machine de l'utilisateur, ou bien local à son réseau de confiance. Notons au passage qu'utiliser un résolveur lointain comme Google Public DNS ou OpenDNS est particulièrement dangereux pour la confidentialité.

[20] Plus précisément : pas résolues localement, car pas encore vues par le résolveur local, donc pas dans son cache.

[21] Si votre résolveur local est un Unbound, la directive à utiliser pour faire suivre au résolveur 192.0.2.20 sera :

[22] Par contre, on n'est alors plus protégé contre les résolveurs menteurs. La sécurité, ce sont toujours des compromis.

[23] Internet Engineering Steering Group, la direction technique de l'IETF

[24] Rappelez-vous que tous les RFC ne sont pas des normes. Le statut « Expérimental » est prévu pour les propositions dont on n'est pas encore sûr qu'elles marcheront bien dans l'Internet réel.