La surveillance du trafic réseau est-elle encore pertinente aujourd’hui ?

L’Internet est né comme un projet ouvert et collaboratif. La sécurité est un composant qui n’y a été greffé qu’au fil du temps. Bon nombre des protocoles de base de l’Internet, dont le système de noms de domaine et le protocole HTTP, n’ont pas été pensés pour la confidentialité.

Pour HTTP, nous avons assisté à la multiplication des déploiements HTTPS (HTTP sur TLS) ; mais même avec les versions actuelles de Transport Layer Security (TLS), la confidentialité des activités des utilisateurs n’est pas pleinement assurée. Plus récemment, des extensions de TLS et des variantes du protocole DNS (Domain Name System) ont été développées pour combler les derniers trous restants.

Mais cette confidentialité accrue peut avoir des conséquences malvenues pour la surveillance du trafic réseau.

La plupart des organisations ont un bilan mitigé en matière de sécurisation des terminaux. Et pour combler leurs lacunes en la matière, notamment dans le cadre de projets IoT et BYOD, la surveillance du trafic réseau a été utilisée comme complément. Mais cette approche mérite d’être questionnée.

Et cela commence avec le DNS. À bien des égards, le DNS est une grande réussite parmi les protocoles Internet. Développé à la fin des années 1980, il a démontré son élasticité au fur et à mesure que le nombre d’hôtes et que le volume de trafic traité ont explosé. Des protocoles beaucoup plus récents, comme IPv6, sont capables d’utiliser le DNS avec uniquement des ajustements relativement mineurs.

Mais le DNS a deux gros points faibles : toutes les requêtes et réponses sont transmises en clair et l’authentification des réponses DNS est faible. Il a été tenté d’ajouter une couche de sécurité au DNS, avec les DNSSEC (Domain Name System Security Extensions). Elles s’avèrent très efficaces pour valider l’authenticité d’une réponse, mais il s’agit d’un protocole très complexe qui ne protège pas la confidentialité des échanges DNS.

L’infrastructure DNS distingue les serveurs de noms récursifs des serveurs de noms faisant autorité. Les utilisateurs se connectent généralement à un petit nombre de serveurs de noms récursifs exploités par leur fournisseur d’accès. Ces serveurs de noms récursifs obtiennent ensuite des réponses en se connectant à l’un des nombreux serveurs de noms faisant autorité et distribués sur Internet.

Du point de vue de la confidentialité, la connexion de l’utilisateur au serveur de noms récursif est essentielle. Toute personne capable d’effectuer une surveillance du trafic réseau entre l’utilisateur et un serveur de noms récursif pourra constituer un inventaire des requêtes lancées par l’utilisateur, donc de ses usages, et pourra également altérer à la volée les réponses retournées, de manière très ciblée.

Un client et un serveur TLS correctement configurés peuvent résister aux tentatives les plus récentes d’interception du trafic réseau. Pour autant, le protocole DNS – voire TLS lui-même, dans certains cas – divulgue encore certaines informations sensibles, par exemple, les sites Web que quelqu’un visite ou le système d’exploitation et le navigateur qu’il utilise pour visiter le site : ce protocole est devenu une source majeure de renseignements sur le trafic réseau.

Deux options de transport ont été utilisées pour améliorer la confidentialité du DNS. Traditionnellement, il utilise des paquets UDP simples et non chiffrés. Ce protocole de transport n’est pas aussi fiable que TCP, mais il est simple et parfaitement adapté à de petites requêtes et réponses, comme celles utilisées typiquement pour le DNS.

Mais l’usurpation est relativement aisée avec UDP, et le DNS n’a pas manqué être régulièrement détourné pour des attaques en déni de service (DoS) distribuées et par réflexion. Les requêtes DNS peuvent être beaucoup plus petites que les réponses ; un attaquant peut utiliser un certain nombre de petites requêtes en usurpant l’adresse de sa cible pour rediriger de grandes quantités de trafic vers celle-ci.

Face à ce risque, il y a les cookies DNS. Ceux-ci commencent à apparaître et à être fréquemment utilisés dans les implémentations de DNS. Ils empêchent certaines attaques basées sur l’usurpation d’identité en ajoutant une couche de protection additionnelle.

L’avantage des cookies DNS par rapport aux DNSSEC est qu’ils protègent non seulement contre certaines attaques d’usurpation d’identité, mais traitent aussi la question des attaques en déni de service par réflexion. Les cookies DNS sont par ailleurs très faciles à déployer. Mais ils ne fournissent pas l’authentification cryptographique forte qu’apporte DNSSEC et ils n’assurent pas la confidentialité du trafic DNS – à l’instar de DNNSEC.

Pour assurer la confidentialité du trafic DNS, c’est DNS sur TLS qui a reçu le soutien le plus important : il apporte à DNS ce que HTTPS a fait pour HTTP. Il utilise le protocole DNS existant, mais transmet les échanges dans un tunnel TLS protégé. Cela assure la confidentialité entre le client et les résolveurs récursifs. Ce protocole utilise le port UDP 853, au lieu du port 53 utilisé par défaut pour DNS. Par conséquent, l’utilisation de ce protocole peut être facilement détectée et bloquée.

Pour éviter ce type de blocage, HTTPS peut être utilisé comme mécanisme de transport. DNS sur HTTPS (DoH) utilise des requêtes et réponses HTTPS. Ce protocole masque non seulement le contenu des requêtes et des réponses DNS, mais il masque également le fait que DNS est utilisé. Le trafic DNS devient plus ou moins impossible à distinguer du trafic HTTPS. Le seul indice qu’un utilisateur utilise DoH est l’adresse IP du point de terminaison des requêtes.

L’un de ces points les plus populaires est exploité par Cloudflare. Mais ce dernier assure la terminaison HTTPS pour de nombreux sites Web. Du coup, il est encore plus difficile de distinguer HTTPS de DoH. En outre, les points de terminaison DoH peuvent être déployés dans n’importe quelle infrastructure cloud, ce qui rend encore plus difficile leur identification.

Les critiques de DoH relèvent qu’il augmente de manière significative le volume de trafic généré par les échanges DNS. De fait, chaque requête est encapsulée dans une requête HTTPS. Cela peut être moins problématique si de nouvelles versions du protocole, comme HTTP/2 et QUICare, sont utilisées, mais jusqu’à présent, les points de terminaison DoH semblent préférer continuer de s’appuyer sur HTTP/1.1.

Le client peut envoyer des données binaires encodées de la même manière qu’une requête DNS UDP traditionnelle ou des données JSON. De quoi ajouter au trafic réseau de manière substantielle, ainsi qu’à la puissance de calcul nécessaire à l’analyse des requêtes. Les réseaux ne seront alors pas en mesure d’extraire les informations à leurs mécanismes de défense sans une solution d’interception TLS robuste.

Pour la plupart des systèmes d’exploitation standard, il suffit d’installer un proxy TLS et d’ajouter une autorité de certification de confiance au terminal. Sous Windows, par exemple, cela peut être fait facilement avec une stratégie de groupe. Pour les objets connectés, en revanche, il peut être très difficile d’y parvenir, surtout à grande échelle.

Mais ce n’est pas seulement la surveillance du trafic réseau qui est affectée par ces nouveaux protocoles. Il y a aussi un risque souvent négligé pour les utilisateurs finaux. Avec des fournisseurs comme Cloudflare qui concentrent de plus en plus de trafic, il existe maintenant des points de concentration idéalement équipés pour faire ce que ces protocoles sont censés empêcher : inspecter le trafic réseau et mettre en danger la vie privée des utilisateurs.

Bien que Cloudflare assure expressément qu’il n’utilisera pas les données des clients, il n’y a aucune garantie technique à cela. Même si les fournisseurs agrégeant le trafic n’utilisent pas les données, la sécurité de leurs réseaux est critique. Une brèche chez l’un de ces fournisseurs pourrait avoir des conséquences considérables pour toute personne utilisant ses services.

Ce qui manque à ce stade, c’est une méthode pour diversifier ces services. Tor est probablement l’effort le plus connu pour accomplir cela à ce stade, mais ce n’est pas une solution viable pour la plupart des utilisateurs d’Internet.

De nouvelles technologies telles que TLS 1.3 et DNS sur TLS et HTTPS représentent des défis importants pour les approches traditionnelles de sécurité des réseaux basées sur une surveillance passive du trafic. La sécurité et la configuration des terminaux deviendront plus importantes pour contrôler ces technologies, et une interception TLS robuste constituera un outil important pour prévenir l’abus de ces technologies, et en particulier DoH.

À propos de l’auteur : Johannes Ullrich est membre de l’institut SANS et directeur du SANS Internet Storm Center (ISC), qui se consacre à la surveillance des activités malveillantes et des cyberattaques. En 2000, il a fondé DShield, un système collaboratif de corrélation des journaux d’activité de pare-feu, devenu depuis le socle de la collecte de données de l’ISC.