Skip to main content
JohnGeorge
JohnGeorge
New Member
February 20, 2017
Question

Web Filtering not working until client's cache is cleared

  • February 20, 2017
  • 1 reply
  • 12481 views

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?

    1 reply

    hmtay_FTNT
    Staff
    hmtay_FTNT
    Staff
    February 25, 2017

    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
    JohnGeorgeAuthor
    New Member
    February 27, 2017

    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
    Staff
    hmtay_FTNT
    Staff
    February 27, 2017

    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.

     

     

    Terms & ConditionsAccessibility statement