R80.20 HTTPS Inspection Bypass for Office365

[Eric_Knopp]

Good morning,

Here's our situation. We'd upgraded from R77.30 to R80.10 a couple months ago to take advantage of new features and to implement HTTPS Inspection, which we'd been told would be a more stable experience. Once we'd upgraded and during testing of HTTPS Inspection, we found our general O365 experience to be lacking. Microsoft recommends not to inspect that traffic, to have the cleanest connection between client and their servers.

We were going to apply the SK119562 Hotfix to our R80.10 Take 112 environment to take advantage of the Dynamic Objects, but ran into issues. Lo and behold, R80.20 went GA, so we changed our tact to upgrading to R80.20. We found the Updatable Objects for O365/Azure, and thought we could use those in our Bypass Rules. We've been told that those can only be used in Access Policies. Which is a shame, as this is exactly what we need.

1. Should we just use the Dynamic Objects in the Destination column in HTTPS Inspection rules, forgetting about these new "Updatable Objects"?

Unfortunately we have tried employing these Dynamic Objects in R80.20 and get this error.

2. Does R80.20 just work better with Office 365 and there is no need for a specific Bypass Rule?

3. Any other suggestions/solutions?

I cannot believe that this would not have been thought about during the EA period for R80.20, especially as this SK119562 Hotfix was made available.

Regards,

Eric

[PhoneBoy]

I believe the plan is to support those updatable objects in the HTTPS Inspection policy, but it's not supported currently.

It's possible this SK may also still be relevant (even though it mentions R77.20): Bypass for Office 365 in R77.20 HTTPS Inspection policy 

[Stuart_Green]

It was picked up during the EA process, particularly with the new Updatable Objects in R80.20 being so vital to getting O365 to work.  There is a JHF coming to support this but no estimate on timescale.  It's a bit of a nightmare to add in the objects for O365 within the HTTPS Inspection policy but that seems to be the only way to do it at present.  It has to be a source/destination bypass rule within the HTTPS Inspection policy otherwise the first packet is inspected to identify the application which breaks the connection to O365.

[Meital_Natanson]

Hi,

 Unfortunately, updatable objects are not supported in HTTPS Inspection in R80.20.

You can sumbit RFE thru your SE to get support of O365 in HTTPSI policy in R80.20

 Thanks,

Meital 

[phlrnnr]

Does Checkpoint have a best-practices document / whitepaper that explains how they recommend successfully deploying Office 365 services behind their Gateway?  With so many customers making this migration to O365, this would be very helpful. 

If no document exists, it may be beneficial to include best-practices for customers that are "all in" (use the heavy inspection blades + https inspection), "mostly in" (use heavy inspection blades, not https inspection), or FW-only customers.

It may also differ by code version, aka Updatable objects in R80.20,  or some other method in previous versions.

Thanks for your consideration!

[PhoneBoy]

I assume you mean clients behind your gateway

If you're using HTTPS Inspection: How to allow Office 365 services in Application Control R77.30 and above 

If you're not using HTTPS Inspection but using R80.20, you can allow access to the Office 365 Services in your Access Policy:

[phlrnnr]

Yes, I meant clients behind the GW that are connecting to O365, thanks 

So, for now, if using HTTPS inspection, use App Control and don't try to bypass HTTPS (even though MS says to do so).

In the future, if Updatable objects can be used in HTTPS bypass rules, it may make sense to then allow the updatable objects in access control policy, and bypass HTTPS inspection for those same objects.

Thanks, this is helpful info.

[Alessandro_Marr]

hello all, any news about a official best pratices doc or whitepaper from Checkpoint?

[Dor_Marcovitch]

they still did no implemented the dynamic objects for HTTPs Inspection policy so i don't believe 

[Alessandro_Marr]

Dor, did you have implemented https inspection on r80.20?  the kernel parameter enhanced_ssl_inspection is on or off?

[Stuart_Green]

This has been an issue for some time.

The way we have had to implement the bypass is to import objects into the SMS via an API call and then use these objects within the HTTPS Inspection policy.  That's been the only way to bypass HTTPS Inspection.  If it isn't bypassed, there are no end of issues with authentication services as the first packet always gets inspected and that breaks trust.

[HristoGrigorov]

I find importing gazillions of IPs crazy, impractical and really frustrating for end-users where every day something stops to work because M$ changed their IP range or because of the way HTTPS-I is currently implemented. 

So, CheckPoint, please come up with an easy-to-deploy solution for this for all firmware supporting HTTPS-I (not only R80.20). I know this is partly not a vendor problem but it can only be properly solved by you.

Being polite I will skip my comments on the way M$ forces FW admins to compromise security for their online services to work.

[Chris_Thuys]

Hi We have the same issue. we are currently doing the bypass by creating a custom Office365 Application/site.

It contains  6 urls and seems to have solve the main problem for us.

currently we have in the list

I hope this helps.

[Bernhard_Sayer]

Hi!

Are there any news regarding using domain objects in HTTPS inspection in R80.20?

BR,

Bernhard

[Gregory_Link]

Any update on this?

[Andrey_Kuzmenko]

Any News?

[PhoneBoy]

I am not aware of any specific plans to use Domain Objects in the HTTPS Inspection policy.
That said, we should see some improvement in upcoming releases.

[Gera_Dorfman]

We plan supporting it in R80.40 planned for the end of this year, and we're looking for EA customers for EA program to start in 2 months.