Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

Apple va supporter DNS over HTTPS (DoH) et DNS over TLS (DoT)... à sa manière

À vouloir trop en faire...
Logiciel 4 min
Apple va supporter DNS over HTTPS (DoH) et DNS over TLS (DoT)... à sa manière

Bonne nouvelle : Apple va à son tour permettre le chiffrement des échanges entre un appareil et un résolveur DNS. Il ne gère d'ailleurs pas un protocole mais deux, avec différentes implémentations selon les besoins. Et c'est peut être bien là que ça coince... car certaines risquent de créer plus de problèmes qu'elles n'en résolvent.

Le DNS est l'une des rares briques de l'internet à n'avoir pas encore fait l'objet d'un recours massif au chiffrement, mais cela change peu à peu. On l'a vu à travers les choix opérés par différents navigateurs, de Chrome à Firefox, mais aussi d'éditeurs comme Google qui a misé sur DNS over TLS (DoT) sur  Android ou encore Microsoft qui se prépare à supporter DNS over HTTPS (DoH) dans la prochaine version de Windows 10.

Sur le sujet, on attendait la réaction d'Apple, silencieuse alors qu'elle n'est pas la dernière lorsqu'il s'agit de mettre en avant son intérêt pour la sécurité et le respect de la vie privée des utilisateurs. Profitant de sa WWDC 2020, elle sort de son mutisme : DoH et DoT seront supportés par ses systèmes d'exploitation.

Une intégration qui ne se fera pas vraiment de manière classique.

Notre dossier sur DNS over HTTPS :

Vers des applications de gestion des DNS

Après avoir rappelé les bases du DNS et en quoi un chiffrement des requêtes/réponses pouvait être important, l'ingénieur Tommy Pauly dévoile le choix de l'entreprise : là où certains ne misent que sur DoT ou DoH, ses systèmes gèreront les deux, à la convenance des développeurs, éditeurs de services et peut être des utilisateurs.

Il ne s'agira pas d'un simple paramètre réseau, tout du moins pas de manière aussi directe que l'on pourrait s'y attendre. Il y aura deux méthodes exploitables. La première s'appliquera à l'ensemble du système, donc de toutes les applications. Elle s'activera via un profil MDM (Mobile Device Management, pour la gestion de flotte en entreprise) ou une application désignée comme gestionnaire de DNS, comme c'est déjà le cas avec les VPN.

  • Apple DNS DoT DoH
  • Apple DNS DoT DoH
  • Apple DNS DoT DoH
  • Apple DNS DoT DoH
  • Apple DNS DoT DoH
  • Apple DNS DoT DoH
  • Apple DNS DoT DoH
  • Apple DNS DoT DoH
  • Apple DNS DoT DoH
  • Apple DNS DoT DoH

Un éditeur de service proposant des résolveurs DoT ou DoH pourra ainsi y donner accès à travers une application exploitant le framework NetworkExtension, qui permet de modifier plusieurs paramètres réseau. Il pourra préciser via des règles quand utiliser ou non le chiffrement des DNS : réseau mobile et/ou Wi-Fi, sur tel ou tel SSID, etc.

Apple précise que pour éviter tout souci, certaines exceptions sont appliquées automatiquement, comme la détection de portails captifs ou de VPN (dont le résolveur DNS sera utilisé plutôt que celui du système). Chaque règle pourra être appliquée globalement ou seulement pour certains domaines. La transparence des applications à ce sujet sera vitale.

En cas de blocage du chiffrement des DNS (notamment dans le cas de DoT) par le réseau, une alerte sera affichée.

Une gestion possible application par application

L'autre solution est celle redoutée par beaucoup, puisqu'elle permet à chaque développeur de préciser le résolveur DNS à utiliser pour son application, par défaut ou pour des requêtes bien spécifiques, via NWParameters.PrivacyContext

On imagine dès lors les abus possibles, si Google venait à forcer ses propres serveurs dans Chrome par exemple, une banque les siens en prétextant une question de sécurité, une application malveillante des DNS menteurs, etc. Malheureusement, il ne semble pas prévu qu'une alerte vienne informer l'utilisateur d'un tel choix par une application.

Dans la démonstration effectuée par Pauly, on ne voit pas non plus de moyen de s'opposer à une telle mécanique. Espérons donc que d'ici la version finale des prochains OS d'Apple, ces soucis seront pris en compte.

26 commentaires
Avatar de Stéphane Bortzmeyer Abonné
Avatar de Stéphane BortzmeyerStéphane Bortzmeyer- 25/06/20 à 12:51:12

Excellente nouvelle (après, il faudra regarder les détails, la vidéo n'est pas suffisante). Comme d'habitude, cela va énerver les acteurs qui voudraient bien contrôler la résolution DNS eux-mêmes.
 

Avatar de Mimoza Abonné
Avatar de MimozaMimoza- 25/06/20 à 12:56:33

Si tu avait lu l'article tu aurais vu que même au niveau des applications cela est paramétrable, donc avec des abus possible qui ne sont pas des moindres.

Avatar de jb18v Abonné
Avatar de jb18vjb18v- 25/06/20 à 12:57:24

"On imagine dès lors les abus possibles, si Google venait à forcer ses propres serveurs dans Chrome par exemple, une banque les siens en prétextant une question de sécurité, une application malveillante des DNS menteurs, etc. Malheureusement, il ne semble pas prévu qu'une alerte vienne informer l'utilisateur d'un tel choix par une application."

cela dit normalement comme Apple valide les applis pour apparaitre sur le store, ils devraient filtrer les mauvais élèves. Sauf si l'appli peut changer après coup de config ? et là ça craint aussi. Un indicateur visuel serait en effet bienvenu :chinois:

Avatar de jpagin Abonné
Avatar de jpaginjpagin- 25/06/20 à 13:13:41

Impossible de choisir un serveur DNS de son choix, et commun à toutes les applications ? Le coup du serveur DNS propre à chaque application ça me semble ouvert à de nombreuses dérives, multiplier potentiellement des requêtes d'un même appareil et causer des problèmes (si une appli commence à dire qu'Internet ne fonctionne pas car elle reçoit pas de réponse de son serveur DNS parce qu'elle en a choisi un en carton, par exemple).

Avatar de Stéphane Bortzmeyer Abonné
Avatar de Stéphane BortzmeyerStéphane Bortzmeyer- 25/06/20 à 13:16:26

Mimoza a écrit :

Si tu avait lu l'article

Je suis vexé car non seulement je l'ai lu, mais j'ai regardé la vidéo.

Avatar de aureus Abonné
Avatar de aureusaureus- 25/06/20 à 13:21:17

Bah même si on te laisse le choix, qui va aller se taper les paramètres de chacune de ses 200 applications pour voir s'il y a le choix du DNS ? Et penser à le configurer vers 1.1.1.1 (ou autre)

Moi mais si je dois expliquer ça à mes parents je préfère laisser tomber.

Comme dit jpagin, quid des applications qui vont fonctionner avec des entrées DNS non renseignées sur les serveurs racines ?
 
Je dois être un méchant type qui veut que contrôler les DNS des gens mais je vois très peu d'avantage pour énormément d'inconvénient.

Avatar de wagaf Abonné
Avatar de wagafwagaf- 25/06/20 à 13:25:05

"On imagine dès lors les abus possibles, si Google venait à forcer ses propres serveurs dans Chrome par exemple, une banque les siens en prétextant une question de sécurité, une application malveillante des DNS menteurs, etc. Malheureusement, il ne semble pas prévu qu'une alerte vienne informer l'utilisateur d'un tel choix par une application."

Dans le fond, une appli peut utiliser le résolveur DNS qu'elle veut, voire hardcoder des addresses IP, sans aucun impact pour la sécurité du reste du système, et avec un potentiel d'abus très limité.  
Au pire l'appli se rend elle même vulnérable en utilisant un DNS vulnérable, mais le problème se pose pour n'importe quel accès à un serveur. 
On n'informe pas l'utilisateur pour chaque requête réseau donc pas de raison de le faire pour une requête DNS, qu'elle soit "custom" ou pas, ce qui ne change rien. 

Le cas plus intéressant est celui d'un browser ou autre appli permettant à l'utilisateur d'effectuer ses propres requêtes sur un domaine précisé. Mais même là, si l'utilisateur n'est pas en mesure de faire confiance à l'appli, celle ci pourrait ne même pas résoudre le domaine demandé, donc le problème sera la confiance dans l'appli plus que le DNS.
Édité par wagaf le 25/06/2020 à 13:28
Avatar de David_L Équipe
Avatar de David_LDavid_L- 25/06/20 à 13:29:39

jpagin a écrit :

Impossible de choisir un serveur DNS de son choix, et commun à toutes les applications ?

Si, comme dit dans l'article.

wagaf a écrit :

Dans le fond, une appli peut utiliser le résolveur DNS qu'elle veut, voire hardcoder des addresses IP, sans aucun impact pour la sécurité du reste du système, et avec un potentiel d'abus très limité. Au pire l'appli se rend elle même vulnérable en utilisant un DNS vulnérable, mais le problème se pose pour n'importe quel accès à un serveur.

Peut être, mais est-ce le rôle d'Apple que de le faciliter sans aucune alerte au niveau de l'utilisateur, lui-même étant conscient que l'accès au DNS est tout sauf anodin ?

Avatar de Mimoza Abonné
Avatar de MimozaMimoza- 25/06/20 à 13:37:31

Alors j'ai mal compris ton commentaire, il est trop succin et positif. Comme je ressort de la lecture avec pas mal de crainte (pas pour moi je suis pas Mac), je pensais que l'auteur du commentaire n'avait pas vu les risques et finalement c'est moi qui n'ai regardé l'auteur du commentaire :transpi:

Avatar de jpaul Abonné
Avatar de jpauljpaul- 25/06/20 à 14:37:20

Pour le coup, pourquoi pas ?

Je suis sincèrement curieux de savoir quel est le véritable problème de fond qu’une appli utilise le DNS qu’elle veut.

Je vois ces cas de gênants :

  • l’appli utilise des DNS qui me trackent.

  • l’appli utilise un DNS foireux

    Dans les deux cas le problème est évité si je fais confiance à l’application (qui n’a pas franchement besoin du dns pour m’épier si elle en a envie).
    Oui ça enlève les possibilités d’utiliser des outils comme PiHole et compagnie. Mais ces outils ne sont que des rustines pour masquer un problème plus global : est-ce vraiment le rôle du DNS que de bloquer la publicité ?

    Au contraire des exemples donnnés ci dessus, je trouve ça sain si ma banque veut utiliser son propre resolver dns (même si d’un point de vue sécurité, on est d’accord, ça ne sert à rien). Du moment que bien sûr ça reste scopé à l’appli, qui n’est de toutes façons pas un browser.

    Pour reprendre l’exemple ci dessus, si l’app Chrome décide d’utiliser 8.8.8.8, tant que ça s’applique pas en dehors je vois pas le soucis : quand t’as le browser, Google n’a franchement pas besoin de tes logs de requête.

Il n'est plus possible de commenter cette actualité.
Page 1 / 3