- Products
- Learn
- Local User Groups
- Partners
-
More
Celebrate the New Year
With CheckMates!
Value of Security
Vendor Self-Awareness
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
Mobile Security
Buyer's Guide Out Now
Important! R80 and R80.10
End Of Support around the corner (May 2021)
Hi All,
This issue has been discussed before in
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 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.
Hi john
regarding your implementation, is the picture below, similar to what you implemented?
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
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY