break HTTPS Domain Filter for HTTPS traffic

Zyxel_James

Hello @PeterUK

For your information, 

In the content filter profile, Trusted Web Sites and Forbidden Web Sites need to be fully matched to the domain, and Blocked URL Keywords only needs to be matched with the keyword. For example, if you want to block grc.com, you need to put "www.grc.com" into the Forbidden websites, instead of "grc.com" because grc.com is not fully matching to the website domain.

You may test with the profiles below

Profile1 "grc_w_wildcard" has a forbidden website - *.grc*.com

Profile2"grc_wout_wildcard" has a forbidden website - grc.com

Profile3 "www_grc_com" has a forbidden website - www.grc.com

Profile4 "block_keyword_grc" has a blocked URL Keywords - grc.com

and you will find that only Profile2 "grc_wout_wildcard" is not blocked.

Usually, users add the wildcard to the forbidden websites, and we also recommend it. If you don't want to use a wildcard, please use the Blocked URL keyword feature, thank you.


James

PeterUK

Its not the case that grc.com will not block grc.com but that if used you go to grc its not blocked then use profile with forbidden *.grc*.com grc will not be blocked because the profile with forbidden grc.com breaks the content filter until you use debug content-filter https-domain-filter cache flush.

So first I show grc.com being blocked with *.grc*.com profile grc3 then I change to profile grc4 and grc.com is allowed I then change back to profile grc3 grc.com is still allowed then I do debug content-filter https-domain-filter cache flush grc.com now is blocked.

Zyxel_James

Hello @peterUK

According to your clip, grc4 has a forbidden website without wildcards - grc.com, right?

As I said, the website needs to be fully matched to the domain you put into the forbidden websites. grc.com won't be blocked because grc.com is not fully matched to the domain www.grc.com.

Let me explain by your steps.

1. apply profile "grc_w_wildcard" which forbids website - *.grc*.com

>> grc.com is blocked as we expected.

2. apply profile "grc_wout_wildcard" which forbids website - grc.com. (this step same as your grc4)

>> grc.com is not blocked because grc.com is not fully matched to www.grc.com. And the cache is saved in the device and browser.

3. apply profile "grc_w_wildcard" again

>> grc.com is not blocked because the cache exists. 

4. Try "debug content-filter https-domain-filter cache flush and clear the browser cache

>> grc.com is blocked.

PeterUK

Yes but it's the idea that I could not need to use the debug command when I change back the grc3 profile with *.grc*.com to block grc after using profile grc4?

PeterUK

So for anyone following or has the same problem

lets take nordvpn.com or www.nordvpn.com

you don't put in forbids

nordvpn.com

you can put in

www.nordvpn.com

but then this does not block nordvpn.com

you put in

www.nordvpn.com

nordvpn.com

and this does not bock nordvpn.com until you run

debug content-filter https-domain-filter cache flush

Then blocks both

Question is should you need to use the debug? I don't think so...

PeterUK

Done a video of of the problem so if you setup a content filter and then someone goes to a site which you then want blocked the site will still be allowed under the content filter cache until you run the debug command.

Really what should happen is if the site is not blocked or allowed under all the content filter rules it should be allowed (unless action for Unrated pages or action when category is unavailable is set) un-cached this way when you do go and block it then it will block it.   

Zyxel_James

Hello @peterUK

According to your newer clip provided, I'm more sure it's a cache problem instead of an issue although it's not intuition that you need to clear the content filter cache before blocking.

In your clip, nordvpn.com was loaded first, so the device had the cache already. It's no doubt that you need to clear the cache before blocking it again.

James

PeterUK

Yes I get now the cache has to have a allow mainly for the content filter category or it be looking up all the time! so one quick fix would be to have the debug command run on a change to profile.