2 Replies Latest reply on Jul 18, 2017 4:16 PM by DBO

    Whitelisting link with URL.Path


      I just called support because whiltelisting object with URL.PATH wasn't working for my default policy.  They end up putting a bypass for CONNECT / CERTVERIFY on one of the block rule of the default policy.  Since we have multiple whitelist/blocklist (associated with the 6 URL Filtering policies (DOC-3649)), this do not seem a very optimal strategy.


      After rereading DOC-4810 (and understanding it this time (I hope)) I understand what they were doing but, there is surely a better way..


      Where would be the best place (performance wise) to place the ALLOW CONNECT rule form the example?  Right now, I had to put it after the Direct Proxy Auth ruleset otherwise I am receiving auth-request popup...  To limit the performance hit, I have created a dedicated list of the URL.HOST (ex: *.facebook.com, *.youtube.com*, etc...)  that have a URL.Path entries in all the whitelist/Blacklist further down in the rules...  Any better idea?

        • 1. Re: Whitelisting link with URL.Path
          Jon Scholten

          Hi DBO!


          That's exactly what you will need to do. "Allow CONNECT" should be after authentication otherwise you'll have authentication issue as you described.


          Specifically this problem has to do with whitelisting the URL.Path for HTTPS websites. If this was an HTTP site, you wouldnt have this problem.


          During SSL connection establishment, the MWG (or any other proxy) only knows the host you are connecting to (e.g. facebook.com), there is NO path information available. This SSL connection establishment is the CONNECT and CERTVERIFY phases.


          Only after we've cracked open the tunnel do we get the URL.Path information.


          So, if there is a site you wish to whitelist based on the path AND it's HTTPS, then we need to allow the CONNECT and CERTVERIFY for the domain first, then allow the path.


          What what the SR # you opened by chance?


          Best Regards,


          • 2. Re: Whitelisting link with URL.Path

            Yesterday, case 4-17668322823. They (the tech was asking a colleague) were going in the right direction (bypassing the Default – Category Blocklist for the Connect/CertVerify cycle) but not correctly integrated with the ruleset.

            A week ago (I had to close the case because it was nearly 22h30 and I had to prepare for a trip to another site), case 4-17646339299.  The tech diagnostic the whole connection and arrive by himself to the correct conclusion (that I didn’t understood at that point) but he evidently didn’t know about Doc-4810. 


            I must say that I didn’t realized until yesterday that with each cycle, we are going across the whole ruleset (except when reaching a Block, Stop Rule Set and Stop Cycle).  My request was going through the SSL Scanner so, URL.Path value was supposed to be available…  And the rule tracing was driving me crazy…  Why didn’t it match on the whitelist rule!!!


            Ok, I know a little bit more now…