# Analyse du trafic chiffré sans déchiffrement

> Comment un NDR détecte les menaces dans le trafic TLS sans le déchiffrer : ce qui reste visible, ce qui échappe, et ce que NetSenX lit de chaque connexion.

Source page: https://netsenx.com/fr/encrypted-traffic-analysis

Dernière vérification : 6 novembre 2026

L'analyse du trafic chiffré détecte les menaces dans le trafic réseau chiffré par TLS sans le déchiffrer, à partir de ce qui reste visible : qui communique avec qui, quand, à quelle fréquence, quel volume de données circule et quels paramètres présente le handshake TLS. Elle repère le beaconing C2 et les transferts inhabituels ; elle ne voit pas le contenu d'une session.

## Le fait à retenir

TLS 1.3 (RFC 8446, IETF, août 2018) chiffre tous les messages du handshake après le ServerHello, y compris le certificat du serveur, et supprime l'échange de clés RSA statique. Un capteur passif disposant d'une copie de la clé privée du serveur ne peut donc plus déchiffrer la session ; il faut pour cela un proxy d'interception ou des clés de session exportées depuis les terminaux.

Source : [RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3, IETF, August 2018 (section 1.2)](https://www.rfc-editor.org/rfc/rfc8446)

## Ce que NetSenX fait aujourd'hui

- Ne déchiffre jamais le trafic : aucun proxy d'interception à exploiter, aucun certificat d'interception à installer sur vos appareils.
- Détecte le beaconing C2 et les transferts sortants inhabituels dans le trafic chiffré à partir du rythme, du volume et des destinations, et à partir de l'offre Starter aussi du handshake TLS. 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.
- Sur l'hôte surveillé, l'agent lit le nom du serveur et les paramètres du handshake TLS ainsi que les réponses aux requêtes DNS, pour associer chaque connexion au service qu'elle atteint. Il ne lit pas le contenu chiffré d'une session.
- Explique chaque alerte en langage clair en indiquant les caractéristiques réseau qui ont déterminé son score, dans toutes les offres.

## Ce que NetSenX ne fait pas

Sans déchiffrement, NetSenX ne voit pas ce que contient une session : un fichier malveillant téléchargé en HTTPS, le texte d'un e-mail ou le contenu d'un envoi. La protection des terminaux (EDR) et la sécurité de la messagerie couvrent ce terrain. Si l'inspection du contenu est une exigence, choisissez un outil qui déchiffre le trafic et prévoyez la gestion du contenu déchiffré.

## Questions des acheteurs

### 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.

### 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é.

### 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.

### 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.

## Sources

- [RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3, IETF, August 2018 (section 1.2)](https://www.rfc-editor.org/rfc/rfc8446)
- [Court of Justice of the EU, Case C-582/14 (Breyer), judgment of 19 October 2016 — EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62014CJ0582)

Cette page est une information générale et ne constitue pas un conseil juridique. Vérifiez vos obligations auprès de votre autorité nationale ou de votre conseil juridique.

## Pages associées

- [Guide de la cryptographie post-quantique (article en anglais)](https://netsenx.com/fr/blog/2026-11-12_post-quantum-readiness-guide)
- [NetSenX, une alternative à ExtraHop](https://netsenx.com/fr/compare/extrahop-alternative)
- [Fonctionnalités](https://netsenx.com/fr/features)
- [Données hébergées dans l'UE](https://netsenx.com/fr/eu-data-residency)
- [Surveillance réseau NIS2](https://netsenx.com/fr/nis2-network-monitoring)
- [Détecter les mouvements latéraux et le beaconing C2](https://netsenx.com/fr/detect-lateral-movement-c2-beaconing)