O365 + HTTPS Inspection + Bypass

[Shahar_Grober]

Hi All,

This issue has been discussed before in 

https://community.checkpoint.com/t5/Policy-Management/R80-20-HTTPS-Inspection-Bypass-for-Office365/m...

but I have a few questions about this issue

I am running App control + HTTPS Inspection in R80.20.

In the HTTPs Inspection policy, I bypassed Microsoft and Office365 services category as in the below rule but traffic to office365 is still inspected by https inspection 

So in order to mitigate it, I had to create a custom category with all Office365 and MS domain

My questions are:

1. Is the fact that the "Microsoft & Office365 services" category do not resolve Microsoft & Office365 URL/domains is a bug in R80.20?

2. is there a way to make it work in R80.20  without adding all Microsoft Domains to the bypass rules (and without waiting for R80.40)? (sk104564 discuss adding manual domains but it refers to R70.20 only. if it is relevant to R80.20 as well, please update the SR)

3. It is discussed that activating "enhanced_ssl_inspection" can help this issue. What is this exactly and how it can be achieved?

[PhoneBoy]

Are you on JHF 117 or above?
You need that for SNI support, which should make the simple “easy” rule work.

[Shahar_Grober]

H PB,

I didn't upgrade yet to JHF 117 but I am willing to try. Is there an SK or any documentation about it?

Whitelisting all MS domains is tedious. They have 20 different domains for each service they offer.

[PhoneBoy]

There's not much on it other than what's said in the R80.30 release notes.
Basically it enhances the certificate matching used for "light" inspection to also include support for SNI.

[John_Fenoughty]

PhoneBoy hinted towards it but the reality needs a stronger statement (IMHO): upgrade to R80.30 - it properly fixes this!

I have O365 on various sites and it's been pretty much impossible to do anything with an expectation of 100% success other than a complex exclusion from HTTPS inspection using the Microsoft IP subnet based destinations as a HUGE group of networks which we update weekly from the published Microsoft list of O365 subnets just like you have had to do.

....until R80.30!

The SNI and other really effective changes Check Point have made from R80.20 to R80.30 in HTTPS inspection make it a genuinely realistic option...make sure you're sitting down here...to do HTTPS inspection on Office 365 traffic!

The enhanced_ssl_inspection parameter is now (at r80.30 level)  completely irrelevant and ignored by the kernel.

For example, I support a site with HTTPS fully enabled, we're rolling out O365 and all I have done is allow the Application Microsoft & Office365 Services for all users. I have tested quite thoroughly for all of the main applications and everything works, with the exception of file transfer within a Teams chat (which never used to be able to work in Skype with HTTPS inspection either - I'm guessing it's a similar issue) but most corporates are not at all bothered that this particular backdoor is closed, albeit accidentally.

I have a major issue with the ability to access personal outlook.com and I'll be posting separately about that but for your needs, once upgraded to R80.30 you can drop loads of HTTPS inspection overrides and expect success! Do expect to have to keep HTTPS inspection overrides for Dropbox and Box (there's a full list in usercenter) which use sticky certificates and craplicaitons by such companies as Fedex and DHL which just break if you look at them in the wrong way.

[PhoneBoy]

In our HTTPS Inspection Best Practices sessions we've done in local user groups, we make exactly this point. 😁

[Kaspars_Zibarts]

This is really good news as I hate MS / O365 network requirements - pls don't proxy us, pls don't intercept, but do filter on URLs with wildcards... Worst security setup ever

[Steve_Payne1]

Hi john

regarding your implementation,   is the picture below, similar to what you implemented?

[Shahar_Grober]

Good info put here John!

It is sufficient reason upgrade to R80.30

I wish there was an SK with all services which have issues with HTTPS inspection. I guess it is impossible to test all but at least put a list of high usage apps like box/dropbox/O365 that can break using HTTPS inspection and how to bypass them

[PhoneBoy]

We have such an SK: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Shahar_Grober]

good stuff.
So if I get it correctly, HTTPS Inspection bypass is working on R80.30 with the pre-defined apps mentioned in the SK?
and on R80.20 and lower versions, I have to create a custom app with domain names to do the HTTPS Inspection Bypass?

[FedericoMeiners]

@John_Fenoughty 

Hope you are doing fine. Would you mind pointing which SKs do you used to do proper overrides on applications? Do you use the bypass action?

There are some applications that i still have issues with even in R80.30, the only way to make them work is probe bypass but... 🙂

I think that the real killer will be the granular HTTPS inspection policy on R80.40

[BCServerTeam]

So, I have read through this entire thread, and I'm a but confused as the "Microsoft & Office365 Services" Tag does not appear to be working for me. I have created a separate custom App/Site list made from my own observations of the logs and from Microsoft's website of addresses and IP's that need to be allowed. My list works, but the built in "Microsoft & Office365 Services" does not.

I'm using R80.40. Any ideas why this might be a problem?

Thanks.

[Cyber_Serge]

in R80.40 you can use updatable object for o365 services for that. There are several updatable objects all related to different Microsoft services so maybe you have to figure out which one you use and pick the right one.