# Chiffrement et trafic chiffré (FAQ)

> 40 questions sur Chiffrement et trafic chiffré, en langage clair : quoi vérifier, ce que montre NetSenX et ce qu'une sonde ne voit pas.

Source page: https://netsenx.com/fr/faq/encryption

## NetSenX détecte-t-il les menaces dans le trafic chiffré ?

Oui, à partir des métadonnées : le trafic chiffré n'est jamais déchiffré. NetSenX examine les métadonnées de flux et quelques champs de protocole — rythme, volume, destinations et handshake TLS —, de sorte que le beaconing et les transferts inhabituels restent visibles sans casser le chiffrement ni lire le contenu.

https://netsenx.com/fr/faq/can-netsenx-detect-threats-in-encrypted-traffic

## Un NDR peut-il détecter des menaces dans le trafic chiffré sans le déchiffrer ?

Oui, à partir des métadonnées. Le rythme, le volume, les destinations et le handshake TLS restent visibles lorsque le contenu est chiffré : le beaconing vers un serveur C2 et les transferts inhabituels peuvent donc être détectés sans casser le chiffrement. Le contenu de la session, lui, reste invisible.

https://netsenx.com/fr/faq/can-ndr-detect-threats-in-encrypted-traffic-without-decrypting-it

## Que lit NetSenX dans une connexion chiffrée ?

Les métadonnées de flux (qui se connecte à qui, quand, à quelle fréquence et avec quel volume de données) et quelques champs de protocole : le nom du serveur et les paramètres du handshake TLS, ainsi que les réponses aux requêtes DNS. NetSenX ne déchiffre jamais la session et n'en lit pas le contenu chiffré.

https://netsenx.com/fr/faq/what-does-netsenx-read-from-an-encrypted-connection

## Faut-il déchiffrer TLS pour détecter les menaces ?

Pas pour beaucoup d'entre elles. Qui parle à qui, quand, à quelle fréquence et avec quel volume, ainsi que la négociation TLS non chiffrée et les réponses DNS, restent visibles sans déchiffrement. Cela suffit pour voir le beaconing vers un serveur de commande et de contrôle, les balayages, les mouvements latéraux entre hôtes internes et les envois inhabituels, soit des étapes que franchissent la plupart des intrusions avant de faire des dégâts. Le déchiffrement est nécessaire pour voir le contenu, comme un fichier malveillant dans un téléchargement ou le texte d'une commande, et il a un coût : un proxy d'interception qui détient clés et données déchiffrées, un certificat d'entreprise sur chaque appareil géré, des applications qui cessent de fonctionner, des questions de vie privée et de dialogue social, et des angles morts sur les appareils non gérés. Beaucoup d'entreprises tirent plus de valeur d'une protection des terminaux pour les fichiers et processus de chaque machine, et d'une détection réseau pour le comportement de tous les appareils. NetSenX ne déchiffre jamais le trafic : ses détections de base fonctionnent dans chaque offre, et les empreintes TLS dès l'offre Starter là où l'agent capture les paquets.

https://netsenx.com/fr/faq/do-i-need-tls-decryption-to-detect-threats

## Pourquoi ne pas déchiffrer le trafic TLS pour l'inspecter ?

Le déchiffrement donne accès au contenu, mais il impose un point d'interception qui détient des clés, un certificat d'interception sur chaque appareil et la gestion d'un contenu déchiffré pouvant inclure des données personnelles. Depuis TLS 1.3, un capteur passif ne peut plus déchiffrer les sessions avec une copie de la clé privée du serveur.

https://netsenx.com/fr/faq/why-not-decrypt-tls-traffic-for-inspection

## Que casse l'inspection TLS sur un pare-feu ?

Plus qu'on ne le pense. Pour inspecter HTTPS, le pare-feu ou le proxy termine chaque connexion, la déchiffre, l'inspecte et ouvre une nouvelle connexion chiffrée vers le vrai serveur, en présentant son propre certificat signé par une racine d'entreprise installée sur chaque appareil géré. Effets secondaires : les applications avec épinglage de certificat, beaucoup de mécanismes de mise à jour, certaines applications bancaires et de santé et une partie des services cloud refusent le certificat de substitution, si bien que les listes d'exceptions s'allongent sans cesse ; les appareils non gérés, les invités et les machines ne peuvent pas être inspectés du tout ; le proxy devient un point unique qui détient du trafic déchiffré, y compris des données personnelles, ce qui soulève des questions RGPD et de dialogue social ; les proxys anciens peuvent ne pas prendre en charge les fonctions récentes de TLS ou les nouveaux groupes hybrides post-quantiques et affaiblir discrètement les connexions ; et l'inspection coûte en performances. Elle garde sa place, par exemple pour analyser les téléchargements sur des portables gérés. Mais beaucoup de menaces sont visibles sans elle. C'est l'approche de NetSenX : il ne déchiffre jamais et travaille à partir des métadonnées et de la négociation non chiffrée.

https://netsenx.com/fr/faq/what-does-tls-inspection-on-a-firewall-break

## L'inspection approfondie des paquets fonctionne-t-elle sur le trafic chiffré ?

Seulement sur les parties non chiffrées, sauf à déchiffrer. L'inspection approfondie des paquets (DPI) consiste à lire au-delà des en-têtes, dans le contenu. Avec TLS, le contenu est chiffré : les signatures classiques qui cherchent un fichier ou une commande malveillante dans le flux ne correspondent plus. Restent lisibles les messages de négociation non chiffrés, avec la version de TLS, les choix de chiffrement et d'échange de clés, une empreinte du client et en général le nom du serveur, ainsi que les réponses DNS qui ont précédé la connexion. Combiné aux métadonnées de flux, c'est-à-dire qui, quand, à quelle fréquence et combien, cela suffit pour de nombreuses détections : beaconing vers un serveur de commande et de contrôle, balayages, mouvements latéraux et envois inhabituels. Pour voir le contenu, il faut un proxy d'interception qui déchiffre et rechiffre le trafic, avec ses propres coûts et risques. NetSenX lit les champs de la négociation là où son agent capture les paquets, sous Linux ou en sonde SPAN/TAP, pas en mode de base sous macOS, et ne déchiffre jamais le trafic.

https://netsenx.com/fr/faq/can-deep-packet-inspection-work-on-encrypted-traffic

## Peut-on détecter un logiciel malveillant à partir des seules statistiques de flux ?

Souvent, oui, car un logiciel malveillant doit se comporter d'une certaine façon pour être utile, et ce comportement se voit dans les flux. Les enregistrements de flux décrivent chaque connexion : source et destination, ports, heure de début, durée, octets et paquets dans chaque sens. Un appareil compromis qui contacte son serveur de contrôle à intervalles réguliers produit un rythme reconnaissable, le beaconing ; un appareil qui explore le réseau touche beaucoup d'hôtes et de ports internes en peu de temps, ce qui correspond au balayage et aux mouvements latéraux ; un appareil qui vole des données envoie bien plus que d'habitude, souvent la nuit. Rien de cela ne nécessite de déchiffrement, et la recherche sur l'analyse du trafic chiffré montre depuis des années que les motifs de temps et de taille portent beaucoup d'information. Les limites : une connexion isolée vers un service cloud connu peut sembler anodine, et les attaquants patients cherchent à se fondre dans la masse. C'est pourquoi l'analyse de flux fonctionne mieux par rapport à une référence de ce qui est normal pour chaque appareil. NetSenX détecte le beaconing, les balayages, les mouvements latéraux et les volumes sortants inhabituels dans chaque offre, y compris Free.

https://netsenx.com/fr/faq/can-malware-be-detected-from-flow-statistics

## Le trafic chiffré peut-il révéler ce qu'il contient ?

Pas le contenu, mais plus de choses à son sujet qu'on ne le croit. Le chiffrement cache les mots, les fichiers et les frappes au clavier, pourtant la taille, le moment et le sens des paquets laissent fuir des motifs : un appel vidéo, un gros envoi, une session de bureau à distance et une mise à jour logicielle ont chacun une forme reconnaissable. Les chercheurs montrent depuis des années qu'une telle analyse de trafic peut identifier, avec une précision variable, les sites visités ou les applications utilisées, même à travers un VPN. Pour la défense, c'est utile : c'est ainsi qu'un capteur réseau distingue une session interactive d'un contact automatique, ou remarque un serveur qui envoie soudain des gigaoctets, sans rien déchiffrer. Pour la vie privée, c'est un rappel que chiffrement ne veut pas dire invisibilité. Ce que l'analyse de trafic ne peut pas faire : lire un message, voir quel fichier a été envoyé ou savoir ce que quelqu'un a tapé dans un chatbot d'IA. NetSenX utilise les métadonnées de flux et la négociation non chiffrée, ne déchiffre jamais les sessions et ne reconstitue aucun contenu.

https://netsenx.com/fr/faq/can-encrypted-traffic-reveal-what-is-inside

## Les métadonnées réseau sont-elles des données personnelles au sens du RGPD ?

Elles peuvent l'être. Dans l'arrêt Breyer (affaire C-582/14, 19 octobre 2016), la Cour de justice de l'UE a jugé qu'une adresse IP dynamique peut constituer une donnée à caractère personnel. NetSenX publie un accord de traitement des données au titre de l'article 28 du RGPD et conserve les données clients dans l'UE.

https://netsenx.com/fr/faq/is-network-metadata-personal-data-under-gdpr

## Peut-on attraper un logiciel malveillant sur un site HTTPS ?

Oui. HTTPS signifie que la connexion est chiffrée et que le serveur détient un certificat valide pour le nom affiché dans la barre d'adresse ; cela ne dit rien de la sûreté du site ou de ses téléchargements. Les attaquants utilisent HTTPS aussi couramment que tout le monde, car les certificats sont gratuits et automatisés, et une grande partie de l'hameçonnage et de la diffusion de logiciels malveillants passe par là. Le cadenas vous protège contre quelqu'un qui lirait ou modifierait le trafic en chemin, pas contre le contenu à l'autre bout. La protection contre les téléchargements malveillants vient de la protection du terminal, du filtrage dans le navigateur et la messagerie, de logiciels à jour et de la limitation de qui peut installer des programmes. Côté réseau, le chiffrement cache le fichier mais pas le comportement qui suit en général une infection : un appareil qui contacte soudain une nouvelle destination à intervalles réguliers, balaie des hôtes internes ou envoie des volumes de données inhabituels. NetSenX détecte ces comportements dans chaque offre, à partir des métadonnées de flux et sans déchiffrer le trafic.

https://netsenx.com/fr/faq/can-you-get-malware-from-an-https-website

## Le trafic HTTPS peut-il être intercepté par une attaque de l'homme du milieu ?

Seulement si l'on peut amener le client à faire confiance à l'intercepteur. Une attaque de l'homme du milieu sur HTTPS exige un certificat que le client accepte pour le nom visé, un utilisateur qui passe outre l'avertissement ou une application qui vérifie mal les certificats. Les entreprises le font volontairement avec des proxys d'inspection TLS, en installant leur propre certificat racine sur les appareils gérés. Les attaquants tentent la même chose en implantant un faux certificat racine via un logiciel malveillant, en poussant les utilisateurs à accepter les avertissements ou en exploitant des applications qui vérifient mal les certificats. Défenses : n'habituez jamais le personnel à ignorer les avertissements de certificat, contrôlez quels certificats racines sont installés sur les appareils de l'entreprise, tenez les applications à jour et utilisez HTTP Strict Transport Security (HSTS) sur vos sites pour que les navigateurs refusent les connexions non chiffrées. L'épinglage de certificat dans certaines applications refuse tout intercepteur, y compris votre propre proxy. En TLS 1.3, le certificat du serveur est chiffré : un capteur réseau passif ne peut pas vérifier qui l'a émis ; ce contrôle se fait sur l'appareil ou dans les journaux du proxy.

https://netsenx.com/fr/faq/can-https-traffic-be-intercepted

## Qu'est-ce que l'empreinte TLS JA4 ?

Quand un programme ouvre une connexion TLS, son premier message liste les versions, suites de chiffrement et extensions qu'il prend en charge, dans un ordre caractéristique. Une empreinte comme JA4 condense ce message en une courte chaîne, ce qui permet de reconnaître le même logiciel client d'une connexion à l'autre sans rien déchiffrer. Cela aide à repérer des clients inhabituels, comme un script qui se fait passer pour un navigateur. NetSenX calcule les empreintes TLS à partir de la négociation dès l'offre Starter, avec sa propre implémentation. La négociation n'est visible que là où l'agent capture les paquets : sous Linux ou comme sonde sur un port SPAN ou TAP, pas dans le mode de base utilisé sous macOS.

https://netsenx.com/fr/faq/what-is-ja4-tls-fingerprinting

## Quelle différence entre JA3 et JA4 ?

Tous deux établissent une empreinte du côté client d'une négociation TLS, mais JA4 s'adapte au comportement des navigateurs modernes. JA3, publié en 2017, calcule un hachage des champs du ClientHello dans l'ordre où ils apparaissent. Depuis début 2023, Chrome mélange l'ordre des extensions TLS à chaque connexion, ce qui change la valeur JA3 à chaque fois et la rend bien moins utile pour reconnaître les navigateurs. JA4, publié en 2023, trie les champs avant le hachage, ajoute la version de TLS, le transport (TCP ou QUIC) et le premier protocole applicatif proposé, et produit une chaîne lisible dont les parties se comparent séparément. Aucun ne prouve à lui seul une intention malveillante : beaucoup de programmes partagent une empreinte, et un logiciel malveillant peut imiter un navigateur. Ils servent à repérer un client qui ne correspond pas à l'appareil, comme un script se faisant passer pour un navigateur sur un serveur. NetSenX calcule les empreintes TLS dès l'offre Starter, avec sa propre implémentation, là où son agent capture les paquets : sous Linux ou en sonde SPAN/TAP, pas en mode de base sous macOS.

https://netsenx.com/fr/faq/what-is-the-difference-between-ja3-and-ja4

## Qu'est-ce que le SNI et pourquoi compte-t-il pour la surveillance ?

Le Server Name Indication (SNI) est un champ du ClientHello TLS dans lequel le client nomme le site qu'il veut joindre, par exemple login.example.com, parce que de nombreux sites partagent une même adresse IP et que le serveur doit savoir quel certificat présenter. Il est envoyé avant le début du chiffrement, donc lisible par quiconque se trouve sur le chemin. Pour la surveillance, c'est l'un des champs les plus utiles du trafic chiffré : il nomme le service derrière une adresse IP, ce qui aide à distinguer un assistant d'IA, un site de partage de fichiers ou une application métier connue d'un serveur inconnu, sans lire aucun contenu. La plupart des filtres web et beaucoup de pare-feu s'appuient aussi dessus. Deux choses réduisent sa valeur : les connexions directes vers une adresse IP ne portent pas de nom utile, et l'Encrypted Client Hello (ECH) cache le vrai nom derrière un nom public de façade. Les réponses DNS et l'historique de chaque destination comptent alors davantage. NetSenX lit le nom du serveur dans la négociation là où son agent capture les paquets, sous Linux ou en sonde SPAN/TAP.

https://netsenx.com/fr/faq/what-is-sni-and-why-does-it-matter-for-monitoring

## Qu'est-ce que l'Encrypted Client Hello (ECH) ?

ECH est une extension de TLS qui chiffre la partie sensible du ClientHello, y compris le vrai nom du serveur, avec une clé publique que le site publie dans le DNS. Sur le réseau, un observateur ne voit qu'un ClientHello extérieur portant un nom public partagé, en général celui du réseau de diffusion de contenu qui héberge le site, au lieu du site réel. Il a été conçu pour la vie privée : empêcher quiconque sur le chemin, du Wi-Fi d'un café au fournisseur d'accès, de savoir quel site vous visitez. Les grands navigateurs le prennent en charge et certains grands réseaux de diffusion de contenu le proposent : une part du trafic web l'utilise déjà, alors que la plupart des serveurs d'entreprise et internes ne l'utilisent pas. ECH va en général de pair avec le DNS chiffré, faute de quoi le nom fuiterait encore par la requête DNS. Le certificat et le contenu de la session étaient déjà chiffrés en TLS 1.3 ; ECH ferme l'un des derniers champs lisibles. Pour les équipes de sécurité, cela signifie moins de noms et davantage de recours au comportement.

https://netsenx.com/fr/faq/what-is-encrypted-client-hello

## L'Encrypted Client Hello rend-il la surveillance réseau aveugle ?

En partie. Avec ECH, un capteur ne voit plus le vrai nom du serveur dans la négociation : les règles fondées sur les noms, les filtres web et les listes simples de shadow IT perdent en précision pour les sites qui l'utilisent. Il reste beaucoup : l'adresse IP de destination et son exploitant, le nom public extérieur, en général celui d'un grand réseau de diffusion de contenu, les réponses DNS quand le DNS n'est pas chiffré de bout en bout, le moment, le volume et le sens de chaque flux, et l'empreinte du client. Les détections comportementales comme le beaconing, les balayages, les mouvements latéraux et les envois inhabituels ne dépendent pas du nom du serveur et continuent de fonctionner. Le trafic interne est rarement concerné, car les serveurs internes publient rarement des clés ECH. Sur les appareils gérés, vous avez la main : faites-leur utiliser votre propre résolveur DNS et appliquez les politiques d'entreprise du navigateur, qui permettent de contrôler ECH et le DNS chiffré. La visibilité par nom des services d'IA ou de partage de fichiers devient moins complète pour les sites derrière ECH, pour tout capteur réseau, NetSenX compris.

https://netsenx.com/fr/faq/does-encrypted-client-hello-blind-network-monitoring

## QUIC et HTTP/3 rendent-ils les pare-feu aveugles ?

Ils réduisent ce que voient les pare-feu anciens, sans rendre le trafic invisible. QUIC (RFC 9000, 2021) est le transport sous HTTP/3. Il passe par le port UDP 443 et chiffre presque tout, y compris une grande partie de ce que TCP laissait lisible, comme les numéros de paquets et les accusés de réception. Ses premiers paquets portent un ClientHello TLS 1.3 protégé uniquement par des clés que tout le monde peut dériver : un capteur qui comprend QUIC peut donc encore lire le nom du serveur et les paramètres de négociation. Les pare-feu et proxys conçus pour TCP ne savent souvent pas inspecter QUIC du tout. Dans les entreprises qui s'appuient sur l'inspection TLS ou le filtrage web, la pratique courante consiste à bloquer le port UDP 443, ce qui fait revenir les navigateurs à HTTP/2 sur TCP sans que les utilisateurs le remarquent. Sans une telle règle, QUIC apparaît simplement comme des flux UDP, avec horaires et volumes comme tout autre trafic, et les détections fondées sur les flux, comme le beaconing et les volumes d'envoi inhabituels, s'appliquent toujours. Vérifiez si votre pare-feu rend compte de QUIC avant de le supposer couvert.

https://netsenx.com/fr/faq/do-quic-and-http3-blind-firewalls

## Le DNS over HTTPS peut-il cacher du trafic à la surveillance de sécurité ?

Il peut cacher les requêtes DNS, pas les connexions qui suivent. DNS over HTTPS (DoH, RFC 8484) et DNS over TLS (DoT, RFC 7858) chiffrent les questions qu'un appareil pose à son résolveur. Si des navigateurs ou des applications utilisent un résolveur DoH extérieur, votre serveur DNS d'entreprise et ses journaux ne voient plus quels noms sont résolus, ce qui affaiblit le filtrage DNS et les investigations. Un logiciel malveillant peut utiliser DoH pour la même raison. Les connexions vers les destinations réelles traversent toujours le réseau avec leurs adresses IP, leurs horaires et leurs volumes, et souvent avec le nom du serveur dans la négociation TLS. Mesures pratiques : exploitez votre propre résolveur, ou celui d'un fournisseur, compatible avec le DNS chiffré et faites-le utiliser par les appareils gérés ; empêchez par des politiques de navigateur et de système d'exploitation l'usage d'autres résolveurs ; et repérez les appareils qui parlent directement à des services DoH publics. DoT se repère facilement, car il utilise le port 853 ; DoH ressemble à du HTTPS ordinaire. NetSenX alerte sur le tunnel DNS ; il ne filtre ni ne bloque le DNS.

https://netsenx.com/fr/faq/can-dns-over-https-hide-traffic-from-security-monitoring

## Comment déchiffrer du trafic TLS pour un dépannage ?

Sur une machine que vous contrôlez, le plus simple est de faire écrire au client ses clés de session dans un fichier et de charger ce fichier dans Wireshark. Les navigateurs et de nombreux outils en ligne de commande fondés sur OpenSSL ou NSS respectent la variable d'environnement SSLKEYLOGFILE : définissez-la, reproduisez le problème en capturant avec Wireshark ou tcpdump, puis indiquez le fichier de clés dans les paramètres TLS de Wireshark. Cela fonctionne aussi avec TLS 1.3, où la clé privée du serveur ne suffit plus. Sur un serveur que vous exploitez, certains serveurs web et proxys savent aussi journaliser les clés, ou vous pouvez tester sur une copie de préproduction avec la journalisation activée. Traitez les fichiers de clés comme des mots de passe : quiconque possède le fichier et la capture peut lire le trafic ; supprimez les deux ensuite et ne les collectez jamais sur les appareils d'autrui sans base claire et sans que les personnes le sachent. Pour la surveillance courante, le déchiffrement est rarement nécessaire : les métadonnées de flux et la négociation non chiffrée répondent à la plupart des questions sur qui parle à qui, et comment.

https://netsenx.com/fr/faq/how-to-decrypt-tls-for-troubleshooting

## Comment fonctionne une négociation TLS ?

En TLS 1.3, il faut un aller-retour avant que les données circulent. Le client envoie un ClientHello listant les versions de TLS, suites de chiffrement et groupes d'échange de clés qu'il prend en charge, une part de clé pour son groupe préféré et en général le nom du serveur qu'il veut joindre (SNI). Le serveur répond par un ServerHello qui choisit version, chiffrement et groupe, avec sa propre part de clé. À partir des deux parts, les deux côtés dérivent le même secret, et dès cet instant tout est chiffré, y compris le certificat du serveur et la preuve qu'il détient la clé privée correspondante. Le client vérifie le certificat auprès des autorités qu'il reconnaît, et les données applicatives commencent. Le ClientHello et le ServerHello circulent en clair : c'est pourquoi un capteur passif voit la version de TLS, le groupe d'échange de clés choisi, par exemple X25519 classique ou X25519MLKEM768 hybride, et une empreinte du client sans rien déchiffrer. Avec l'Encrypted Client Hello, une partie du ClientHello, dont le nom du serveur, est cachée aussi.

https://netsenx.com/fr/faq/how-does-a-tls-handshake-work

## Qu'est-ce qui a changé entre TLS 1.2 et TLS 1.3 ?

TLS 1.3 (RFC 8446, 2018) est plus rapide et supprime les options faibles à l'origine de la plupart des attaques passées contre TLS. Il termine la négociation en un aller-retour au lieu de deux. Il ne garde que des échanges de clés offrant la confidentialité persistante, si bien qu'enregistrer le trafic puis voler plus tard la clé privée du serveur ne permet plus de déchiffrer les sessions passées. Il abandonne d'anciens chiffrements et modes comme RC4, 3DES, les suites en mode CBC et l'échange de clés RSA statique, pour ne garder qu'une courte liste de chiffrements authentifiés modernes. Et il chiffre une plus grande partie de la négociation, y compris le certificat du serveur. Pour la surveillance, deux conséquences. Un équipement passif ne peut plus déchiffrer les sessions avec une copie de la clé privée du serveur : l'inspection exige désormais un proxy d'interception actif. Et moins de choses sont visibles en clair : le certificat est caché, tandis que les messages hello, le groupe choisi et le nom du serveur, sauf avec l'Encrypted Client Hello, restent visibles. Privilégiez TLS 1.3 partout et ne gardez TLS 1.2 qu'avec des suites robustes pour les clients plus anciens.

https://netsenx.com/fr/faq/what-changed-between-tls-1-2-and-tls-1-3

## Faut-il désactiver TLS 1.0 et 1.1 ?

Oui. Les deux sont formellement dépréciés par l'IETF depuis la RFC 8996 (mars 2021), les grands navigateurs ne les acceptent plus, et ils reposent sur d'anciennes fonctions de hachage et constructions de chiffrement aux faiblesses connues. S'ils sont encore activés sur un serveur, le risque tient moins à une attaque directe qu'à une voie de rétrogradation, et à un signe de négligence que relèveront auditeurs, assureurs et scanners. Avant de les couper, cherchez qui les utilise encore : vieilles imprimantes, scanners, équipements industriels, applications anciennes et clients embarqués sont les suspects habituels, et couper sans vérifier peut arrêter une ligne de production ou un terminal de paiement. Consultez les journaux des serveurs qui enregistrent la version de TLS, passez un scanner externe sur les services publics et, dans le réseau, regardez les versions de TLS dans les négociations. Désactivez ensuite, ou isolez dans un segment dédié ce qui ne peut pas être mis à jour, avec un plan de remplacement. Le même inventaire servira plus tard à votre travail post-quantique.

https://netsenx.com/fr/faq/should-we-disable-tls-1-0-and-1-1

## Quels chiffrements TLS faut-il désactiver ?

Tout ce qui n'offre pas de confidentialité persistante ou de chiffrement authentifié, et tout ce qui figure sur les vieilles listes. Concrètement : désactivez RC4, que la RFC 7465 interdit dans TLS, 3DES et les autres chiffrements à blocs de 64 bits, les chiffrements export et NULL, l'échange de clés RSA statique et les suites en mode CBC avec SHA-1 si vos clients le permettent. Gardez les suites TLS 1.3, AES-GCM et ChaCha20-Poly1305, et pour TLS 1.2 utilisez l'échange ECDHE avec AES-GCM ou ChaCha20-Poly1305. Servez-vous de guides de configuration publiés plutôt que d'inventer les vôtres : les recommandations Server Side TLS de Mozilla et les guides de l'ANSSI ou les directives techniques du BSI donnent des profils éprouvés pour les clients modernes et plus anciens. Avant de modifier un serveur de production, vérifiez quels clients se connectent et ce qu'ils proposent, à partir des journaux du serveur ou d'une vue des négociations, pour ne pas exclure un vieil appareil. Retestez ensuite de l'extérieur avec un scanner TLS et activez le groupe hybride X25519MLKEM768 là où votre logiciel le prend en charge.

https://netsenx.com/fr/faq/which-tls-ciphers-should-we-turn-off

## Qu'est-ce que la confidentialité persistante (forward secrecy) ?

La confidentialité persistante signifie que chaque session utilise une clé temporaire neuve, jetée ensuite, de sorte que voler plus tard la clé privée de long terme d'un serveur ne permet pas de déchiffrer les sessions enregistrées auparavant. Elle vient des échanges de clés éphémères comme ECDHE ou X25519 : la clé de long terme prouve seulement l'identité du serveur, tandis que la clé de session provient de valeurs jetables choisies par les deux côtés. Les anciennes configurations TLS avec échange de clés RSA statique ne l'avaient pas : une seule clé volée pouvait ouvrir des années de trafic enregistré. TLS 1.3 la rend obligatoire, et les serveurs TLS 1.2 bien configurés l'offrent aussi. Cela explique aussi pourquoi « harvest now, decrypt later » porte sur l'échange de clés : la confidentialité persistante protège contre un vol futur de la clé, pas contre un futur ordinateur quantique capable de casser l'échange éphémère sur courbes elliptiques lui-même. L'échange de clés hybride post-quantique conserve la confidentialité persistante et ajoute la protection manquante. Vérifiez vos serveurs avec un scanner TLS : chaque suite proposée devrait l'offrir.

https://netsenx.com/fr/faq/what-is-forward-secrecy

## Qu'est-ce que le chiffrement, en termes simples ?

Le chiffrement transforme des données lisibles en données brouillées que seul quelqu'un qui possède la bonne clé peut remettre en clair. La méthode, appelée algorithme, est publique ; le secret, c'est la clé. Un bon chiffrement signifie que sans la clé, même un ordinateur puissant ne peut pas retrouver les données en un temps utile. Vous l'utilisez tous les jours : HTTPS sur les sites, le VPN vers le bureau, les messageries, le chiffrement des disques des portables et téléphones, et les sauvegardes. Il protège les données en transit contre quiconque peut écouter le réseau, et les données stockées contre quiconque vole le disque. Il ne protège pas les données contre quelqu'un qui a déjà la clé ou qui contrôle un appareil où elles sont déchiffrées, comme un logiciel malveillant sur un portable ouvert. C'est pourquoi le chiffrement accompagne le contrôle d'accès, les correctifs et la surveillance, sans les remplacer. Un capteur réseau voit que des connexions chiffrées ont lieu, avec leurs métadonnées, mais pas leur contenu.

https://netsenx.com/fr/faq/what-is-encryption-in-plain-terms

## Quelle différence entre chiffrement symétrique et asymétrique ?

Le chiffrement symétrique utilise une seule clé partagée pour fermer et ouvrir ; le chiffrement asymétrique, ou à clé publique, utilise une paire : une clé publique que chacun peut connaître et une clé privée que seul son propriétaire détient. Les algorithmes symétriques comme AES sont rapides et chiffrent presque toutes les données réelles. Leur point faible est le partage sûr de la clé. Les méthodes à clé publique comme RSA, Diffie-Hellman sur courbes elliptiques et leurs successeurs post-quantiques le résolvent : deux parties qui ne se sont jamais rencontrées peuvent convenir d'une nouvelle clé symétrique sur un réseau ouvert, et une clé privée peut signer des données de sorte que quiconque possède la clé publique puisse le vérifier. Les protocoles réels combinent les deux. Une connexion TLS utilise la cryptographie à clé publique dans la négociation pour convenir d'une clé et prouver l'identité du serveur, puis passe à AES ou ChaCha20 pour les données. Cette répartition explique aussi l'enjeu quantique : l'algorithme de Shor menace la partie à clé publique, tandis que le chiffrement symétrique avec des clés de 256 bits reste solide.

https://netsenx.com/fr/faq/what-is-the-difference-between-symmetric-and-asymmetric-encryption

## Quelle longueur doit avoir une clé de chiffrement ?

Cela dépend du type d'algorithme, car les longueurs ne se comparent pas d'un type à l'autre. En chiffrement symétrique, AES-128 reste considéré comme solide et AES-256 offre une marge supplémentaire, y compris face aux futurs ordinateurs quantiques ; utilisez 256 bits pour les données qui doivent rester secrètes de nombreuses années. Pour RSA, 2048 bits est le minimum courant aujourd'hui, et des agences comme l'ANSSI ou le BSI allemand recommandent au moins 3000 bits pour une protection plus longue. Les clés sur courbes elliptiques sont bien plus courtes à sécurité égale : une courbe de 256 bits comme P-256 ou X25519 équivaut à peu près à un RSA d'environ 3000 bits. Pour le hachage, utilisez SHA-256 ou plus fort. Deux réserves comptent plus que les chiffres. La longueur ne sert à rien si la clé est mal générée, stockée dans un script ou jamais renouvelée. Et RSA et les courbes elliptiques, quelle que soit leur longueur, tombent face à un grand ordinateur quantique : leur remplacement à long terme passe par des algorithmes post-quantiques, pas par des clés plus longues. Pour les valeurs exactes, suivez les recommandations actuelles de votre agence nationale.

https://netsenx.com/fr/faq/how-long-should-an-encryption-key-be

## Qu'est-ce qu'une fonction de hachage ?

Une fonction de hachage transforme une quantité quelconque de données en une empreinte courte de longueur fixe, comme la sortie de 256 bits de SHA-256. La même entrée donne toujours la même empreinte, une infime modification en donne une complètement différente, et personne ne peut remonter de l'empreinte à l'entrée ni trouver deux entrées de même empreinte. Les empreintes servent donc à vérifier qu'un téléchargement ou une sauvegarde n'a pas changé, aux signatures numériques, qui signent l'empreinte d'un document, au stockage sûr des mots de passe et aux contrôles d'intégrité dans TLS. D'anciennes fonctions ont cédé : MD5 et SHA-1 sont cassées pour les usages de sécurité, et une collision publique de SHA-1 a été démontrée en 2017 ; traitez-les comme obsolètes partout où elles apparaissent encore, par exemple dans de vieux certificats ou contrôles de fichiers. SHA-256, SHA-384 et SHA-3 sont les choix actuels. Un hachage n'est pas un chiffrement : il n'y a ni clé ni rien à déchiffrer. Les ordinateurs quantiques n'affaiblissent les fonctions de hachage que modérément.

https://netsenx.com/fr/faq/what-is-a-hash-function

## Hacher des mots de passe, est-ce la même chose que les chiffrer ?

Non, et pour les mots de passe, le hachage est le bon choix. Le chiffrement est réversible avec une clé : quiconque vole les mots de passe chiffrés et la clé récupère tous les mots de passe. Une empreinte ne se renverse pas : le système ne stocke que l'empreinte et la compare à la connexion. Les hachages rapides ordinaires comme SHA-256 restent un mauvais choix pour les mots de passe, car un attaquant qui vole une base peut tester d'énormes quantités d'essais par seconde sur des cartes graphiques. Utilisez une fonction conçue pour les mots de passe, volontairement lente et avec un sel aléatoire par utilisateur : Argon2id, scrypt ou bcrypt, comme le recommande le guide OWASP sur le stockage des mots de passe. Si un fournisseur ou une vieille application stocke les mots de passe chiffrés, ou hachés avec MD5 ou SHA-1 seuls, traitez-le comme une anomalie à corriger. Pour votre personnel, les gains les plus importants sont ailleurs : l'authentification multifacteur (MFA), un gestionnaire de mots de passe et le blocage des mots de passe réutilisés. Un capteur réseau ne voit pas comment un serveur stocke les mots de passe ; ce contrôle relève d'une revue applicative.

https://netsenx.com/fr/faq/is-hashing-the-same-as-encryption-for-passwords

## Qu'est-ce qu'une signature numérique ?

Une signature numérique est une valeur calculée à partir de données avec une clé privée, que quiconque détient la clé publique correspondante peut vérifier. Si la vérification réussit, deux choses sont prouvées : les données viennent du détenteur de cette clé privée, et elles n'ont pas changé depuis leur signature. Les signatures protègent bien des choses sur lesquelles vous comptez sans y penser : mises à jour logicielles et pilotes, certificats TLS qui prouvent l'identité d'un site, PDF signés et factures électroniques, courriels signés en S/MIME et code livré par vos développeurs. Dans l'UE, les signatures électroniques qualifiées au sens du règlement eIDAS ont en outre une valeur juridique. Une signature n'est fiable que si sa clé privée l'est : si la clé est volée, un attaquant peut signer un logiciel malveillant qui paraît authentique ; c'est pourquoi les clés de signature ont leur place dans des modules matériels de sécurité ou des coffres protégés de façon comparable, accessibles à peu de personnes. Les signatures actuelles utilisent RSA ou les courbes elliptiques, qu'un grand ordinateur quantique casserait ; leurs remplaçantes post-quantiques sont ML-DSA et SLH-DSA.

https://netsenx.com/fr/faq/what-is-a-digital-signature

## Qu'est-ce qu'un certificat TLS ?

Un certificat TLS est un document signé qui associe une clé publique à un nom, comme www.example.com, afin qu'un navigateur ou un client puisse vérifier qu'il parle au vrai serveur et non à un imposteur. La signature vient d'une autorité de certification (AC) en laquelle le client a déjà confiance, en général via une chaîne : une AC racine, une AC intermédiaire, puis le certificat du serveur lui-même. Pendant la négociation, le serveur présente son certificat et prouve qu'il détient la clé privée correspondante. Les certificats ont une date d'expiration et peuvent être révoqués. Ce qu'un certificat ne prouve pas, c'est que le site est sûr ou honnête : un site d'hameçonnage peut avoir un certificat parfaitement valide, car les AC vérifient surtout le contrôle du domaine, pas l'entreprise derrière. Dans les entreprises, une AC interne délivre souvent les certificats des serveurs, VPN et équipements. Tenez un inventaire de tous les certificats avec responsables et dates d'expiration ; les certificats oubliés provoquent des pannes et cachent des clés faibles.

https://netsenx.com/fr/faq/what-is-a-tls-certificate

## Que se passe-t-il quand un certificat TLS expire ?

Les clients cessent de faire confiance au serveur : les navigateurs affichent un avertissement pleine page, et les applications, API, clients VPN et équipements refusent en général toute connexion. Pour les utilisateurs, cela ressemble à une panne, et c'en est une en pratique : pages de paiement, portails clients, serveurs de messagerie et liaisons entre machines peuvent s'arrêter à l'instant de l'expiration, souvent la nuit ou le week-end. Les certificats expirés habituent aussi le personnel à ignorer les avertissements, exactement ce que voudrait un attaquant qui intercepte le trafic. La solution est un processus, pas un exploit : un inventaire de chaque certificat avec son responsable et sa date d'expiration, des alertes bien en avance et le renouvellement automatique via le protocole ACME (RFC 8555) partout où la plateforme le permet. N'oubliez pas les certificats des appliances, imprimantes, services internes et de la signature de code, que les scanners externes ne voient jamais. Observer les négociations TLS sur le réseau interne aide à trouver des serveurs que personne n'a listés, même si, en TLS 1.3, le certificat lui-même est chiffré et doit être vérifié sur le serveur.

https://netsenx.com/fr/faq/what-happens-when-a-tls-certificate-expires

## Pourquoi la durée de vie des certificats TLS raccourcit-elle ?

Parce que des durées plus courtes limitent les dégâts d'une clé volée ou d'un certificat émis par erreur, et poussent chacun à automatiser le renouvellement. En avril 2025, le CA/Browser Forum, l'instance des autorités de certification et des éditeurs de navigateurs qui fixe les règles des certificats TLS publics, a adopté le vote SC-081 : la durée maximale passe de 398 à 200 jours à partir du 15 mars 2026, à 100 jours à partir du 15 mars 2027 et à 47 jours à partir du 15 mars 2029. Ces règles visent les certificats publiquement reconnus, pas ceux émis par votre propre AC interne. Pour une entreprise qui renouvelle encore ses certificats à la main une fois par an, la charge change : les renouvellements deviennent fréquents et les processus manuels échoueront. La réponse : l'automatisation via ACME (RFC 8555) ou les outils de votre fournisseur, un inventaire de chaque certificat public et de l'endroit où il est installé, répartiteurs de charge et appliances compris, et une surveillance des expirations. Voyez-y un entraînement à l'agilité cryptographique : la même discipline servira pour la transition post-quantique.

https://netsenx.com/fr/faq/why-are-tls-certificate-lifetimes-getting-shorter

## Les certificats auto-signés sur les serveurs internes posent-ils problème ?

Pas parce qu'ils sont auto-signés, mais à cause de ce qui les accompagne en général. Un certificat auto-signé chiffre aussi bien qu'un autre ; le problème, c'est la confiance. Les clients ne peuvent pas le vérifier auprès d'une autorité connue : utilisateurs et administrateurs prennent l'habitude d'ignorer les avertissements ou de désactiver la vérification dans les scripts, et cette même habitude laisse passer une vraie interception. Les certificats auto-signés des appliances ont souvent des clés faibles ou par défaut, aucun suivi d'expiration et aucun responsable. Mieux vaut une autorité de certification interne, qui délivre si possible de façon automatisée, dont la racine est déployée sur les appareils gérés, avec un inventaire de chaque certificat et de son expiration. Pour les équipements livrés uniquement avec des certificats auto-signés, comme les imprimantes ou les automates, remplacez le certificat quand l'appareil le permet et gardez l'appareil dans un segment à accès restreint. Les certificats auto-signés ont aussi leur place dans votre inventaire post-quantique : chacun a un type et une taille de clé qu'il faudra changer un jour.

https://netsenx.com/fr/faq/are-self-signed-certificates-on-internal-servers-a-problem

## Qu'est-ce que le TLS mutuel (mTLS) ?

Le TLS mutuel signifie que les deux côtés d'une connexion présentent des certificats : le serveur prouve son identité au client, et le client la sienne au serveur. Dans le HTTPS ordinaire, seul le serveur a un certificat, et l'utilisateur prouve qui il est ensuite par un mot de passe ou un jeton. Avec mTLS, le client a besoin d'une clé privée et d'un certificat émis par une autorité en laquelle le serveur a confiance, ce qui est difficile à hameçonner et facile à révoquer. Il est courant entre services dans une architecture de microservices, pour les API entre entreprises, pour l'identité des équipements en IoT et OT, et dans certains produits d'accès distant de type zero trust. Les coûts : la gestion des certificats à grande échelle, c'est-à-dire émettre, renouveler et révoquer des certificats clients, et le dépannage quand quelque chose expire. Sur le réseau, mTLS ressemble à du TLS normal. En TLS 1.3, le certificat client est chiffré : un capteur passif voit que la connexion existe et ses paramètres de négociation, pas quel certificat client a été utilisé.

https://netsenx.com/fr/faq/what-is-mutual-tls

## Un VPN chiffre-t-il tout ce que nous envoyons ?

Il chiffre le trafic entre votre appareil et la passerelle VPN, pas tout le chemin jusqu'à la destination. Après la passerelle, le trafic continue vers le réseau du bureau ou internet, protégé seulement par ce qu'utilise l'application elle-même, comme HTTPS. Un VPN d'entreprise protège donc le personnel sur le Wi-Fi d'un hôtel ou d'un café contre l'écoute locale et lui donne accès aux systèmes internes ; il ne rend pas sûre une application interne non chiffrée et ne cache rien au réseau de l'entreprise qui reçoit le trafic. Le split tunneling n'envoie qu'une partie du trafic dans le VPN et le reste directement, ce qui aide les performances mais signifie que la surveillance de l'entreprise n'en voit qu'une partie. Un service VPN commercial déplace votre confiance du fournisseur d'accès vers le fournisseur de VPN. Les passerelles VPN elles-mêmes sont des cibles fréquentes et exigent des correctifs rapides et l'authentification multifacteur (MFA). Sur le réseau, les tunnels VPN apparaissent comme des connexions vers la passerelle, avec leurs horaires et volumes, pas leur contenu.

https://netsenx.com/fr/faq/does-a-vpn-encrypt-everything-we-send

## Comment trouver tous les serveurs SSH du réseau, y compris les oubliés ?

Combinez un balayage actif et une observation passive, car chacun trouve ce que l'autre manque. Un balayage autorisé de vos plages d'adresses sur le port 22 et les autres ports SSH courants, avec un outil comme Nmap, liste chaque hôte qui répond et la version logicielle qu'il annonce. Vérifiez vos consoles cloud et vos enregistrements DNS pour les serveurs hors des plages du bureau. L'observation passive ajoute ce que les balayages ratent : SSH sur des ports inhabituels, des serveurs joignables seulement depuis certains segments, et l'usage réel de SSH, c'est-à-dire quels clients se connectent à quels serveurs et quand. Passez ensuite la liste en revue avec les responsables : chaque serveur a besoin d'une personne nommée, d'une raison d'exister et d'un calendrier de correctifs, et tout ce que personne ne réclame est éteint après un préavis. Limitez SSH aux réseaux d'administration ou à un serveur de rebond, et utilisez des clés plutôt que des mots de passe. NetSenX alerte dans chaque offre quand un hôte commence à joindre de nombreux hôtes internes sur des ports d'administration comme SSH, car c'est ainsi que se présentent les balayages et les mouvements latéraux.

https://netsenx.com/fr/faq/how-to-find-all-ssh-servers-on-the-network

## Comment savoir quels serveurs exécutent une version d'OpenSSH touchée par une nouvelle CVE ?

Commencez par la version que chaque serveur annonce, puis confirmez avec l'état des correctifs de l'éditeur, car l'annonce seule peut induire en erreur. Chaque serveur SSH envoie avant toute chose une chaîne d'identification comme SSH-2.0-OpenSSH_9.6p1, qu'un scanner ou une simple connexion affiche. Comparez cette version à la plage indiquée dans l'avis. Pour regreSSHion (CVE-2024-6387), par exemple, l'avis publié par Qualys le 1er juillet 2024 citait OpenSSH de 8.5p1 jusqu'à 9.8p1 exclue, sur Linux à base de glibc. Vérifiez ensuite la version du paquet sur chaque serveur : les distributions Linux reportent souvent les correctifs de sécurité dans un numéro de version plus ancien, si bien qu'un serveur annonçant une version touchée peut déjà être corrigé ; le suivi de sécurité de la distribution fait foi. Corrigez via le gestionnaire de paquets, redémarrez le service et vérifiez à nouveau. Tenez une liste des serveurs SSH dans votre inventaire, pour que le prochain avis prenne des minutes et non des jours.

https://netsenx.com/fr/faq/how-to-check-openssh-versions-against-a-new-cve

## Une bannière de version SSH prouve-t-elle qu'un serveur est vulnérable ?

Non. C'est un indice fort, pas une preuve, dans les deux sens. La bannière est le texte qu'un serveur annonce sur son logiciel, par exemple OpenSSH_8.9p1 Ubuntu-3ubuntu0.10. Les distributions Linux corrigent souvent les failles en modifiant l'ancienne version plutôt qu'en passant à la nouvelle version amont : un serveur peut donc annoncer une version listée comme vulnérable et être pourtant sûr, ce que disent le suffixe du paquet de la distribution et son suivi de sécurité. La bannière peut aussi être modifiée ou masquée par un administrateur, et certaines appliances annoncent des chaînes trompeuses. À l'inverse, un numéro de version récent n'exclut pas des problèmes de configuration, comme des connexions par mot de passe ouvertes sur internet ou des clés d'hôte faibles. Utilisez la bannière pour classer les serveurs entre ceux à vérifier en premier et ceux qui sont probablement en ordre, puis confirmez sur l'hôte avec le gestionnaire de paquets ou un scan de vulnérabilités authentifié. Ne signalez jamais à la direction un serveur comme compromis ou vulnérable sur la seule foi de sa bannière.

https://netsenx.com/fr/faq/does-an-ssh-version-banner-prove-a-server-is-vulnerable

FAQ: https://netsenx.com/fr/faq