Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Microsoft activera DNS-Over-HTTPS par défaut dans Windows 10

Microsoft activera DNS-Over-HTTPS par défaut dans Windows 10

Le 20 novembre 2019 à 10h36

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.

Le 20 novembre 2019 à 10h36

Commentaires (25)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Quel rapport ?



On parle ici de protéger le trafic DNS.

votre avatar

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 🤔)

votre avatar

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

votre avatar







33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



PiHole est condamné à plus ou moins brève échéance. Toute méthode qui consiste à utiliser un autre DNS que l’officiel peut être contournée par les mmrd*urs publicitaires: au lieu d’inclure un lien avec un nom de domaine dans l’URL, ils feront la résolution sur le serveur et mettront l’adresse IP directement dans le script. C’est difficile en environnement IPV4 où plusieurs serveurs mutualisés ont la même IPV4 et un reverse proxy fait le dispatching, mais en IPV6 ce sera les doigts dans le nez.





Utiliser des IP fixe ne marche pas dans tout les reseaux d’entreprise derriere un proxy bien foutu, dont entre autre les grosse boites qui tiennent ces sites.



Et PiHole marche très bien avec du DoH.


votre avatar







sarbian a écrit :



Utiliser des IP fixe ne marche pas dans tout les reseaux d’entreprise derriere un proxy bien foutu, dont entre autre les grosse boites qui tiennent ces sites.







On a dû mal se comprendre… Si je suis un publicitaire, au lieu de fourguer au navigateur la balise iframe qui va chercher son contenu sur “www.publicitaire-bien-chiant.com” (résolu par un “vrai” DNS comme “123.56.43.23”), je peux fourguer directement “123.56.43.23” dans le script. Quand le navigateur de la victime affichera le iframe, il n’aura pas besoin de résoudre le nom puisqu’il a déjà l’adresse IP. Pour l’Internet tout entier, c’est totalement transparent, aucun proxy, aucun routeur ne pourra déterminer que la requête vers “123.56.43.23” a été hardcodée dans une page et n’a pas été retrouvée par une résolution de nom.



En clair, ton navigateur ira piocher l’écran de pub sans que ton PiHole ait eu l’opportunité de résoudre “publicitaire-bien-chiant” en 127.0.0.1…



votre avatar

Mais ca ne résiste pas à un bloqueur ou une liste d’ip…

votre avatar







CryoGen a écrit :



Mais ca ne résiste pas à un bloqueur ou une liste d’ip…







Certes, mais alors tu reviens à l’utilisation d’un bloqueur classique, or là on parlait bien spécifiquement de PiHole…


votre avatar

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.

votre avatar







Ailothaen a écrit :



Tout passer sur le port 443 juste parce que “mais souvent les ports sont bloqués” …







C’est là tout son intérêt justement.<img data-src=" />


votre avatar







Zerdligham a écrit :



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.





Une requête HTTP contient toujours l’IP de la destination (dans l’en-tête de la couche IP), et optionnellement le nom de domaine de la cible (dans l’en-tête de la couche applicative). Techniquement, rien n’empêcherait de mettre un nom de domaine quelconque dans les requêtes DNS over HTTPS, et absolument rien ne permettrait alors de les distinguer d’une requête HTTPS classique, si ce n’est l’IP de la destination (si le firewall est un peu intelligent, il refait lui même la résolution DNS du domaine qui est dans l’en-tête HTTP, et si ça correspond pas à l’IP de destination, il bloque).


votre avatar

Est-ce que MS va mettre en place le domaine canary comme Mozilla ?

votre avatar







empty a écrit :



Est-ce que MS va mettre en place le domaine canary comme Mozilla ?





Quel serait l’intérêt ? La façon de faire de Mozilla détourne ton DNS vers un autre serveur, alors que la méthode MS change juste le protocole, mais en utilisant toujours le serveur DNS donné par l’utilisateur.

Pour une fois, MS fait mieux les choses que Mozilla.


votre avatar

C’est la méthode Google aussi (pour DoH (bientôt) et aussi DoT - sous Android 9+ en mode “Automatique”)

votre avatar

”… 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.

&nbsp;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é!

&nbsp;

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 ?

&nbsp;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 ?

votre avatar







Zerdligham a écrit :



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.





C’est possible techniquement, mais pour ça tu dois faire du DPI, donc arriver à déchiffrer le trafic https. D’autre part, si ton proxy bloque toutes les requêtes http qui spécifient directement l’adresse IP, tu vas aussi bloquer les sites qui utilisent des adresses IP hardcodées pour des motifs légitimes.


votre avatar

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.

votre avatar

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 <img data-src=" />

votre avatar

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…

votre avatar

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?

votre avatar

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.

votre avatar

Celà signe la fin de piHole ?

votre avatar

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.

votre avatar







Origami a écrit :



Celà signe la fin de piHole ?





PiHole est condamné à plus ou moins brève échéance. Toute méthode qui consiste à utiliser un autre DNS que l’officiel peut être contournée par les mmrd*urs publicitaires: au lieu d’inclure un lien avec un nom de domaine dans l’URL, ils feront la résolution sur le serveur et mettront l’adresse IP directement dans le script. C’est difficile en environnement IPV4 où plusieurs serveurs mutualisés ont la même IPV4 et un reverse proxy fait le dispatching, mais en IPV6 ce sera les doigts dans le nez.


votre avatar

Ca empechera pas les opérateurs de juguler le trafic vers les destinations qui leur semble indésirables…

&nbsp;

votre avatar

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” …&nbsp;

Microsoft activera DNS-Over-HTTPS par défaut dans Windows 10

Fermer