Most outbound traffic is TLS 1.3, and company policy forbids decrypting it. The SOC still wants to detect malware command-and-control sessions on the network. What can detection rely on?
Select an answer to reveal the explanation.
Short Explanation
You can't read a sealed letter, but you can still notice the odd return address, the strange postage, and that it arrives every 60 seconds like clockwork. Encrypted traffic analysis works on that envelope-level metadata. The trap is any option that needs the inside of the envelope.
Full Explanation
When payloads are encrypted and decryption is not permitted, detection shifts to the observable characteristics of the connection. The TLS handshake exposes information such as offered cipher suites and extensions that can fingerprint client software; the server name and destination can be checked against reputation and threat intelligence; and the sequence of packet sizes, timing and periodicity can reveal beaconing typical of command-and-control channels. Machine-learning models applied to this metadata can classify sessions as likely malicious without reading content. Intrusion content signatures need to see the bytes they match, and encrypted payload is effectively random, so signature inspection of it yields nothing. Using server private keys for passive decryption violates the stated policy, and with TLS 1.3 the ephemeral key exchange means even a server private key would not decrypt recorded sessions. HTTP header fields such as User-Agent and URL path travel inside the encrypted tunnel, so they are not visible without decryption. Exam caveat: TLS 1.3 encrypts more of the handshake than earlier versions, including the server certificate, so some metadata visible in TLS 1.2 is no longer available. Operational check: confirm the monitoring source captures handshake metadata and flow timing for outbound sessions, and test detection with a known beaconing sample in a lab.