Network Detection and Response Under TLS 1.3 and ECH

Network detection and response was designed for a network where a sensor could read a lot of each connection. That network is going away. TLS 1.3 encrypts the server certificate. Encrypted Client Hello (ECH) encrypts the server name. Chrome shuffles its handshake so the classic JA3 fingerprint changes on every connection.

NDR keeps working under encryption, but a different set of detections carries the load. This post maps the fields that encryption removed, the signals that remain, and the questions to put to an NDR vendor about encrypted traffic.

What TLS 1.3 and ECH remove from the wire

Each protocol change took a specific field away from passive sensors. The detections built on that field went with it.

TLS 1.3 encrypts the certificate

In TLS 1.2, the server certificate crossed the wire in clear text. A sensor could flag self-signed certificates, odd issuers, or certificates reused across malicious infrastructure. RFC 8446, the TLS 1.3 specification, lists this change among its major differences: all handshake messages after the ServerHello are now encrypted. The certificate is one of those messages.

On a TLS 1.3 connection, a passive sensor sees the ClientHello and the ServerHello. It does not see who the server claims to be.

ECH encrypts the server name and ALPN

TLS 1.3 still sends the Server Name Indication (SNI) in the clear. Many NDR and proxy detections match on that hostname. RFC 9849, published by the IETF in March 2026, closes that gap. It encrypts an inner ClientHello that carries the SNI and other sensitive fields, such as the Application-Layer Protocol Negotiation (ALPN) list. ALPN names the application protocol the client wants, such as HTTP/2.

What stays visible is an outer ClientHello. Its server_name field carries a public_name chosen by the client-facing server, which is often a CDN or hosting provider. A sensor learns the provider you connected to. The site behind it stays hidden.

RFC 9849 also defines GREASE ECH, a decoy mechanism. A client can send a dummy ECH extension to a server that does not support ECH, so real ECH connections look less distinctive. The presence of the extension tells you little.

Browsers randomize the ClientHello

JA3 hashes the ClientHello fields in the order they appear. In January 2023, Chrome began permuting the order of its TLS extensions on each connection. Fastly's measurements showed Chrome's most common JA3 hash dropping off from 20 January 2023. Fastly estimated close to 15 factorial possible orderings, so each Chrome connection gets a practically unique JA3.

An allowlist or blocklist of JA3 hashes now breaks for Chromium browsers, even on an unchanged network.

Field visibility by protocol

The table is read from RFC 8446 and RFC 9849. It describes a passive sensor with no decryption.

What NDR still detects without decryption

Payload was already encrypted under TLS 1.2. Analytics built on metadata were never affected by that. Four signal classes survive TLS 1.3 and ECH.

Client and server fingerprints

JA4, from FoxIO, sorts cipher suites and extensions before hashing. That makes it stable against Chrome's permutation. The JA4 project states that sorting gets around the randomization, and adding signature algorithms keeps fingerprints unique.

The JA4+ suite covers more than the client hello. JA4S fingerprints the server response. JA4T fingerprints TCP behavior. JA4SSH fingerprints SSH sessions. JA4X fingerprints X.509 certificates, which only helps where the certificate is visible: TLS 1.2 traffic, or traffic you decrypt.

Licensing differs by method. JA4 itself is BSD 3-Clause. JA4S, JA4H, JA4X, JA4T and the other methods use the FoxIO License 1.1.

The project lists Zeek, Suricata, Wireshark and Arkime among the tools that support it. Check which methods your NDR vendor ships, and under which license.

Flow shape: packet lengths and timing

Encryption hides content but leaves the shape of a conversation visible. Cisco's Encrypted Traffic Analytics is a documented example. It exports the Sequence of Packet Lengths and Times (SPLT): payload length and inter-arrival time for the first several packets of a flow. Cisco uses that metadata to identify malware traffic without bulk decryption.

The same principle supports beacon detection. Command and control traffic often checks in on a schedule, with request and response sizes that repeat. MITRE ATT&CK tracks Encrypted Channel (T1573) as its own technique, because adversaries encrypt C2 to conceal it. Periodicity and size patterns stay visible after the encryption.

Connection graph

Who talked to whom, on which port, how often and for how long: none of that is inside the encrypted payload. For east-west traffic, the graph is often the strongest signal a sensor has. A workstation that starts connecting to many internal hosts on administrative ports looks the same encrypted or not.

Destination context

ECH hides the site name behind a provider's public_name. The destination IP, the provider and the outer name are still there. Traffic to a provider your organization never uses, or to address space with no business reason, still stands out.

What NDR loses

Be specific with vendors about which detections degrade. Four classes lose the most.

• Payload signatures. Content-matching rules need plaintext. On encrypted sessions they fire only where you decrypt.
• Certificate checks on TLS 1.3. Self-signed, expired or suspicious-issuer detections need the certificate. Passive sensors lose them on TLS 1.3.
• Hostname matching under ECH. SNI blocklists and domain reputation lookups see only the provider's public_name.
• JA3 lists for Chromium clients. Existing JA3 content needs review. Rewrite it in JA4, or retire it.

Server-side fingerprints and flow statistics degrade far less. Detection engineers should move coverage toward them, and replay rewritten rules against past traffic before retiring the old ones. Our detection authoring and replay workspace is built for that loop.

Decrypting: where it fits and what it costs

Decryption brings back payload and certificates at a single point. It also adds a device that holds keys and trusted certificates for your whole network.

CISA's alert on HTTPS interception sets out the main risk. Many inspection products do not properly verify the certificate chain, and they rarely pass those errors to the client. CISA advises you to verify that your product validates certificate chains and forwards warnings or errors. It also advises weighing the pros and cons before deployment.

ECH adds a consideration. RFC 9849 describes how a TLS-terminating proxy handles an ECH connection: it acts as if connecting to the outer server_name. Clients get ECH keys from DNS, as set out in RFC 9848 on bootstrapping ECH with DNS service bindings. Your resolver and proxy configuration therefore affect how much ECH traffic your sensors see.

A practical split for many environments:

1. Decrypt at the egress proxy for managed user traffic, where policy allows.
2. Rely on metadata, fingerprints and flow shape for server-to-server and east-west traffic.
3. Send the proxy's decrypted-session logs to the same place as NDR detections, so an analyst sees both.

Fused signal beats a single sensor

A network sensor on an encrypted flow knows the endpoints, the timing and the fingerprints. The endpoint agent knows which process opened the socket. The proxy knows the URL, if it decrypts. The identity provider knows which account was logged in. Any one of them gives a partial answer.

This is why network visibility architecture matters as much as sensor analytics. Our network security product supports both sensors and sensorless collection from the firewalls, proxies and cloud flow logs you already run. It combines that signal with identity, endpoint and cloud data in one graph. For an honest comparison with sensor-first products, see our Port0 vs. traditional NDR comparison.

Questions to ask your NDR vendor about encrypted traffic

• Which detections depend on SNI, and what happens to them when ECH is in use?
• Which detections depend on the server certificate, and do they work on TLS 1.3 without decryption?
• Do you ship JA3, JA4, or both? Which JA4+ methods, and under which license?
• Do your analytics use packet lengths and timing? From how many packets per flow?
• Where does decryption happen, if at all? Does the inspection point validate certificate chains, as CISA advises?
• Can your detections be joined with proxy, endpoint and identity logs in one investigation?

The answers show which parts of your network the product can still judge under TLS 1.3 and ECH.