Encrypted traffic
Encrypted traffic analysis without decryption
Encrypted traffic analysis detects threats in TLS-encrypted network traffic without decrypting it, from what stays visible on the wire: who talks to whom, when, how often, how much data moves, and the parameters of the TLS handshake. It finds command-and-control beaconing and unusual data transfers; it cannot see the content of a session.
The fact to plan around
TLS 1.3 (RFC 8446, IETF, August 2018) encrypts every handshake message after the ServerHello, including the server's certificate, and removes static RSA key exchange. A passive sensor holding a copy of the server's private key can no longer decrypt the session; decryption needs an interception proxy or session keys exported from the endpoints.
Source: RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3, IETF, August 2018 (section 1.2)
What NetSenX does today
- Never decrypts traffic: there is no interception proxy to run and no interception certificate to install on your devices.
- Detects command-and-control beaconing and unusual outbound transfers in encrypted traffic from timing, volume and destinations, and from the Starter plan also from the TLS handshake. The handshake is visible only where the agent captures packets: on Linux or as a sensor on a SPAN or TAP port, not in the basic mode used on macOS.
- On the monitored host, the agent reads the server name and the parameters in the TLS handshake and the answers to DNS queries, to label each connection with the service it reaches. It does not read the encrypted content of a session.
- Explains every alert in plain language, listing the network features that drove its score, on every plan.
What NetSenX does not do
Without decryption, NetSenX cannot see what is inside a session: a malicious file downloaded over HTTPS, the text of an e-mail or the content of an upload. Endpoint protection (EDR) and e-mail security cover that ground. If payload-level inspection is a requirement, choose a tool that decrypts traffic, and plan for handling the decrypted content.
Questions buyers ask
Can NDR detect threats in encrypted traffic without decrypting it?
Yes, from metadata. Timing, volume, destinations and the TLS handshake stay visible when the content is encrypted, so beaconing to a command-and-control server and unusual data transfers can be detected without breaking encryption. What stays invisible is the content of the session.
What does NetSenX read from an encrypted connection?
Flow metadata (who connects to whom, when, how often and how much data moves) and a few protocol fields: the server name and the parameters in the TLS handshake, and the answers to DNS queries. NetSenX never decrypts the session and does not read its encrypted content.
Why not decrypt TLS traffic for inspection?
Decryption gives payload visibility, but it means running an interception point that holds keys, installing an interception certificate on every device, and handling decrypted content that may include personal data. Since TLS 1.3, a passive sensor can no longer decrypt sessions with a copy of the server's private key.
Is network metadata personal data under GDPR?
It can be. The Court of Justice of the EU held in Breyer (Case C-582/14, 19 October 2016) that a dynamic IP address can be personal data. NetSenX publishes a data processing agreement under GDPR Article 28 and keeps customer data in the EU.
Sources
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3, IETF, August 2018 (section 1.2)
- Court of Justice of the EU, Case C-582/14 (Breyer), judgment of 19 October 2016 — EUR-Lex
This page is general information, not legal advice. Check your obligations with your national authority or legal counsel.
Related pages
Try NetSenX on your own network
Start on the Free plan with up to 3 devices, or book a 20-minute demo.