Une annonce importante pour la sécurité, puisque le protocole DNS-Over-HTTPS (DoH) permet le chiffrement des requêtes DNS en se servant de HTTPS. L’éditeur indique que DNS over TLS (DoT) est également toujours une piste envisagée.
Les testeurs du programme Insider recevront « bientôt » une modification transparente, mais cruciale : Windows 10 chiffrera par défaut les requêtes DNS si les serveurs utilisés sont détectés comme compatibles.
Il n’y aura donc pas de changement dans les adresses elles-mêmes. Microsoft insiste d’ailleurs sur ce point : « Modifier silencieusement les serveurs DNS de confiance pour réaliser les résolutions dans Windows pourrait par mégarde contourner ces contrôles et frustrer nos utilisateurs. Nous estimons que les administrateurs ont le droit de contrôler où va leur trafic DNS ».
L’éditeur se dit conscient que de nombreux utilisateurs changent les paramètres par défaut des DNS. Il s’agit souvent de contourner une limite, s’adapter à une situation particulière ou même bloquer par défaut des publicités pendant la navigation.
Plusieurs avantages à cette méthode selon Microsoft. D’une part, un changement transparent donc. D’autre part, la possibilité pour les applications d’en tirer parti sans avoir à changer quoi que ce soit. Enfin, préparer le terrain à de prochaines étapes.
Parmi ces dernières, Microsoft cite la mise en place de serveurs DoH explicites. Plus tard, il s’agira surtout de déterminer à quel moment il faudra considérer qu’il est préférable de ne pas effectuer une résolution DNS plutôt que de la faire sans chiffrement. Il est probable que cette bascule ne soit pas envisageable avant des années.
Commentaires (25)
#1
Celà signe la fin de piHole ?
#2
je dirais que non
“Windows 10 chiffrera par défaut les requêtes DNS si les serveurs utilisés sont détectés comme compatibles”
piHole sera détectés comme non compatible (le temps qu’ils mettent à jour) et la requête sera standard.
#3
#4
Ca empechera pas les opérateurs de juguler le trafic vers les destinations qui leur semble indésirables…
#5
Autant DNS-over-TLS est la suite logique de DNS (tous les protocoles ont commencé avec une version non chiffrée pour ensuite avoir une version chiffrée), autant je trouve que DoH est un truc assez sale.
Tout passer sur le port 443 juste parce que “mais souvent les ports sont bloqués” …
#6
Quel rapport ?
On parle ici de protéger le trafic DNS.
#7
DoH est “sale” mais si y a que ça, on est a peu près sûr que ça passe. D’ailleurs, on peut parier que nombreux gros résolveurs DoH/DoT vont être bloqué par certains opérateurs facétieux et certains États (Google Public DNS est déjà bloqué en Chine, on peut parier que ceux de CloudFlare aussi 🤔)
À noter que MS annonce vouloir implémenter DoT, mais plus tard. (Je suppose qu’ils font DoH en premier parce que c’est le truc à la mode en ce moment et qu’ils n’avaient pas du voir passer le RFC 7858 publié il y a 3 ans tout de même 🤔)
#8
Bientôt on fera du DNS sur HTTPS en VPN encapsulé sur IPv4 Naté chez l’opérateur
ça fait mal à mon modèle TCP IP
#9
#10
#11
Mais ca ne résiste pas à un bloqueur ou une liste d’ip…
#12
#13
Je pense qu’il a bien compris, mais qu’il voulait juste dire que le proxy bloquerait les requêtes http qui sont directement des IP.
Je ne sais pas si c’est un comportement classique ni quels seraient les effets de bord, mais ce serait tout à fait possible techniquement.
#14
#15
#16
Est-ce que MS va mettre en place le domaine canary comme Mozilla ?
#17
#18
C’est la méthode Google aussi (pour DoH (bientôt) et aussi DoT - sous Android 9+ en mode “Automatique”)
#19
”… Nous estimons que les administrateurs ont le droit de contrôler où va leur trafic DNS”, La vache ça a due leur coûter de dire ça.
Y a due y avoir d’interminable débats interne.
Et étonnement, ce n’est pas la version “pour le bien de l’humanité, et la paix dans le monde, tout votre trafic DNS sera 100% sécurisé sur nos serveurs.” qui a gagné!
Même pas un comportement par défaut qui tente de résoudre chez-eux ? Avant que l’administrateur n’ait agit ?
Aller, même sur la version Home ?
Même pas un “bug” qui résout chez eux par défaut pour certaines langues ?
Mais qu’est-ce qui leur prends ! Qui nous a changé MS ?
#20
#21
On parle de proxy d’entreprises qui voudraient contrôler précisément les choses. Je prends pour acquis le fait qu’elles fasse du MITM https et qu’elles filtrent sur les NDD visités. D’ailleurs, il me semble que la quasi-totalité des échanges https utilisent actuellement TLS/SNI, donc c’est même pas nécessaire de déchiffrer le flux pour avoir accès à l’URL (mais ça devrait progressivement disparaitre avec eSNI).
Pour les sites dont le ‘nom de domaine’ est l’IP hardcodée, ils seraient effectivement blacklistés, mais serait-ce réellement gênant en pratique? Perso je ne me rappelle pas de la dernière fois que je suis allé sur un site comme ça.
#22
Certes, il doit être possible de contourner un proxy en forgeant les requêtes http adéquates, mais ça nécessite à la fois un paramétrage spécifique du serveur (qui devra passer outre les informations falsifiées de la requête), et une forte implication du client (qui va lui-même forger des requêtes falcifiées).
" />
Il me semble qu’on a un peu dérivé du contexte du publicitaire qui essaie de contourner les filtrages en utilisant une IP brute dans ses iframes
#23
Le paramétrage spécifique du serveur, ce n’est pas une grosse difficulté, puisque c’est le serveur de la régie pub, donc elle a la main pour la paramétrer comme elle veut.
En réalité, il n’y a même pas besoin de paramétrage spécifique : la plupart des serveurs HTTP ne tiennent pas compte du hostname dans leur configuration par défaut… Ils ne tiennent compte du hostname que s’ils sont configurés pour en gérer plusieurs, et même comme ça, c’est en général configuré avec un vhost “collecteur” qui va servir tout ce qui ne match pas un des autres vhost.
Et côté client, à priori la requête peut être forgée et envoyée via JavaScript, donc là encore, même si ça s’exécute sur le client, ça peut être à la main de la régie publicitaire, qui fournit le code JavaScript.
Donc j’aurais tendance à penser que c’est bel et bien à la porté des régies publicitaires de faire ça…
#24
Je ne connais pas assez pour me prononcer avec certitude, mais j’ai a priori un gros doute sur le fait qu’il est possible de forger une requête http où IP et NDD ne matchent pas depuis du javascript.
Si c’est réellement le cas ça me semble être une faille de sécurité des navigateurs (quid des cookies envoyés, seront-ils ceux du faux NDD ou ceux de l’IP?).
Tu as des une source que je pourrais aller voir?
#25
Tu as raison je pense. Je viens de tester, le setRequestHeader de XmlHttpRequest n’autorise pas à setter le header Host :)
J’ai trop l’habitude de curl qui permet de faire un peu ce qu’on veut, j’avais oublié que l’environnement JS est très restrictif.