HTTPS Inspection not working as expected

[Luis-arusd]

Hello, we have recently migrated to Checkpoint for our firewall and we are having many issues with HTTPS inspection. 

Here is our setup:

We want to inspect packets going to docs.google.com or sites.google.com so that we can block specific URLs and Google sites from the student network and we do not decrypt any other sites.  The problem we have is that when we try to enroll a new chromebook, it needs to connect to either tools.google.com, clients1.google.com, clients2.google.com, clients3.google.com or clients4.google.com and these packets are being decrypted even though there is no rule in our firewall telling it to decrypt.  Attached to this post is a screenshot of what the logs show and I highlighted that the device is going to clients2.google.com.  The destination shows docs.google.com which would explain why it was decrypted as we decrypt this subdomain, but the device was not going to that subdomain so this rule should NOT have applied.

Has anyone else experienced this?  My guess here is that perhaps there is some reverse lookup that is being done on the destination that is causing this problem.  We just migrated from Palo Alto Networks firewall and we were not having this problem.

Any help will be greatly appreciated.

[PhoneBoy]

What version/JHF are you running?
Note the decision to decrypt is based on either the certificate CN or client SNI, the later of which is verified by the gateway prior to letting the client connect.

If we can't see the SNI (e.g. because it's non existent or encrypted SNI is used), then we'll use the CN of the certificate, which with Google, is often a wildcard certificate. 
Which makes it very difficult to match specific Google sites.

You may wish to create FDQN domain objects (instead of using a Custom Application/Sites) for the two Google domains in question and use that in your HTTPS Inspection policy in the destination field.
That assumes the gateway and your clients will receive exactly the same results from the configured DNS resolver.

[Luis-arusd]

Hi, Thank you for your response,

We were using FDQN domain objects and then switched to Custom Application/Sites but that did not fix the issue.  We are running Gaia version R81.20.  I understand what you are saying that it is looking at the certificate which I can see as an advantage to make sure you are going to the right place, however, in today's day and age, many sites may have this issue as they are hosting multiple sub-domains and we only need to decrypt a specific one and the firewall should simply ignore decryption if the URL that the device is going to is not the one specified in the Custom Application/Sites or if it is the FQDN in the rule regardless of what the website/certificate responds with.  This behavior we did not experience in the Palo Alto Network firewall and I just finished running a test on my FORTINET firewall and it did not have this problem either.  It did not try to decrypt packets that were not specifically going to docs.google.com or sites.google.com.

I attached two more screenshots showing both rules and what the Custom Application/Sites was setup.  We disabled the FQDN one after creating the one with the Custom Applications/Sites.  But now, the decryption is broken and we are not decrypting any packets to docs.google.com or sites.google.com

[PhoneBoy]

Do the DNS requests made by the clients traverse the gateway at all?
This is one of the ways we do IP/FQDN mapping for these objects. 
See: https://support.checkpoint.com/results/sk/sk161612 

You might try debugging wstlsd: https://support.checkpoint.com/results/sk/sk105559 
TAC may be required to assist further: https://help.checkpoint.com 

[Luis-arusd]

Thank you for your reply.  I will take a look at those SKs and see if they help.  I put in a request to TAC and the person who helped me was not able to resolve the issue so he is escalating it internally but I thought maybe someone had experienced this issue before and could help.  Once I get this resolved, I'll update this post but if someone else has seen/experienced this.  Please reply and let me know how it was fixed.