Le cryptage DNS explique

Avec Windows 11, Microsoft a à nouveau activé la fonction DOH et les utilisateurs peuvent recommencer à le tester s’ils utilisent actuellement des serveurs DNS à partir de CloudFlare, Google ou Quad9.

Présentation DNS

Le système de noms de domaine est le «répertoire d’Internet». DNS traduit les noms de domaine en adresses IP afin que les navigateurs et autres services puissent charger des ressources Internet, via un réseau décentralisé de serveurs.

Qu’est-ce que DNS ?¶

Lorsque vous visitez un site Web, une adresse numérique est retournée. Par exemple, lorsque vous visitez les guides de confidentialité.org, l’adresse 192.98.54.105 est retourné.

DNS existe depuis les premiers jours d’Internet. Les demandes DNS faites vers et depuis les serveurs DNS sont pas généralement crypté. En milieu résidentiel, un client reçoit des serveurs par le FAI via DHCP.

Les demandes DNS non cryptées peuvent être facilement surveillé et modifié en transit. Dans certaines parties du monde, les FAI sont ordonnés de faire un filtrage DNS primitif. Lorsque vous demandez l’adresse IP d’un domaine qui est bloqué, le serveur peut ne pas répondre ou répondre avec une adresse IP différente. Comme le protocole DNS n’est pas crypté, le FAI (ou tout opérateur de réseau) peut utiliser DPI pour surveiller les demandes. Les FAI peuvent également bloquer les demandes en fonction des caractéristiques communes, quel que soit le serveur DNS utilisé. DNS non crypté utilise toujours le port 53 et utilise toujours UDP .

Ci-dessous, nous discutons et fournissons un tutoriel pour prouver ce qu’un observateur extérieur peut voir en utilisant un DNS non crypté régulier et un DNS crypté régulier .

DNS non crypté ¶

1. En utilisant Tshark (partie du projet Wireshark), nous pouvons surveiller et enregistrer le flux de paquets Internet. Cette commande enregistre les paquets qui répondent aux règles spécifiées:

tshark -w / tmp / dns.port UDP PCAP 53 et hôte 1.1.1.1 ou hôte 8.8.8.8 

Linux, MacOS Windows

DIG + NOALL + RÉPONSE PRINCAYGUIDES.org @ 1.1.1.1 DIG + NOALL + RÉPONSE PRINCAYGUIDES.org @ 8.8.8.8 

nslookup privacyguides.org 1.1.1.1 nslookup privacyguides.org 8.8.8.8 

Wireshark Tshark

Wireshark -R / TMP / DNS.PCAP 

tshark -r / tmp / dns.PCAP 

Si vous exécutez la commande Wireshark ci-dessus, le volet supérieur affiche les “cadres” et le volet inférieur montre toutes les données sur le cadre sélectionné. Les solutions de filtrage et de surveillance de l’entreprise (telles que celles achetées par les gouvernements) peuvent effectuer le processus automatiquement, sans interaction humaine, et peuvent agréger ces cadres pour produire des données statistiques utiles à l’observateur de réseau.

Non.	Temps	Source	Destination	Protocole	Longueur	Info
1	0.000000	192.0.2.1	1.1.1.1	DNS	104	Requête standard 0x58ba A PrivacyGuides.org opt
2	0.293395	1.1.1.1	192.0.2.1	DNS	108	Réponse de requête standard 0x58ba A PrivacyGuides.org a 198.98.54.105 Opt
3	1.682109	192.0.2.1	8.8.8.8	DNS	104	Requête standard 0xf1a9 A PrivacyGuides.org opt
4	2.154698	8.8.8.8	192.0.2.1	DNS	108	Réponse de requête standard 0xf1a9 A PrivacyGuides.org a 198.98.54.105 Opt

Un observateur pourrait modifier l’un de ces paquets.

Qu’est-ce que “DNS crypté”?¶

Le DNS crypté peut se référer à l’un des nombreux protocoles, les plus courants étant:

Dnscrypt¶

Dnscrypt a été l’une des premières méthodes de cryptage des requêtes DNS. DNSCrypt fonctionne sur le port 443 et fonctionne avec les protocoles de transport TCP ou UDP. Dnscrypt n’a jamais été soumis au groupe de travail d’ingénierie Internet (IETF) et n’a pas suivi le processus de demande de commentaires (RFC), il n’a donc pas été largement utilisé en dehors de quelques implémentations. En conséquence, il a été largement remplacé par le DNS plus populaire sur HTTPS .

DNS sur TLS (dot) ¶

DNS sur TLS est une autre méthode pour chiffrer la communication DNS définie dans RFC 7858. Le support a été mis en œuvre pour la première fois dans Android 9, iOS 14, et sur Linux en point à DOH ces dernières années, car DOT est un protocole complexe et a une conformité variable à la RFC à travers les implémentations qui existent. DOT fonctionne également sur un port dédié 853 qui peut être bloqué facilement par des pare-feu restrictifs.

DNS sur HTTPS (DOH) ¶

DNS sur HTTPS tel que défini dans les requêtes RFC 8484 Packages dans le protocole HTTP / 2 et assure la sécurité avec HTTPS . Le support a d’abord été ajouté dans des navigateurs Web tels que Firefox 60 et Chrome 83.

L’implémentation native du DOH est apparue dans iOS 14, MacOS 11, Microsoft Windows et Android 13 (cependant, il ne sera pas activé par défaut). La prise en charge du bureau General Linux attend sur l’implémentation SystemD, donc l’installation de logiciels tiers est toujours requise.

Que peut voir une fête extérieure?¶

Dans cet exemple, nous enregistrerons ce qui se passe lorsque nous faisons une demande DOH:

Tout d’abord, démarrez Tshark:

tshark -w / tmp / dns_doh.PCAP -F "TCP PORT HTTPS et HOST 1.1.1.1" 

curl -vi --doh-url https: // 1.1.1.1 / dns-query https: // privacyguides.org 

Wireshark -r / tmp / dns_doh.PCAP 

Nous pouvons voir l’établissement de connexion et la poignée de main TLS qui se produit avec toute connexion cryptée. Lorsque vous regardez les paquets “Données d’application” qui suivent, aucun d’entre eux ne contient le domaine que nous avons demandé ou l’adresse IP renvoyée.

Pourquoi ne devrait pas J’utilise DNS crypté ?¶

Dans les endroits où il y a le filtrage sur Internet (ou la censure), la visite des ressources interdites peut avoir ses propres conséquences que vous devriez considérer dans votre modèle de menace. Nous faisons pas Suggérez l’utilisation de DNS cryptés à cet effet. Utilisez Tor ou un VPN à la place. Si vous utilisez un VPN, vous devez utiliser les serveurs DNS de votre VPN. Lorsque vous utilisez un VPN, vous leur faites déjà confiance avec toute votre activité de réseau.

Lorsque nous faisons une recherche DNS, c’est généralement parce que nous voulons accéder à une ressource. Ci-dessous, nous discuterons de certaines des méthodes qui peuvent divulguer vos activités de navigation même lorsque vous utilisez DNS crypté:

Adresse IP¶

Le moyen le plus simple de déterminer l’activité de navigation pourrait être de regarder les adresses IP à vos appareils. Par exemple, si l’observateur sait que les guides de confidentialité.L’organisation est à 198.98.54.105, et votre appareil demande des données de 198.98.54.105, il y a de fortes chances que vous visiez des guides de confidentialité.

Cette méthode n’est utile que lorsque l’adresse IP appartient à un serveur qui n’héberge que peu de sites Web. Il n’est pas non plus très utile si le site est hébergé sur une plate-forme partagée (e.g. Pages github, pages cloudflare, netlify, wordpress, blogueur, etc.). Il n’est pas non plus utile si le serveur est hébergé derrière un proxy inversé, qui est très courant sur Internet moderne.

Indication du nom du serveur (SNI) ¶

L’indication du nom du serveur est généralement utilisée lorsqu’une adresse IP héberge de nombreux sites Web. Cela pourrait être un service comme CloudFlare, ou une autre protection d’attaque au déni de service.

Recommencez à capturer avec Tshark . Nous avons ajouté un filtre avec notre adresse IP afin de ne pas capturer de nombreux paquets:

tshark -w / tmp / pg.port PCAP 443 et hôte 198.98.54.105 

Wireshark -r / tmp / pg.PCAP 

▸ Sécurité de la couche de transport ▸ TLSV1.3 Couche d'enregistrement: Protocole de poignée de main: Client Hello ▸ Protocole de poignée de main: Client Hello ▸ Extension: Server_name (Len = 22) ▸ Extension d'indication du nom du serveur 

tshark -r / tmp / pg.pcap -tfields -y tls.poignée de main.extensions_server_name -e tls.poignée de main.extensions_server_name 

Cela signifie que même si nous utilisons des serveurs “cryptés DNS”, le domaine sera probablement divulgué par SNI . Le TLS v1.3 Le protocole apporte le client crypté Hello, ce qui empêche ce type de fuite.

Les gouvernements, en particulier la Chine et la Russie, ont déjà commencé à le bloquer ou ont exprimé le désir de le faire. Récemment, la Russie a commencé à bloquer les sites Web étrangers qui utilisent la norme HTTP / 3. En effet.

Protocole de statut de certificat en ligne (OCSP) ¶

Une autre façon dont votre navigateur peut divulguer vos activités de navigation est le protocole de statut de certificat en ligne. Lors de la visite d’un site Web HTTPS, le navigateur peut vérifier si le certificat du site Web a été révoqué. Cela se fait généralement via le protocole HTTP, ce qui signifie que c’est pas crypté.

La demande OCSP contient le certificat “numéro de série”, qui est unique. Il est envoyé au “répondeur OCSP” afin de vérifier son statut.

Nous pouvons simuler ce qu’un navigateur ferait en utilisant la commande OpenSSL.

Obtenez le certificat de serveur et utilisez SED pour garder la partie importante et l’écrire dans un fichier:

OpenSSL S_Client -Connect PrivacyGuides.org: 443 / dev / null 2>&1 | sed -n '/ ^ - * begin /, / ^ - * end / p' > / tmp / pg_server.certificat 

OpenSSL S_Client -Showcerts -Connect PrivacyGuides.org: 443 / dev / null 2>&1 | sed -n '/ ^ - * begin /, / ^ - * end / p' > / tmp / pg_and_intermediate.certificat 

sed -n '/ ^ - * Tertificat de fin - * $ /!d ;: a n; p; ba ' \ / tmp / pg_and_intermediate.Cert> / tmp / intermédiaire_chain.certificat 

OpenSSL X509 -NoOUT -OCSP_URI -IN / TMP / PG_SERVER.certificat 

Notre certificat affiche le Responceur de certificat de chiffre d’affaires. Si nous voulons voir tous les détails du certificat que nous pouvons utiliser:

OpenSSL X509 -Text -Noout -in / TMP / PG_SERVER.certificat 

tshark -w / tmp / pg_ocsp.PCAP -F "TCP Port HTTP" 

OpenSSL OCSP -ISSUER / TMP / Intermediate_Chain.certificat \ -CERT / TMP / PG_SERVER.certificat \ -texte \ -url http: // r3.o.lencr.org 

Wireshark -r / tmp / pg_ocsp.PCAP 

Il y aura deux paquets avec le protocole “OCSP”: une “demande” et une “réponse”. Pour la “demande”, nous pouvons voir le “numéro de série” en élargissant le triangle ▸ à côté de chaque champ:

▸ Protocole de statut de certificat en ligne ▸ TBSREQUEST ▸ Liste de demande: 1 Article ▸ Demande ▸ REQCERT SERIALNUMBER 

Pour la “réponse”, nous pouvons également voir le “numéro de série”:

▸ Protocole de statut de certificat en ligne ▸ ResponseBytes ▸ BasicocspResponse ▸ TBSRESPONSEDATA ▸ Réponses: 1 Article ▸ SingleResponse ▸ Certid serialnumber 

tshark -r / tmp / pg_ocsp.PCAP -TFIELDS -Y OCSP.serialnumber -e OCSP.numéro de série 

Si l’observateur du réseau a le certificat public, qui est accessible au public, il peut correspondre au numéro de série avec ce certificat et donc déterminer le site que vous visitez de cela. Le processus peut être automatisé et peut associer les adresses IP aux numéros de série. Il est également possible de vérifier les journaux de transparence des certificats pour le numéro de série.

Dois-je utiliser DNS crypté ?¶

Nous avons fait ce flux pour décrire lorsque vous devrait Utilisez DNS crypté:

graphique TB start [start] -> anonyme anonyme?> Anonyme -> | Oui | tor (utiliser tor) anonymous -> | Non | censure de censure?> censure -> | Oui | VPNORTOR (Utiliser 
VPN ou TOR) Censure -> | Non | confidentialité du FAI?> Confidentialité -> | Oui | VPNORTOR Confidentialité -> | Non | odieux odieux 
redirection?> odieux -> | Oui | crypteddns (utilisation 
DNS crypté 
avec tiers) odieux -> | Non | ISPDNs cryptés DNS?> ISPDNS -> | Oui | useisp (utilisez 
DNS crypté 
avec ISP) ISPDNS -> | Non | rien (ne faire rien)

Le DNS crypté avec un tiers ne doit être utilisé que pour contourner les redirections et le blocage de base du DNS lorsque vous pouvez être sûr qu’il n’y aura pas de conséquences ou que vous êtes intéressé par un fournisseur qui fait un filtrage rudimentaire.

Qu’est-ce que DNSSEC ?¶

Les extensions de sécurité du système de noms de domaine (DNSSEC) sont une caractéristique du DNS qui authentifie les réponses aux recherches de noms de domaine. Il ne fournit pas de protection de la vie privée pour ces recherches, mais empêche plutôt les attaquants de manipuler ou d’empoisonner les réponses aux demandes DNS.

En d’autres termes, DNSSEC signe numériquement des données pour assurer sa validité. Afin d’assurer une recherche sécurisée, la signature se produit à tous les niveaux du processus de recherche DNS. En conséquence, toutes les réponses du DNS peuvent être fiables.

Le processus de signature du DNSSEC est similaire à quelqu’un qui signait un document juridique avec un stylo; Cette personne signe avec une signature unique que personne d’autre ne peut créer, et un expert judiciaire peut examiner cette signature et vérifier que le document a été signé par cette personne. Ces signatures numériques garantissent que les données n’ont pas été falsifiées.

DNSSEC implémente une politique de signature numérique hiérarchique sur toutes les couches de DNS . Par exemple, dans le cas d’un guide de confidentialité.Recherche d’organes, un serveur DNS racine signerait une clé pour le .Org Nameserver, et le .Org Nameserver signerait alors une clé pour les guides de confidentialité.Le serveur de noms faisant autorité d’Org.

Qu’est-ce que la minimisation QName?¶

Un QNAME est un “nom qualifié”, par exemple PrivacyGuides.org . La minimisation QName réduit la quantité d’informations envoyées du serveur DNS au serveur de noms faisant autorité.

Au lieu d’envoyer l’ensemble du domaine PrivacyGuides.org, la minimisation QName signifie que le serveur DNS demandera tous les enregistrements qui se terminent par .org . Une description technique supplémentaire est définie dans RFC 7816.

Qu’est-ce que le sous-réseau client EDNS (ECS)?¶

Le sous-réseau client EDNS est une méthode pour un résolveur DNS récursif pour spécifier un sous-réseau pour l’hôte ou le client qui fait la requête DNS.

Il est destiné à “accélérer” la livraison des données en donnant au client une réponse qui appartient à un serveur proche d’eux comme un réseau de livraison de contenu, qui sont souvent utilisés dans le streaming vidéo et le service d’applications Web JavaScript.

Cette fonctionnalité a un coût de confidentialité, car il indique au serveur DNS quelques informations sur l’emplacement du client.

Guides de confidentialité est un site Web à but non lucratif et à motivation sociale qui fournit des informations pour protéger la sécurité et la confidentialité de vos données.
Nous ne gagnons pas d’argent en recommandant certains produits, et nous n’utilisons pas de liens d’affiliation.
© 2019 – 2023 Guides et contributeurs de confidentialité.

Le cryptage DNS explique

Le système de noms de domaine (DNS) est le carnet d’adresses d’Internet. Lorsque vous visitez Cloudflare.com ou tout autre site, votre navigateur demandera à un résolveur DNS pour l’adresse IP où le site Web peut être trouvé. Malheureusement, ces requêtes et réponses DNS sont généralement non protégées. Le cryptage DNS améliorerait la confidentialité et la sécurité des utilisateurs. Dans cet article, nous examinerons deux mécanismes de cryptage DNS, connu sous le nom de DNS sur TLS (DOT) et DNS sur HTTPS (DOH), et expliquer comment ils fonctionnent.

Les applications qui souhaitent résoudre un nom de domaine sur une adresse IP utilisent généralement DNS. Cela n’est généralement pas fait explicitement par le programmeur qui a écrit l’application. Au lieu de cela, le programmeur écrit quelque chose comme Fetch (“https: // Exemple.com / news “) et s’attend à ce qu’une bibliothèque de logiciels gère la traduction de« Exemple.com ”à une adresse IP.

Dans les coulisses, la bibliothèque de logiciels est chargée de découvrir et de se connecter au résolveur DNS récursif externe et de parler du protocole DNS (voir la figure ci-dessous) afin de résoudre le nom demandé par l’application. Le choix du résolveur DNS externe et si une confidentialité et une sécurité sont fournies sont hors du contrôle de l’application. Cela dépend de la bibliothèque logicielle utilisée et des politiques fournies par le système d’exploitation de l’appareil qui exécute le logiciel.

Le résolveur DNS externe

Le système d’exploitation apprend généralement l’adresse de résolveur du réseau local à l’aide du protocole de configuration de l’hôte dynamique (DHCP). Dans les réseaux à domicile et mobiles, il finit généralement par utiliser le résolveur de l’internet Provider (ISP). Dans les réseaux d’entreprise, le résolveur sélectionné est généralement contrôlé par l’administrateur du réseau. Si vous le souhaitez, les utilisateurs ayant un contrôle sur leurs appareils peuvent remplacer le résolveur avec une adresse spécifique, comme l’adresse d’un résolveur public comme Google 8.8.8.8 ou Cloudflare 1.1.1.1, mais la plupart des utilisateurs ne prendront probablement pas la peine de le changer lors de la connexion à un hotspot Wi-Fi public dans un café ou un aéroport.

Le choix du résolveur externe a un impact direct sur l’expérience de l’utilisateur final. La plupart des utilisateurs ne modifient pas leurs paramètres de résolveur et finiront probablement par utiliser le résolveur DNS de leur fournisseur de réseau. La propriété observable la plus évidente est la vitesse et la précision de la résolution du nom. Les fonctionnalités qui améliorent la confidentialité ou la sécurité peuvent ne pas être immédiatement visibles, mais qui aideront à empêcher les autres de profilage ou d’interférer avec votre activité de navigation. Ceci est particulièrement important sur les réseaux Wi-Fi publics où toute personne à proximité physique peut capturer et déchiffrer le trafic de réseau sans fil.

DNS non crypté

Depuis que DNS a été créé en 1987, il n’a pas été crypté en grande partie. Tout le monde entre votre appareil et le résolveur est en mesure de fouiner ou même de modifier vos requêtes et réponses DNS. Cela inclut toute personne de votre réseau Wi-Fi local, votre fournisseur de services Internet (ISP) et les fournisseurs de transports en commun. Cela peut affecter votre vie privée en révélant les noms de domaine que vous visitez.

Que peuvent-ils voir? Eh bien, considérez cette capture de paquets de réseau tirée d’un ordinateur portable connecté à un réseau domestique:

Les observations suivantes peuvent être faites:

• Le port source UDP est de 53. La charge utile UDP est donc susceptible d’être une réponse DNS.
• Cela suggère que l’adresse IP source 192.168.2.254 est un résolveur DNS tandis que la destination IP 192.168.2.14 est le client DNS.
• La charge utile UDP pourrait en effet être analysée comme une réponse DNS et révèle que l’utilisateur essayait de visiter Twitter.com.
• S’il existe des connexions futures à 104.244.42.129 ou 104.244.42.1, alors c’est probablement le trafic qui s’adresse à «Twitter.com ».
• S’il y a d’autres trafics HTTPS cryptés vers cette IP, succédé à plus de requêtes DNS, cela pourrait indiquer qu’un navigateur Web a chargé des ressources supplémentaires de cette page. Cela pourrait potentiellement révéler les pages qu’un utilisateur envisageait lors de la visite de Twitter.com.

Étant donné que les messages DNS ne sont pas protégés, d’autres attaques sont possibles:

• Les requêtes pourraient être adressées à un résolveur qui effectue un détournement DNS. Par exemple, au Royaume-Uni, Virgin Media et BT renvoient une fausse réponse pour les domaines qui n’existent pas, rediriger les utilisateurs vers une page de recherche. Cette redirection est possible car l’ordinateur / le téléphone fait aveuglément confiance au résolveur DNS qui a été annoncé à l’aide du DHCP par le routeur de passerelle fourni par les FAI.
• Les pare-feu peuvent facilement intercepter, bloquer ou modifier tout trafic DNS non chiffré en fonction du numéro de port seul. Il convient de noter que l’inspection en texte en clair n’est pas une solution miracle pour atteindre les objectifs de visibilité, car le résolveur DNS peut être contourné.

Crypter DNS

Le chiffrement du DNS rend beaucoup plus difficile pour les snoopers de regarder vos messages DNS, ou de les corrompre en transit. Tout comme le Web est passé de HTTP non crypté aux HTTPs cryptés, il y a maintenant des mises à niveau vers le protocole DNS qui crypte le DNS lui-même. Le chiffrement du Web a permis aux communications et au commerce privés et sécurisés de s’épanouir. Le cryptage DNS améliorera encore la confidentialité des utilisateurs.

Il existe deux mécanismes standardisés pour sécuriser le transport DNS entre vous et le résolveur, DNS sur TLS (2016) et DNS Queries Over HTTPS (2018). Les deux sont basés sur la sécurité de la couche de transport (TLS) qui est également utilisée pour sécuriser la communication entre vous et un site Web à l’aide de HTTPS. Dans TLS, le serveur (que ce soit un serveur Web ou un résolveur DNS) s’authentifie au client (votre appareil) à l’aide d’un certificat. Cela garantit qu’aucun autre parti ne peut se faire passer pour le serveur (le résolveur).

Avec DNS sur TLS (DOT), le message DNS d’origine est directement intégré dans le canal TLS sécurisé. De l’extérieur, on ne peut ni apprendre le nom qui était interrogé ni le modifier. L’application client prévue pourra décrypter TLS, il semble que ceci:

Dans la trace de paquet pour le DNS non crypté, il était clair qu’une demande DNS peut être envoyée directement par le client, suivie d’une réponse DNS du résolveur. Dans le cas de DOT chiffré cependant, certains messages de poignée TLS sont échangés avant d’envoyer des messages DNS cryptés:

• Le client envoie un client bonjour, faisant la publicité de ses capacités TLS prises en charge.
• Le serveur répond avec un serveur bonjour, en accord sur les paramètres TLS qui seront utilisés pour sécuriser la connexion. Le message de certificat contient l’identité du serveur tandis que le message de vérification du certificat contiendra une signature numérique qui peut être vérifiée par le client à l’aide du certificat de serveur. Le client vérifie généralement ce certificat par rapport à sa liste locale des autorités de certificat de confiance, mais la spécification DOT mentionne des mécanismes de confiance alternatifs tels que la clés publique épingle.
• Une fois la poignée de main TLS terminée par le client et le serveur, ils peuvent enfin commencer à échanger des messages cryptés.
• Alors que l’image ci-dessus contient une requête et une réponse DNS, en pratique, la connexion TLS sécurisée restera ouverte et sera réutilisée pour les futures requêtes DNS.

La sécurisation des protocoles non cryptés en giflant TLS au-dessus d’un nouveau port a été fait auparavant:

• Trafic Web: HTTP (TCP / 80) -> HTTPS (TCP / 443)
• Email Envoi: SMTP (TCP / 25) -> SMTPS (TCP / 465)
• Recevoir des e-mails: IMAP (TCP / 143) -> IMAPS (TCP / 993)
• Maintenant: DNS (TCP / 53 ou UDP / 53) -> DOT (TCP / 853)

Un problème avec l’introduction d’un nouveau port est que les pare-feu existants peuvent le bloquer. Soit parce qu’ils utilisent une approche de listlist Autlover où les nouveaux services doivent être explicitement activés, soit une approche de liste de blocs où un administrateur réseau bloque explicitement un service. Si l’option sécurisée (DOT) est moins susceptible d’être disponible que son option non sécurisée, les utilisateurs et les applications pourraient être tentés d’essayer de retomber au DNS non crypté. Cela pourrait par la suite permettre aux attaquants de forcer les utilisateurs à une version non sécurisée.

De telles attaques de secours ne sont pas théoriques. Le décapage SSL a déjà été utilisé pour rétrograder les sites Web HTTPS en HTTP, permettant aux attaquants de voler des mots de passe ou des comptes de détournement.

Une autre approche, DNS requêtes sur HTTPS (DOH), a été conçue pour prendre en charge deux cas d’utilisation principaux:

• Empêcher le problème ci-dessus où les appareils sur le chemin interfèrent avec DNS. Cela inclut le problème de blocage du port ci-dessus.
• Activer les applications Web pour accéder au DNS via les API du navigateur existant.
  DOH est essentiellement HTTPS, la même norme cryptée que le Web utilise et réutilise le même numéro de port (TCP / 443). Les navigateurs Web ont déjà obsolète HTTP non sécurisé en faveur de HTTPS. Cela fait de HTTPS un excellent choix pour transporter en toute sécurité les messages DNS. Un exemple d’une telle demande DOH peut être trouvé ici.

Certains utilisateurs craignaient que l’utilisation de HTTPS puisse affaiblir la vie privée en raison de l’utilisation potentielle des cookies à des fins de suivi. Les concepteurs du protocole DOH ont considéré divers aspects de confidentialité et ont explicitement découragé l’utilisation des cookies HTTP pour empêcher le suivi, une recommandation largement respectée. La reprise de la session TLS améliore TLS 1.2 performances de poignée de main, mais peuvent potentiellement être utilisées pour corréler les connexions TLS. Heureusement, l’utilisation de TLS 1.3 évite la nécessité de reprise de la session TLS en réduisant le nombre d’aller-voyage par défaut, répondant efficacement à son problème de confidentialité associé.

L’utilisation de HTTPS signifie que les améliorations du protocole HTTP peuvent également profiter à DOH. Par exemple, le protocole HTTP / 3 en développement, construit au-dessus de la quic, pourrait offrir des améliorations de performances supplémentaires en présence d’une perte de paquets en raison du manque de blocage de la tête de ligne. Cela signifie que plusieurs requêtes DNS pourraient être envoyées simultanément sur le canal sécurisé sans se bloquer lorsqu’un paquet est perdu.

Un projet de DNS sur Quic (DNS / QUIC) existe également et est similaire à DOT, mais sans le problème de blocage de la tête de ligne en raison de l’utilisation de Quic. HTTP / 3 et DNS / QUIC, cependant, nécessitent un port UDP pour être accessible. En théorie, les deux pourraient retomber à DOH sur HTTP / 2 et DOT respectivement.

Déploiement de points et de DOH

Comme DOT et DOH sont relativement nouveaux, ils ne sont pas encore déployés universellement. Du côté du serveur, les principaux résolveurs publics, y compris 1 CloudFlare.1.1.1 et Google DNS le prend en charge. De nombreux résolveurs du FAI manquent cependant toujours de soutien. Une petite liste de résolveurs publics prenant en charge DOH peut être trouvé dans les sources du serveur DNS, une autre liste de résolveurs publics prenant en charge le point et le DOH peut être trouvé sur DNS Privacy Resolvers Public Resolvers.

Il existe deux méthodes pour activer DOT ou DOH sur les dispositifs de l’utilisateur final:

• Ajouter un support aux applications, en contournant le service de résolveur à partir du système d’exploitation.
• Ajouter un support au système d’exploitation, fournissant de manière transparente le support aux applications.

Il existe généralement trois modes de configuration pour DOT ou DOH du côté client:

• Off: DNS ne sera pas crypté.
• Mode opportuniste: essayez d’utiliser un transport sécurisé pour le DNS, mais le repli vers le DNS non crypté si le premier n’est pas disponible. Ce mode est vulnérable aux attaques de rétrogradation où un attaquant peut forcer un appareil à utiliser le DNS non crypté. Il vise à offrir une confidentialité lorsqu’il n’y a pas d’attaquants actifs sur le chemin.
• Mode strict: essayez d’utiliser DNS sur un transport sécurisé. Si indisponible, échouez dur et affichez une erreur à l’utilisateur.

L’état actuel de la configuration à l’échelle du système de DNS sur un transport sécurisé:

• Android 9: prend en charge DOT via sa fonctionnalité «DNS privée». Modes:
  • Le mode opportuniste («automatique») est utilisé par défaut. Le résolveur des paramètres réseau (généralement DHCP) sera utilisé.
  • Le mode strict peut être configuré en définissant un nom d’hôte explicite. Aucune adresse IP n’est autorisée, le nom d’hôte est résolu à l’aide du résolveur par défaut et est également utilisé pour valider le certificat. (Code source pertinent)

  Les navigateurs Web prennent en charge DOH au lieu de DOT:

  • Firefox 62 prend en charge DOH et fournit plusieurs paramètres de résolveur récursif de confiance (TRR). Par défaut DOH est handicapé, mais Mozilla exécute une expérience pour activer DOH pour certains utilisateurs aux États-Unis. Cette expérience utilise actuellement CloudFlare 1.1.1.1 Resolver, puisque nous sommes le seul fournisseur qui satisfait actuellement la politique stricte de résolveur requise par Mozilla. Étant donné que de nombreux résolveurs DNS ne prennent toujours pas en charge un transport DNS crypté, l’approche de Mozilla garantira que davantage d’utilisateurs sont protégés en utilisant DOH.
    • Lorsqu’il est activé via l’expérience ou via l’option «Activer DNS sur HTTPS» aux paramètres réseau, Firefox utilisera le mode opportuniste (réseau.TRR.mode = 2 à environ: config).
    • Le mode strict peut être activé avec le réseau.TRR.mode = 3, mais nécessite un résolveur explicite IP à spécifier (par exemple, le réseau.TRR.bootstrapaddress = 1.1.1.1).
    • Alors que Firefox ignore le résolveur par défaut du système, il peut être configuré avec des résolveurs alternatifs. De plus, les déploiements d’entreprise qui utilisent un résolveur qui ne prend pas en charge DOH a la possibilité de désactiver DOH.

    La page DNS sur HTTPS du projet Curl a une liste complète des fournisseurs DOH et des implémentations supplémentaires.

    Comme alternative au chiffrement du chemin de réseau complet entre l’appareil et le résolveur DNS externe, on peut prendre un terrain d’entente: utiliser des DN non cryptés entre les appareils et la passerelle du réseau local, mais chiffrer le trafic DNS entre le routeur de passerelle et le routeur externe Resolver DNS. En supposant un réseau câblé ou sans fil sécurisé, cela protégerait tous les appareils du réseau local contre un FAI de scoop, ou d’autres adversaires sur Internet. Comme les points chauds Wi-Fi publics ne sont pas considérés comme sécurisés, cette approche ne serait pas sûre sur les réseaux Wi-Fi ouverts. Même s’il est protégé par mot de passe avec WPA2-PSK, d’autres pourront toujours espionner et modifier le DNS non crypté.

    Autres considérations de sécurité

    Les sections précédentes décrivaient des transports DNS sécurisés, DOH et DOT. Ceux-ci garantiront uniquement que votre client reçoit la réponse indemnable du résolveur DNS. Il ne protège cependant pas le client contre le résolveur renvoyant la mauvaise réponse (grâce à un détournement DNS ou à des attaques d’empoisonnement au cache DNS). La «vraie» réponse est déterminée par le propriétaire d’un domaine ou d’une zone comme indiqué par le serveur de noms faisant autorité. DNSSEC permet aux clients de vérifier l’intégrité de la réponse DNS retournée et de prendre toute altération non autorisée le long du chemin entre le client et le serveur de noms faisant autorité.

    Cependant, le déploiement de DNSSEC est entravé par des boîtes intermédiaires qui transmettent incorrectement les messages DNS, et même si les informations sont disponibles, les résolveurs de talons utilisés par les applications peuvent même ne pas valider les résultats. Un rapport de 2016 a révélé que seulement 26% des utilisateurs utilisent des résolveurs de validation du DNSEC.

    DOH et DOT protéger le transport entre le client et le résolveur public. Le résolveur public peut avoir à atteindre des serveurs de noms faisant autorité supplémentaires afin de résoudre un nom. Traditionnellement, le chemin entre tout résolveur et le serveur de noms faisant autorité utilise un DNS non crypté. Pour protéger ces messages DNS également, nous avons fait une expérience avec Facebook, en utilisant DOT entre 1.1.1.1 et les serveurs de noms faisant autorité de Facebook. Lors de la configuration d’un canal sécurisé en utilisant TLS augmente la latence, il peut être amorti sur de nombreuses requêtes.

    Le cryptage des transports garantit que les résultats du résolveur et les métadonnées sont protégés. Par exemple, les informations sur le sous-réseau client EDNS (ECS) incluses avec les requêtes DNS pourraient révéler l’adresse du client d’origine qui a commencé la requête DNS. Cacher ces informations le long du chemin améliore la confidentialité. Il empêchera également les boîtes intermédiaires cassées de casser le DNSEC en raison des problèmes de transfert DNS.

    Problèmes opérationnels avec le cryptage DNS

    Le chiffrement DNS peut relever des défis aux particuliers ou aux organisations qui s’appuient sur la surveillance ou la modification du trafic DNS. Les appareils de sécurité qui s’appuient sur une surveillance passive regardent tous les trafics réseau entrants et sortants sur une machine ou sur le bord d’un réseau. Sur la base des requêtes DNS non cryptées, ils pourraient potentiellement identifier les machines infectées par des logiciels malveillants par exemple. Si la requête DNS est cryptée, alors les solutions de surveillance passives ne pourront pas surveiller les noms de domaine.

    Certaines parties s’attendent à ce que les résolveurs DNS appliquent le filtrage de contenu à des fins telles que:

    • Blocage des domaines utilisés pour la distribution de logiciels malveillants.
    • Bloquer des publicités.
    • Effectuer un filtrage de contrôle parental, des domaines de blocage associés au contenu adulte.
    • Bloquer l’accès aux domaines servant du contenu illégal selon les réglementations locales.
    • Offrez un DNS à horizon fendu pour fournir des réponses différentes en fonction du réseau source.

    Un avantage de bloquer l’accès aux domaines via le résolveur DNS est qu’il peut être effectué de manière centralisée, sans le réimplémenter dans chaque application. Malheureusement, c’est aussi assez grossier. Supposons qu’un site Web héberge le contenu de plusieurs utilisateurs à l’exemple.com / vidéos / for-kids / et exemple.com / vidéos / for-adults /. Le résolveur DNS ne pourra voir que «Exemple.com »et peut choisir de le bloquer ou non. Dans ce cas, les contrôles spécifiques à l’application tels que les extensions du navigateur seraient plus efficaces car ils peuvent réellement examiner les URL et empêcher sélectivement le contenu d’être accessible.

    La surveillance DNS n’est pas complète. Les logiciels malveillants peuvent ignorer les adresses IP DNS et Hardcode, ou utiliser des méthodes alternatives pour interroger une adresse IP. Cependant, tous les logiciels malveillants ne sont pas compliqués, donc la surveillance du DNS peut toujours servir d’outil de défense en profondeur.

    Tous ces cas d’utilisation non passifs de surveillance ou de blocage DNS nécessitent le soutien du résolveur DNS. Les déploiements qui s’appuient sur les mises à niveau opportuniste DOH / DOT du résolveur actuel conserveront le même ensemble de fonctionnalités que celle généralement fournie sur le DNS non crypté. Malheureusement, cela est vulnérable aux rétrogradations, comme mentionné précédemment. Pour résoudre ce problème, les administrateurs système peuvent pointer des points de terminaison à un résolveur DOH / DOT en mode strict. Idéalement, cela se fait via des solutions de gestion des périphériques sécurisées (MDM, stratégie de groupe sur Windows, etc.).

    Conclusion

    L’une des pierres angulaires d’Internet est de mapper des noms à une adresse utilisant DNS. DNS a traditionnellement utilisé des transports non sécurisés et non cryptés. Cela a été maltraité par les FAI dans le passé pour injecter des publicités, mais provoque également une fuite de confidentialité. Les visiteurs curieux du café peuvent utiliser des DN non cryptés pour suivre votre activité. Tous ces problèmes peuvent être résolus en utilisant DNS sur TLS (DOT) ou DNS sur HTTPS (DOH). Ces techniques pour protéger l’utilisateur sont relativement nouvelles et voient une adoption croissante.

    D’un point de vue technique, le DOH est très similaire à HTTPS et suit la tendance générale de l’industrie pour déprécier les options non sécurisées. Le point est un mode de transport plus simple que DOH car la couche HTTP est supprimée, mais cela facilite également d’être bloqué, soit délibérément ou par accident.

    Le choix d’un transport sécurisé est le choix d’un résolveur DNS. Certains fournisseurs utiliseront le résolveur DNS configuré localement, mais essaieront de mettre à niveau opportun le transport non crypté vers un transport plus sécurisé (DOT ou DOH). Malheureusement, le résolveur DNS est généralement par défaut celui fourni par le FAI qui peut ne pas prendre en charge les transports sécurisés.

    Mozilla a adopté une approche différente. Plutôt que de s’appuyer sur des résolveurs locaux qui peuvent même ne pas prendre en charge le DOH, ils permettent à l’utilisateur de sélectionner explicitement un résolveur. Les résolveurs recommandés par Mozilla doivent satisfaire des normes élevées pour protéger la confidentialité des utilisateurs. Pour s’assurer que les caractéristiques de contrôle parental basées sur le DNS restent fonctionnelles et pour soutenir le cas d’utilisation à horizon fendu, Mozilla a ajouté un mécanisme qui permet aux résolveurs privés de désactiver DOH.

    Les protocoles de transport DOT et DOH sont prêts pour que nous déménageons sur un Internet plus sécurisé. Comme on peut le voir dans les traces de paquets précédentes, ces protocoles sont similaires aux mécanismes existants pour sécuriser le trafic d’application. Une fois ce trou de sécurité et de confidentialité fermé, il y en aura beaucoup d’autres à aborder.

    

    Visitez 1.1.1.1 de n’importe quel appareil pour commencer avec notre application gratuite qui rend votre Internet plus rapide et plus sûr.

    Pour en savoir plus sur notre mission pour aider à créer un meilleur Internet, commencez ici. Si vous cherchez une nouvelle direction de carrière, consultez nos postes ouverts.

    Windows 11 comprend la fonction de confidentialité DNS-Over-HTTPS – comment utiliser

    

    Microsoft a ajouté une fonctionnalité de confidentialité à Windows 11 appelée DNS-sur-HTTPS, permettant aux utilisateurs d’effectuer des recherches DNS cryptées pour contourner la censure et l’activité Internet.

    Lorsque vous vous connectez à un site Web ou à un autre hôte sur Internet, votre ordinateur doit d’abord interroger un serveur de système de noms de domaine (DNS) pour l’adresse IP associée au nom d’hôte.

    DNS-Over-HTTPS (DOH) permet à votre ordinateur d’effectuer ces recherches DNS sur une connexion HTTPS cryptée plutôt que par le biais de recherches DNS normales, que les FAI et les gouvernements peuvent espionner.

    Comme certains gouvernements et ISPS bloquent les connexions aux sites en surveillant le trafic DNS d’un utilisateur, DOH permettra aux utilisateurs de contourner la censure, d’éviter les attaques de l’usurpation et d’augmenter la confidentialité car leurs demandes DNS ne peuvent pas être aussi facilement surveillées.

    Les navigateurs à base de chrome, tels que Google Chrome et Microsoft Edge, et Mozilla Firefox, ont déjà ajouté la prise en charge de DOH. Pourtant, il n’est utilisé que dans le navigateur et non par d’autres applications exécutées sur l’ordinateur.

    C’est pourquoi il est utile pour un système d’exploitation de prendre en charge la fonctionnalité, car toutes les recherches DNS sur l’appareil seront cryptées.

    Windows 11 obtient DNS-sur-HTTPS

    Microsoft a publié pour la première fois DNS-sur-HTTP.

    Avec Windows 11, Microsoft a à nouveau activé la fonction DOH et les utilisateurs peuvent recommencer à le tester s’ils utilisent actuellement des serveurs DNS à partir de CloudFlare, Google ou Quad9.

    Si le périphérique est actuellement configuré pour utiliser un serveur CloudFlare, Google ou Quad9 DNS, vous pouvez configurer DNS-Over-HTTPS en utilisant les étapes suivantes:

    1. Ouvrez l’application des paramètres Windows 10 et accédez à Réseau et Internet.
    2. Sur la page réseau et Internet, cliquez sur soit Ethernet ou Sans fil en fonction de la connexion réseau que vous avez.

    

    

    

    L’option de chiffrement DNS préférée offre les choix suivants:

    • Non crypté uniquement – Utilisez le DNS non crypté standard.
    • Crypte uniquement (DNS sur HTTPS) – Utilisez uniquement les serveurs DOH.
    • Crypté préféré, non crypté uniquement – essayez d’utiliser des serveurs DOH, mais si ce n’est pas disponible, retombez à DNS non crypté standard.

    À l’heure actuelle, Microsoft déclare que les serveurs DNS suivants sont connus pour prendre en charge DOH et peuvent être utilisés automatiquement par la fonction Windows 11 DNS-Over-HTTP.

    • CloudFlare: 1.1.1.1 et 1.0.0.1 serveurs DNS
    • Google: 8.8.8.8 et 8.8.8.4 serveurs DNS
    • Quad9: 9.9.9.9 et 149.112.112.112 serveurs DNS

    Pour voir les définitions DNS-sur-HTTP configurées déjà configurées dans Windows 11, vous pouvez utiliser les commandes suivantes:

    Utilisation de netsh: netsh DNS montre un cryptage à l'aide de PowerShell: get-dnsclientdohserveraddress 

    Microsoft permet également aux administrateurs de créer leurs propres définitions de serveur DOH en utilisant les commandes suivantes:

    Utilisation de netsh: netsh dns Ajouter le serveur de cryptage = [résolver-ip-address] dohTemplate = [Resolver-Doh-Template] Autoupgrade = yes udpFallback = no Utilisation de PowerShell: Add-DnsClientDoHServerAddress -ServerAddress ' '[Resolver-Doh-Template]' -AllowfallbackToudp $ false -Autoupgrade $ true 

    Microsoft dit qu’il serait préférable que le serveur DOH pour un serveur DNS configuré puisse être déterminé automatiquement, mais cela entraînerait un risque de confidentialité.

    “Il serait plus facile pour les utilisateurs et les administrateurs si nous autorisons un serveur DOH à faire déterminer son adresse IP en résolvant son nom de domaine. Cependant, nous avons choisi de ne pas autoriser cela. Soutenir cela signifierait qu’avant qu’une connexion DOH puisse établir, nous devions d’abord envoyer une requête DNS en texte ordinaire pour le bootstrap “, explique Tommy Jensen, un gestionnaire de programme de l’équipe de réseautage Windows Core, dans un nouveau blog.

    “Cela signifie qu’un nœud sur le chemin du réseau pourrait modifier ou bloquer la requête du nom du serveur DOH. À l’heure actuelle, la seule façon d’éviter cela est de faire connaître à l’avance Windows à l’avance le mappage entre les adresses IP et les modèles DOH.”

    À l’avenir, Microsoft espère en savoir plus sur les nouvelles configurations de serveur DOH à partir d’un serveur DNS en utilisant la découverte de résolveurs désignés (DDR) et la découverte de résolveurs (DNR) désignés par le réseau, qu’ils ont proposé à IETF Ajouter WG.

    Gérer DOH via les politiques de groupe

    Microsoft a également ajouté la possibilité de gérer les paramètres de Windows 11 DNS-sur-HTTPS via des politiques de groupe.

    Avec Windows 11, Microsoft a introduit un ‘Configurer la résolution du nom DNS sur HTTPS (DOH)‘Politique sous configuration de l’ordinateur> Templates administratifs> Réseau> Client DNS.

    

    Cette stratégie vous permet de configurer la machine pour utiliser des DN non cryptés standard, préférer DOH ou nécessiter DOH.