DNS Over HTTPS (DoH) : implications pour le filtrage du WiFi public

Bienvenue dans ce briefing technique Purple. Je suis votre hôte pour la session d'aujourd'hui, et nous allons passer les dix prochaines minutes sur un sujet qui compromet discrètement les politiques de filtrage de contenu sur des milliers de déploiements de WiFi publics en ce moment même : le DNS over HTTPS, ou DoH. Si vous gérez un WiFi invité dans un hôtel, un commerce de détail, un stade ou un établissement du secteur public, et que vous n'avez pas spécifiquement traité le DoH dans votre architecture réseau, il y a de fortes chances que votre politique de filtrage présente une lacune importante. Voyons ensemble en quoi consiste exactement cette lacune, pourquoi elle est importante et ce que vous pouvez faire pour y remédier. Première partie — contexte et énoncé du problème. Commençons par un bref rappel du fonctionnement du filtrage DNS traditionnel, car pour comprendre le mécanisme de contournement, il faut d'abord comprendre ce qui est contourné. Lorsqu'un appareil invité se connecte à votre WiFi et tente de visiter un site web, la première chose qu'il fait est d'envoyer une requête DNS — en demandant essentiellement quelle est l'adresse IP de ce domaine. Cette requête transite via UDP ou TCP sur le port 53. Votre infrastructure réseau intercepte cette requête, l'achemine vers le résolveur DNS de votre choix, et ce résolveur vérifie le domaine par rapport à votre politique de filtrage. Si le domaine figure sur une liste de blocage — logiciels malveillants, contenu pour adultes, jeux d'argent, quel que soit ce que spécifie votre politique d'utilisation acceptable — le résolveur refuse de renvoyer l'adresse IP, et la connexion ne s'établit jamais. C'est la base de tout déploiement de filtrage de contenu basé sur le DNS. C'est rentable, cela n'impacte pas le débit, et c'est l'approche standard des exploitants d'établissements depuis près d'une décennie. Le DNS over HTTPS brise ce modèle. Voici comment. Le DoH encapsule les requêtes DNS dans le trafic HTTPS standard sur le port 443. Du point de vue de votre réseau, cela semble identique à tout autre trafic web chiffré. Il n'y a aucun moyen de distinguer une requête DoH d'un utilisateur chargeant une page web, visionnant une vidéo en streaming ou accédant à une application bancaire. La requête va directement à un résolveur DoH externe — le 8.8.8.8 de Google, le 1.1.1.1 de Cloudflare ou bien d'autres — via un canal chiffré que votre filtre DNS ne peut pas inspecter. Le résultat ? Votre politique de filtrage DNS soigneusement configurée est complètement contournée. L'appareil résout le domaine directement, sans que votre résolveur ne voie jamais la requête. Or, il ne s'agit pas d'une attaque délibérée de la part de vos invités. Dans la plupart des cas, c'est entièrement passif. Firefox a activé le DoH par défaut depuis 2020. Chrome met automatiquement à niveau les requêtes DNS vers le DoH si le résolveur configuré le prend en charge. Android 9 et versions ultérieures prennent en charge le DNS privé avec DNS over TLS par défaut. iOS prend en charge les profils de configuration DoH depuis iOS 14. Ce sont des appareils grand public courants qui font ce que leurs fabricants ont prévu. Vos invités n'essaient pas de contourner votre filtrage. Leurs appareils le font simplement de manière automatique. Deuxième partie — l'analyse technique approfondie. Entrons dans les détails mécaniques. Il existe deux principaux modèles d'implémentation du DoH que vous rencontrerez sur le terrain. Le premier est le DoH au niveau applicatif, où l'application — généralement un navigateur — gère sa propre configuration DoH indépendamment des paramètres DNS du système d'exploitation. Firefox en est l'exemple canonique. Lorsque Firefox est installé et que le DoH est activé, il ignore complètement le résolveur DNS du système et envoie toutes ses requêtes DNS à son fournisseur DoH configuré, qui est par défaut Cloudflare. Votre serveur DNS attribué par DHCP n'a plus d'importance. Vos règles d'interception du port 53 n'ont plus d'importance. Firefox mène une conversation DNS totalement distincte sur le port 443 que vous ne pouvez pas voir. Le second modèle est le DoH au niveau du système d'exploitation, où le système d'exploitation lui-même gère la mise à niveau. Chrome et Windows 10 et 11 adoptent cette approche. Ils vérifient si le résolveur DNS configuré du système — celui attribué par votre serveur DHCP — possède un point de terminaison DoH correspondant. Si c'est le cas, ils passent automatiquement au DoH. C'est ce qu'on appelle le DoH opportuniste. Si vous attribuez 8.8.8.8 comme serveur DNS invité, Chrome utilisera automatiquement le point de terminaison DoH de Google. Si vous attribuez 1.1.1.1, il utilisera celui de Cloudflare. La distinction est importante pour votre stratégie d'atténuation, sur laquelle nous reviendrons sous peu. Il y a un troisième vecteur qui mérite d'être mentionné : le DNS over TLS, ou DoT. Celui-ci fonctionne sur le port 853 et chiffre les requêtes DNS à l'aide de TLS plutôt que de les encapsuler dans HTTPS. Il est plus facile à bloquer que le DoH car il utilise un port dédié, mais il est de plus en plus courant sur les appareils Android avec le DNS privé activé. Votre stratégie d'atténuation doit traiter les deux. Parlons maintenant de la raison pour laquelle cela représente un risque opérationnel et de conformité, et pas seulement une curiosité technique. Sous le régime du GDPR, si votre politique d'utilisation acceptable stipule que vous filtrez certaines catégories de contenu, et que vos contrôles techniques n'appliquent pas réellement cette politique, vous avez un écart entre vos engagements déclarés en matière de protection des données et de gouvernance du contenu et votre mise en œuvre technique réelle. C'est un problème de défendabilité si vous devez faire face à une enquête réglementaire ou à un incident. En vertu de l'Online Safety Act du Royaume-Uni, les exploitants d'établissements fournissant un accès public à Internet ont des obligations concernant la protection des utilisateurs — en particulier les mineurs — contre les contenus préjudiciables. Si le DoH contourne silencieusement votre filtrage de contenu, il se peut que vous ne respectiez pas ces obligations. Pour les établissements qui entrent dans le champ d'application de PCI DSS — en particulier ceux où les données de cartes de paiement transitent sur des réseaux adjacents au WiFi invité —, la version 4.0 de PCI DSS exige que vous surveilliez et contrôliez le trafic DNS dans le cadre de vos contrôles de sécurité réseau. Le trafic DoH non surveillé constitue une lacune dans ce cadre de contrôle. Et d'un point de vue purement sécuritaire, le DoH a été activement exploité par des logiciels malveillants. Les acteurs de menaces ont utilisé le DoH comme canal de commande et de contrôle (C2) car il se fond dans le trafic HTTPS normal. La porte dérobée GodLua a utilisé le DoH pour ses communications de commande et de contrôle. Le logiciel malveillant PsiXBot a utilisé le service DoH de Google. Si votre surveillance de la sécurité repose sur la visibilité DNS pour détecter les activités malveillantes, les zones d'ombre créées par le DoH constituent une menace réelle. Troisième partie — recommandations de mise en œuvre. Très bien, passons à la pratique. Il existe trois principales stratégies d'atténuation, et dans la plupart des déploiements en établissement, vous voudrez implémenter les trois en combinaison. Stratégie un : bloquer les points de terminaison des résolveurs DoH connus au niveau du pare-feu. C'est votre première ligne de défense et l'option la plus immédiatement déployable. Maintenez une liste de blocage des adresses IP et des domaines des résolveurs DoH connus — Google, Cloudflare, Quad9, NextDNS, AdGuard, etc. — et refusez le trafic HTTPS sortant vers ces points de terminaison depuis votre VLAN invité. L'IETF et divers fournisseurs de sécurité publient et maintiennent ces listes. Le projet curl sur GitHub maintient une liste complète des résolveurs DoH connus, ce qui constitue un bon point de départ. Cette approche traite la majorité du trafic DoH car, comme l'ont montré les recherches du Software Engineering Institute de Carnegie Mellon, la majeure partie du trafic DoH se dirige vers un petit nombre de résolveurs bien connus. Les utilisateurs qui s'y connaissent suffisamment en DNS pour configurer un résolveur DoH personnalisé représentent une très faible minorité. La limite de cette approche est qu'il s'agit d'une liste de blocage, et que les listes de blocage nécessitent une maintenance. De nouveaux résolveurs DoH apparaissent régulièrement. Mais combinée aux autres stratégies, elle offre une couverture solide. Stratégie deux : l'inspection TLS sur votre pare-feu de nouvelle génération. Les pare-feux de nouvelle génération de fournisseurs tels que Palo Alto Networks, Fortinet, Check Point et Cisco Firepower prennent en charge l'inspection TLS — également appelée inspection SSL ou inspection approfondie des paquets. Lorsqu'elle est activée, le pare-feu agit comme un intermédiaire (man-in-the-middle) pour le trafic HTTPS, en le déchiffrant, en inspectant la charge utile et en le rechiffrant avant de le transmettre. Cela permet au pare-feu d'identifier le trafic DoH même lorsqu'il est destiné à un résolveur inconnu. L'App-ID de Palo Alto peut identifier spécifiquement le trafic DoH et lui appliquer une politique. Le FortiGate de Fortinet dispose d'une capacité similaire. L'étape de configuration clé consiste à s'assurer que le trafic de votre VLAN invité est acheminé via la politique d'inspection. La considération opérationnelle ici est la confiance dans le certificat. Pour que l'inspection TLS fonctionne sur les appareils des invités, ces appareils doivent faire confiance à votre certificat d'inspection. Sur les appareils d'entreprise gérés, c'est simple : vous déployez le certificat via MDM. Sur les appareils d'invités non gérés, c'est plus complexe. L'approche pratique pour le WiFi invité consiste à utiliser le flux d'acceptation du Captive Portal pour informer les utilisateurs que le trafic peut être inspecté à des fins de filtrage de contenu, et à s'appuyer sur la combinaison du blocage des résolveurs DoH et de l'interception DNS comme contrôles principaux, avec l'inspection TLS comme couche secondaire pour les environnements à plus haut risque. Stratégie trois : forcer l'interception et la redirection DNS. Configurez votre pare-feu ou votre contrôleur sans fil pour intercepter tout le trafic DNS sortant sur le port UDP et TCP 53 et le rediriger vers votre résolveur DNS conforme. Cela n'arrête pas le DoH, mais cela garantit que tout trafic DNS qui se rabat sur le port 53 — parce que le DoH a échoué ou n'était pas disponible — est capturé et filtré. Combinez cela avec le blocage du port 853 en sortie du VLAN invité pour empêcher le DNS over TLS de contourner vos contrôles. Pour les terminaux gérés — appareils d'entreprise, appareils du personnel —, vous disposez d'une option supplémentaire : la configuration de la stratégie de groupe ou du MDM pour désactiver le DoH au niveau du navigateur et du système d'exploitation. Dans Firefox, la préférence network.trr.mode définie sur 5 désactive complètement le DoH. Dans Chrome, le drapeau disable-features égal à DnsOverHttps permet d'obtenir le même résultat. Windows 10 et 11 disposent de paramètres de stratégie de groupe pour contrôler le comportement du DoH. C'est le contrôle le plus fiable pour les appareils gérés, mais il n'est pas applicable aux appareils d'invités non gérés. Quatrième partie — les pièges de la mise en œuvre. Quelques problèmes qui surviennent couramment sur le terrain. Le mode de défaillance le plus fréquent est une interception incomplète du port 53. Les équipes configurent correctement leur service de filtrage DNS mais oublient d'ajouter la règle de pare-feu qui redirige tout le trafic sortant du port 53. Les appareils dotés de paramètres DNS codés en dur — 8.8.8.8, 1.1.1.1 — contournent entièrement le filtre. Vérifiez toujours que cette règle est en place et testez-la en configurant un appareil de test avec un serveur DNS codé en dur et en confirmant que les domaines filtrés sont toujours bloqués. Le deuxième échec courant est de ne pas prendre en compte l'IPv6. Les requêtes DNS sur IPv6 sont de plus en plus courantes, et de nombreuses règles de pare-feu sont écrites pour l'IPv4 uniquement. Assurez-vous que votre interception du port 53 et vos listes de blocage de résolveurs DoH couvrent à la fois les adresses IPv4 et IPv6. Troisièmement : des listes de blocage de résolveurs DoH obsolètes. Si vous maintenez une liste de blocage statique d'adresses IP de résolveurs DoH, elle deviendra obsolète. Automatisez le processus de mise à jour ou utilisez un service de filtrage DNS qui maintient cette liste pour vous. Cloudflare Gateway, Cisco Umbrella et les services DNS d'entreprise similaires incluent la détection du contournement DoH en tant que fonctionnalité gérée. Quatrièmement : une dépendance excessive à l'égard d'une seule couche d'atténuation. L'atténuation du DoH est un problème de défense en profondeur. Aucun contrôle unique n'est suffisant. Le blocage des résolveurs connus traite la plupart des cas. L'inspection TLS traite les cas limites. L'interception DNS fournit un filet de sécurité. Superposez les trois. Cinquième partie — questions-réponses rapides. L'atténuation du DoH bloque-t-elle les outils de confidentialité légitimes ? Potentiellement, oui. Si un utilisateur utilise une configuration de navigateur légitime axée sur la confidentialité, votre blocage du DoH le forcera à utiliser votre résolveur DNS. Votre politique d'utilisation acceptable doit indiquer clairement que le résolveur DNS de l'établissement est utilisé à des fins de filtrage de contenu. C'est une pratique courante et juridiquement défendable. Le DoH peut-il être utilisé pour exfiltrer des données de mon réseau ? Oui, et c'est un véritable vecteur de menace. Le tunnel DNS (DNS tunnelling) via DoH a été démontré dans la nature. La capacité de détection DoH de votre pare-feu de nouvelle génération doit inclure la détection d'anomalies pour les volumes de requêtes anormalement élevés ou les modèles de requêtes correspondant à du tunnel. Qu'en est-il des applications mobiles qui utilisent le DoH ? C'est le cas le plus difficile. Les applications mobiles qui implémentent leur propre pile DoH — plutôt que d'utiliser les paramètres DNS du système d'exploitation — sont difficiles à contrôler sans inspection TLS. Votre meilleure atténuation est la combinaison du blocage des résolveurs connus et de l'inspection TLS. Le WPA3 est-il pertinent ici ? Le WPA3 améliore le chiffrement radio et offre une confidentialité persistante, ce qui est excellent pour la vie privée des invités. Mais le WPA3 ne traite pas le DoH — il s'agit d'un problème de protocole applicatif de couche 7, et non d'un problème de sécurité sans fil de couche 2. Ce sont des contrôles complémentaires qui traitent des vecteurs de menace différents. Sixième partie — ROI et impact commercial. Permettez-moi de conclure avec l'analyse de rentabilité pour traiter ce problème correctement. Le coût de l'absence de traitement du DoH est asymétrique. Un seul incident — un invité accédant à un contenu illégal sur votre réseau, un retour d'appel de logiciel malveillant passant inaperçu parce que votre surveillance DNS avait une zone d'ombre, une enquête réglementaire sur votre conformité en matière de filtrage de contenu — peut coûter nettement plus cher que l'investissement dans une atténuation appropriée. Pour un groupe hôtelier exploitant 20 établissements, le déploiement de l'atténuation du DoH implique généralement un effort de configuration unique de deux à quatre heures par établissement pour les règles de pare-feu et la configuration de l'interception DNS, plus un coût opérationnel continu pour maintenir les listes de blocage de résolveurs — ce qui est largement automatisé si vous utilisez un service de filtrage DNS géré. L'investissement total est modeste par rapport à la réduction des risques. Pour les chaînes de vente au détail soumises à la norme PCI DSS, l'avantage en matière de conformité est directement quantifiable. Démontrer que vos contrôles de sécurité réseau incluent l'atténuation du DoH réduit le risque d'une observation d'audit PCI DSS et les coûts de remédiation associés. Pour les établissements du secteur public et ceux soumis à l'Online Safety Act, l'atténuation documentée du DoH fait partie de vos éléments de preuve attestant que vous avez pris des mesures techniques raisonnables pour appliquer votre politique de filtrage de contenu. En conclusion : le DoH n'est pas un problème futur. C'est un problème actuel. Firefox, Chrome, Android et iOS déploient tous des configurations compatibles DoH sur les appareils de vos invités en ce moment même. Si vous n'avez pas audité votre architecture de filtrage DNS pour détecter les vecteurs de contournement DoH au cours des 12 derniers mois, cet audit devrait figurer sur votre feuille de route à court terme. Pour résumer les points clés du briefing d'aujourd'hui. Un : le DoH chiffre les requêtes DNS au sein de HTTPS sur le port 443, les rendant invisibles pour le filtrage DNS traditionnel du port 53. Cela se produit par défaut sur les navigateurs et systèmes d'exploitation grand public. Deux : la stratégie d'atténuation à trois couches — bloquer les IP des résolveurs DoH connus, implémenter l'inspection TLS sur votre pare-feu de nouvelle génération et imposer l'interception du port 53 — offre une couverture de défense en profondeur pour les appareils d'invités gérés et non gérés. Trois : il s'agit d'un problème de conformité, et pas seulement technique. Le GDPR, l'Online Safety Act et PCI DSS ont tous des implications pour les établissements où le DoH contourne silencieusement les politiques de filtrage de contenu. Quatre : la défaillance de mise en œuvre la plus courante est une interception incomplète du port 53. Testez-la. Vérifiez-la. Ne supposez pas qu'elle fonctionne. Cinq : les services de filtrage DNS gérés — Cloudflare Gateway, Cisco Umbrella et similaires — incluent de plus en plus la détection du contournement DoH en tant que fonctionnalité gérée, ce qui réduit la charge opérationnelle liée à la maintenance des listes de blocage statiques. C'est tout pour le briefing technique Purple d'aujourd'hui. Si vous cherchez à auditer votre architecture de filtrage DNS actuelle ou à mettre en œuvre l'atténuation du DoH sur l'ensemble de vos établissements, la plateforme Purple fournit l'intelligence réseau et la couche de gestion du WiFi invité nécessaires pour soutenir ce déploiement. Merci pour votre écoute, et à bientôt pour la prochaine session.