Web Filtering not working until client's cache is cleared

[JohnGeorge]

Web Filtering is set up for a certain category. "Deep" Full SSL Certificate Inspection is enabled. All client machines have the fortigate certificate installed, it comes through when browsing websites, and no user gets certificate errors in their browsers. I was surprised a user was still able to visit this category of site for several weeks after blocking. Once their internet cache in Chrome was cleared, the site is now blocked.

Why?

[hmtay_FTNT]

Hello JohnGeorge,

When a page is "cached" by the browser, the browser does not create a new network session to the server to grab the page. The cached page loads from your hard drive. This is the nature of the browser cache. If no packet is sent out, the FortiGate will not be able to block the traffic. 

[JohnGeorge]

It's odd because packets are definitely getting sent out. The blocked category is webmail, and users are still actively using up-to-date webmail. 

Someone suggested that a session between a browser and a gmail server would last as long as the cookie lasted on the client machine. Once a session has been established using the web server's certificate and public key, all session communication is encrypted with a random symmetric key. Is the Fortigate unable to interrogate the symmetric key on existing sessions? Which would mean web filtering only works while creating new sessions?

[hmtay_FTNT]

Okay, what you are explaining is a cached session and not a cached page. In a SSL connection, some sessions allow the browser to cache the session key to speed up negotiation to increase the speed. If the browser already has a session cached when you modify the policy, the FortiGate will not be able to decrypt the traffic. To intercept the symmetric key, the FortiGate has to intercept the full SSL session instead of the cached one. The answer to your first question is unfortunately no, the FortiGate cannot get the symmetric keys of existing sessions.

The Web filter should work if the FortiGate sees the TCP handshake and the hostname in the Client Hello SNI. If you want to force the users to re-establish new sessions, you can use the command "diagnose sys session clear" to clear out existing sessions.