GuiGui's Show

Résumé : l'utilisation de DNS over HTTPS (DoH) se généralise et on lit beaucoup d'idioties. Je vais essayer de faire moins pire. Je déplore le "tout sur HTTP" dont il est l'énième illustration. Je déplore l'énième réponse technique qu'il tente d'apporter au problème social et politique qu'est la censure. Comme toute parade à la censure, DoH va la pousser plus loin (par IP, par nom en clair dans une connexion chiffré dit SNI), ce qui peut renforcer la centralisation des contenus chez quelques acteurs économiques. DoH s'occupe uniquement de la résolution des noms, donc la vie privée continuera à fuiter, notamment dans les adresses IP de destination et les connexions chiffrées (SNI ; encrypted-SNI est très expérimental), y compris dans la connexion au service DoH (le SNI y apparaît), donc, comme avec toute protection, ne te sens pas excessivement protégé. Par leur nature même, et comme tout service DNS externe, les services DoH publics cassent les vues DNS / split DNS / domaines privés / racines alternatives / TLD alternatifs. Pour un gestionnaire de parc informatique, DoH fait perdre le bénéfice d'une configuration centralisée au niveau du système d'exploitation de la résolution des noms et demande plus (+) de boulot : se tenir informer sur l'usage de DoH par les applications du parc, apprendre à diagnostiquer un service DoH (des outils sont disponibles, mais pas encore empaquetés dans Debian) ; désactiver ou configurer DoH dans chaque logiciel qui l'utilise afin que que la vie privée des utilisateurs ne fuite pas vers un service DoH externe (Mozilla propose CloudFlare par défaut) et afin de rétablir le fonctionnement des vues DNS si besoin ; baisser le TTL lors de migrations (et se préparer à une migration forcée imprévue car DoH = double lame).

DoH, c'est DNS over HTTPS. Pour ceux et celles qui veulent approfondir koikeC : version texte et version vidéo.

Fin février, Mozilla a annoncé qu'après une période de test, elle active DoH par défaut dans Firefox pour les utilisateurs localisés aux États-Unis Source. L'activation par défaut va viendre pour la France. Pas d'annonce des concurrents, mais ils suivront, car le segment marketing « protection de la vie privée » est juteux.

Depuis l'annonce de Mozilla, je vois des imbéciles recommander d'activer DoH partout sans prise de recul (le mimétisme de l'humain me désole). Mes arguments contre une généralisation à outrance de DoH sont les suivants :

• Le "tout sur HTTP" est dangereux pour la liberté de création / d'entreprise. On a eu l'échange de fichiers sur HTTP, puis le mail sur HTTP (webmail), puis la discussion instantanée sur HTTP (FB Messager ou Mattermost ou…) puis… Cela rend plus compliqué le développement de nouveaux protocoles réseaux (genre SCTP), car, puisque tout est sur HTTP, nombre de Fournisseurs d'Accès à Internet et d'administrateurs systèmes et réseaux font de la merde en bloquant / altérant le fonctionnement des autres protocoles ;

  • Si l'on veut prétendument protéger sa vie privée (DoH n'y suffit pas, non) avec du DNS prétendument sécurisé, on utilise DoT (DNS over TLS, du DNS chiffré) au lieu de DoH. Cela présente les mêmes avantages et inconvénients que DoH sauf que DoT sera bloqué sur les réseaux malpropres.
• D'une manière générale (hors DoH), je n'aime pas donner une réponse technique à un problème politique. À ce sujet, je recommande vivement la lecture du livre Pour tout résoudre, cliquez ici. L'aberration du solutionnisme technologique (mes notes). La censure sur Internet est l'un des signes qu'une société humaine va mal. Cela dépasse Internet. Si tu ne peux pas avoir confiance en ton fournisseur d'accès à Internet (FAI), il y a un gros problème. Si tu ne peux pas avoir confiance en ton employeur (pour la connexion à Internet de ton taff), il y a un gros problème. Si tu ne peux pas avoir confiance en ton État, il y a un gros problème. Je préfère d'autres solutions que DoH : augmenter le nombre de FAI de confiance, augmenter la force du prolo face aux patrons (syndicats et/ou coopératives et/ou salaire à vie, etc.), et interdire la censure dans la loi. En gros, je préfère des solutions actives, où l'on se bouge pour nos convictions. Oui, cette réaction est celle d'un bobo eurocentré, mais j'affirme que DoH ne va pas changer la vie des Chinois ou des citoyens des pays en « -stan » : ils ont un problème démocratique plus large que la censure sur Internet. Mais peut-être que DoH n'est pas conçu pour répondre à ce besoin de démocratie et que j'exagère ? On peut aussi voir DoH comme une possibilité, une garantie effective contre la censure, mais alors il ne faut pas le généraliser, mais savoir qu'elle existe et l'utiliser avec parcimonie ;
  
  
• DoH (comme DoT), au motif de lutter contre la censure, va la repousser plus loin, notamment vers de la censure par adresse IP (des services DoH et/ou des contenus). Rien de neuf ni de spécifique à DoH : toute technique de protection de la vie privée / liberté / sécurité déclenche l'apparition de sa parade et l'on retombe sur le vieux débat "bombe nucléaire" (fallait-il l'inventer ou l'interdire ?). Le seul moyen facilement utilisable par le commun des mortels pour contrer une censure par IP est de publier plusieurs contenus derrière une même adresse IP afin que le coût de la censure soit trop élevé : si pour flinguer un serveur DoH, il faut aussi censurer 385 autres services, par exemple, la censure n'aura pas lieu. Le nombre d'acteurs économiques capables de proposer / vendre ce type de service est faible. Cela va donc centraliser encore plus la publication des contenus Internet entre les mains de quelques multinationales. En tout cas, certains y pensent (lire ESNI ci-dessous). Faut-il vraiment aller sur ce terrain ? Si la censure se renforce, il n'y aura pas beaucoup d'humains capables de la contourner, et ça me pose un problème. ÉDIT DU 10/08/2020 À 16 H 55 : la censure poussée plus loin n'est plus uniquement une hypothèse de pensée : Premières observations publiques d'une censure basée sur TLS Encrypted SNI.FIN DE L'ÉDIT DU 10/08/2020 ;
  
  
• Lors de l'établissement d'une connexion chiffrée, le client (navigateur web, gestionnaire d'emails, etc.) indique, en clair, sans chiffrement, le domaine avec lequel il veut discuter. C'est le champ « Server Name Indication » dans TLS. Cela permet d'avoir plusieurs contenus hébergés derrière une même adresse IP accessibles de manière chiffrée, car le client indique à qui il veut parler, donc le serveur peut répondre en présentant le « bon » certificat x509, celui de la ressource demandée. Il est parfaitement possible de censurer des connexions en se basant sur le champ SNI (exemple avec Netfilter, le pare-feu de Linux). DoH peut rien contre ça.
  • Encrypted SNI (ESNI) résout ce problème, mais, même s'il est déjà présent dans Firefox, il est en cours de normalisation, donc sujet à des modifications majeures impromptues (le formalisme retenu a rien à voir entre la première version du brouillon et l'actuelle), et il fonctionne uniquement pour les très rares sites web qui l'ont mis en place à des fins de test (et vu le nombre d'acteurs qui utilisent encore la version 1.0 de TLS, sa généralisation va prendre du temps ‒ ESNI requiert la version 1.3 de TLS ‒). En attendant, utiliser DoH est, au mieux, un joli jouet inutile pour geek, au pire dangereux s'il est utilisé avec trop d'assurance dans un contexte risqué (lanceur d'alerte, dictature, etc.). Rien de spécifique à DoH, toute technique de protection a ses limites, mais ce n'est pas rappelé dans les écrits qui préconisent d'activer DoH fissa en promettant une protection magique de la vie privée ;
    
    
  • Même si l'on active ESNI dans Mozilla Firefox, que l'on valide sa bonne activation avec le testeur de CloudFlare, que l'on configure la paramètre « network.trr.bootstrapAddress » de Firefox, le nom du service DoH utilisé fuite toujours dans le SNI de la connexion TLS au service DoH. C'est normal puisque ESNI repose (actuellement) sur le DNS. On a un problème de poule et d'œuf : il faut aller chercher, dans le DNS, la tambouille pour remplir le contenu du champ ESNI, oui, mais il faut ESNI pour consulter le DNS. Dans certains cas (dictacture), ce SNI peut suffire à te faire vivre un mauvais quart d'heure, au même titre qu'utiliser TOR, même pour consulter un site web officiel des autorités du pays, est considéré comme un acte dissident. Prudence, donc ;
    
    
  • Plus haut, j'écris sur le risque de centraliser les contenus chez peu d'acteurs. À la fin de l'introduction du document de travail d'ESNI, on lit « The design in this document takes a different approach: it assumes that private origins will co-locate with or hide behind a provider (CDN, app server, etc.) which is able to activate encrypted SNI, by encrypting the entire ClientHello (ECHO), for all of the domains it hosts. As a result, the use of ECHO to protect the SNI does not indicate that the client is attempting to reach a private origin, but only that it is going to a particular service provider, which the observer could already tell from the IP address. ». Pas de parano, ESNI pourra être utilisé de manière décentralisée avec DoT / DoH, mais cette introduction indique quand même la cible, le monde envisagé, ce qui n'est pas anodin.

Mon avis n'a pas d'importance, DoH existe, il sera utilisé, donc le gestionnaire d'un parc informatique doit s'y adapter (il faut gérer la merde générée et imposée par autrui, comme d'hab). Qu'est-ce que DoH change, qu'est-ce qu'on en retient, qu'est-ce qu'il faut adapter ? Je me base sur ce que je connais, c'est-à-dire un parc informatique français de plusieurs centaines de machines sans modèle de menace spécifique géré par quelques clampins en sous-effectif.

Un logiciel comme un navigateur web avec DoH activé n'utilise plus le service DNS configuré sur le système d'exploitation que ce soit manuellement (/etc/resolv.conf) ou en utilisant DHCP. Ce qui signifie que l'on pourra constater une différence de comportement entre un logiciel, un navigateur web, d'une part et un autre logiciel d'autre part, notamment les outils de diagnostic (ping, dig, host, nslookup). L'un pourra dire "ce nom n'existe pas" pendant que l'autre dira "chez moi, ça marche".

• Solutions : le savoir et être vigilant, s'équiper d'outils de diagnostic DoH (qui ne sont pas encore empaquetés dans les systèmes) afin de compléter dig/host/nslookup, utiliser DoH dans les outils de diag (curl --doh-url, par exemple), etc.

Une conséquence du point précédent (utilisation, par défaut, d'un service DNS différent de celui voulu par le gestionnaire du parc) est qu'avec DoH, sur une infrastructure qui mélange serveur DNS qui fait autorité et serveur DNS récursif, la mise en cache des noms DNS se fera désormais côté service DoH, et non plus du côté du service DNS interne au parc. Les utilisateurs dépendent de cette mise en cache. La préconisation évidente est d'abaisser le délai de mise en cache avant une migration. Chez nous, je le préconise depuis deux ans, mais nous le faisons peu à l'heure actuelle. Il faudra s'y mettre. En soi, rien de neuf, nous sommes déjà censés travailler ainsi car, sinon, lors d'une migration, on perd d'or-et-déjà les utilisateurs qui ne sont pas connectés à notre réseau c'est-à-dire ceux qui utilisent d'autres services DNS et les machines qui ont un cache local + renvoi vers nos récursifs DNS (Ubuntu a dnsmasq / systemd par défaut, par exemple). DoH augmentera le nombre d'utilisateurs impactés.

• Inutile de désactiver DoH pour contrer cela : travailler selon les règles de l'art (migrations planifiées, abaissement du TTL, etc.) suffit, sauf en cas de migration forcée imprévue (gros incident, etc.).

Certaines organisations fonctionnent avec des vues DNS (aussi nommées « split DNS ») : quand on est connecté au réseau interne, un nom se résout différemment de quand on est à l'extérieur. Comme il est peu probable que l'organisation ait envie d'installer un récursif DoH interne dans l'immédiat (ça apporte rien aux employés puisqu'ils doivent à nouveau faire confiance à leur employeur), cela signifie qu'avec DoH, ce mécanisme de vue DNS ne fonctionnera plus. Là encore, rien de spécifique à DoH : tout service DNS externe a le même comportement.

• Plutôt que de désactiver DoH, on peut renoncer aux vues DNS (elles sont une mauvaise idée) ou regarder si l'application permet de ne pas utiliser DoH pour certains domaines. Mozilla Firefox permet cela avec son paramètre « network.trr.excluded-domains ». Évidemment, ce n'est pas pratique si l'on a un domaine par client, par exemple (la liste devient alors fluctuante donc difficilement maintenable). En revanche, si l'on installe un service DoH interne et si les noms internes se résolvent en adresses IP privées, il faudra changer la valeur de « network.trr.allow-rfc1918 » pour « true »).
  
  
• On notera que tout ce qui est racine DNS alternative (exemple : OpenNIC) ou TLD alternatif (exemple : .42) ne fonctionnera plus si le service DoH utilisé ne les reconnaît pas comme légitimes. Même chose, évidemment, pour tout domaine non publié pour lequel le récursif DNS du parc a été configuré en mode « forward » (exemple : ceux du RIE, Réseau Interministériel de l’État ‒ fiche technique ici ‒).
  
  
• On notera, qu'à l'heure actuelle, le paramétrage par défaut mis en place par Mozilla n'est pas violent : si la résolution DoH échoue, une résolution en utilisant le service DNS configuré sur le système sera effectuée. Cela permet la continuité de fonctionnement des vues DNS, sauf celles dans lesquelles un même nom est associé à une adresse IP (ou autre info) interne et une externe (car alors, la réponse DoH sera reconnue comme valide / légitime, ce qu'elle est, d'un point de vue technique). On notera que cette reprise sur panne (fallback) balance des noms censés rester privés au service DoH utilisé. Notons que cette reprise sur panne va donner l'illusion que tout fonctionne comme avant, que DoH a rien changé, et tout tombera en panne quand Mozilla (ou un autre éditeur) décidera de ne plus fallback.

À l'heure actuelle, il existe peu de services DoH (publics comme privés / internes). Par défaut, Mozilla Firefox utilise CloudFlare DNS. Cela pose un problème de respect de la vie privée et de concentration des activités numériques sur un petit nombre d'acteurs économiques, d'absence d'un contrat et de garantie de fonctionnement, d'ajout d'une dépendance externe, etc. Plutôt que de désactiver DoH, on peut aussi chercher des services DoH éthiques de confiance (mais la question d'absence de contrat et de garantie de fonctionnement revient) ou installer le sien (à plusieurs, sinon ça a aucun intérêt puisque ça revient à faire confiance au service DNS local) . Dans les trois cas, il faut configurer chaque application qui utilise DoH.

Ce qui ressort des points qui précèdent, c'est qu'avec des applications qui utilisent DoH par défaut, le gestionnaire d'un parc informatique perd la maîtrise de son infrastructure : les requêtes DNS ne passent plus par son service DNS interne. Sur ce point, Stéphane Bortzmeyer se trompe. Afin d'illustrer que DoH change rien, il évoque les logiciels qui effectuent déjà, sans DoH, des résolutions DNS sans utiliser le paramétrage du système, c'est-à-dire les logiciels malveillants et les logiciels merdiques, en gros. Or, DoH va concerner les usages légitimes et les rendre plus compliqués à diagnostiquer. On passe de "l'exception était pénible à diagnostiquer" à "le commun, notre taff quotidien, devient pénible à diagnostiquer".

• S'il veut reprendre la maîtrise, le gestionnaire de parc ne doit plus se contenter de configurer un serveur DHCP (et Radvd / DHCPv6), mais aussi chaque application utilisant DoH (Mozilla Firefox, mais aussi l'application bidule, mais aussi l'application truc), alors que nous avons plein d'applications que nous ne configurons pas (ce qui nous rend vulnérable au changement de la conf' par défaut, éternel débat entre implicite et explicite…). On perd en factorisation et l'on gagne en complexité de gestion du parc (se tenir informer du comportement de chaque logiciel, plus (+) de GPO / code dans notre outil de gestion des configurations, etc.). Au fond, rien de neuf, c'est une sorte de prolongement, au niveau logiciel, de la pratique BYOD aux machines gérées (et ça pose les mêmes questions : on autorise ou non ? quelques limites fixe-t-on ?).

Au final, faut-il désactiver DoH sur un parc informatique ? Je n'en suis pas convaincu, sauf à avoir une démarche militante « le tout sur HTTP est merdique » (ce qui va être mon cas à titre perso + continuer à utiliser DoT). Ça dépend du parc.

• Dans le mien, les utilisateurs utilisent beaucoup nos services depuis l'extérieur (avec ou sans VPN, en fonction de la publicité d'une ressource), sur des machines que nous ne gérons pas. En conséquence, nous devons déjà faire ce qu'il faut pour que des services DNS externes, y compris ceux des FAI français, fonctionnent (abaisser le TTL lors d'une migration, par exemple).
  
  
• Sur les machines que nous gérons :
  • Désactiver DoH dans chaque application qui en fait usage ou configurer DoH (choisir un autre service DoH, permettre l'usage des vues, etc.), ça revient environ au même : il faut faire une manip' de configuration dans les deux cas. Désactiver DoH apporte en sus la certitude de ne pas avoir oublié un paramètre et de ne pas avoir à y revenir ;
    
    
  • Faut-il apprendre à diagnostiquer l'intermédiaire supplémentaire que constitue un service DoH ou désactiver DoH et donc avoir un comportement différent entre une utilisation interne et externe de nos services ? Ça dépend du nombre de services accessibles depuis l'extérieur et la fréquence de leur utilisation ;
    
    
  • En fonction des architectures, on peut très bien ne pas utiliser DoH pour le domaine DNS de l'organisation, comme ça le gestionnaire du parc s'évite du boulot, tout en laissant un service DoH externe activé pour le reste (activités pros et persos des employés), ce qui tend à préserver la vie privée (au sens large) de l'employé (mais uniquement à destination de services mutualisés sinon flicage par adresse IP destination, donc le gain est très relatif). mais on dépend alors d'un énième prestataire extérieur avec lequel on n'a pas signé de contrat…