A customer wants to spot command-and-control traffic inside TLS sessions but has ruled out decryption, so they ask what the Encrypted Visibility Engine actually looks at. Which detail from the TLS handshake does EVE use to identify the application?
Select an answer to reveal the explanation.
Short Explanation
You got it — EVE works from the TLS handshake itself, before any protected payload is read. It's like judging a book by its cover: the client hello hands you a fingerprint and a name to match on. That's why you still get visibility when nothing is decrypted.
Full Explanation
The Encrypted Visibility Engine (EVE) identifies applications from observable TLS client hello information, including JA3—a fingerprint derived from selected client hello parameters—and the server name indication (SNI). These features provide useful application clues while the session remains encrypted, so they meet the customer’s no-decryption constraint. Inspecting certificate subject and issuer fields is a legitimate TLS metadata technique, but it relies on certificate information rather than the client hello fields EVE uses for this identification. Server-selected cipher suite and TLS version can also contribute to TLS fingerprinting, but treating those server-side values as the identifying signature does not describe EVE’s stated client hello and JA3/SNI method. Packet sizes and timing are commonly used for encrypted traffic classification, but they are flow-level behavioral signals, not details read from the TLS handshake. Exam caveat: JA3 and SNI are indicators, not guaranteed unique identities; shared hosting, changing infrastructure, and encrypted or absent SNI can reduce attribution confidence. Practical check: inspect a packet capture or EVE event for client hello-derived JA3 and SNI fields, and verify that application identification still occurs with payload decryption disabled.