Avec les objets connectés, le problème est encore plus net. Ces appareils ne se contentent pas d’envoyer ou de recevoir une commande ponctuelle : ils maintiennent souvent des échanges réguliers avec des services distants, des systèmes de mise à jour, des mécanismes d’authentification, des serveurs de temps ou des infrastructures cloud liées au fabricant. La CNIL rappelle d’ailleurs que les objets connectés génèrent une grande quantité de données et qu’ils peuvent avoir un impact direct sur la vie privée, y compris dans des usages très ordinaires comme les assistants vocaux, les téléviseurs connectés ou les compteurs communicants. (cnil.fr)
Autrement dit, la bonne question n’est pas seulement : “Est-ce que le trafic est chiffré ?” La vraie question est plutôt : “Que peut-on encore déduire du comportement réseau de l’appareil, même sans lire le contenu des échanges ?” C’est là qu’entrent en jeu le DNS, l’IPv6, les flux d’arrière-plan, la dépendance au cloud et, plus largement, toute l’architecture technique qui entoure l’objet connecté.
Ce que le chiffrement protège réellement
Il faut être précis : dire que le chiffrement ne rend pas un objet “invisible” ne revient pas à dire qu’il ne sert à rien. TLS et HTTPS restent essentiels, parce qu’ils protègent le contenu échangé entre le client et le service distant contre une partie des interceptions et modifications en transit. Sans eux, le niveau d’exposition serait bien pire. Mais ce bénéfice ne doit pas être confondu avec une disparition des métadonnées réseau. (datatracker.ietf.org)
Ce que le réseau continue souvent de laisser voir, ce n’est pas forcément ce qui est dit, mais qu’il se passe quelque chose, à quel moment, à quelle fréquence, vers quelle famille de services et parfois dans quelle logique fonctionnelle. Un observateur placé au bon endroit — par exemple un résolveur DNS, un administrateur réseau, un routeur ou un fournisseur d’accès selon le contexte — peut encore tirer des indications utiles à partir des destinations contactées, des rythmes de connexion et des dépendances techniques visibles. L’IETF rappelle d’ailleurs que le DNS soulève des enjeux de vie privée spécifiques et que son usage est profondément ancré dans presque toute activité Internet.
C’est précisément pour cette raison que les efforts récents pour mieux masquer certaines informations dans TLS ne suffisent pas à eux seuls. L’IETF note, dans ses travaux sur l’Encrypted Client Hello, que le chiffrement d’informations comme le nom de serveur est beaucoup moins utile si les requêtes DNS, elles, restent observables en transit. C’est une remarque importante : elle montre bien que la confidentialité réelle ne dépend pas d’une seule couche, mais d’un ensemble cohérent de choix techniques.
La conséquence est simple, mais souvent mal comprise : un objet connecté peut chiffrer correctement son trafic et rester pourtant très bavard sur le plan comportemental. Le chiffrement protège le message ; il ne corrige ni la dépendance au cloud, ni la fréquence de la télémétrie, ni la logique applicative du produit. Quand un fabricant a conçu un appareil pour dialoguer en permanence avec son infrastructure, le tunnel chiffré ne transforme pas ce design en modèle de discrétion.
Le DNS : premier révélateur d’activité
Le DNS est souvent présenté comme un simple annuaire de l’Internet. C’est vrai, mais c’est une définition beaucoup trop pauvre pour comprendre son intérêt dans l’analyse des objets connectés. En pratique, le DNS sert de point d’entrée à une grande partie des communications réseau : avant d’atteindre une API, un service cloud, un serveur de mise à jour ou une infrastructure de télémétrie, l’appareil doit généralement résoudre un nom de domaine. L’IETF résume ce point de manière limpide : presque toute activité sur Internet commence par une requête DNS, et souvent par plusieurs. (datatracker.ietf.org)
C’est ce qui fait du DNS un révélateur particulièrement utile. Même sans accès au contenu des échanges applicatifs, les requêtes DNS peuvent renseigner sur l’écosystème technique d’un appareil : constructeur, prestataires tiers, services d’analyse, distribution de mises à jour, authentification, CDN, voire coexistence de plusieurs briques cloud derrière un même produit. L’ICANN rappelle d’ailleurs que la composition des requêtes et les schémas de trafic DNS peuvent, à eux seuls, révéler des signaux d’activité suffisamment parlants pour détecter des comportements anormaux sur un réseau. Ce constat vaut aussi, à un niveau différent, pour des objets connectés simplement très bavards ou fortement dépendants de services distants.
Dans un environnement domestique, cela signifie qu’une caméra peut laisser entrevoir ses routines de fonctionnement sans que son flux vidéo soit lisible ; qu’un assistant vocal peut trahir sa dépendance à plusieurs services distants sans exposer le détail des commandes prononcées ; ou qu’un téléviseur connecté peut multiplier les résolutions DNS vers des services que l’utilisateur ne soupçonnait même pas. La CNIL insiste depuis longtemps sur le fait que ces appareils peuvent avoir un impact concret sur la vie privée précisément parce qu’ils génèrent, transmettent et centralisent une quantité importante de données et de signaux d’usage.
Il faut aussi éviter un autre contresens : le DNS n’est pas seulement une question de “nom de domaine vu ou non vu”. C’est aussi une question d’architecture de confiance. Qui résout les noms ? Le routeur ? Le fournisseur d’accès ? Un résolveur tiers ? Un mécanisme chiffré ? Un service imposé par l’écosystème logiciel ? Tant que cette couche reste mal comprise, beaucoup d’utilisateurs surestiment la discrétion réelle de leurs objets connectés. Et tant que le DNS reste observable ou centralisé chez un acteur donné, une partie du comportement réseau de ces appareils reste, elle aussi, observable ou au moins largement inférable.
IPv6 : une couche réseau différente, pas un détail cosmétique
IPv6 n’est pas un “IPv4 un peu plus moderne”. Sa logique d’adressage est propre : le protocole repose sur des adresses de 128 bits et distingue notamment des adresses unicast, anycast et multicast. Ce n’est pas un simple changement de format ; c’est une autre architecture, avec ses mécanismes de découverte, de configuration et de circulation du trafic. (datatracker.ietf.org, datatracker.ietf.org)
Dans un réseau domestique ou professionnel où IPv6 est activé, un objet connecté ne se contente pas de “recevoir une IP”. Les nœuds IPv6 utilisent le Neighbor Discovery Protocol pour découvrir la présence d’autres machines, trouver les routeurs et maintenir des informations de joignabilité sur le lien local. L’autoconfiguration sans état permet ensuite à un hôte de générer ses adresses à partir des informations reçues sur le réseau, notamment via les annonces du routeur.
Ce point est important pour la vie privée parce qu’il change la surface technique réelle du problème. Avec IPv6, un objet peut disposer d’une adresse link-local, puis d’une ou plusieurs adresses valides pour communiquer au-delà du segment local, tout en apprenant aussi certains paramètres réseau par les mécanismes propres à IPv6. Le standard prévoit même que les routeurs IPv6 puissent annoncer aux hôtes la liste des résolveurs DNS récursifs et la search list via des options dédiées dans les Router Advertisements.
Autrement dit, IPv6 n’est pas un “risque” par nature. Le vrai risque apparaît quand une politique réseau a été pensée surtout pour IPv4, tandis que les flux IPv6, eux, continuent d’exister, de se configurer et de se résoudre selon leur propre logique. Dans ce cas, on ne parle pas d’un bug magique d’IPv6, mais d’un angle mort opérationnel : filtrage incomplet, politique DNS inégale, observation partielle du trafic, ou sentiment trompeur de contrôle parce qu’une partie seulement de la pile réseau a été prise en compte. Cette conclusion est une déduction technique raisonnable à partir du fait qu’IPv6 a ses propres mécanismes d’adressage, de découverte et de configuration.
Pour les objets connectés, cette différence compte d’autant plus qu’ils sont rarement conçus pour être lisibles du point de vue de l’utilisateur. Quand un appareil se connecte, découvre le routeur, apprend sa configuration, résout des noms, contacte un cloud et maintient des échanges de fond, ce n’est pas “IPv6” seul qui pose question. Ce qui compte, c’est la combinaison entre adressage, résolution, dépendance applicative et services distants. Réduire l’analyse à “le trafic est chiffré” fait donc passer à côté d’une partie de l’architecture réelle.
Exemple : ce qu’une caméra connectée peut faire au démarrage
Prenons maintenant un exemple volontairement schématique. Il ne décrit pas un modèle précis, mais une séquence techniquement plausible pour une caméra connectée moderne dépendante d’un service cloud. L’intérêt n’est pas de prétendre que tous les produits se comportent exactement ainsi ; l’intérêt est de montrer combien d’étapes réseau existent avant même de parler d’image, d’audio ou de chiffrement applicatif.
Au démarrage, la caméra peut d’abord se doter d’une adresse IPv6 link-local, puis utiliser les mécanismes de Neighbor Discovery pour identifier le routeur du segment et recevoir les informations utiles à sa configuration. Si le réseau lui fournit ensuite un préfixe global par autoconfiguration, elle peut très vite devenir capable d’émettre vers l’extérieur sans que l’utilisateur ait forcément conscience de toute la chaîne qui vient de se mettre en place.
La deuxième étape plausible est la résolution de noms. La caméra peut interroger un résolveur DNS afin de retrouver l’adresse des services du constructeur : API d’authentification, infrastructure de gestion, point de terminaison de télémétrie, serveur de mise à jour ou service de notification. Le DNS joue ici son rôle habituel de porte d’entrée vers les services distants ; c’est précisément pour cela qu’il révèle déjà une partie de l’écosystème technique de l’appareil.
Elle peut ensuite synchroniser son horloge via NTP, ce qui est banal mais loin d’être anodin : NTP est largement utilisé pour synchroniser les horloges des machines sur Internet, et cette synchronisation conditionne souvent la validité des certificats, des journaux d’événements et d’une partie des mécanismes de sécurité. (rfc-editor.org)
Une fois ces prérequis en place, la caméra peut ouvrir une connexion TLS vers un service du constructeur pour s’authentifier, récupérer sa configuration, vérifier l’état de son compte, signaler sa disponibilité ou chercher une mise à jour. Même si le contenu de cette session est chiffré, la succession logique des étapes reste partiellement lisible au niveau réseau : requêtes DNS, contact avec l’infrastructure de temps, ouverture de sessions vers des endpoints distants, puis maintien périodique d’une présence en ligne. Le fait qu’ECH améliore la confidentialité de certaines informations dans l’établissement d’une connexion TLS ne change pas le fond du problème si le DNS et les autres signaux restent observables.
Enfin, selon son design, la caméra peut aussi utiliser des mécanismes locaux comme mDNS pour la découverte sur le réseau local, par exemple lorsqu’une application doit la repérer automatiquement sans serveur DNS classique. Là encore, cela ne signifie pas forcément “danger”, mais cela rappelle qu’un objet connecté n’échange pas uniquement avec “une appli” ou “un cloud” : il peut aussi produire de la signalisation locale, en parallèle de ses échanges distants.
Le point important est donc celui-ci : avant même que l’utilisateur consulte une image en direct, le réseau a déjà pu observer une séquence faite d’autoconfiguration, de découverte, de résolution, de synchronisation et de connexion à des services tiers. C’est exactement pour cela qu’un objet connecté peut être correctement chiffré tout en restant partiellement interprétable du point de vue de son comportement.
Pourquoi “c’est en HTTPS” ne suffit pas comme réponse
Dire qu’un objet connecté utilise HTTPS est utile, mais très loin d’être suffisant. HTTPS protège le contenu applicatif transporté par TLS ; il ne transforme pas pour autant l’appareil en boîte noire. L’IETF souligne explicitement que la confidentialité du DNS reste un problème propre, et que l’activité Internet commence très souvent par des requêtes DNS. Autrement dit, une partie de ce qu’un objet “raconte” sur le réseau se joue avant même la session HTTPS elle-même. (datatracker.ietf.org)
C’est précisément ce qui rend le raccourci trompeur. Un objet peut très bien chiffrer correctement ses échanges tout en restant facile à interpréter sur le plan comportemental : domaines contactés, fréquence des communications, dépendance à un cloud, maintien de session, appels de synchronisation, découverte locale. Le chiffrement protège le message ; il ne supprime ni la logique applicative du produit ni la visibilité laissée par ses métadonnées réseau. L’IETF le reconnaît d’ailleurs indirectement dans le RFC sur Encrypted Client Hello : même si certaines informations du handshake TLS sont mieux protégées, l’intérêt est réduit si le DNS reste observable en clair.
Il faut aussi éviter un autre contresens : HTTPS ne dit rien, à lui seul, sur la qualité d’ensemble du produit. Un fabricant peut chiffrer ses flux tout en imposant une forte dépendance à son cloud, des permissions excessives côté application, un support logiciel médiocre ou une architecture qui multiplie les points de contact inutiles. Le NCSC rappelle justement, dans ses principes de sécurité pour les appareils connectés, qu’il faut adopter une lecture holistique du design : sécuriser des composants isolés ne garantit pas la sécurité de l’architecture globale. (ncsc.gov.uk)
En pratique, “c’est en HTTPS” répond donc à une question plus étroite que celle que se pose vraiment un lecteur soucieux de sa vie privée. La vraie question n’est pas seulement : “le contenu est-il chiffré ?” La vraie question est : “qu’est-ce que l’appareil continue de révéler par sa manière de fonctionner, par les services qu’il appelle et par l’écosystème auquel il reste attaché ?” Tant que cette distinction n’est pas faite, beaucoup d’analyses donnent une impression de sécurité supérieure à la réalité.
Ce qu’un utilisateur peut réellement reprendre en main
La première chose à reprendre en main, ce n’est pas un réglage miracle : c’est la lecture du problème. Un objet connecté moins intrusif n’est pas seulement un objet “chiffré”, mais un objet qui limite sa dépendance au cloud, documente son fonctionnement, reçoit des mises à jour sérieuses et laisse une marge de contrôle à l’utilisateur. Le NCSC recommande d’ailleurs d’évaluer les appareils selon des principes comme les mises à jour sécurisées, la transparence de l’état du dispositif, la limitation des privilèges et les capacités de journalisation ou de gestion.
La deuxième reprise en main concerne le réseau domestique. Séparer les objets connectés du reste de son réseau n’est pas une lubie de passionné : c’est souvent la mesure la plus rationnelle quand on veut limiter les conséquences d’un appareil trop bavard ou mal conçu. La FTC recommande elle-même l’usage d’un réseau invité distinct, notamment pour réduire l’exposition du réseau principal. Pour une maison connectée, cette logique peut être poussée plus loin : TV, caméras, assistants vocaux et autres appareils peu sensibles au partage local n’ont pas besoin d’être mélangés sans distinction avec les ordinateurs de travail ou les téléphones personnels. (consumer.ftc.gov)
La troisième reprise en main porte sur les dépendances invisibles : DNS, IPv6, services tiers, mises à jour et découverte locale. Il ne s’agit pas d’exiger que chaque lecteur audite ses paquets comme un analyste réseau, mais de comprendre que ces couches existent et qu’elles méritent d’être vérifiées quand on choisit un appareil ou qu’on le déploie. Un produit qui ne fonctionne qu’avec un compte obligatoire, qui cache mal ses flux, qui dépend massivement d’un cloud et qui documente peu ses mécanismes de support mérite d’être regardé avec plus de distance qu’un produit plus transparent et plus local-first. Les principes du NCSC insistent justement sur la nécessité de réponses précises, transparentes et étayées, pas sur des promesses vagues.