Suivre

Le sachiez-tu ? Les résolveurs d'Orange mentent sur use-application-dns.net, prétendant qu'il n'existe pas.

Ce domaine est le « canari » de Firefox, permettant au FAI de débrayer à volonté et donc de forcer les requêtes DNS vers leur résolveur.

@bortzmeyer

Techniquement j'ai pas compris comment ça marche ?

@LienRag Firefox essaie de résoudre use-application-dns.net avec le résolveur par défaut. Si il récupère NXDOMAIN (domaine non existant), il débraye DoH : plus de sécurité et plus de vie privée. Ce « domaine canari » a été créé par Mozilla en réponse aux exigences des FAI, qui avaient beaucoup lobbyé pour ce  « kill switch ».

@bortzmeyer

C'est pas le contraire de ce qu'est un canari (et de ce que devrait faire Firefox) ?
Firefox donne au FAI la possibilité de bloquer DoH alors que le but de DoH est d'éviter les DNS menteurs des FAI ?

@LienRag @bortzmeyer sauf que les dns ne sont pas forcément fournis par les fai.
Et que faire les requêtes d'un intranet chez cloudflare c'est plutôt crade

@R1Rail @LienRag Le canari avait en effet été marketé en prétendant que c'était pour les zentreprises qui voulaient avoir un résolveur « spécial ». Comme prévu, il est en fait utilisé par les FAI pour forcer le pessage par leurs résolveurs.

@bortzmeyer @R1Rail @LienRag bah j'ai pas plus confiance en cloudflare qui en plus a déjà plein d'informations sur les sites visités

@bortzmeyer @R1Rail @LienRag sauf que tu râles sur ce qui n'est qu'une option par défaut, plus facile à désactiver que mettre son propre resolveur DoH

@LienRag @R1Rail @bortzmeyer Il me semble, ou en choisissant la bonne valeur pour la préférence de firefox, celle qui a un nom à la CO qui n'a rien à voir avec DoH.

@R1Rail @LienRag Meuh non, il y a un menu graphique à la souris convivial GUI user-friendly, maintenant.

@bortzmeyer @R1Rail @LienRag Donc c'est encore plus simple que de monter son propre résolveur DoH qui doit être accessible de partout et en accès public pour fonctionner.

@R1Rail @LienRag « En accès public » Euh, non. (Celui de nos collègues de SIDN est privé, par exemple.)

@bortzmeyer La dernière fois que j'avais regardé c'était le cas; Sans compter que monter un DoH était quand même une bonne grosse saloperie Web bourré de librairies incontrolées.

@R1Rail N'importe quoi. (Et je sais de quoi je parle, moi, je gère un serveur DoH. )

@bortzmeyer @R1Rail Ah ? tu as une doc pour en monter un ? J'ai déjà un nginx et un unbound qui tournent, ça devrait être simple alors ?

@R1Rail ldd trouve 34 bibliothèques (dont la libc et le loader). Pour un programme moderne, ce n'est pas beaucoup :-)

@bortzmeyer @R1Rail Et vu que tu es seul utilisateur sur ton résolveur DoH et que lui fais ses requêtes en clair tu es tout aussi espionnable que sans. Tu n'as rien gagné. Le DoH te protège uniquement parce que tu es au milieu de la foule, ce qui impose la centralisation, et donc un acteur qui lui va être en première place pour t'espionner.

@R1Rail @bortzmeyer C'est plus ou moins vrai, ou en tout cas plus compliqué que ca, donc ca ne tient pas dans un toot.Le serveur DoH utilisé peut être un serveur virtuel/physique dans un nuage, et donc les requêtes qu'il fera seront noyées parmi plein d'autres.Il est toujours important de d'abord spécifier contre quoi on veut se protéger, de là découlent les défenses. Il y a aussi les promoteurs de l'usage de plusieurs résolveurs et répartir les requêtes entre. Sans compter la QNAME minimization

@R1Rail Les requêtes sortantes sont en clair, mais QNAME minimisation + cache améliorent les choses. Et je ne suis pas le seul utilisateur. L'opposition binaire résolveur strictement individuel vs. gros GAFA est absurde.

@bortzmeyer @R1Rail @LienRag Il faut coder à la main l'en-tête. De fait il faut donc un résolveur public.
Sans parler des options liées et de leur (non ?) documentation, mais ça c'est standard chez mozilla

@R1Rail @LienRag Non, c'est faux et tu n'as manifestement pas testé. (La syntaxe standard user@password dans l'URI marche parfaitement avec Firefox et un DoH privé. Pas essayé avec l'authentification par certificat.)

@bortzmeyer @R1Rail @LienRag n'ayant pas de serveur DoH demandant authentification (et ta solution marchera pas chez moi j'ai déjà nginx sur le 443) je ne vois pas comment tester.
Et là on retombe sur le manque de doc accessible de Mozilla

@R1Rail @LienRag Le user@password dans l'URL est tout à fait standard, et ne nécessite donc pas de doc spécifique de Mozilla.

@bortzmeyer @R1Rail @LienRag Pas trouvé sur mon Firefox Android. Je chercherai sur le Linux quand je l'aurai booté.

@bortzmeyer @R1Rail @LienRag Mettre network.trr.mode à 5 (l'option en question) reste plus sûr que l'interface. 🤔 (question de confiance dans la zoli interface — placée dans Général/Paramètres Réseaux et non Vie privée, d'ailleurs — a priori 🤔)

@bortzmeyer @R1Rail @LienRag (en parlant de DoH - et surtout DoT - je vais bientôt ouvrir mon résolveur public. Reste à terminer la doc et 2-3 trucs. #Teasing)

@R1Rail @LienRag @bortzmeyer Mozilla (mais Android fait la même entourloupe) a effectivement décidé de parler de "Trusted Recursive Resolver" (et donc l'option s'appelle "trr" dans leur code), alors que ce n'est pas (juste) le transport qui permet de dire si on fait confiance à la partie en face ou pas (c'est bien pour cà que dans TLS, qui assure à la fois confidentialité et authentification, les deux aspects sont séparés même si très souvent utilisés simultanément)

@R1Rail @LienRag @bortzmeyer Il y a un autre prestataire maintenant, NextDNS, et l'interface de Firefox permet de "choisir": blog.mozilla.org/blog/2019/12/ Ils ont des "critères" pour tout autre prestataire qui veut y être: wiki.mozilla.org/Security/DOH- On notera, parmi diverses choses, l'absence de DNSSEC (on ne peut s'empêcher de penser que cela vient de ceux qui pensent que DoH/DoT remplace DNSSEC en en remplissant le rôle, ce qui est faut, comme TLS ou HTTPS ne remplacent pas DNSSEC)

@R1Rail @LienRag @bortzmeyer Firefox permet de spécifier une liste de domaines à exclure des requêtes DoH vers leur choix de prestataire distant centralisé. Cf support.mozilla.org/en-US/kb/f

@bortzmeyer
Quels arguments avaient-ils pour convaincre Mozilla d'accepter ?
@LienRag

@bortzmeyer Quand Mozilla va s'apercevoir que tous les ISPs feront cela, ils vont choisir d'outrepasser le résultat, comme ils outrepassent déjà totalement unilatéralement la configuration locale sur l'OS. L'approche de Google Chrome sur ce point précis est la seule qui ait du sens et qui laisse réellement l'utilisateur (et pas le développeur de Mozilla) au contrôle de ses requêtes DNS.

@pmevzek L'approche de Chrome n'a quasiment aucun intérêt. Faire du DoH avec le résolveur par défaut, c'est comme faire du TLS avec le serveur Web de Trump : on aura toujours des mensonges, même s'ils sont chiffrés.

@bortzmeyer Ce n'est pas comme ca que je la lis: si l'utilisateur a décidé d'utiliser le serveur DNS X (quel qu'il soit: local, de l'ISP, de l'opérateur tiers Y) *ET* si le navigateur sait que le DNS X supporte DoH/DoT alors il fait du DoH/DoT au lieu de faire du DoUT classique. Mais tout part du fait que 1) l'utilisateur décide quel DNS utiliser et 2) l'application n'écrase pas ce choix par ses propres souhaites, en l'affichant plus ou moins à l'utilisateur.

@bortzmeyer Et pour continuer l'analogie, si le choix est entre "au final je ne sais quel serveur est interrogé et je ne peux le contrôler" et "le serveur web de Trump", la deuxième option n'est pas pire que la première elle est identique: dans la deuxième je sais que ce sont des mensonges, dans la deuxième je ne sais même pas quel niveau de confiance je peux accorder (car je n'ai pas choisi à qui j'accorde ma confiance ou pas).

@bortzmeyer D'autre part, purement techniquement, je suis particulièrement peu persuadé que les canaris sont une bonne idée, surtout en réservant des noms comme ca (et les ancres utilisées pour DNSSEC sont à peine mieux). Apparemment personne n'a retenu les débâcles genre us-cert.gov/ncas/alerts/TA16-1 ; bien sûr un canari sans DNSSEC c'est doublement idiot.

@pmevzek L'absence de DNSSEC est cohérente puisque le canari est prévu pour qu'on puisse mentir (et ainsi débrayer DoH).

@bortzmeyer Oui je me suis mal exprimé. J'ai amendé. Ce qui donne un mauvais signal: DNSSEC c'est bien sauf justement pour des trucs sérieux de configuration de DNS on doit faire sans... Complétement illogique.

@bortzmeyer
J'ai peut être mal compris, mais donc si on force l'utilisation de DoH, il ne regarde plus le canari ?
Ou il regarde forcément le canari avant d'activer ?

Car dans le 2ième cas, si Orange bloque le canari, ils passeront forcement sans DoH.
A moins d'avoir configuré sur sa machine un autre résolveur (donc une minorité d'utilisateur).

@pmevzek

@C_Chell @bortzmeyer support.mozilla.org/en-US/kb/c " If a user has chosen to manually enable DoH, the signal from the network will be ignored and the user’s preference will be honored. " Donc c'est le premier cas: si on force DoH, le canari n'est plus interrogé.

@pmevzek
Ok, merci, j'avais raté la ligne (bon à 23h, cela ne m'étonne pas)
@bortzmeyer

@bortzmeyer Ou plutôt je veux dire qu'un canari pour bien fonctionner doit ne pas avoir DNSSEC ce qui semble clairement donner un mauvais signal en général si d'un côté on dit qu'on va tous mourir sans DNSSEC et de l'autre à la première occasion on le contourne.

@bortzmeyer Vu que chaque resolveur se comporte légèrement différemment (implem, config, mensonges, ...) on pourrait imaginer faire du "resolver fingerprinting" ? Je veux dire lancer 10 requêtes bien senties, et en fonction des réponses te dire si tu es chez Orange, Cloudflare, 8.8.8.8, 9.9.9.9, chez toi, ... Ça existe déjà peut être ?

@mdk Je ne comprends pas le but. Si on veut savoir quel résolveur on utilise, on regarde le /etc/resolv.conf (ou son équivalent Windows).

@bortzmeyer je réfléchisais uniquement a la faisabilité, pas au but, après si on arrive a en faire une page web, avec une explication "bien / pas bien : comment améliorer" ça permettrait (peut être) aux moins geeks d'améliorer leur config. Bon faire des requêtes DNS depuis une page web... j'ignore si a part img onerror on a un meilleur indicateur pour savoir si une requête réussit ou échoue, et ce n'est peut-être pas suffisant pour fingerprinter.

@mdk Ah, je pensais à un programme, pas à une page Web (qui ne peut évidemment pas accéder à la config du résolveur).

Dans ce cas, il faut ajouter un <img src="http://un-cookie-unique.domain.example"/pic.png> et, sur les serveurs faisant autorité pour domain.example, on verra l'adresse IP source du résolveur (qui n'est pas forcément son adresse de service, notamment pour les résolveurs anycastés ; il faudra donc avoir une liste des préfixes de chaque résolveur anycasté)

@bortzmeyer probablement plus fiable que du fingerprinting dans un navigateur oui bien vu.

@bortzmeyer Jusqu'à environ la semaine dernière, il était dans une des listes de blocages d'AdAway

(L'utilisant pour mon blocage de pub Unbound, j'avais un beau NXDOMAIN, corrigé avec la mise à jour des listes)

adaway.org/hosts.txt

@Shaft C'est pas complètement absurde. Le but de ce canari était de dire à Firefox « attention, ce réseau a une résolution spéciale » (ce qui est le cas si tu as un résolveur menteur qui bloque la pub). C'est en tout cas bien plus légitime que ce que fait Orange.

@bortzmeyer Oui.

Bon, je pense ne pas le noir-lister manuellement, mes Pandas étant configurés correctement :)

(Et sinon, je trouve ça toujours agaçant d'être un cobaye sans être expliciter prévenu 🤔)

Inscrivez-vous pour prendre part à la conversation
Mastodon - Gougère Network

Le réseau social de l'avenir : Pas d'annonces, pas de surveillance institutionnelle, conception éthique et décentralisation ! Possédez vos données avec Mastodon !