Without SSL deep inspection enabled, what is a realistic expectation for application control's ability to identify applications running inside fully encrypted HTTPS sessions?
Select an answer to reveal the explanation.
Short Explanation
Encryption hides most of the conversation, but not the introduction — the certificate and the hostname sent early in the handshake are often enough for FortiOS to put a name on many common apps. Getting more specific than that, though, usually means actually decrypting the session.
Full Explanation
Even without decrypting a session, application control can inspect elements exchanged before encryption fully takes hold — most notably the TLS handshake's SNI field and the server's certificate — and match those against known application signatures, which is often enough to name a well-known application at a coarse level. Distinguishing finer sub-application behavior within that same app, however, generally requires seeing the actual encrypted payload, which is only available when SSL deep inspection is decrypting the session for further engine inspection. The option claiming zero visibility overstates the limitation, since handshake-level metadata is not encrypted and is exactly what supports this coarse-grained identification. The option claiming application control decrypts every session regardless of configuration misrepresents deep inspection as something that happens automatically; it is an explicit profile setting, not a default behavior. And identification does not depend on DNS filtering having already logged the domain — application control evaluates the session's own traffic independently of whatever DNS filtering profile may or may not be applied. An operational caveat: some newer TLS behaviors, such as encrypted SNI, can remove even that handshake-level visibility. Confirm actual visibility by checking whether the application control log names a specific application or falls back to a generic SSL/HTTPS classification for that session.