Necessity of using HTTPS Inspection

[Matlu]

Hello, team.

One question, 

Is it really necessary to use HTTPs Inspection, when I activate the APPC+URLF+Content Awareness blades?

My question is based on the fact that I only have these blades active now, and I am "exploiting" the virtues of APPC+URLF basically, but for some reason, the traffic does not "behave" as we want.

For example, we have created a rule to block the page cnn.com, this we have done with a "Custom Application/Site", where we put the domain like this:

*.cnn.com*

But for some reason, the Firewall, does not block the page, and continues to allow it.

Other particular pages have the same behavior (they should be blocked, and they are not blocked).

That's where I wonder "why" this is happening.

Is it a problem of the blades?

Is HTTPS Inspection really necessary here?

Can someone clarify the doubt, please.

Regards

[the_rock]

Bro, this was already answered many times before ; - )

No, its NOT mandatory, but additional filtering/inspection wont be performed through TP blades. Now, here is the thing. As fas as blocking pages, they should be blocked, but you would never see the actual block page as https inspection is not enabled, so user may see page is reset or page cant be displayed error. I actually verified this in my lab many times.

Andy

[Matlu]

Then,

To be us (as administrators) 100% sure that the pages are being blocked, based on our created rules, is it necessary to enable the HTTPS Inspection, and install this certificate on the PCs of the users of our network?

Indeed, based on your comment, the pages are still showing as allowed, and from time to time, we observe that the page "refreshes" itself, and leaves us many doubts. LOL

Cheers 🙂

[the_rock]

Yes, thats right, for pages to be blocked PROPERLY, you need https inspection.

Btw, IF inspection is off, pages should still be inaccessible(thats if url filtering is blocking right categories), so you may need to look into that why they are allowed.

Andy

[Matlu]

Friend,

Does it offer any advantage, to block domains of web pages, using "DOMAIN" objects, instead of using "Custom Applications/Sites"?

I understand according to the theory, that the DOMAIN object, pulls up to 10 subdomains, and only depends on the Firewall blade, right?

I can in any case, migrate a rule, to stop using DOMAIN object, and use the "CUSTOM APPLICATION/SITE" (which I understand, works with the APPC+URLF blades).

Is it feasible to perform this practice?

Cheers 🙂

[the_rock]

Sorry, not sure I understand what you mean, apologies. blade has absolutely nothing to do with domain/custom site difference, but everything to do how traffic is inspected.

Andy

[Matlu]

I guess I didn't know how to explain.

We have a website which is: *.gob.pe

This website, currently, the client has it working on a firewall rule, but using FQDN (Object Domain), and I wonder, if using it this way, offers 100% efficiency, to control the access of users to this particular domain?

Or in your experience, would you rather use the Custom Application/Site to be able to "leverage" the APPC+URLF blades that are already enabled in the Firewall.

I hope now my doubt is clearer. 🙂

[the_rock]

Can you send a screenshot of how you have it configured? Personally, I ALWAYS use custom app group, find it works 100% of the time.

Andy

[Matlu]

It is something like this.

This GW, has already enabled the APPC+URLF blades.

So, I think it would be better to start using the "Custom Application/Site" option, right?

Because as the rule stands, the page (main domain and subdomains) that involve ".gob.pe", are still blocked, and what we are looking for, is to "allow" the consumption of those pages.

[the_rock]

That works, but I ONLY use that if I know fqdn, then its fine, otherwise, I stick with custom site. Makes sense?

Either way, you got it bro 🙂

Andy

[Bob_Zimmerman]

I spent some time earlier this year figuring out the right way to build the matching expressions for Custom Application/Site objects. You may find the results useful.

HTTPS Inspection is absolutely needed for deep inspection like IPS. The firewall can't inspect what it can't see. TLSv1.3 also adds the ability to negotiate anonymous encryption before authenticating the site, so you may need HTTPS Inspection to be able to filter TLSv1.3 traffic with URL Filtering.

[the_rock]

Super helpful @Bob_Zimmerman 🙌