cancel
Showing results for 
Search instead for 
Did you mean: 
DBO
Level 9
Report Inappropriate Content
Message 1 of 3

Whitelisting link with URL.Path

Jump to solution

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 Solution

Accepted Solutions
McAfee Employee jscholte
McAfee Employee
Report Inappropriate Content
Message 2 of 3

Re: Whitelisting link with URL.Path

Jump to solution

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,

Jon

View solution in original post

2 Replies
McAfee Employee jscholte
McAfee Employee
Report Inappropriate Content
Message 2 of 3

Re: Whitelisting link with URL.Path

Jump to solution

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,

Jon

View solution in original post

Highlighted
DBO
Level 9
Report Inappropriate Content
Message 3 of 3

Re: Whitelisting link with URL.Path

Jump to solution

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…

Ruleset.png

More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator
  • Community Help Hub

      New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

    • Find Forum FAQs
    • Learn How to Earn Badges
    • Ask for Help
    Go to Community Help

    Join the Community

      Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

    • Get helpful solutions from McAfee experts.
    • Stay connected to product conversations that matter to you.
    • Participate in product groups led by McAfee employees.
    Join the Community
    Join the Community