HTTPS masque ce que vous envoyez à un site Web, mais avant même que votre Mac puisse ouvrir cette connexion, il doit poser une question en texte brut : « vers quel serveur ce nom pointe-t-il ? Cette question – une recherche DNS – circule par défaut en clair sur la plupart des réseaux, ce qui signifie que votre fournisseur d'accès Internet, l'administrateur réseau de votre bureau ou toute personne partageant un réseau Wi-Fi non sécurisé peut voir chaque domaine que vous résolvez, même si les pages elles-mêmes sont ensuite entièrement cryptées.
Pourquoi de simples fuites DNS
Le DNS traditionnel, standardisé des décennies avant que HTTPS ne devienne la valeur par défaut du Web, envoie des requêtes via UDP ou TCP simple sur le port 53 sans cryptage et, dans la plupart des configurations de réseaux domestiques et publics, sans authentification du résolveur non plus. Un opérateur réseau n’a pas besoin de rompre le protocole HTTPS pour créer une liste de tous les domaines que vous visitez : il lui suffit de surveiller votre trafic DNS, qui se trouve en clair juste à côté. C’est également ainsi que fonctionnent de nombreux filtres de contenu basés sur DNS et certaines formes de surveillance au niveau du réseau : non pas en inspectant votre trafic chiffré, mais simplement en enregistrant ou en bloquant la recherche qui doit avoir lieu avant que ce trafic n’existe.
DoH et DoT : deux façons de chiffrer la même recherche
Deux normes de l'IETF résolvent ce problème en encapsulant la requête DNS elle-même dans un chiffrement. DNS-over-TLS, défini dans la RFC 7858, enveloppe les requêtes DNS dans une connexion TLS cryptée dédiée sur le port 853, la distinguant du trafic ordinaire et facilitant son identification par un réseau – et, en principe, permettant à un réseau de le bloquer entièrement s'il souhaite arrêter spécifiquement le DNS crypté. DNS-over-HTTPS, défini dans la RFC 8484, mappe à la place une requête DNS sur une requête HTTPS standard sur le port 443, le même port utilisé par presque tout le trafic Web ordinaire – un choix de conception qui rend les requêtes DoH beaucoup plus difficiles à distinguer et donc à bloquer séparément de la navigation Web générale.
Le support natif d’Apple depuis macOS 11
Apple a intégré le DNS crypté directement dans sa pile réseau plutôt que de le laisser à des applications tierces, annonçant cette fonctionnalité lors de la WWDC 2020 aux côtés de macOS Big Sur (macOS 11) et de la version équivalente d'iOS 14. La session a présenté deux façons de l'activer : une API NEDNSSettingsManager permettant aux applications de le configurer par programme et, l'option que la plupart des gens utiliseront réellement, un profil de configuration portant la charge utile com.apple.dnsSettings.managed, documentée dans la référence de gestion des appareils d'Apple, qui vous permet de spécifier l'adresse d'un résolveur DoH ou DoT et de faire en sorte que chaque application du système l'utilise par défaut, aucun logiciel tiers n'est requis.
Un exemple de profil de configuration
Un profil de configuration est une liste de propriétés XML (un fichier .mobileconfig) que macOS peut installer via les paramètres système une fois que vous double-cliquez dessus ou que vous le faites glisser dans le volet Profils. L’exemple ci-dessous pointe un Mac vers le résolveur DNS sur HTTPS public de Quad9 – un service largement utilisé et sans compte requis qui bloque également par défaut les connexions aux domaines connus pour le phishing et d’autres activités malveillantes. Remplacez l'identifiant d'espace réservé et les valeurs UUID avant de l'utiliser ; chaque profil réel a besoin de son propre PayloadUUID.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>PayloadType</key>
<string>com.apple.dnsSettings.managed</string>
<key>PayloadIdentifier</key>
<string>com.example.dns.quad9-doh</string>
<key>PayloadUUID</key>
<string>REPLACE-WITH-A-UNIQUE-UUID-1</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>PayloadDisplayName</key>
<string>Quad9 Encrypted DNS (DoH)</string>
<key>DNSSettings</key>
<dict>
<key>DNSProtocol</key>
<string>HTTPS</string>
<key>ServerURL</key>
<string>https://dns.quad9.net/dns-query</string>
<key>ServerAddresses</key>
<array>
<string>9.9.9.9</string>
<string>149.112.112.112</string>
<string>2620:fe::fe</string>
<string>2620:fe::9</string>
</array>
</dict>
</dict>
</array>
<key>PayloadDisplayName</key>
<string>Encrypted DNS - Quad9</string>
<key>PayloadIdentifier</key>
<string>com.example.dns.quad9-doh.root</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>REPLACE-WITH-A-UNIQUE-UUID-2</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>Pour utiliser Cloudflare à la place, définissez ServerURL sur https://cloudflare-dns.com/dns-query et ServerAddresses sur 1.1.1.1 et 1.0.0.1 (avec 2606:4700:4700::1111 et 2606:4700:4700::1001 pour IPv6) — ou, pour DNS-over-TLS au lieu de DoH, définissez DNSProtocol sur TLS et ServerName sur one.one.one.one, selon la documentation DoT publiée par Cloudflare.
L'installer
- Enregistrez le fichier avec une extension
.mobileconfiget double-cliquez dessus, ou ouvrez Paramètres système, accédez à Confidentialité et sécurité, puis Profils et faites glisser le fichier. - macOS affichera le contenu de la charge utile, y compris le résolveur que vous avez configuré, avant de l'approuver ; vérifiez-le à chaque fois, car un profil est exactement la façon dont un acteur malveillant pourrait rediriger votre DNS si vous en installez un à partir d'une source non fiable.
- Cliquez sur Installer et authentifier. Un profil non signé comme cet exemple affichera le statut de vérification « Non signé » ; cela est attendu pour un profil créé à la main et n'est pas en soi un signe de falsification, mais pour tout ce qui va au-delà des tests personnels, vous devez signer le profil afin que son intégrité puisse être vérifiée.
Vérifier que cela a fonctionné
Ne vous contentez pas de faire confiance au volet des paramètres : vérifiez depuis le terminal.
# Show the resolvers macOS is actually configured to use
scutil --dns
# Look for your interface's resolver entry — it should now show
# the DoH/DoT server address you configured, not your router or ISP's resolver
# Confirm a lookup succeeds and see which resolver answered
dig example.com
# Cloudflare's own diagnostic page also reports whether your
# connection is using encrypted DNS when you open it in a browser
open https://1.1.1.1/helpSi scutil --dns répertorie toujours l'adresse de votre routeur ou le résolveur de votre FAI comme serveur DNS actif, le profil n'a pas pris effet - vérifiez que vous l'avez installé sous Profils plutôt que de simplement le télécharger, et qu'aucune autre configuration réseau (voir ci-dessous) ne le remplace.
Pièges qui empêchent cela de fonctionner silencieusement
- Une application VPN remplace très souvent les paramètres DNS du système lorsqu’elle est connectée, acheminant les recherches via son propre résolveur – vérifiez à nouveau votre configuration DNS après vous être connecté à un VPN, pas juste avant.
- Les portails captifs sur le Wi-Fi des hôtels, des aéroports et des cafés ne peuvent généralement pas terminer leur flux de connexion via un DNS crypté, car ils s'appuient sur l'interception d'une simple requête DNS pour vous rediriger vers une page de connexion ; vous devrez peut-être supprimer ou désactiver temporairement le profil pour vous connecter, puis le réinstaller une fois connecté.
- Certains navigateurs, parmi lesquels Firefox et Chrome, proposent leur propre paramètre DoH distinct qui peut remplacer ou dupliquer la configuration au niveau du système ; vérifiez les paramètres réseau du navigateur si son comportement ne correspond pas à ce que
scutil --dnsrapporte. - iCloud Private Relay et le DNS crypté résolvent différents problèmes qui se chevauchent : Private Relay masque votre adresse IP aux sites que vous visitez dans Safari, tandis que le DNS crypté masque les domaines que vous résolvez de votre réseau ; l’utilisation de l’un ne rend pas l’autre redondant.
Le rôle de FireAI et de HisnLabs
FireAI does not provide encrypted DNS today — it is on the roadmap, not in the current release — so a configuration profile like the one above is what actually closes the DNS-leak gap; FireAI’s job is different, watching and controlling which apps get to make a connection at all once that lookup resolves.
FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction Autopilot) sur du trafic réel, sans que rien ne quitte votre Mac.
Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.
