Close

TLS 1.3 et DNS chiffré : quels impacts pour le monitoring des réseaux des organisations ?

Les protocoles réseau qui sous-tendent la navigation Internet évoluent. Les protocoles de communication qui étaient jusque-là dépourvus de chiffrement, en acquièrent, et la robustesse de celui-ci se renforce pour les autres. L’IETF[1] a validé l’année dernière la version 1.3 du protocole TLS, qui permet le chiffrement des données de navigation HTTPS, et son déploiement est soutenu par Google et Mozilla qui le prennent déjà en charge dans leur navigateur. D’autre part, ces mêmes acteurs soutiennent également les protocoles DNS chiffrés que sont DoT (DNS over TLS) et DoH (DNS over HTTPS).

Si le chiffrement permet généralement un renforcement de la sécurité des échanges légitimes, il va cependant compliquer la tâche de surveillance du réseau à la recherche de flux malicieux.

Le déploiement de ces protocoles n’en est encore qu’à ses balbutiements, mais il semble bien enclenché. Quels sont les apports concrets de ces nouveaux protocoles et quelles conséquences leur déploiement aura-t-il pour la sécurité interne des organisations ?

Du TLS 1.2 au TLS 1.3

En mars 2018, 10 ans après la publication de TLS 1.2, l’IETF a approuvé la norme TLS 1.3. Ses principaux apports sont les suivants :

  • Une amélioration des performances. Le protocole TLS 1.3 ne nécessite qu’un seul aller-retour entre le client et le serveur pour établir une session sécurisée, là où la version 1.2 en nécessitait deux.
  • Une sécurité du chiffrement renforcée: Tous les protocoles de chiffrement obsolètes intégrés à TLS disparaissent se voient disparaître. En effet, lors de l’établissement d’une session TLS, le client et le serveur doivent commencer par s’accorder sur le protocole de chiffrement à utiliser. Il était important de faire disparaître ces protocoles, pour éviter les attaques alors courantes consistant à “convaincre” les cibles d’utiliser un protocole de chiffrement plus faible pour permettre l’écoute malveillantes d’une session TLS. Parmi les protocoles restants, tous offrent la confidentialité persistante (Forward Secrecy), ce qui signifie que la compromission de la clé privée du serveur ne compromet pas la confidentialité de l’ensemble des communications passées.

 

Jusqu’au protocole TLS 1.2, le plus répandu aujourd’hui, les solutions de sécurité internes aux organisations pouvaient se contenter d’une écoute passive du réseau pour surveiller le contenu des sessions TLS à destination de leurs serveurs. Il suffisait d’intégrer à la solution de sécurité la clé privée du serveur à protéger et de lui envoyer une copie du trafic réseau (mirroring). L’outil pouvait alors choisir les paquets à déchiffrer pour inspection, de façon complètement transparente pour les participants à la session TLS.

Du fait, du choix de n’intégrer dans TLS 1.3 que des protocoles de chiffrement PFS (Perfect Forward Secrecy), cette technique n’est plus applicable. Il devient nécessaire, pour inspecter les flux TLS, de placer la solution entre le client et le serveur, ce qui nécessite de déchiffrer et re-chiffrer l’ensemble de leurs échanges. Concrètement, la solution de sécurité devient un intermédiaire car elle établit deux sessions TLS : l’une avec le client, l’autre avec le serveur, ce qui n’est pas sans impact sur les performances de la session client/serveur. Et ce d’autant que cette technique doit être mise en œuvre dès l’ouverture de la session. De ce fait, il faudra généralement systématiser le procédé, une opération au coût computationnel qui peut être considérable selon les cas.

Les protocoles de chiffrement DNS : DoT et DoH

Les détournements DNS massifs révélés fin 2018 ont incité l’ICANN[2] à réagir en encourageant le déploiement global du protocole DNSSEC[3]. Celui-ci permet de répondre partiellement à la problématique des détournements DNS en établissant une chaîne de confiance entre les serveurs racines DNS et l’utilisateur final. Cependant, la réalité du schéma de déploiement de DNSSEC par les opérateurs (qui sont tentés de le dénaturer afin d’éviter d’éventuels échecs de résolution), couplé à l’absence de sa prise en charge par les navigateurs, prive l’utilisateur du dernier maillon de la chaîne de confiance du DNSSEC. En outre, le protocole DNSSEC n’intègre aucune fonctionnalité de chiffrement du contenu des échanges DNS, qu’il s’agisse des requêtes ou des réponses, ce qui ouvre la porte à d’éventuelles interceptions.

Le chiffrement des requêtes et réponses DNS qu’apportent ces nouveaux protocoles séduit pour plusieurs raisons :

  • Il apporte une garantie de protection de la vie privée des utilisateurs, dont les données de navigation ne sont plus accessibles aux acteurs qui contrôlent ne serait-ce qu’un seul élément réseau entre le poste client et son résolveur DNS. Notons cependant que le propriétaire du résolveur DNS (FAI, GAFAM par exemple) a toujours pour sa part accès à ces données. A ce titre, il n’est donc sans doute pas surprenant que Google et Cloudflare s’empressent d’intégrer ces nouveaux protocoles de DNS chiffrés et en fassent la promotion ;
  • Il assure l’intégrité des échanges DNS entre le client et son résolveur DNS. Les données n’étant pas lisibles par un hypothétique attaquant sur le réseau, elles ne peuvent pas être modifiées de façon à tromper l’utilisateur. Le chiffrement des requêtes et réponses DNS apporte donc une sécurité renforcée de la navigation, ainsi que de tout autre type de communication par Internet faisant usage du DNS.

Historiquement, DNSCrypt est le premier protocole de DNS chiffré à avoir été développé et déployé (principalement par OpenDNS, depuis racheté par Cisco). Cependant, ce sont aujourd’hui les protocoles DoT (DNS over TLS) et DoH (DNS over HTTPS) qui ont le vent en poupe, ayant été adoptés comme standards par l’IETF et étant soutenus par des acteurs majeurs du numérique tels que Google, Mozilla et Cloudflare (Mozilla et Cloudflare ont un partenariat pour le développement de DoT).

La différence majeure entre DoT et DoH réside dans le port utilisé, et ceci intéresse directement la surveillance du réseau :

  • Le DoT utilise un port réseau spécifique (le 853), ce qui facilite le monitoring légitime des organisations en interne, en permettant de distinguer le flux DNS ;
  • Le DoH, comme son nom l’indique, se mêle au trafic HTTPS du port 443. Il vise spécifiquement à empêcher la surveillance du réseau, partant du principe que l’adversaire (notamment quand il s’agit d’un acteur étatique) ne pourra pas se permettre de couper le trafic HTTPS – donc Internet, et donc perdra sa capacité à tracer la navigation de l’utilisateur qui l’emploie.

Les flux DNS font partie des premiers éléments qui intéressent les équipes de sécurité dans le cadre de la surveillance réseau d’une organisation. Face à ces nouveaux protocoles, celle dernière devra intégrer des solutions de sécurité adaptées à ceux-ci. Quoiqu’il en soit, le DoH impliquera nécessairement une majeure partie du trafic HTTPS afin de pouvoir continuer à surveiller les flux DNS.

Développement de solutions alternatives de surveillance des réseaux.

Face à la démocratisation des flux chiffrés, les outils de sécurité réseau commencent à intégrer des capacités d’analyse sans déchiffrement des flux. Il va s’agir de s’intéresser aux métadonnées intra-flux comme la longueur des messages ou l’intervalle de temps entre deux paquets, mais aussi par exemple aux données contenues dans le premier paquet de chaque flux, car il contient généralement des informations non chiffrées sur le flux. Evidemment, cela restera en-deçà des capacités d’analyse disponibles avec un flux qu’il est possible de déchiffrer.

Le développement de ces capacités d’analyse des flux chiffrés est d’autant plus important que les flux chiffrés malveillants bénéficient de la démocratisation des protocoles chiffrés, qui facilitent leur camouflage aux côtés des flux légitimes.

L’arrivée des protocoles de chiffrement DNS et du TLS 1.3 ne rend pas impossible la surveillance réseau, mais nécessitera certainement une adaptation, à savoir une révision de l’architecture de sécurité et le déploiement de produits prenant en compte les évolutions des protocoles. Les améliorations apportées par ces protocoles ont en effet un coût…

[1] (Internet Engineering Task Force – groupe de normalisation rattaché à l’Internet Society)

[2] Internet Corporation for Assigned Names and Numbers, autorité de régulation de l’Internet

[3] Domain Name System Security Extensions, un protocole standardisé qui permet de résoudre plusieurs problèmes de sécurité liés au protocole DNS.