Meridian Electric Cooperative's web filter profile blocks a specific category, and the destination sites are all HTTPS. Which statement correctly distinguishes what FortiGate can enforce on that HTTPS traffic without SSL deep inspection versus with it enabled?
Select an answer to reveal the explanation.
Short Explanation
The hostname you're connecting to actually gets sent in the clear during the TLS handshake, so FortiGate can read it without decrypting anything. Once you need to know which specific page on that site someone opened, though, that detail is inside the encrypted request — and that's where deep inspection has to step in.
Full Explanation
During the TLS handshake, the client typically sends the destination hostname unencrypted in the Server Name Indication field, which lets FortiGate identify and act on the domain being requested without decrypting the session at all — that's enough for domain-level, category-based web filtering to work on HTTPS traffic. Restricting access to a specific path or page on that same domain is a different level of granularity, because the requested path lives inside the encrypted HTTP request, and only SSL deep inspection, which decrypts the session, exposes that detail to the web filter. The option claiming FortiGate can't see any part of an HTTPS connection overstates the limitation — the handshake itself leaks the hostname by design. The option claiming deep inspection is required just to see the hostname reverses that same fact. And treating domain-level and path-level filtering as requiring identical visibility ignores the real difference the SNI field creates between the two. The operational caveat is that some clients and newer TLS extensions can encrypt the SNI field, which would remove even that domain-level visibility without deep inspection — worth checking whether that is happening on Meridian's network before assuming SNI-based filtering alone is reliable. Verify by capturing a session's ClientHello to confirm the hostname is actually visible in the clear.